Topic starter
18/08/2026 2:44 pm
TL;DR: An AI pentesting engine found pre-auth SpEL-based RCE and a WAF bypass in a Spring JSP portal by reading source code, reasoning about expression evaluation, and rebuilding the exploit live, according to Escape. The result is a reminder that signature-based DAST and annual testing can miss context-driven injection paths.
Editorial analysis by NHI Mgmt Group, based on content published by Escape: “Two Critical Vulnerabilities, One AI Pentester: How Cascade Found an Unauthenticated RCE and Walked Around the WAF”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The core failure was letting untrusted data reach an expression evaluator that could execute commands on the server.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:27 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI pentesting exposed pre-auth RCE that DAST scanners missed