Complete this checklist. If you answer "No" to any question, do not submit a report:

• I have read the Tomcat Security Model and my finding doesn't require access to config files, data stores, binaries, or admin interfaces
• I have written a working Tomcat JUnit test case that compiles, runs, and demonstrates the vulnerability, or I have provided a justification as to why a JUnit test case cannot be written for this report and I have provided a minimal proof of concept
• I have tested against the most recent release of a supported Tomcat version - this is not theoretical analysis or scanner output
• I am submitting in plain text (no PDFs, archives, videos, or formatted documents)

Include this completed checklist in your report. If you cannot check all boxes, your report will be rejected.

security@tomcat.apache.org - Exclusively for undisclosed security vulnerabilities in Tomcat

Not for: Bug reports (Bugzilla), configuration help (users list), theoretical issues, scanner output, or application vulnerabilities.

These will be rejected without response:

• "Tomcat allows deploying WAR files that execute code" - Web apps are trusted, this is normal
• "I can modify server.xml to change behavior" - Config files are trusted
• "Sending lots of data crashes Tomcat" - Generic DoS without non-linear consumption
• "XSS/SQLi in my deployed application" - Your app's bug, not Tomcat's
• "Manager app accessible with valid password" - Admin users are trusted
• Scanner reports without actual testing - Must verify manually with working PoC
• Theoretical vulnerabilities or AI-generated reports - Must include working test case

Review the security model to understand what qualifies as a Tomcat vulnerability.

Every report MUST include a complete Tomcat JUnit test case that:

• Extends TomcatBaseTest or appropriate test base class
• Compiles against Tomcat source without errors
• Runs via ant test and demonstrates the vulnerability
• Uses real Tomcat APIs (not pseudo-code)
• Includes comments explaining the attack and impact

The test must actually work - we will run it. If it doesn't compile or doesn't reproduce the issue, your report will be rejected.

Exception: If a JUnit test case cannot be written for your report, you must provide a clear justification explaining why a test case is not possible, along with a minimal proof of concept that demonstrates the vulnerability.

package org.apache.catalina.security;

import org.junit.Assert;
import org.junit.Test;
import org.apache.catalina.startup.TomcatBaseTest;
import org.apache.catalina.startup.Tomcat;
import org.apache.catalina.Context;
import org.apache.tomcat.util.buf.ByteChunk;

/**
 * Demonstrates [specific vulnerability].
 * Attack: [how it works]
 * Impact: [security consequence]
 */
public class TestSecurityIssueXXXXX extends TomcatBaseTest {

    @Test
    public void testVulnerabilityName() throws Exception {
        // Setup: Configure Tomcat to expose the vulnerability
        Tomcat tomcat = getTomcatInstance();
        Context ctx = tomcat.addContext("", null);
        Tomcat.addServlet(ctx, "test", new YourTestServlet());
        ctx.addServletMappingDecoded("/test", "test");
        tomcat.start();

        // Attack: Send malicious request
        ByteChunk response = new ByteChunk();
        int rc = getUrl("http://localhost:" + getPort() + "/test?malicious=payload",
                        response, null);

        // Verify: Demonstrate security impact
        Assert.assertNotEquals("Should reject malicious input", 200, rc);
        // Or: Assert.assertFalse("Response leaked sensitive data",
        //                        response.toString().contains("secret"));
    }
}

Include all of the following:

1. Summary - 1-2 sentences describing the vulnerability
2. Tomcat Version - Exact version tested (e.g., Apache-Tomcat/11.0.5)
3. Configuration - Non-default settings needed to reproduce (if any)
4. Impact - Specific consequence (RCE, information disclosure, authentication bypass, etc.)
5. Test Case - Working JUnit test as described above

Format: Plain text only (email body or .txt/.java attachments). No .zip, .pdf, .docx, videos, or screenshots.

1. Acknowledgment - Usually within a few business days, if the report passes initial screening
2. Validation - We run your test case and assess impact against the security model
3. Fix & Disclosure - If valid, we develop a fix and coordinate public disclosure timing
4. Credit - Valid reports receive acknowledgment in security advisories

Allow reasonable time (typically 90+ days) for fix development. We'll work with you on disclosure timing.

Trusted (not security bugs):

• Administrative users, configuration files, data stores, Tomcat binaries (JARs, scripts)
• Deployed web applications (app bugs are the app's responsibility)
• Manager/Host Manager access, JMX, debugging interfaces

Untrusted (potential security bugs):

• HTTP/AJP connector data from clients
• Malicious requests via supported protocols

See the full security model for details.

• Advisories: https://tomcat.apache.org/security.html
• Announcements: Mailing lists
• Secure configuration: https://tomcat.apache.org/tomcat-11.0-doc/security-howto.html

Thank you for helping keep Apache Tomcat secure through high-quality, actionable vulnerability reports.

The project website is the authoritative source for Apache Tomcat's security policy and disclosure process. This file exists so agents and tooling that look for SECURITY.md in the repository can find the canonical documents.