Responsible Security Disclosure Policy and Submission Form
At MODX, we prioritize the security of our software and services for all users, customers, and clients. We actively encourage responsible security research and welcome collaborative disclosure from security professionals under the following terms.
Compensation and Recognition Policy
No Financial Compensation
MODX does NOT:
- Pay monetary rewards for security reports
- Provide financial bounties of any kind especially "beg bounties"
- Offer compensation in cash, credits, or equivalent value
- Give merchandise, swag, or gift cards for vulnerability findings
Researcher Recognition
Our goal is to foster a collaborative security research community. While we do not offer financial incentives, we are committed to:
- Officially acknowledging significant security contributions
- Providing public recognition for verified, substantive reports
- Appreciating the community's commitment to responsible disclosure
Scope of Security Research
What's In Scope
Security research is welcome for:
- Currently supported releases of MODX Revolution (not previous patch releases or EOL versions)
- modx.com and associated services hosted on its subdomains (with some exclusions below)
- dashboard.modxcloud.com
What's Out of Scope
We will NOT acknowledge reports involving:
Excluded Vulnerability Types
- Self-XSS (XSS requiring interaction other than browsing)
- Issues requiring Admin/Sudo privileges to MODX Revolution Manager
- Features of the MODX Revolution Manager back-end
- Issues found through automated testing
- "Tab-Nabbing" or rel="noopener" bugs
- "Scanner output" or scanner-generated reports
- Publicly-released bugs in internet software
- DNSSEC or Content Security Policy (CSP) Absence
Specific Exclusions
- Vulnerabilities requiring:
- Physical access to an unlocked device
- Access to a victim's email account
- Denial of Service attacks
- Brute Force attacks
Social Engineering and Information Disclosure
- Spam or Social Engineering techniques, including:
- SPF, DKIM, and DMARC issues
- Content injection
- Hyperlink injection in emails
- IDN homograph attacks
- RTL Ambiguity
- Content Spoofing
- Version number information disclosure
- Discovery of publicly-available URLs
Specific Domain Exclusions
- *.modx.dev domains
- Development *.paas MODX Cloud subdomains
- audit.modx.com
- status.modx.com
- support.modx.com
- status.modxcloud.com
Additional Exclusions
- Third-party applications in MODX Extras directory
- Non-exploitable security headers
- Bugs without actual security risk
- Security issues in recently acquired software (90 days post-acquisition)
Issue Classification
Severity Levels
Low Severity Bugs
- Server misconfiguration or provisioning errors
- Information leaks (excluding customer data)
- HTTP referrer leaks
- Improper or missing input validation
Medium Severity Bugs
- Information leaks including customer data
- Cross-Site Scripting (XSS) compromising user data
- Cross-Site Request Forgery on Sensitive Actions (CSRF/XSRF)
High Severity Bugs
- Remote Code Execution
- Remote database access
- Privilege Escalation
- Bypassed Authentication
- Server-Side Request Forgery (SSRF) with critical impact
Reporting Guidelines
Reporting Principles
- Submit reports in good faith
- No expectation of monetary reward
- Do not make threats
- Absolutely no "beg bounty" submissions
- No automated testing
- Test only with your own accounts
- Do not interact with other accounts without consent
Recognition Criteria
- First reporter receives initial acknowledgment
- Subsequent reports may be recognized if providing additional information
- Must include full vulnerability demonstration
- Must provide clear reproduction steps
- "Speculative" vulnerabilities not accepted
Reproduction Requirements
- Provide step-by-step instructions
- Demonstrate issue using a fresh MODX or MODX Cloud installation
- Include screenshots or videos if possible
Confidentiality and Disclosure
- Do NOT publicly disclose vulnerabilities before submission
- Do NOT publish until MODX confirms disclosure is acceptable
- Acknowledgments published at time of fix
- MODX will provide updates during resolution process
Reporting Process and Guidelines
Communication Commitment
- Initial Response: Within 24-48 hours of report submission
- Regular Updates: Researchers will receive regular status updates as available
- Final Resolution Communication: Detailed explanation of findings, fixes, and impact
Preferred Communication Channels
- Reporting: Secure Submission Form below
- Follow-on: email
Ethical Reporting Guidelines
Reporting Principles
Security researchers must:
- Report vulnerabilities directly and privately
- Provide clear, detailed, and reproducible vulnerability information
- Maintain confidentiality during investigation
Prohibited Actions
Do NOT:
- Publicly disclose vulnerabilities before resolution
- Exploit discovered vulnerabilities
- Cause intentional damage or disruption
- Attempt to access unauthorized systems or data
Consequences of Policy Violations
- Immediate disqualification from recognition
- Potential referral to legal authorities for serious breaches
- Permanent exclusion from future reporting considerations
Legal and Ethical Protections
Researcher Safeguards
We commit to:
- No legal action against researchers reporting in good faith
- Protection from harassment or legal threats
- Fair and transparent evaluation of security reports
Conditions of Protection
Researchers must:
- Follow responsible disclosure guidelines
- Not intentionally access or damage systems
- Provide detailed, verifiable information
- Maintain confidentiality during investigation
Our Security Handling Process
Vulnerability Management Workflow
Initial Assessment (1-3 days)
- Verify report details
- Assess potential impact
Investigation (3-14 days)
- Reproduce vulnerability
- Analyze root cause
- Develop mitigation strategy
Resolution
- Develop and test patch
- Coordinate responsible disclosure
- Deploy fix across affected systems
Our Commitment to Transparency
We pledge to:
- Provide clear communication
- Acknowledge researcher contributions
- Publish security advisories
- Continuously improve our security practices
Characteristics of a Quality Security Report
Ideal Report Components
A high-quality security report should include:
- Specific vulnerability type
- Exact affected versions
- Detailed, step-by-step reproduction steps
- Potential security consequences
- Suggested remediation strategies
Report Template
Required Information
Vulnerability Description
- Type of vulnerability
- Affected components/versions
- Potential impact
Technical Details
- Proof of Concept (PoC)
- Reproduction steps
- Supporting evidence (screenshots, logs)
Mitigation Recommendations
- Suggested fixes
- Potential workarounds
Submission Form
Launch a MODX site with ease
Turn your code into a MODX-powered digital experience and deploy with confidence.
Request a Demo Plans & Pricing
Got questions? Contact us to ask or schedule a demo. Want to self-host? Download MODX