Spring can pass the resolved view name into Thymeleaf expression parsing before the template is loaded. If attacker-controlled data reaches that path, the value may be evaluated as an expression instead of treated as literal text. That is why seemingly harmless concatenation in a controller can become expression language injection, which may escalate from template selection to command execution.
Why the view-name path becomes dangerous
A Spring view name is supposed to be a routing decision, not executable input. The risk appears when controller code builds that name from user-controlled data and the value is handed to a templating engine that can interpret expressions before rendering. At that point, the input is no longer just selecting a page, it can influence how the engine parses and evaluates content.
The critical mistake is assuming the string stays inert because it looks like a filename or logical view identifier. In systems such as Thymeleaf, expression parsing can happen during view resolution, so a crafted value may change control flow, reference objects, or trigger method calls. That turns a presentation-layer convenience into an expression injection sink, with remote code execution as the worst-case outcome.
When this pattern is present, the real security boundary is not the controller method itself, but the handoff into the view resolver and expression language. A safe implementation treats any externally influenced view name as untrusted, especially if the same path can reach a flexible template engine or custom resolver logic. The practical lesson is that template selection and template evaluation are different security events.
How expression injection can escalate to code execution
Expression language injection is dangerous because the attacker may not need to upload a file, bypass authentication, or directly reach a command API. If the template engine exposes access to helper objects, reflection-like capabilities, or downstream functions that ultimately reach the runtime, the injected expression can become an execution primitive. That is why the issue is often described as a progression from view manipulation to server-side code execution.
The exact exploitability depends on the resolver, the template engine configuration, and what execution features are available in the processing context. A hardened setup may block many paths, but you should not rely on default safety assumptions. Small implementation choices, such as concatenating a prefix or suffix around user input, can still preserve the attacker-controlled fragment in a position where the parser sees it as active syntax.
In practice, the highest-risk versions of this bug are the ones where the application also exposes enough context for the expression engine to reach sensitive objects or invoke dangerous methods. That is why the issue deserves code-review attention even when the visible effect initially looks like only a malformed page render. The control failure is hidden in the rendering pipeline, not the HTTP response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Prompt Injection and Input Manipulation | Covers user-controlled input being interpreted with unintended authority in an execution path. |
| A4 — Tool and Action Authorization | Relevant to preventing user input from triggering actions beyond its intended presentation role. | |
| Recommendation — Treat externally influenced view identifiers as untrusted instructions and constrain them to allowlisted values. Bind user input to non-executable display values and require explicit server-side authorization for actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Leakage | Relevant because injected view logic can expose sensitive runtime material or execution paths. |
| Recommendation — Keep untrusted values out of rendering paths that could expose sensitive objects or secrets. | ||
| CIS Controls v8 | CIS 16 — Application Software Security | Applies to preventing injection flaws in application rendering and request handling. |
| Recommendation — Review controller-to-view data flows and remove dynamic concatenation in template selection. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorization Management | Supports limiting which inputs can influence sensitive application behavior. |
| Recommendation — Restrict which request-derived values can reach sensitive routing or rendering decisions. | ||
Practitioner Guidance
What to verify: Trace every controller path that returns a view name and confirm whether any segment of that string can be influenced by request parameters, path variables, headers, cookies, or downstream model content. If the final view identifier is not fully constant, treat it as a potential injection boundary and inspect the exact resolver and template engine behavior.
Common mistake: Teams often focus on whether the application “sanitizes” user input before concatenation, but sanitizing for HTML output does not make a value safe for expression parsing. The safer rule is to keep user input out of the view-name decision altogether unless the allowed values are strictly enumerated and mapped server-side.
Decision rule: If externally influenced data can reach a view name or template selector, replace dynamic concatenation with a closed allowlist or fixed routing table. If you cannot prove that the value is only used as inert text, assume the parser may evaluate it and treat the path as code-injection-prone.
Practitioner takeaway: The core control is to separate user choice from executable template syntax, because once untrusted data can influence view resolution, the rendering layer may become an execution boundary instead of a presentation layer.
Related resources from NHI Mgmt Group
- How should security teams reduce remote code execution risk in publicly exposed analytics platforms that process user-uploaded reports?
- Why do user-controlled scripting features create outsized risk in data integration and BI platforms?
- How should security teams reduce remote code execution risk in notebook rendering paths that parse repository-controlled JSON?
- Why does remote code execution create such high operational risk for servers and applications?
