AI pentesting exposed pre-auth RCE that DAST scanners missed

At a glance

What this is: Escape reports that an AI pentesting engine uncovered pre-auth SpEL injection leading to remote code execution, plus a separate WAF bypass, in a Spring JSP portal that traditional DAST scanning missed.

Why it matters: This matters because application security teams can no longer rely on payload matching alone when the exploit depends on source-code context, expression parsing order, and runtime payload reconstruction.

Context

This is an application security and governance problem, not just a tooling story. Signature-based DAST is effective at known patterns, but it does not understand how request data is transformed before it reaches an evaluator, which is exactly where expression-injection failures hide. In this case, the security boundary failed because the application treated untrusted input as part of executable template logic.

The identity angle is indirect but real: the issue is not human IAM, but the control model around application trust, runtime execution, and machine-authenticated access paths inside the web stack. When an unauthenticated request can drive server-side code execution, the application itself becomes the weakest identity boundary in the environment.

Cascade is described as an AI pentesting engine that reads source, maps data flow, and then tests the live application to confirm whether a sink is actually reachable. That combination is atypical compared with periodic manual testing and standard DAST, which is why the article treats the finding as a gap in how teams validate their controls.

Key questions

Q: What breaks when user input reaches a server-side expression evaluator?

A: The application stops treating input as data and starts treating it as code. That is where injection becomes remote code execution, especially when the evaluator allows type references, reflection, or method calls. The safe assumption is that anything reaching SpEL, EL, or similar mechanisms needs strict allowlisting and context restriction before the parser ever sees it.

Q: Why can a WAF miss an exploit that the application still executes?

A: Because the WAF inspects the request before the application transforms it, while the vulnerable code may only emerge after parsing, templating, or runtime string assembly. If the exploit can be reconstructed from harmless fragments, the filter sees benign text and the evaluator sees the payload. That mismatch is why WAFs reduce risk but do not eliminate injection exposure.

Q: What do teams get wrong about running DAST on authenticated web applications?

A: A common mistake is scanning without configuring authentication and session handling, which leaves large parts of the application untested. Teams also underdefine scope, allowing irrelevant areas to distract from real risk. Effective DAST requires context-aware setup so the scanner can move through logged-in flows, respect boundaries, and focus on the pages and parameters that actually matter.

Q: How should teams validate controls against source-aware AI pentesting?

A: They should test whether the tool can follow data flow from request to sink, then confirm whether its findings still hold after obfuscation or WAF blocking. The point is to verify coverage of the application’s actual execution path, not just its response to canned payloads. That approach exposes blind spots that routine scanning and annual tests routinely miss.

Technical breakdown

Why SpEL injection becomes code execution in JSP templates

Spring Expression Language, or SpEL, is designed to evaluate expressions, call methods, and traverse object graphs. That flexibility becomes dangerous when untrusted input reaches an expression rather than a plain string. In the article’s case, the request parameter was substituted into a JSP template before the expression parser ran, so the attacker controlled the expression source itself. Under a StandardEvaluationContext, method calls and type references are allowed by default, which means a payload can move from string handling to operating system command execution without needing a separate privilege escalation step.

Practical implication: treat any untrusted value entering an expression evaluator as a code-execution risk, not a templating bug.

Why payload matching DAST misses context-driven injection

DAST tools work by sending payloads and comparing responses against known patterns. That approach is useful for regression testing, but it does not reason about how the application assembles input before evaluation. If the vulnerable sink only appears after server-side template substitution, a scanner can miss the issue because it never reconstructs the application’s execution path. The article shows why source-code awareness matters: the vulnerable parameter was not dangerous in isolation, it became dangerous only after JSP and SpEL combined their own parsing rules.

Practical implication: combine DAST with source-aware analysis for any application that evaluates user-controlled expressions.

How WAF evasion works when dangerous strings are rebuilt at runtime

A WAF sees the raw request, while the expression engine sees the result after evaluation. That difference creates an evasion window whenever dangerous strings can be assembled dynamically from safe-looking fragments. In the article, the payload replaced literal keywords with character-building and reflection so that names such as java.lang.Runtime only existed inside the evaluator, after the WAF had already inspected the request. The control did not fail because inspection was absent; it failed because the inspection point was before the dangerous semantics emerged.

Practical implication: validate WAF coverage against runtime reconstruction tricks, not only against literal exploit strings.

Threat narrative

Attacker objective: The attacker’s objective is to gain arbitrary command execution on the application server without authentication and then bypass perimeter controls to keep that access working.

