Skip to main content

The Identity at the Core

The Definitive Chronicle of Identity & Access Management

CVE-2026-87337: Unauthenticated HTTP Attack Puts Oracle Access Manager at Critical Risk

A CVSS 10.0 flaw in Oracle Access Manager 12.2.1.4.0 and 14.1.2.1.0 lets unauthenticated attackers read and modify all OAM data over plain HTTP.

By Paulo Barrilli
2 min read2 views0 comments

A maximum-severity vulnerability has been disclosed in Oracle Access Manager, affecting versions 12.2.1.4.0 and 14.1.2.1.0. According to the NVD entry for CVE-2026-87337, an unauthenticated attacker with network access over HTTP can fully compromise the Authentication Engine, gaining the ability to read, create, delete, or modify all data OAM can touch. The scope change rating means downstream systems protected by OAM are also in play.

Let's be direct about what this means operationally. OAM is a gateway product. It sits in front of your applications and makes authentication decisions on behalf of everything behind it. A CVSS 10.0 here isn't an abstract score, it's an attacker walking through your front door, grabbing your session tokens, and then having a quiet look around every app your workforce or customers log into. No credentials required. No user interaction. Just network access and the right HTTP request.

The control that failed conceptually is pre-authentication input handling in the Authentication Engine itself. We don't have the full technical breakdown yet, but a network-exploitable, no-privilege-required flaw in an auth component almost always comes down to one of a short list: unauthenticated endpoint exposure, broken deserialization, or malformed request handling that bypasses an assumed authentication check. Any of those should have been caught in code review or fuzz testing before shipping. The scope change flag tells me the OAM session or policy store is reachable post-exploitation in a way that crosses trust boundaries into connected applications.

If you're running either affected version, this is a patch-first, questions-later situation. While you're waiting for a maintenance window, you can reduce exposure by restricting HTTP access to the OAM Admin and runtime ports to known internal source IPs only. WAF rules won't reliably stop something this low-level in the auth stack, so don't lean on them as your primary control here. Also audit what systems rely on OAM for SSO or policy enforcement because your blast radius calculation depends on that list.

Get the Oracle patch applied this week. If you can't patch immediately, network-layer access controls to the OAM listener are your best short-term move, not application-layer mitigations. Once you're patched, pull your OAM access logs for the past 30 days and look for anomalous authentication traffic, particularly requests that succeeded without matching a known user pattern. If something already got through, you want to know before it becomes a larger problem.

#cve#sso#pam#breach#identity-governance#policy
Share:XLinkedInFacebook

Be the first to comment

Members only: sign up if you have something worth saying.

Want to weigh in? Sign in or create a free account.

No comments yet.