Loading story…
OpenBao disclosed two high-severity vulnerabilities in its OIDC/JWT authentication flow affecting versions before 2.5.2, both tied to roles configured with callback_mode=direct. CVE-2026-33757 allows a remote phishing-style attack because direct callback logins do not require user confirmation, letting an attacker initiate authentication and trick a victim into completing it for the attacker's session. Because the callback returns to the API and the attacker can poll for token issuance, successful exploitation can expose secrets and enable unauthorized actions, with the flaw tracked as CWE-384.
A second issue, CVE-2026-33758, allows reflected cross-site scripting through the error_description parameter on a failed OIDC authentication page, potentially exposing a victim's Web UI token. OpenBao addressed both flaws in 2.5.2 by adding a mandatory confirmation screen for direct logins and replacing the user-controlled error text with a static message. Organizations using OpenBao were advised to remove roles using callback_mode=direct or enforce confirmation at the identity provider for the Client ID used by OpenBao until upgrades are completed.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
OpenBao released version 2.5.2 to address both vulnerabilities. The update adds a confirmation screen requiring manual user interaction for direct logins and replaces the reflected `error_description` value with a static error message.
A GitHub security advisory disclosed two OpenBao flaws affecting versions before 2.5.2: missing user confirmation in OIDC direct callback mode (CVE-2026-33757) and reflected XSS in OIDC authentication error handling (CVE-2026-33758). Both issues could be exploited remotely in configurations using `callback_mode=direct`.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Two high-severity vulnerabilities in **OAuth2 Proxy** can let unauthenticated remote attackers reach protected upstream resources in specific reverse-proxy deployments. `CVE-2026-34457` affects versions prior to **7.15.2** when OAuth2 Proxy is used with **auth_request**-style integrations such as nginx `auth_request` and either `--ping-user-agent` or `--gcp-healthchecks` is enabled. In that configuration, any request carrying the configured health-check User-Agent can be treated as a successful health check regardless of the requested path, creating an authentication bypass. The flaw is tracked as **CWE-290** and carries a **CVSS 3.1** score vector of `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`. A second flaw, `CVE-2026-40575`, affects OAuth2 Proxy versions **7.5.0 through 7.15.1** when `--reverse-proxy` is enabled alongside `--skip-auth-regex` or `--skip-auth-route`. In those setups, the product may trust a client-supplied `X-Forwarded-Uri` header, allowing attackers to spoof the header so authentication and skip-auth rules are evaluated against a different path than the one actually forwarded upstream. Both issues were fixed in **OAuth2 Proxy 7.15.2**. Recommended mitigations include upgrading immediately, stripping or overwriting `X-Forwarded-Uri`, restricting direct access to OAuth2 Proxy, and narrowing or removing skip-auth rules where possible.
Jun 29, 2026
Multiple high-severity vulnerabilities in **Open WebUI** allow attackers to plant malicious chat content that executes when viewed, leading to theft of JWTs and session tokens from `localStorage`, full account takeover, and compromise of sensitive AI assets. The flaws affect markdown rendering, citation and response iframe handling, and HTML file-serving paths, including cases where attacker-controlled content was rendered with dangerous HTML processing or iframe sandbox settings such as `allow-scripts allow-forms allow-same-origin`. Reported impacts include exposure of DOM data, `indexedDB`, cookies, backend API keys, model parameter files, private databases, and other enterprise AI resources. Several reports warn that if an administrator opens a malicious shared transcript or chat, the attack can escalate from stored XSS to **remote code execution** through Open WebUI's administrative features and Python-based functions or plugins, potentially yielding code execution on the Docker container or local host. The issues were addressed across releases including **v0.6.6** and **v0.7.0** by tightening file ownership checks, removing or making optional same-origin iframe access, and recommending stronger HTML sanitization and restrictive CSP settings; one report also provided a database query to hunt for stored chats containing suspicious `data:text/html` or `javascript:` embed payloads.
Jul 7, 2026
Apache disclosed **CVE-2026-65583**, a low-severity flaw in the Apache CXF OIDC relying-party token validation logic that can cause self-issued ID tokens to be accepted without required claim checks. Missing validation may skip verification of fields such as issuer, subject, audience, time-based claims, and `sub_jwk` binding, creating a path for authentication bypass with crafted tokens in deployments that accept self-issued ID tokens. The issue affects the Apache CXF module `org.apache.cxf:cxf-rt-rs-security-sso-oidc` in versions `4.2.0` before `4.2.3`, `4.0.0` before `4.1.8`, and the `3.6.x` line before `3.6.12`. Apache said self-issued ID tokens are **not accepted by default** in the validator, but advised users to upgrade to **4.2.3**, **4.1.8**, or **3.6.12** to remediate the vulnerability. Guanping Zhang was credited with reporting the issue.
Aug 7, 2026