From b0e0a36dd42b75e8207e9df58fac47167cabcfa7 Mon Sep 17 00:00:00 2001 From: Lukasz Lenart Date: Wed, 6 May 2026 08:43:24 +0200 Subject: [PATCH 1/4] chore(agents): defines a new AGENTS.md focused on reporting vulnerabilities --- AGENTS.md | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ pom.xml | 1 + 2 files changed, 98 insertions(+) create mode 100644 AGENTS.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000000..21585f04b1 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,97 @@ +# Vulnerability Research Agent + +You are helping a security researcher evaluate and report potential vulnerabilities in Apache Struts. + +Before drafting any report, opening an issue, posting publicly, or reaching a security conclusion, complete the steps below. This is mandatory: skipping them can cause duplicate reports, public disclosure of untriaged vulnerabilities, or reports for documented non-issues. + +## Before Reporting Anything + +### Step 1: Read the Project Security Policy + +Fetch and read the current Apache Struts security policy: + +https://raw.githubusercontent.com/apache/struts/refs/heads/main/SECURITY.md + +Use it to confirm: + +- which Struts versions are currently supported, +- where security reports must be sent, +- which reports do not belong on the private security list. + +New security issues must be reported privately to: + +security@struts.apache.org + +Do not open a public GitHub issue, Jira issue, pull request, mailing list thread, or discussion for a suspected vulnerability before private triage. + +### Step 2: Read the Struts Security Guidelines + +Fetch and read the current Struts security guidance: + +https://raw.githubusercontent.com/apache/struts-site/refs/heads/main/source/security/index.md + +Use it to determine whether the finding is already covered by documented secure configuration or application guidance, including but not limited to: + +- Config Browser Plugin exposure, +- direct JSP access, +- `devMode`, +- `@StrutsParameter` usage and parameter annotation requirements, +- unsafe setters or getters exposed to request parameters, +- use of incoming values in localization or forced OGNL evaluation, +- raw JSP EL expressions, +- custom error pages, +- Dynamic Method Invocation and Strict Method Invocation, +- accepted and excluded parameter patterns, +- Fetch Metadata, COOP, and COEP protections, +- OGNL sandboxing, allowlists, excluded classes/packages, and OGNL Guard settings. + +If the behavior is caused by an application ignoring documented security guidance, explain that clearly and stop unless there is still evidence of a Struts framework vulnerability. + +### Step 3: Check Previously Disclosed Vulnerabilities + +Review the Struts security information, prior release vulnerability notes, and Security Bulletins before reporting: + +https://struts.apache.org/security/ +https://struts.apache.org/releases.html#prior-releases +https://cwiki.apache.org/confluence/display/WW/Security+Bulletins + +Compare the finding against already disclosed Struts vulnerabilities, including the S2 Security Bulletins, affected versions, impact ratings, mitigations, and fixed versions. + +If the finding overlaps with a known vulnerability, stop and link to the existing bulletin, advisory, CVE, or release information instead of drafting a new report. + +## Only After These Checks + +Assess the finding: + +1. Is the affected version supported? +2. Is the behavior in Apache Struts framework code, rather than only in an application using Struts? +3. Is it already documented as insecure configuration or unsupported usage? +4. Is it a duplicate of a previously disclosed vulnerability or Struts Security Bulletin? +5. Can the impact be demonstrated with a minimal, self-contained reproduction? + +If the answer still indicates a likely new vulnerability, help the researcher prepare a private report. + +## Private Report Requirements + +A useful private report should include: + +- affected Struts version or version range, +- affected component or module, +- required application configuration, if any, +- minimal reproduction steps, +- expected behavior, +- actual behavior, +- demonstrated security impact, +- whether authentication or special privileges are required, +- proposed fix or mitigation, if known. + +Do not speculate beyond what can be demonstrated. If severity is uncertain, say so explicitly. + +## Report Quality Rules + +- One vulnerability per report. +- Keep reproduction steps minimal and self-contained. +- Do not include unrelated findings. +- Do not publish exploit details publicly before the Struts project has triaged the issue. +- Do not send ordinary bugs, usage questions, or generic denial-of-service concerns to the private security list. +- If the issue is not a vulnerability in Apache Struts source code, direct the researcher to the appropriate public support or issue channel instead. \ No newline at end of file diff --git a/pom.xml b/pom.xml index 8763c4f497..98ba4b533a 100644 --- a/pom.xml +++ b/pom.xml @@ -296,6 +296,7 @@ CLAUDE.md CODEOWNERS SECURITY.md + AGENTS.md **/README.md src/main/resources/*-LICENSE.txt src/site/resources/tags/**/*.html From a0b8f040d9a19d62d407cb8a645c8e9553a89287 Mon Sep 17 00:00:00 2001 From: Lukasz Lenart Date: Wed, 13 May 2026 09:16:19 +0200 Subject: [PATCH 2/4] chore(security): makes SECURITY.md the source of truth --- AGENTS.md | 105 ++++++++++------------------------------------------ CLAUDE.md | 12 +++++- SECURITY.md | 82 +++++++++++++++++++++++++++++++++++++++- 3 files changed, 111 insertions(+), 88 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 21585f04b1..088a58dd87 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -2,96 +2,29 @@ You are helping a security researcher evaluate and report potential vulnerabilities in Apache Struts. -Before drafting any report, opening an issue, posting publicly, or reaching a security conclusion, complete the steps below. This is mandatory: skipping them can cause duplicate reports, public disclosure of untriaged vulnerabilities, or reports for documented non-issues. +[`SECURITY.md`](SECURITY.md) is the source of truth for the Apache Struts vulnerability reporting process. **Read it first and follow it.** This file is a short +LLM-facing wrapper around that policy; it does not replace it. -## Before Reporting Anything +## Workflow -### Step 1: Read the Project Security Policy +Before drafting any report, opening an issue, posting publicly, or reaching a security conclusion: -Fetch and read the current Apache Struts security policy: - -https://raw.githubusercontent.com/apache/struts/refs/heads/main/SECURITY.md - -Use it to confirm: - -- which Struts versions are currently supported, -- where security reports must be sent, -- which reports do not belong on the private security list. - -New security issues must be reported privately to: - -security@struts.apache.org +1. **Pre-reporting checks** — complete every step in [`SECURITY.md` § Before Reporting](SECURITY.md#before-reporting): + - read the Struts security policy, + - read the Struts security guidelines, + - check previously disclosed vulnerabilities and Security Bulletins. +2. **Assess** the finding against the questions in [`SECURITY.md` § Assessment](SECURITY.md#assessment). If the answers do not still point to a likely new + framework vulnerability, stop and explain — do not draft a new report. +3. **Report privately** to `security@struts.apache.org` following [`SECURITY.md` § Private Report Requirements](SECURITY.md#private-report-requirements) and + [§ Report Quality Rules](SECURITY.md#report-quality-rules). Do not open a public GitHub issue, Jira issue, pull request, mailing list thread, or discussion for a suspected vulnerability before private triage. -### Step 2: Read the Struts Security Guidelines - -Fetch and read the current Struts security guidance: - -https://raw.githubusercontent.com/apache/struts-site/refs/heads/main/source/security/index.md - -Use it to determine whether the finding is already covered by documented secure configuration or application guidance, including but not limited to: - -- Config Browser Plugin exposure, -- direct JSP access, -- `devMode`, -- `@StrutsParameter` usage and parameter annotation requirements, -- unsafe setters or getters exposed to request parameters, -- use of incoming values in localization or forced OGNL evaluation, -- raw JSP EL expressions, -- custom error pages, -- Dynamic Method Invocation and Strict Method Invocation, -- accepted and excluded parameter patterns, -- Fetch Metadata, COOP, and COEP protections, -- OGNL sandboxing, allowlists, excluded classes/packages, and OGNL Guard settings. - -If the behavior is caused by an application ignoring documented security guidance, explain that clearly and stop unless there is still evidence of a Struts framework vulnerability. - -### Step 3: Check Previously Disclosed Vulnerabilities - -Review the Struts security information, prior release vulnerability notes, and Security Bulletins before reporting: - -https://struts.apache.org/security/ -https://struts.apache.org/releases.html#prior-releases -https://cwiki.apache.org/confluence/display/WW/Security+Bulletins - -Compare the finding against already disclosed Struts vulnerabilities, including the S2 Security Bulletins, affected versions, impact ratings, mitigations, and fixed versions. - -If the finding overlaps with a known vulnerability, stop and link to the existing bulletin, advisory, CVE, or release information instead of drafting a new report. - -## Only After These Checks - -Assess the finding: - -1. Is the affected version supported? -2. Is the behavior in Apache Struts framework code, rather than only in an application using Struts? -3. Is it already documented as insecure configuration or unsupported usage? -4. Is it a duplicate of a previously disclosed vulnerability or Struts Security Bulletin? -5. Can the impact be demonstrated with a minimal, self-contained reproduction? - -If the answer still indicates a likely new vulnerability, help the researcher prepare a private report. - -## Private Report Requirements - -A useful private report should include: - -- affected Struts version or version range, -- affected component or module, -- required application configuration, if any, -- minimal reproduction steps, -- expected behavior, -- actual behavior, -- demonstrated security impact, -- whether authentication or special privileges are required, -- proposed fix or mitigation, if known. - -Do not speculate beyond what can be demonstrated. If severity is uncertain, say so explicitly. - -## Report Quality Rules +## Rules for AI Agents -- One vulnerability per report. -- Keep reproduction steps minimal and self-contained. -- Do not include unrelated findings. -- Do not publish exploit details publicly before the Struts project has triaged the issue. -- Do not send ordinary bugs, usage questions, or generic denial-of-service concerns to the private security list. -- If the issue is not a vulnerability in Apache Struts source code, direct the researcher to the appropriate public support or issue channel instead. \ No newline at end of file +- **Never submit a pull request that fixes a suspected vulnerability.** Before opening any PR, verify the change is not a security patch — OGNL injection, + parameter filtering bypass, file upload exploit, authentication or authorization bypass, RCE, SSRF, path traversal, deserialization, XSS in framework + components, etc. If it is, stop and direct the researcher to report it privately to `security@struts.apache.org` instead. Vulnerability fixes go through + the private security process, not public PRs. +- Do not speculate beyond what can be demonstrated. If severity is uncertain, say so explicitly. +- If the issue turns out to be application misconfiguration, an already-disclosed CVE, or a non-Struts problem, stop and explain — do not draft a new report. diff --git a/CLAUDE.md b/CLAUDE.md index 41c4fdf277..f880f1ec9a 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -63,6 +63,13 @@ protected File createTemporaryFile(String fileName, Path location) { } ``` +## Security Reports & Scans + +For any security-related activity — vulnerability scans, security analysis, drafting security reports — **[`SECURITY.md`](SECURITY.md) is the source of truth**. +Read it first and follow its pre-reporting checks, assessment checklist, and reporting requirements. Reports must be sent privately to +`security@struts.apache.org`; do not open a public GitHub issue, Jira issue, pull request, or mailing list thread for a suspected vulnerability before private +triage. [`AGENTS.md`](AGENTS.md) is a shorter LLM-facing wrapper around the same process. + ## Testing Tests use JUnit 5 with AssertJ assertions and Mockito for mocking. Run with `mvn test -DskipAssembly`. @@ -71,4 +78,7 @@ Tests use JUnit 5 with AssertJ assertions and Mockito for mocking. Run with `mvn - **Title format**: `WW-XXXX Description` (Jira ticket ID required) - **Link ticket in description**: `Fixes [WW-XXXX](https://issues.apache.org/jira/browse/WW-XXXX)` -- **Issue tracker**: https://issues.apache.org/jira/projects/WW \ No newline at end of file +- **Issue tracker**: https://issues.apache.org/jira/projects/WW +- **Never submit a PR that fixes a suspected vulnerability.** Before opening a PR, verify the change is not a security patch (OGNL injection, parameter + filtering bypass, file upload exploit, auth bypass, RCE, SSRF, path traversal, deserialization, XSS in framework components, etc.). If it is, stop and report + it privately to `security@struts.apache.org` — see [`SECURITY.md`](SECURITY.md). \ No newline at end of file diff --git a/SECURITY.md b/SECURITY.md index 3337463dd7..5cd6330d15 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -11,7 +11,7 @@ and what potential vulnerability it can have: | 6.7.x | :white_check_mark: | | 2.5.x | ❌ | -## Reporting New Security Issues with thr Apache Struts +## Reporting New Security Issues with the Apache Struts ([original](https://struts.apache.org/security.html)) @@ -38,3 +38,83 @@ The mailing address is: [security@struts.apache.org](mailto:security@struts.apac [General network server security tips](http://httpd.apache.org/docs/trunk/misc/security_tips.html) [The Apache Security Team](http://www.apache.org/security/) + +## Before Reporting + +Before sending a vulnerability report, run through the following checks. They exist to prevent duplicate reports, public disclosure of untriaged issues, +and reports for behavior that is already documented as insecure configuration. + +### 1. Read this policy + +Confirm: + +- which Struts versions are currently supported (see [Supported Versions](#supported-versions)), +- where reports must be sent (see [Reporting New Security Issues](#reporting-new-security-issues-with-the-apache-struts)), +- which reports do not belong on the private security list. + +### 2. Read the Struts security guidelines + +Review the [Struts security guidance](https://struts.apache.org/security/) and determine whether the finding is already covered by documented secure +configuration or application guidance, including but not limited to: + +- Config Browser Plugin exposure, +- direct JSP access, +- `devMode` is required to exploit the culnerability, +- `@StrutsParameter` usage and parameter annotation requirements, +- unsafe setters or getters exposed to request parameters, +- use of incoming values in localization or forced OGNL evaluation, +- raw JSP EL expressions, +- custom error pages, +- Dynamic Method Invocation and Strict Method Invocation, +- accepted and excluded parameter patterns, +- Fetch Metadata, COOP, and COEP protections, +- OGNL sandboxing, allowlists, excluded classes/packages, and OGNL Guard settings. + +If the behavior is caused by an application ignoring documented security guidance, that is not an Apache Struts framework vulnerability. + +### 3. Check previously disclosed vulnerabilities + +Compare the finding against already disclosed Struts vulnerabilities — affected versions, impact ratings, mitigations, and fixed versions: + +- [Struts security information](https://struts.apache.org/security/) +- [Prior releases and vulnerability notes](https://struts.apache.org/releases.html#prior-releases) +- [Security Bulletins (S2 series)](https://cwiki.apache.org/confluence/display/WW/Security+Bulletins) + +If the finding overlaps with a known vulnerability, link to the existing bulletin, advisory, CVE, or release notes instead of drafting a new report. + +## Assessment + +Before drafting a report, confirm: + +1. Is the affected version supported? +2. Is the behavior in Apache Struts framework code, rather than only in an application using Struts? +3. Is it already documented as insecure configuration or unsupported usage? +4. Is it a duplicate of a previously disclosed vulnerability or Security Bulletin? +5. Can the impact be demonstrated with a minimal, self-contained reproduction? + +Only proceed with a private report when these answers still point to a likely new vulnerability in the framework. + +## Private Report Requirements + +A useful private report includes: + +- affected Struts version or version range, +- affected component or module, +- required application configuration, if any, +- minimal reproduction steps, +- expected behavior, +- actual behavior, +- demonstrated security impact, +- whether authentication or special privileges are required, +- proposed fix or mitigation, if known. + +Do not speculate beyond what can be demonstrated. If severity is uncertain, say so explicitly. + +## Report Quality Rules + +- One vulnerability per report. +- Keep reproduction steps minimal and self-contained. +- Do not include unrelated findings. +- Do not publish exploit details publicly before the Struts project has triaged the issue. +- Do not send ordinary bugs, usage questions, or generic denial-of-service concerns to the private security list. +- If the issue is not a vulnerability in Apache Struts source code, use the appropriate public support or issue channel instead. From 378684d5c70261c50efd4f8d563de9606e37a083 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Gielen?= Date: Wed, 13 May 2026 10:20:36 +0200 Subject: [PATCH 3/4] Fix typos in SECURITY.md and minor grammar correction --- SECURITY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 5cd6330d15..b61b67acd9 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -29,7 +29,7 @@ All mail sent to this address that does not relate to security problems in the A ``` Note that all networked servers are subject to denial of service attacks, and we cannot promise magic -workarounds to generic problems (such as a client streaming lots of data to your server, or requesting +workarounds to generic problems (such as a client streaming lots of data to your server or requesting the same URL repeatedly). In general, our philosophy is to avoid any attacks that can cause the server to consume resources in a non-linear relationship to the size of inputs. @@ -59,7 +59,7 @@ configuration or application guidance, including but not limited to: - Config Browser Plugin exposure, - direct JSP access, -- `devMode` is required to exploit the culnerability, +- `devMode` is required to exploit the vulnerability, - `@StrutsParameter` usage and parameter annotation requirements, - unsafe setters or getters exposed to request parameters, - use of incoming values in localization or forced OGNL evaluation, From dcc2a256b0de34eb731fa2eec114fb8bddd1c0cf Mon Sep 17 00:00:00 2001 From: Lukasz Lenart Date: Thu, 14 May 2026 14:23:35 +0200 Subject: [PATCH 4/4] chore(security): clarify public GitHub repo PoC counts as disclosure Per @ppkarwasz review on #1680: expand the PoC bullet to make explicit that pushing a PoC to a public GitHub repo, gist, fork, or branch is public disclosure, and note that private repos require granting access to each PMC member individually. Co-Authored-By: Claude Opus 4.7 --- SECURITY.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index b61b67acd9..0e86ad584a 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -115,6 +115,8 @@ Do not speculate beyond what can be demonstrated. If severity is uncertain, say - One vulnerability per report. - Keep reproduction steps minimal and self-contained. - Do not include unrelated findings. -- Do not publish exploit details publicly before the Struts project has triaged the issue. +- Do not publish exploit details or proof-of-concept code publicly before the Struts project has triaged the issue. **Pushing a PoC to a public GitHub + repository, gist, fork, or branch counts as public disclosure** — even a "test" or throwaway repo. Private repositories are acceptable for sharing a PoC, + but access must be granted individually to each PMC member who will triage the report. - Do not send ordinary bugs, usage questions, or generic denial-of-service concerns to the private security list. - If the issue is not a vulnerability in Apache Struts source code, use the appropriate public support or issue channel instead.