# CVE-2026-111245: Apache OpenEJB authentication context leakage in HTTP server

Source: https://junglewise.ai/threats/cve-2026-111245-after-a-successful-ws-security-usernametoken-authentication-the  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-11-10. Updated: 2026-11-10  
License: CC BY 4.0 with a link back

CVE-2026-111245 · Severity: info · Published 2026-11-10

Apache OpenEJB's standalone HTTP server fails to clear user authentication context after request completion, allowing a subsequent request processed on the same thread to invoke protected methods with a previously authenticated user's identity. An attacker can exploit this thread reuse to gain unauthorized access to Enterprise Java Beans without providing valid credentials.

Technologies: [Apache OpenEJB](https://junglewise.ai/threats/technologies/openejb). Vendors: [Apache](https://junglewise.ai/threats/vendors/apache).

## Quick answers

**Is CVE-2026-111245 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-111245 being exploited in the wild.

**How severe is CVE-2026-111245?** Informational severity, published 10 November 2026.

**Which products and versions are affected?** Apache OpenEJB versions prior to 10.3.0 and 11.0.0-M2.

**Is there a fix for CVE-2026-111245?** Yes: fixed in Apache OpenEJB 10.3.0, 11.0.0-M2. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-111245 attacked?** It is attacked over the network, in a software library.

**Am I affected by CVE-2026-111245?** Check whether you run Apache OpenEJB at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## How to fix

- Fixed in Apache OpenEJB 10.3.0, 11.0.0-M2

## Technical details

When WS-Security UsernameToken authentication succeeds in OpenEJB's HTTP server, the caller identity remains bound to the worker thread after the request completes. A subsequent unauthenticated request routed to the same thread can invoke protected EJB methods using the stale authentication context from the previous request. This is a thread-safety issue in session/identity cleanup that requires no additional authentication from the attacker.

## Affected products

- Apache OpenEJB versions prior to 10.3.0 and 11.0.0-M2

## Timeline

- 2026-11-10: disclosed

## References

- [https://repo.maven.apache.org/maven2](https://repo.maven.apache.org/maven2)
- [https://lists.apache.org/thread/6nr7gp3kxf919mhv2o0yg45t310x5go8](https://lists.apache.org/thread/6nr7gp3kxf919mhv2o0yg45t310x5go8)

## Related threats

- [Apache OpenEJB embedded HTTP server privilege escalation via thread identity reuse](https://junglewise.ai/threats/cve-2026-97888-the-embedded-http-server-does-not-clear-the-security-identity)
- [Apache OpenEJB path traversal in HTTP server](https://junglewise.ai/threats/cve-2026-97881-the-embedded-openejb-http-server-does-not-restrict-static)
- [Apache OpenEJB HTTP server authentication bypass in REST endpoints](https://junglewise.ai/threats/cve-2026-97880-the-embedded-openejb-http-server-dispatches-some-requests-to-rest)
- [Apache OpenEJB HTTP server resource exhaustion](https://junglewise.ai/threats/cve-2026-86531-the-embedded-openejb-http-server-does-not-limit-the-size-of)
- [Apache OpenEJB authentication bypass in embedded HTTP server](https://junglewise.ai/threats/cve-2026-111256-when-jax-ws-or-jax-rs-endpoints-are-published-by-the-embedded)