ExpressionEngine

PLEASE NOTE: DO NOT TEST OUR WEB SITES This program is for the downloadable self-hosted application ExpressionEngine, not the ExpressionEngine.com or EllisLab.com web sites. Scans and intrusion attempts are a violation of our web site's terms of use and reports will be marked Not Applicable without notice, incurring a loss of HackerOne reputation.

We take security issues very seriously, and encourage responsible reporting with a high priority on making security fixes or patches available rapidly, prior to any public disclosure of the vulnerability. We find this is the best balance of giving security issues the attention they rightly deserve, and protecting end users and site visitors from malicious individuals and script kiddies.

All software has vulnerabilities, but when we work together with developers and researchers, we can all help make the Internet a safer and better place. We love to acknowledge researchers who make valid security reports and work with us, and while we do not have a bounty program, sometimes will donate software or swag for being classy.

What are Security Issues?

When we speak about security related bugs, we are most interested in:

• Cross-site Scripting (XSS)
• Cross-site Request Forgery (CSRF)
• Privilege Escalation
• Session Hijacking
• Arbitrary Code Execution

Making Good Security Reports

We don’t have rigid guidelines for what a security bug report should include, as we want to minimize barriers—ultimately we just want to receive the information. That said, the best security reports not only describe the vulnerability, but include a proof of concept as well as how it might be exploited in a realistic situation. Bonus points for including your recommended solution.

On the converse, security reports that are merely the output of penetration testing software are generally not only unhelpful, but typically contain false-positives as the software cannot grasp the context or implications of a piece of code that checks off one of the items on the vendor’s preset list of vulnerabilities.

Since our team only speaks English all security reports must be made in English, and communication will be in that language.

Reporting and Disclosure

Once you have reported the security issue, a number of steps will be taken to assess and address the reported issue prior to disclosure.

• The report will be triaged within 72 hours to determine if the issue is a legitimate security issue. Issues reported on weekends or U.S. holidays may take up to 96 hours to be triaged.

• Immediately after being triaged, an engineer will be assigned as the owner of the issue and will contact you regarding your report.

• If confirmed, the engineer will set to work on resolving the issue, providing the reporter with a patch to test the prospective fix.

• We try to have all security issues fixed within two weeks of being triaged, often much more quickly. All valid security reports have a high priority, but will be addressed in a relative priority based on:

  • Whether a known exploit is in the wild
  • The severity of the exploit
  • The likelihood of user impact
  • Complexity of the issue

• In any case, the engineer assigned to the issue will maintain regular contact with the reporter throughout the process, at minimum once per week.

• The security bug fix will typically be included in the next software release. Depending on the priority conditions above and how distance the next planned release is, we may issue a release and/or patch that only addresses the reported security bug.

• We disclose in our application Change Log that a security bug has been fixed, and what type. We do not disclose the steps or circumstances to reproduce the bug.

• Releases are posted to our blog, and for users who have left the default feature enabled, receive notification when logged in to their control panel.

• Public disclosure of a security bug prior to resolution makes our engineers and customers quite unhappy, and will not be met with gratitude.