Enterprise Java middleware gaps can still enable pre-auth RCE

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Novee's blog post: Enterprise Java middleware still contains pre-authentication paths that can chain routing mistakes, authentication bypasses, and execution sinks into remote code execution.

Why it matters: IAM and security teams need to treat internal middleware boundaries as attacker-reachable, because exposed routing, shared signing material, and unsafe deserialisation or template evaluation can bypass front-door controls entirely.

Context

Enterprise Java middleware sits between public entry points and internal services, so control failures there can turn a supposedly authenticated boundary into an unauthenticated execution path. The central issue is not a single bug class, but the way routing, dispatch, signing, and evaluation logic interact when middleware trusts that only legitimate traffic can reach it.

This article is materially relevant to IAM because the chains abuse authentication glue, shared signing keys, and internal service assumptions rather than breaking a perimeter firewall. In both examples, access control fails at the boundary where request handling hands attacker-controlled input to code that assumes the caller is already trusted.

Key questions

Q: What breaks when enterprise Java middleware exposes internal routes before authentication?

A: The access boundary breaks because filters, dispatchers, and route normalisation no longer agree on what is public and what is internal. Once forwarded or rewritten requests can reach privileged servlets, authentication controls stop protecting the execution path and an attacker can pivot from a harmless-looking URL to a backend sink.

Q: Why do shared signing keys and trusted claims increase pre-auth RCE risk?

A: They collapse trust between authentication and execution. If the same key signs multiple features, or if a signed claim is later fed into a template or evaluator, a forged but valid token can carry attacker-controlled input straight into code execution. The signature proves integrity, not safe downstream use.

Q: What do security teams get wrong about deserialisation and template engines?

A: They often treat them as implementation details instead of execution boundaries. Deserialisers and expression evaluators are risky because they transform input into objects or code, so permissive type handling, unsafe defaults, or denylist-only protections can leave a direct path from request data to execution.

Q: Should teams treat internal middleware surfaces like externally reachable attack paths?

A: Yes. If routing or forwarding can expose an internal API, callback, or rendering surface without the intended authentication checks, then the surface is attacker-reachable regardless of deployment intent. Security reviews should focus on actual reachability, not on whether the team expected the endpoint to stay private.

Technical breakdown

How routing and dispatch mistakes expose internal servlet surfaces

Enterprise Java applications often split public and internal endpoints across filters, servlet mappings, and dispatcher types. When URL normalisation, request forwarding, and filter matching disagree about what a path means, an attacker can smuggle a request from a public route to an internal one. The important point is that the vulnerability is not just traversal syntax or a bad regex on its own. It is the mismatch between components that each make a locally reasonable decision, then collectively expose a protected surface. In Bonita's case, a parser differential, partial-match filtering, and incomplete dispatcher constraints combined to bypass the expected access boundary.

Practical implication: review request routing, dispatcher coverage, and filter logic together, not as separate controls.

Why signed authentication artifacts can become execution inputs

A signed token or cookie only protects integrity if the signing secret is unique, protected, and used for a single trust domain. When the same key is reused across features, or when a trusted claim is later treated as template input, the signature stops being a boundary and becomes a delivery mechanism for attacker-controlled data. That is the deeper failure in the OFBiz chain: authentication succeeded, but the application trusted the claim too far and handed it to a template evaluator. Once a rendering path can expand code-like expressions, the authentication layer no longer limits what the attacker can make the server do.

Practical implication: separate signing keys by trust domain and ensure signed claims never flow into evaluators.

Why deserialisation and template engines are still high-risk execution sinks

Deserialisation engines and expression evaluators are dangerous because they turn structured input into object creation or code execution. Security depends on strict allowlists, constrained types, and the removal of generic execution primitives wherever possible. If a platform relies on permissive type handling, AnyTypePermission-style defaults, or a denylist in front of an evaluator, the control is brittle by design. The article shows the same pattern twice: once through XStream and once through Groovy evaluation. Different technologies, same mistake, attacker data crosses into a runtime interpreter without a strong boundary.

Practical implication: eliminate generic execution sinks or lock them to allowlisted types and contexts.

Threat narrative

Attacker objective: The attacker wants unauthenticated remote code execution by converting middleware trust failures into execution on the server.

