CVE-2026-50229: Apache Tomcat examples app XSS in numguess.jsp

CVE-2026-50229 is a reflected/stored cross-site scripting (XSS) vulnerability in the bundled examples web application of Apache Tomcat. The vulnerable JSP page webapps/examples/jsp/num/numguess.jsp uses wildcard bean property binding (<jsp:setProperty name="numguess" property="*"/>) against a session-scoped NumberGuessBean. Because the NumberGuessBean exposes a hint property, an attacker can supply a hint request parameter that overwrites the bean's intended hint value. The page later renders the bean's hint value directly into the HTML response using <%= numguess.getHint() %>, which does not escape the content. This allows an attacker to inject arbitrary JavaScript/HTML into the response.

• Product / Component: Apache Tomcat, bundled examples web application (webapps/examples/jsp/num/numguess.jsp)
• Affected versions: 7.0.0 through 7.0.109, 8.5.0 through 8.5.100, 9.0.0.M1 through 9.0.118, 10.1.0-M1 through 10.1.55, and 11.0.0-M1 through 11.0.22
• Fixed versions: 11.0.23, 10.1.56, 9.0.119 (8.5 and 7.0 are end-of-life)
• Risk level / consequences: Medium. An attacker who can trick a user into visiting a crafted URL can execute JavaScript in the user's browser session in the context of the Tomcat examples application. Because the bean is session-scoped, the payload is also persisted until the session is reset, giving a stored-like behavior.

Impact Parity

• Disclosed / claimed maximum impact: XSS in the bundled Tomcat examples web application via attacker-controlled request parameters.
• Reproduced impact from this run: A live HTTP request to the numguess.jsp endpoint on Tomcat 10.1.55 rendered the unescaped <script>alert(1)</script> payload in the HTML response. The same request against Tomcat 10.1.56 did not render the payload because the hint parameter is no longer bound into the session bean.
• Parity: full — the reproduced behavior matches the disclosed XSS impact.

Root Cause

The root cause is the combination of two design choices in numguess.jsp:

1. Wildcard bean property binding:

   <jsp:useBean id="numguess" class="num.NumberGuessBean" scope="session"/>
   <jsp:setProperty name="numguess" property="*"/>
   

   property="*" binds every request parameter to a bean property of the same name. This exposes properties other than the intended guess parameter (e.g., hint, answer, success, numGuesses).

2. Unescaped output:

   Good guess, but nope. Try <b><%= numguess.getHint() %></b>.
   

   The hint value is emitted directly into the HTML without escaping. When an attacker sets hint to HTML/JavaScript, the browser parses and executes it.

Apache fixed this by restricting the property binding to the intended guess parameter:

-<jsp:setProperty name="numguess" property="*"/>
+<jsp:setProperty name="numguess" property="guess"/>

Fix commit: 0d5bdd5b0dd964e9f73e530b7d753462b9bfd1d0 ("Minor optimisation. Only need to set 1 property so don't use wild card.")

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh.
2. The script installs Java if needed, downloads and extracts Apache Tomcat 10.1.55 (vulnerable) and 10.1.56 (fixed), then configures and starts each instance in turn on port 18080.
3. For each version, the script performs two requests in the same HTTP session:
   • First request: GET /examples/jsp/num/numguess.jsp?guess=abc — establishes a session and advances the game state so the hint branch is rendered.
   • Second request: GET /examples/jsp/num/numguess.jsp?hint=%3Cscript%3Ealert(1)%3C%2Fscript%3E — attempts to bind the attacker-controlled hint parameter into the session bean.
4. The script inspects the second response for the literal string <script>alert(1)</script>.

Expected evidence:

• Vulnerable (10.1.55): the second response contains Good guess, but nope. Try <b><script>alert(1)</script></b>.
• Fixed (10.1.56): the second response contains the default hint (e.g., a number next time) and no attacker-controlled markup.

Evidence

• bundle/logs/reproduction_steps.log — full script execution log.
• bundle/repro/vulnerable_resp2.html — HTTP response from the vulnerable Tomcat 10.1.55 showing the unescaped payload.
• bundle/repro/fixed_resp2.html — HTTP response from the fixed Tomcat 10.1.56 showing the payload is absent.
• bundle/repro/runtime_manifest.json — runtime evidence manifest.

Key excerpt from vulnerable_resp2.html:

Good guess, but nope.  Try <b><script>alert(1)</script></b>.

Key excerpt from fixed_resp2.html:

Good guess, but nope.  Try <b>a number next time</b>.

Environment:

• OpenJDK 25.0.3 (installed via default-jdk package)
• Apache Tomcat 10.1.55 and 10.1.56 binary distributions from https://archive.apache.org/dist/tomcat/

Recommendations / Next Steps

• Upgrade to a fixed Tomcat version (10.1.56+, 9.0.119+, or 11.0.23+).
• Remove or disable the examples web application in production environments; it is intended for demonstration only.
• Avoid wildcard bean property binding (property="*") when the request can contain untrusted parameters; explicitly whitelist the parameters the application intends to bind.
• Escape output when rendering dynamic content, or use a framework that escapes expression-language output by default.
• Add regression tests that verify untrusted request parameters are not bound into session beans and are not reflected unescaped in responses.

Additional Notes

• The reproduction script is idempotent: it reuses cached Tomcat archives, reconfigures ports deterministically, and cleanly stops each instance before starting the next one.
• The script was run twice consecutively and produced the same confirmed result both times.
• The examples application is typically not deployed in production, which limits real-world exploitability, but the vulnerability is real in the shipped product.