Enterprise Java middleware gaps can still enable pre-auth RCE

At a glance

What this is: This research shows that enterprise Java middleware can still be turned into pre-auth remote code execution through routing mismatches, filter bypasses, shared keys, and execution sinks.

Why it matters: It matters to IAM, PAM, and platform teams because unauthenticated middleware exposure can bypass identity controls entirely and turn internal trust boundaries into attacker entry points.

By the numbers:

• Novee Security researchers uncovered 12 vulnerabilities across major Enterprise Java platforms.

👉 Read Novee's analysis of pre-auth RCE in enterprise Java middleware

Context

Enterprise Java middleware is often treated as internal plumbing, but that assumption breaks when routing logic, authentication filters, and execution sinks do not agree on what is public and what is protected. In this case, pre-auth RCE emerged because attacker-controlled requests could cross boundaries that the application believed were still internal. The primary keyword here is enterprise Java middleware, and the issue is not one bug class but the seam between several.

For identity and access teams, this kind of flaw matters because it can bypass authentication, token validation, and privilege controls before IAM ever gets involved. When a middleware layer exposes internal services, the security model depends on the correctness of request routing, session handling, and trust boundaries. That is why enterprise Java middleware security belongs in the same governance conversation as secrets management, service authentication, and workload identity.

The article’s two exploit chains are typical of large Java estates rather than exceptional. Long-lived platforms accumulate routing shortcuts, legacy filters, and execution primitives that were never designed for hostile input, which makes chainable pre-auth issues more likely than isolated bugs.

Key questions

Q: What breaks when enterprise Java middleware relies on inconsistent routing and filter logic?

A: When routing, filter exclusions, and dispatcher rules disagree, an attacker can steer a request from a public entry point into an internal-only surface. That can collapse the boundary that authentication was meant to protect and expose deserialisation or execution sinks before credentials are even checked. The failure is architectural, not just a single bad line of code.

Q: Why do shared signing keys create such a serious authentication risk?

A: A shared signing key lets one secret authorise multiple trust domains, so compromise or default reuse can bypass login controls and reach privileged functions. If the application then trusts claims without strong validation, forged tokens can impersonate high-value users and carry attacker-controlled data into dangerous code paths. Secrets governance and identity validation fail together.

Q: How do you know if a Java application is exposed to pre-auth RCE risk?

A: Look for untrusted input reaching deserialisers, template engines, expression evaluators, or callback handlers before authentication completes. Also check for path canonicalisation mismatches, loose filter matching, and missing dispatcher coverage. If the application uses any of those patterns on reachable routes, assume the control boundary is weaker than it appears.

Q: Who is accountable when middleware trust boundaries fail in production?

A: Accountability usually spans application owners, platform teams, and identity governance teams because the failure crosses routing, authentication, and runtime execution layers. From a governance perspective, teams should map which service owns canonicalisation, which team owns token issuance, and who is responsible for removing exposed execution sinks. That clarity matters before incidents do.

Technical breakdown

How routing mismatches turn internal Java paths into external reachability

The BadBonita chain shows how a request can be interpreted differently by separate layers in the same stack. One component treats the path as still inside a public API, while another normalises it into a traversal into /serverAPI/. When filters use partial matching and dispatcher rules omit forward handling, the application creates a route from unauthenticated entry to an internal-only surface. The security failure is not merely path traversal. It is inconsistent canonicalisation across the parser, servlet container, and access controls.

Practical implication: audit dispatcher coverage and path normalisation together, because either control alone can leave internal endpoints reachable.

Why shared signing keys and claim trust create pre-auth execution paths

In the OFBiz chain, a hardcoded JWT signing key allows token forgery, and the application then trusts claim values as if they were already authorised session data. That is a classic trust-boundary failure: one secret authorises multiple functions, and an attacker can move from token creation to admin session creation without any password or interactive approval. Once the forged identity reaches a rendering or callback path, attacker-controlled claims can flow into code evaluation. The problem is not JWT itself. The problem is reusing a signing key as both identity proof and access gate for unrelated features.

Practical implication: separate signing domains, rotate defaults, and treat claim content as untrusted until after explicit validation.

Why deserialisation and template engines remain high-risk execution sinks

XStream deserialisation and Groovy template evaluation are dangerous because they convert data into executable behaviour. When an application exposes either sink before authentication, it no longer needs an attacker to compromise an identity first. The code path itself becomes the exploit. Allowlist-based serializer controls and removal of unsafe evaluation primitives are stronger than denylist filters, because denylists rarely cover every gadget, expression form, or alternate import path. In enterprise middleware, the safe design choice is to minimise dynamic execution near externally reachable request paths.

Practical implication: remove or isolate dynamic execution points, and enforce strict type or expression allowlists on any unauthenticated request path.

Threat narrative

Attacker objective: The attacker’s objective is unauthenticated remote code execution on enterprise Java platforms by turning middleware trust seams into an execution path.

1. Entry occurs when an unauthenticated attacker reaches an internal middleware surface through routing and filter inconsistencies, or forges a trusted JWT using a hardcoded signing key.
2. Escalation happens when the application accepts the attacker as authenticated and routes the request into a deserialisation or template-evaluation path that was never meant for hostile input.
3. Impact is pre-auth remote code execution inside enterprise Java platforms, giving the attacker code execution without credentials.

NHI Mgmt Group analysis

