Oracle WebCenter Content CVE-2026-35319

No special conditions - remote unauthenticated exploitation over HTTP against default configurations of Oracle WebCenter Content 12.2.1.4.0 and 14.1.2.0.0 Content Server, per Oracle's explicit 'easily exploitable' characterization and the AV:N/AC:L/PR:N/UI:N vector. The only practical limiting factors are network reachability of the Content Server HTTP port from the attacker and the target running one of the two named versions; deployments behind VPN/zero-trust ingress, or already patched to the June 2026 CPU level, are not exploitable. There is no user interaction, no authentication, and no non-default configuration requirement implied by Oracle's description.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H represents the worst practical combination: network-reachable, low-complexity, no auth, no user interaction, with full confidentiality, integrity, and availability impact - Oracle explicitly describes it as 'easily exploitable' resulting in 'takeover.' This CVE is not listed in CISA KEV and no public POC is referenced, and EPSS data was not provided, so real-world exploitation pressure is currently unknown despite the maximal CVSS. Oracle Fusion Middleware CPU bugs of this profile historically attract exploit development within weeks of disclosure (CVE-2023-22515, CVE-2021-35587 in WebLogic/Access Manager being recent comparators), so the gap between disclosure and weaponization should be treated as short. The tag 'Information Disclosure' in the input conflicts with Oracle's own 'takeover' wording and the C:H/I:H/A:H impact set - defenders should trust the CVSS vector over the tag.

An external attacker scans for internet-exposed Oracle WebCenter Content instances on standard HTTP/HTTPS ports, sends a single crafted HTTP request to the vulnerable Content Server endpoint, and gains full control of the application - enabling theft of managed documents, modification of records, and use of the server as a pivot into the Fusion Middleware tier. No credentials, user interaction, or prior foothold are required, and given Oracle's 'easily exploitable' wording, mass scanning is plausible once a POC emerges even though none is publicly identified at time of analysis.