1. Entry occurred through an unauthenticated GET request to a shared Spring JSP template that accepted the ref parameter.
2. Credential access was unnecessary because the attacker-controlled value was inserted into a SpEL expression before parsing, allowing direct server-side execution.
3. Escalation happened when the expression resolved to Runtime.exec() under a permissive StandardEvaluationContext, giving arbitrary command execution on the host.
4. Impact was full pre-auth server compromise, with command output reflected back into the page and a second path showing WAF bypass through obfuscated expression reconstruction.

Breaches seen in the wild

• 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.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

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

Context-aware testing is now a control requirement, not an advanced option. The article shows that a working exploit can depend on source-level reasoning, not on rare or novel vulnerabilities. That changes the governance question from whether a scanner found a known signature to whether the programme can understand execution flow well enough to detect dangerous transformations before release. For application security teams, source-aware validation belongs alongside regression testing, not after it.

Expression evaluation is a trust boundary, not a convenience feature. SpEL, template engines, and similar evaluators collapse the line between data and code when they accept attacker-controlled content. The control gap here was not the absence of a WAF, but the assumption that blocked keywords meant blocked risk. Practitioners should treat evaluators as privileged execution surfaces and govern them with the same care as other code-bearing interfaces.

Runtime reconstruction is the named concept this article sharpens: dangerous payloads can be assembled after inspection. That matters because many defences still assume the malicious string must be visible in transit. Once an attacker can spell out a blocked keyword from innocuous fragments, the control objective shifts from string detection to semantic validation. Security teams should evaluate whether their controls still work after the application rewrites the request.

AI pentesting is exposing a coverage gap between periodic testing and continuously changing application state. The article does not argue that automation replaces human review. It shows that an agent can carry forward code-level context, adapt to blocking controls, and keep probing in a way that point-in-time testing cannot. For practitioners, that means the real comparison is not human versus machine, but intermittent versus continuous verification.

WAF false confidence remains a governance problem when teams equate blocking with prevention. If a payload can be re-encoded until the evaluator accepts it, the WAF has only filtered one syntax, not the underlying exploit class. That should push teams to measure controls against bypass resistance, not just alert volume. The practitioner conclusion is simple: the control is only as strong as the attacker’s ability to express the same intent another way.

What this signals

Runtime reconstruction is becoming a practical bypass pattern, not a niche trick. When dangerous strings can be assembled after inspection, controls that only look for literal keywords will miss the exploit class. Security teams should expect attackers, including automated ones, to adapt payloads until the application itself reveals the path to execution.

The programme-level question is whether your testing model can understand the application’s execution order. If it cannot, then the organisation is validating syntax filters rather than verifying exploitability, which leaves a predictable gap between scan results and real risk.

For practitioners

• Instrument source-to-sink reviews for expression evaluators Trace every user-controlled value that reaches JSP, SpEL, EL, templating, or reflection paths, and require review at the point where data becomes executable syntax.
• Remove attacker input from template expressions Refactor global templates so request parameters are handled as data only, with server-side allowlists or safe builders instead of concatenated evaluation strings.
• Constrain evaluation contexts by default Use the most restrictive evaluation context available and forbid type references, reflective method calls, and direct command execution from evaluated expressions.
• Test WAF rules against obfuscated reconstruction Validate controls with payloads that rebuild blocked keywords from benign fragments, then tune detections for semantic intent rather than literal strings.
• Run continuous source-aware pentesting on release candidates Use ongoing testing to confirm that a parameter remains safe after code changes, especially when template logic or parser order changes in a minor release.

Key takeaways

• The core failure was letting untrusted data reach an expression evaluator that could execute commands on the server.
• The article shows that a WAF and a DAST scanner can both miss the same issue when the exploit depends on source-code context and runtime reconstruction.
• Teams need source-aware validation and restrictive evaluation contexts, because literal-payload blocking does not stop semantic injection.

Key terms

• SpEL Injection: SpEL injection happens when attacker-controlled data is inserted into a Spring Expression Language expression and the evaluator treats it as executable syntax. That can expose object access, reflection, and method invocation, turning a template issue into server-side command execution.
• Runtime reconstruction: The ability to rebuild what an identity did, in what order, and through which tools or systems after an event. For agentic environments, this is essential because the attacker may hide inside a legitimate workflow. Without reconstruction, investigation cannot separate normal orchestration from abuse.
• Expression Evaluation Sink: An expression evaluation sink is any code path where user input is parsed as executable syntax instead of inert data. These sinks are high-risk because they collapse the boundary between content and command, so secure design depends on strict context control and input segregation.
• Source-To-Sink Trace: A source-to-sink trace shows how data moves from its origin to the place where it is used or exposed. Security teams use it to understand whether untrusted input reaches sensitive operations, such as command execution or external transmission. It helps explain impact, not just identify a code finding.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.