Reporting Security Issues
Reporting and Testing Policy
Liferay recognizes the important role that the Liferay community and independent security researchers play, and we encourage responsible reporting of vulnerabilities discovered in our products.
Liferay believes in Responsible Disclosure. This means that when you are reporting new bugs related to security vulnerabilities, you give Liferay a chance to respond (evaluate, resolve) security bugs before its details are publicly and fully disclosed.
Please be aware that vulnerabilities within an application may take longer to resolve than what you may be used to. Except in the case of a critical vulnerability, an application vulnerability will most likely be included in the next regular release of the application.
The key fingerprint is: 9325 A69B 681E EFA7 DA94 1233 D2B5 73D2 8A47 A0FF
The key ID is: 0xD2B573D28A47A0FF
Please do not submit vulnerabilities on any public channel, including but not limited to, Liferay community forums, blogs comment pages and social media.
Please attach all images and videos supporting your submission directly to your submission. Do not use third party sites to host the files.
If the vulnerability involves unauthorized access to data on a Website, please provide all IP addresses you used for testing.
We do not offer any monetary reward, but we do publicly recognize new and unique submissions on our Hall of Fame.
- Within 72 hours of receiving a report, Liferay will acknowledge the report and attempt to reproduce the issue using the supplied information.
- Liferay will fix and (if applicable) release patches for affected applications.
- If appropriate, Liferay will request a CVE number be assigned to the vulnerability.
- Liferay will notifiy the reporter that the vulnerability has been fixed.
- An advisory will be published on the known vulnerabilities page.
- In Scope:
Application Liferay Commerce
Application Liferay Developer Studio
Application Liferay Digital Experience Platform (DXP)
Application Liferay Faces
Application Liferay IDE
Application Liferay Mobile SDK
Application Liferay Portal
Application Liferay Screens
Application Liferay Sync
Application Applications in Liferay Marketplace that are owned by Liferay
Website Liferay Analytics Cloud
WebsiteLiferay Experience Cloud (LXC)
WebsiteLiferay Experience Cloud Self-Managed (LXC-SM) (previously known as Liferay DXP Cloud)
Website *.liferay.com (except subdomains listed in the out of scope section below)
- Out of Scope:
Application Applications in Liferay Marketplace that are not owned by Liferay
Website Any website that is not owned by Liferay including, but not limited to, sites with a Liferay subdomain (e.g., liferay.example.com)
Website Any websites and/or services that Liferay Experience Cloud host on behalf of it’s customers.
Other Physical intrusions
- For all Application:
- We use the label "application" in this document to cover applications, frameworks, libraries, products and projects.
- Please reproduce the vulnerability in a supported version before submitting. (Only the most recent release is supported for most community applications). We still welcome submissions for vulnerabilities against unsupported versions, however, it may take us longer to respond and the submission may not qualify for credit in our hall of fame.
- Vulnerabilities in a third party library should be reported to the company/organization the developed/published the library.
- We will give credit for reporting an application that uses a third party library with known vulnerabilities if we are unaware of the vulnerabilities in the library 30 days after the vulnerabilities has been published. We have our own monitoring in place for this so we want to give our monitoring tools a chance to do its job. However, if we missed the vulnerability, we’ll give you credit. In addition, please provide evidence/PoC that the vulnerability is exploitable from the application.
- We do not review reports produced by automated scanners. Please test the issue on your own to ensure it is exploitable and provide a PoC with your submission.
- We do not give credit for submissions related to best practices if there is no actual vulnerability
- For all Website:
- Please rate-limit automated scanning to a maximum of one (1) request per second.
- No testing for denial of service (DoS). If you suspect there is a DoS vulnerability, please let us know why you think there is a DoS vulnerability and we can work with you to determine if there is a vulnerability. We implement rate limiting and you may be blocked if you perform an excessive number of requests.
- Do not test against another user’s account or any account you do not have explicit permission to access.
- Do not access, destroy or negatively impact another user or another user’s data.
- We will give credit for reporting a website running software from a third party vendor (e.g., Jira) with known vulnerabilities if we are unaware of the vulnerabilities 30 days after the vulnerability has been published (or 14 days for critical vulnerabilities with a .CVSS score of 9.0+). We have our own monitoring in place for this so we want to give our monitoring tools a chance to do its job. However, if we missed the vulnerability, we’ll give you credit.
- We do not give credit for submissions related to best practices if there is no actual vulnerability.
- Liferay Analytics Cloud / Liferay Experience Cloud:
- We do not provide credentials or test accounts for testing purposes. However, you’re free to test the part of the service that is publicly accessible.
- Liferay Marketplace:
- We appreciate submissions for all applications that are owned by Liferay, but we do not give credit for applications that are labeled as “Labs”.
- We currently only accept reports for critical vulnerabilities (e.g., server compromise, authentication bypass, complete service unavailability)
The following are common submissions we receive that we consider as acceptable risk, false-positive, and/or out-of-scope.
- Email address aliasing: Although some email providers support plus (+) aliasing and ignore dots (.), these are not a part of the email standard. Some email providers do not support these email aliasing scheme and will treat these email addresses as different accounts. We don’t believe that maintaining a list of email providers that support email aliasing is a good use of our development effort at this time.
- Limited content reflection: We do not consider all instances of reflected content to be a security vulnerability. Reflecting some parameter value in the response is often expected as long as the value has been properly escaped or sanitized.
- Logout CSRF: We are aware of this issue and believe that this is an acceptable risk.
- Tabnabbing: We are aware of this issue and believe that this is an acceptable risk.
- _vti_inf.html disclosure: Please make sure the server is running FrontPage before reporting. In general, we do not use FrontPage.
- Liferay Portal / Liferay DXP
- Bundled version of Apache Tomcat contains known vulnerabilities: The Tomcat bundles are provided as a convenient starting point and we do not consider it an integral part of the Liferay DXP/Portal application. Apache Tomcat can be upgraded to a newer version independent of the Liferay DXP/Portal.
- CSV command injection: CSV files are just plain text files. If an application that opens CSV files treats the text in the CSV files as commands, we believe that the application opening the CSV file should be responsible for fixing this problem.
- OS command injection in Gogo shell and the script console: The ability to execute OS commands is a known feature and is limited to users with the portal administrator role.
- Directory listing is enabled: Directory listing is enabled on purpose.
- issues.liferay.com (Jira):
- Jira filter disclosures: We do not accept submissions that only informs us that we have publicly accessible Jira filters. As an open source project, many of the filters are public on purpose. To receive credit, you must identify a specific filter that exposes private/sensitive data.
- Log files in Jira: Logs files are often attached to Jira tickets in order to assist with bug fixing so an attached log file is not automatically considered a vulnerability. To receive credit, you must identify the private/sensitive data in the log file.
- Remote code execution in contact administrator form (CVE-2019-11581): This is a false positive if you're only proof is a a DNS resolution.
We appreciate ethical security research and want to encourage it. Therefore we will consider all activities conducted in accordance with this policy as authorized conduct (in accordance with the Computer Fraud and Abuse Act (CFAA) and any similar laws) and exempt from the Digital Millennium Copyright Act (DMCA) and any restrictions set forth in the terms applicable to the concerned applications or services. We will not bring any legal action against security researchers acting in accordance with this policy or accidentally violating this policy acting in good faith.
Except as explicitly permitted above, you are expected to conduct in accordance with all applicable laws. Please note that while we can authorize security research on our own applications and services, any third party applications or services on which Liferay’s applications and services may rely are not covered by this policy and we cannot and do not authorize security research on such third party applications and services.
If you are not sure whether your planned activities are in line with this policy, please reach out to us via firstname.lastname@example.org prior to conducting such activities.