1. Entry occurs through malformed but syntactically valid middleware paths that bypass the intended public-to-internal boundary.
2. Credential or trust material is then abused through either a reused signing key or a dispatch path that treats unauthenticated input as authorised enough to process.
3. Escalation happens when the request reaches a deserialiser or template engine that converts attacker-controlled input into executable behaviour.
4. Impact is pre-auth remote code execution on middleware that the application design assumed was internal only.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Middleware trust boundaries are now the real identity boundary. The article shows that a front-door login control is irrelevant if routing logic can carry unauthenticated input into internal code paths. For IAM teams, that means the boundary is not just the authentication system, but every handoff between public requests, signed artifacts, and backend execution. Practitioners should treat middleware reachability as part of identity governance, not just application security.

Shared signing material creates cross-feature privilege collapse. When one key authorises multiple features, the application has already merged distinct trust domains. That design makes token forgery, session impersonation, and downstream privilege abuse much easier to combine into an execution chain. The governance lesson is to scope keys by function and reject any architecture that lets a single secret authenticate and authorise unrelated surfaces.

Pre-auth RCE in enterprise Java is a governance failure, not just a bug class. The critical weakness is the assumption that internal plumbing cannot be reached before authentication. That assumption fails whenever filters, dispatchers, and evaluators are wired without a shared model of trust. Security programmes should audit for that assumption collapse explicitly, because the exploitability comes from composition, not from any one framework weakness.

Expression evaluation is the new soft underbelly of legacy middleware. Template engines, deserialisers, and callback systems often survive because teams treat them as implementation details rather than security-critical execution surfaces. In practice, those surfaces define whether attacker input stays data or becomes code. The practitioner conclusion is to classify any runtime expansion path as a privileged control point and govern it accordingly.

Internal-only is not a security control. The article reinforces a pattern that appears across identity, application, and platform governance: exposure is determined by reachability, not by whether a team intended the surface to be private. Once a middleware path can be invoked from an unauthenticated route, it must be governed like an external interface. That should change how threat modelling, review, and assurance are performed.

What this signals

Routing trust collapse: enterprise middleware fails when path normalisation, dispatcher logic, and authentication filters each make a different decision about the same request. That is the point where an internal service becomes externally reachable, so assurance needs to cover request flow end to end rather than individual controls in isolation.

Middleware teams should assume that any signed token, callback claim, or forwarded request can become an execution input if the application hands it to a deserialiser or template engine. The control objective is not simply to validate input, but to prevent data from reaching a runtime interpreter unless that path is explicitly intended and tightly constrained.

For practitioners

• Audit dispatcher coverage on all protected routes Check servlet and filter mappings for REQUEST, FORWARD, INCLUDE, and ERROR coverage wherever internal services are exposed through middleware. Missing dispatcher types can leave a route protected only on the front door while forwarded requests bypass the intended control.
• Separate signing keys by feature and trust domain Inventory every JWT, session, callback, or SSO signing key and confirm that one secret does not authorize multiple unrelated functions. Reusing a signing key across features turns token integrity into cross-surface privilege collapse.
• Remove generic execution sinks from middleware paths Replace permissive deserialisation and expression expansion with strict allowlists or safer data handling patterns. If a request can reach XStream, Groovy evaluation, or a similar runtime interpreter, the application is one parsing mistake away from code execution.

Key takeaways

• The article shows that pre-auth RCE in enterprise Java is usually a composition failure, where routing, dispatch, and execution logic line up in the attacker's favour.
• The two highlighted chains differ in mechanism, but both convert unauthenticated reachability into code execution by abusing trust that was meant to stay internal.
• The limiting control is boundary discipline: constrain reachability, separate signing domains, and remove or tightly fence deserialisation and expression evaluation.

Key terms

• Pre-auth RCE: Remote code execution that occurs before a system has authenticated the requester. This is especially dangerous because the attacker does not need valid credentials, so the vulnerability can often be triggered from the public internet with a single request if the endpoint is reachable.
• 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.
• Signing Key Reuse: Signing key reuse means one secret is used to authenticate or authorise multiple features, sessions, or trust domains. That design increases blast radius because compromise or leakage of the key can undermine more than one control path at once.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It is designed for practitioners who need to connect identity controls to the wider security architecture their programmes depend on.