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

1. Reporting: Secure Submission Form below
2. 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

1. Initial Assessment (1-3 days)

   • Verify report details
   • Assess potential impact

2. Investigation (3-14 days)

   • Reproduce vulnerability
   • Analyze root cause
   • Develop mitigation strategy

3. 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

1. Vulnerability Description

   • Type of vulnerability
   • Affected components/versions
   • Potential impact

2. Technical Details

   • Proof of Concept (PoC)
   • Reproduction steps
   • Supporting evidence (screenshots, logs)

3. Mitigation Recommendations

   • Suggested fixes
   • Potential workarounds

Submission Form

Your Name (Required)

Your Email (Required)

Subject

Affected Property or Product (Required) Select a Property MODX.com (or any of it's subdomains) MODXCloud.com (or any of it's subdomains) MODX Revolution CMS

Project Title

Description of Vulnerability or Issue (Required) Describe the vulnerablity or issue in as much detail as possible. The more information you provide the more quickly we can resolve the issue. 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

We use the information you provide in this form solely for the purposes of your submission. You may review our Privacy Policy and MODX Website Terms of Service for more information.

I have read and accept the terms of Responsible Security Disclosure Policy.