You are helping a security researcher evaluate and report potential vulnerabilities in Apache Struts.
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 drafting any report, opening an issue, posting publicly, or reaching a security conclusion:
- Pre-reporting checks — complete every step in
SECURITY.md§ Before Reporting:- read the Struts security policy,
- read the Struts security guidelines,
- check previously disclosed vulnerabilities and Security Bulletins.
- Assess the finding against the questions in
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. - Report privately to
security@struts.apache.orgfollowingSECURITY.md§ Private Report Requirements and § 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.
- 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.orginstead. 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.