Enterprise Java middleware remains a trust-boundary problem, not just a vulnerability-management problem. The article shows that pre-auth RCE emerges when routing, authentication glue code, and execution sinks all make different assumptions about what is internal. That means scanning for isolated CVEs is insufficient when the real weakness is the interaction between layers. Security teams should treat middleware trust boundaries as first-class attack surfaces.

Hardcoded signing keys create a shared-authentication failure mode that IAM teams should recognise immediately. In the OFBiz chain, one static secret authorises multiple functions and collapses identity separation between login and callback flows. That is a secrets governance issue as much as an application flaw, and it aligns with OWASP-NHI concerns around exposed or reused credentials. Practitioners should expect one key to fail more than one trust domain unless it is explicitly segmented.

Pre-auth execution sinks are the real control breakpoint in mature Java estates. XStream and Groovy are not the root cause on their own, but they become decisive when reachable from unauthenticated paths. That makes allowlist-based deserialisation, strict request routing, and removal of dynamic evaluation the relevant control themes. The practitioner conclusion is simple: if untrusted input can reach code execution, the front-door controls have already failed.

Parser differentials are a named concept worth tracking across enterprise applications. When one component canonicalises a request one way and another component interprets it differently, attackers can steer traffic into protected paths without obvious exploitation markers. This is especially dangerous in platforms where servlet dispatchers, reverse proxies, and application filters all participate in access decisions. Teams should map canonicalisation consistency as part of application trust review.

Middleware security debt accumulates in the seams between identity and runtime control. The article demonstrates that authentication, routing, and execution can all be individually defensible and still fail when chained. That is why identity programmes need visibility into how applications validate tokens, protect internal APIs, and constrain dynamic execution. The field implication is that NHI-style secret governance and application runtime hardening are converging control problems.

What this signals

Parser differentials are a reminder that runtime reachability still outpaces many application governance models. Security teams should assume that proxy, servlet, and filter logic will disagree somewhere in a large Java estate, and that disagreement can become a control failure. The practical response is to test canonicalisation consistency as a security control, not just a development concern, and to pair it with review of internal API exposure.

Middleware exploitability increasingly intersects with identity governance because credentials and tokens are often the first exploitable trust artefact. Even when the primary flaw is routing or template evaluation, the path to impact frequently involves forged JWTs, hardcoded secrets, or over-trusted claims. That means IAM and NHI teams should include application auth glue code in their review scope, especially where token signing keys or service credentials live in code or config.

Execution-sink exposure should now be treated as a high-priority indicator of security debt in enterprise platforms. If a public route can reach deserialisation or expression evaluation, attackers do not need to defeat the rest of the control stack. Teams should prioritise route hardening, secret segmentation, and code removal over compensating controls that merely try to detect exploitation after the fact.

For practitioners

• Audit dispatcher coverage on internal servlet routes Verify that security constraints cover forward, include, and error dispatch types on any path that can reach internal APIs. Missing dispatcher handling is a common way for protected middleware endpoints to become reachable through alternate routing paths.
• Replace partial-match URL filters with exact path checks Review authentication and CSRF exclusions that rely on substring matching or loose pattern checks. Exact matching reduces the chance that crafted paths can satisfy a filter while still routing to a protected backend endpoint.
• Eliminate shared signing keys across auth flows Treat JWT and callback signing keys as separate trust domains, rotate any default or repository-shipped secret, and confirm that one token key cannot authorise multiple independent functions.
• Remove unsafe evaluation primitives from externally reachable flows Identify deserialisation, template expansion, and expression-evaluation paths that are reachable before authentication. Where removal is not immediate, constrain them with strict allowlists and isolate them from request paths that accept attacker input.

Key takeaways

• Enterprise Java middleware still exposes pre-auth RCE paths when routing, filter logic, and execution sinks disagree about trust boundaries.
• The research identified 12 vulnerabilities, showing that these failures are still present across mature platform ecosystems rather than confined to one product class.
• Practitioners should focus on dispatcher coverage, exact path validation, secret segmentation, and removal of unsafe evaluation primitives before attackers turn internal plumbing into code execution.

Key terms

• Parser Differential: A parser differential is a security weakness that appears when two components interpret the same input differently. In web systems, that mismatch can let an attacker bypass validation, smuggle requests, or alter security decisions because the layer that checks input is not the layer that ultimately uses it.
• Output Sink: An output sink is any downstream destination where an agent's response can cause a real effect, such as a rendered UI element, webhook, message queue, or database write. In agentic systems, sinks are often more important than the text response itself because they are where model output becomes action.
• Private Signing Key: A private signing key is the secret material that creates a trusted software signature. If it is exposed or copied, an attacker can sign malicious code as if it were legitimate, which is why key storage, access control, and hardware-backed protection are central governance requirements.
• Dispatcher Coverage: Dispatcher coverage describes which request types and forwarding paths are protected by a security constraint or filter. If forward, include, or error dispatches are omitted, an attacker may be able to bypass protections by reaching the same endpoint through an alternate route.

What's in the full article

Novee's full article covers the exploit mechanics this post intentionally leaves for the source:

• Line-by-line walkthrough of the Bonita and OFBiz exploit chains, including the exact request paths and token flow
• Code-level detail on parser differentials, regex bypasses, and the dispatcher mismatch that enabled unauthenticated reachability
• Proof-of-concept exploitation notes and the specific vulnerable components identified across the four audited platforms
• The coordinated disclosure context and the affected-project remediation posture described by the researchers

👉 Novee's full article covers the Bonita and OFBiz attack chains, including the exact execution paths and vulnerability breakdowns.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need stronger control over machine-facing access. It is designed for security and identity teams that must connect governance decisions to real operational risk.