This is an automated email from the ASF dual-hosted git repository.
csutherl pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new cf39ed50ce Add SECURITY.md per dev-list discussion 'Considering AI
suggestions/guardrails for the tomcat project' (#1001)
cf39ed50ce is described below
commit cf39ed50ce7502710a599ce6846f1c6c7e455ba8
Author: Coty Sutherland <[email protected]>
AuthorDate: Tue Aug 18 14:11:01 2026 -0400
Add SECURITY.md per dev-list discussion 'Considering AI
suggestions/guardrails for the tomcat project' (#1001)
---
SECURITY.md | 144 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 133 insertions(+), 11 deletions(-)
diff --git a/SECURITY.md b/SECURITY.md
index db79646e0c..d835cb1520 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -1,14 +1,136 @@
-# Security
+# Security Policy
-Apache Tomcat's security model and disclosure process are
-published on the project website rather than in the repository:
+## Before You Report - Required Self-Check
-- **Threat model and security policy**:
- <https://tomcat.apache.org/security-model.html>
-- **How to report a vulnerability**: see the Security section
- of <https://tomcat.apache.org/>.
+**Complete this checklist. If you answer "No" to any question, do not submit a
report:**
-The project website is the authoritative source; this file
-exists so agents and tooling that look for `SECURITY.md` in
-the repository can mechanically follow the link to the
-canonical documents.
+- [ ] I have read the [Tomcat Security
Model](https://tomcat.apache.org/security-model.html) 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.**
+
+## Where to Report
+
+**[email protected]** - Exclusively for undisclosed security
vulnerabilities in Tomcat
+
+**Not for:** Bug reports ([Bugzilla](https://bz.apache.org/bugzilla/)),
configuration help ([users list](https://tomcat.apache.org/lists.html)),
theoretical issues, scanner output, or application vulnerabilities.
+
+## Common Invalid Reports - Do Not Send
+
+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](https://tomcat.apache.org/security-model.html)
to understand what qualifies as a Tomcat vulnerability.**
+
+## Required: Working Test Case
+
+**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.
+
+### Example Structure
+
+```java
+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"));
+ }
+}
+```
+
+## Required Report Information
+
+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.
+
+## What Happens Next
+
+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.
+
+## Security Model Quick Reference
+
+**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](https://tomcat.apache.org/security-model.html)
for details.
+
+## Published Vulnerabilities & Updates
+
+- **Advisories:** https://tomcat.apache.org/security.html
+- **Announcements:** [Mailing lists](https://tomcat.apache.org/lists.html)
+- **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](https://tomcat.apache.org/) 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
