Notifications
Clear all
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.
NHIMG editorial — based on content published by Escape: AI pentesting exposed pre-auth RCE that DAST scanners missed
Questions worth separating out
Q: How should security teams test for expression injection in Spring applications?
A: They should test the full data flow from request parameter to expression parser, not just the endpoint response.
Q: Why do WAFs often miss obfuscated injection payloads?
A: WAFs usually inspect raw request strings, so they are weak against payloads that assemble dangerous keywords after parsing.
Q: What breaks when application security testing ignores code context?
A: Teams lose the ability to tell whether a suspected issue is actually reachable in the deployed application.
Practitioner guidance
- Remove user input from evaluator source Audit every JSP, template, and server-side expression path where request parameters are concatenated into evaluation strings.
- Review WAF coverage against runtime reconstruction Test whether the WAF still blocks payloads when dangerous identifiers are assembled through concatenation, reflection, or character conversion at runtime.
- Add source-to-sink verification to appsec testing Prioritise testing that traces request parameters from source code to sink, then confirms exploitability in the running application.
What's in the full article
Escape's full analysis covers the exploit details this post intentionally leaves at a governance level:
- The exact request shapes and payload construction used to prove the unauthenticated SpEL injection path.
- The full obfuscation sequence that rebuilt dangerous Java identifiers at runtime to defeat keyword-based WAF rules.
- The agentic workflow used to trace source code, confirm exploitability, and reproduce the findings in the live application.
- The raw proof-of-concept outputs that show command execution returning in the rendered page.
👉 Read Escape's analysis of pre-auth SpEL RCE and WAF bypass in a Spring JSP portal →
AI pentesting and SpEL injection: are your controls keeping up?
Explore further
18/08/2026 3:27 pm
Context-aware exploitation is now the differentiator between a surfaced bug and a real risk. The article shows that known vulnerability classes do not become less dangerous because they are documented; they become more dangerous when testing can prove reachability in the actual application flow. Signature-matching tools can miss that distinction entirely. Practitioners should treat source-aware validation as a required control layer, not a premium enhancement.
A question worth separating out:
Q: Who is accountable when pre-auth RCE is reachable through a template engine?
A: Accountability usually sits with the application owner, security engineering, and the team operating release controls, because the failure spans design, code review, and runtime protection. The relevant standards focus on secure coding, least privilege, and validation of security controls, not on the attacker’s technique. Governance must require proof that controls work in the deployed execution path.
👉 Read our full editorial: AI pentesting exposed pre-auth RCE that DAST scanners missed
