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.

Submission

Reports via email can be sent to security@liferay.com. For secure communication, our PGP key can be found here.

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 Ask, Liferay Community Blogs, and Liferay Community Slack and social media.

Please attach all images and videos supporting your report directly to your email. 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.

Reward

We do not offer any monetary reward, but we do publicly recognize new and unique reports on our Hall of Fame.

Disclosure Process

  1. Within five business days of receiving a report, Liferay will acknowledge the report and attempt to reproduce the issue using the supplied information.
  2. Liferay will fix and (if applicable) release patches for affected applications.
  3. Liferay will notifiy the reporter that the vulnerability has been fixed.
  4. If appropriate, Liferay will assign a CVE ID to the vulnerability. Unless specifically requested by a reporter to do so earlier, the CVE ID will be assigned just prior to publication of the advisory.
  5. An advisory will be published on the known vulnerabilities page.

Scope

  • In Scope:
    Application AlloyEditor
    Application AlloyUI
    Application Clay
    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 Metal.js
    Application PortletMVC4Spring
    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 *.alloyeditor.com
    Website *.alloyui.com
    Website *.clayui.com
    Website *.liferay.cloud
    Website *.liferay.com (except subdomains listed in the out of scope section below)
    Website *.liferay.design
    Website *.liferay.dev
    Website *.sennajs.com
  • Out of Scope:
    Application Applications in Liferay Marketplace that are not owned by Liferay
    Website *.lfr.cloud
    Website events.liferay.com
    Website help.liferay.com
    Website login.liferay.com
    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 (e.g., *.lxc.liferay.com).
    Other Physical intrusions

Notes

  • 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 welcome reports of vulnerabilities against unsupported versions, however, it may not qualify for credit on 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 report.
    • We do not give credit for reports 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 reports 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 accept reports for all applications that are owned by Liferay, but we may not give credit in our hall of fame for applications that are labeled as “Labs”.
  • web.liferay.com:
    • We currently only accept reports for critical vulnerabilities (e.g., server compromise, authentication bypass, complete service unavailability)

Common Exclusions

The following are common reports we receive that we consider as acceptable risk, false-positive, and/or out-of-scope.

  • General:
    • 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.
    • Missing CSP headers: We are aware of this issue and treat it as an acceptable risk.
  • 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.
    • Remote code execution in Gogo shell and the script console: The ability to execute arbitrary code is a known feature and is limited to users with the portal administrator role.
  • docs.liferay.com:
    • Directory listing is enabled: Directory listing is enabled on purpose.
  • issues.liferay.com (Jira):
    • Attached log files: Tickets from Liferay open source projects often have log files attached to a ticket to assist with bug fixing. A log file associated with an open source project or from a non-production environment is most likely not a vulnerability. If you believe the file contains sensitive information, your report must identify the sensitive information within the log file and explain why you believe the information is sensitive.
    • Information disclosures: We do not accept report that only informs us that we have publicly accessible infomration (e.g., Jira filters, attachment). As an open source project, many of the information are public on purpose. When sending a report, please identify the specific private/sensitive data that is exposed and explain why you believe the information is sensitive.
    • Remote code execution in contact administrator form (CVE-2019-11581): This is a false positive if you're only proof is a DNS resolution.

Safe Harbor

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 security@liferay.com prior to conducting such activities.