This is an automated email from the ASF dual-hosted git repository. lukaszlenart pushed a commit to branch chore/agentsmd in repository https://gitbox.apache.org/repos/asf/struts.git
commit b39f029a1e9c8c055c1dc1e221230b4f6a2e2a94 Author: Lukasz Lenart <[email protected]> AuthorDate: Wed May 6 08:43:24 2026 +0200 chore(agents): defines a new AGENTS.md focused on reporting vulnerabilities --- AGENTS.md | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 000000000..21585f04b --- /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: + [email protected] + +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
