Security

Visit ConcreteCMS.com to learn about the security or compliance details around hosting services. 

Scope

The vulnerability management program is for the Concrete Core software, https://github.com/concretecms/concretecms. CVEs are created and updated for fixed security vulnerabilities for supported Concrete Core versions. The Concrete Core CVE program began with version 8.5.4.   

Concrete Core vulnerabilities are listed on NIST  and on the Concrete CMS Disclosed CVE Public Tracker so that the community can take action to harden their sites.

To help keep the web safe, we will not disclose, discuss, or confirm security issues until a full investigation is complete and any necessary patches or releases are publicly available.

What is not in Scope

We do not commit to create CVEs for things outside the Concrete core or for things not considered to be vulnerabilities to the core. These include, but are not limited to:

• Server configuration issues

• Default Credentials

• CSRF Logout

• Self DoS capability

• 3d Party libraries. The 3d party libraries used in Concrete (jQuery, PHP, ADODB, TinyMCE, etc) have their own vulnerability management programs. Our release notes, however, will identify updates to external libraries made for security reasons that are included as part of Concrete core releases.

• Stuff Built by other People using Concrete (Common Sense -  Concrete is open source and anyone can download it and build with it. We can't be responsible for the security of other people's creations.) 

  • Vulnerabilities for Concrete (concrete5) marketplace products created by the open source community.  There are thousands of add-ons and themes for Concrete which are not part of the core software. We do our best to report vulnerabilities to the author of a marketplace item but we currently do not create and manage CVEs for them. We pass on any vulnerability reports to the independent developer. 

  • Websites using our hosting services which we did not build and continue to maintain.

Protecting Your Web Applications

• Overview
• Protecting Against Cross-Site Request Forgery with the Token Validation Library
• Protecting Against Cross-Site-Scripting with Output Filtering and Sanitization
• Guarding against SQL Injection
• Validating File Uploads
• Sanitizing User Input
• Encryption Service
• Anti-Spam and Captcha
• Working with the IP Blacklist Programmatically

Resources

• 12 Customer Data Privacy Tips for Your Business Small businesses often don't consider customer data policy as their priority. But with 43% of cyber attacks targeting small businesses, one thing is clear: protecting and controlling data is critical. 
• Configuration Best Practices Concrete CMS now has a Configuration Best Practices documentation page which provides a checklist to help make sure that your site is secure!
• 7 Reasons Why SSL Is Important For Your Website In this article, we will explain what SSL certificates are, their types, how they are important, and who needs to use an SSL certificate.

Do Not Disclose

Please be responsible! We're here because we want to know vulnerabilities before the world does so we have a chance to provide a solution in a reasonable timeframe. We assume you want the same; hence, please report issues directly to us on HackerOne.

Vulnerabilities will not be disclosed until a fix is publicly available. 

Reporters are expected to follow the HackerOne General Terms and Finder Terms. 

Credit

We've got some limited swag and lots of honor for those who are the first to submit an issue related to the core software, but no cash. Generally we're sending out stickers, but occasionally a truly stellar report gets a t-shirt. 

Keeping You in the Loop

Since we deeply appreciate the contributions of the community to keeping Concrete secure, we will acknowledge your security submission upon receipt. 

We will do our best to respond to clear, understandable, reports within 5 days on whether we deem your submission to be a unique vulnerability. 

We will apprise you once a CVE # is assigned. 

We will advise reporters when the issue they reported is fixed. Credit for reporting a vulnerability will be given in the release to the initial reporter. 

Avoid Duplicate Reporting

Check the NIST page where all CVEs related to the Concrete core codebase are listed. If the vulnerability you are about to report already has a CVE, please help out the community by NOT submitting a duplicate. 

If a vulnerability has previously been reported, we will inform the new reporter that their submission is a duplicate and will request that it not be publicly disclosed.

Only the first submitter will be credited for the vulnerability discovery.

Respect Others

Please install a local copy of Concrete. It is open source! This will let you test Concrete without disrupting other users. Beating on our trial servers or our websites will not be well-received.

See the Installation Guide to download Concrete 

Be Clear

We greatly appreciate the time you spent finding the issue. Please spend a couple extra minutes to spell out what you are able to exploit with it. We’re eager to build a web for the greater good; the more info you provide, the swifter the web can be a safer place! Special public acknowledgement will be provided to reporters who provide a fix at the time they report the issue.

Rule Acknowledgement required to Report

We receive many reports from security researchers who do not read these submission requirements. To prove that you've read and understood the rules outlined on this page, please include the word "crayons" somewhere in your report. If you do not, your report will be closed as invalid automatically by HackerOne.