Community Security Team

The Liferay Community Security Team is an all-volunteer group of community members who manage security issues related to Liferay Portal.

The Liferay Community Security Team pages have moved to the Liferay Developer Network - Community Security Team. Please update your bookmarks, as this page will eventually be removed.

Security Advisory Identifiers

Each individual advisory issued by the CST will be identified with an identifier that is the same as the LPS ticket that was used to initially report the issue (e.g. LPS-26705).  In some cases, this ticket will be private to the CST, and a separate, public ticket will be referenced from the security advisory instead.

Getting Notified

There are a several ways to be immediately notified when new Security Advisories are published:

The CST strives to notify the community as quickly as possible when new vulnerabilities are discovered and corrected, but to ensure you receive these notifications, be sure to follow one of the above channels.

Reporting Security Issues

Like many other open source projects, Liferay believes in Responsible Disclosure. This means that when you are reporting new bugs related to security vulnerabilities, you give Liferay some time to respond (evaluate, resolve) security bugs before its details are publically and fully disclosed. For security-related bugs, follow the guidelines in the JIRA reporting page to report security vulnerabilities to Liferay.

Note that there is a new Security Level that has been added to JIRA.  When reporting security issues, ensure that you select the Secure level.  This ensures that sensitive data included in your report is not made public until the CST has had a chance to evaluate and fix the potential vulnerability.

The Process

  1. An issue is reported and documented on
  2. A fix is developed
    • The CST is not solely responsible for developing fixes for security issues, but as with any open source project, members of the community can submit fixes for any issue, including security issues, by following the general bugfix process.  For SEV-1 issues that are initially private, the CST works with Liferay maintainers to develop a fix.
    • When at all possible, the CST should work with Liferay to review incoming pull requests for all security issues, and recommend changes if needed.
    • The CST should monitor the status of all known vulnerabilities, even if the CST itself isn't involved in developing a fix, for later notification.
    • In some cases, even if the CST isn't involved in the development of a fix, it may be asked to test a fix before the fix is committed.
  3. The fix is committed to Liferay's source code repository
    • Once a fix is developed and tested, a source code commit takes place to one or more repositories. Typically, the fix is first made in the master branch of the main GitHub repository, such that the issue is resolved in all future releases of Liferay. For some issues, fixes might first be made to a private repository, such that patches can be created and distributed first, before full disclosure of the issue.
    • The CST then backports the fix to the existing Liferay release. Here, the CST can recommend that other security fixes also be backported, for the purposes of providing patches to the community.
  4. The CST generates source and binary patches for one or more issues, for the latest Liferay CE release.
    • Liferay's source code for past, current, and future releases is maintained on Github. The CST maintains a separate public repository in which its work is done.  For each known vulnerability, a separate branch is created (which is based on the source code of the current Liferay release), and the fix committed to the branch.  You can see the current list of branches.  The fix is also rolled into a cumulative branch which contains all known vulnerabilities for that release of Liferay.   With the fix isolated on its own branch, a source code patch link is generated (simply a URL to the commit page on github, with .patch appended), and the binary patch for the latest release of Liferay is then updated to include the new fix, by re-building the binary from the cumulative security fix branch, and including any resulting affected binaries in the binary patch. Links to these source and binary patches will be listed as part of the notification process.

    • When a new release is made by the project maintainers, the CST will no longer produce source or binary patches for the old release.  Instead, the CST will begin porting fixes to the most recent release (though the old binary/source patches will still be available)

  5. The community is notified
    • Once an issue is fixed and backported for a given existing Liferay CE release, if the CST was not involved in fixing it, it will be aware that the fix has been made via the JIRA ticket. The JIRA ticket may be made public at that time, or another "sanitized" ticket may be created, to avoid publishing sensitive data from the initial report.
    • The CST is responsible for notifying the community of the newly discovered potential vulnerability, with a brief impact statement, any known workarounds, and documentation on how to fix the issue in the latest CE release. Notifications will be made by posting a new entry to the Known Vulnerabilities list on the CST pages, and making an entry in the Security Advisory forum.
    • The CST will also monitor and respond to queries about specific vulnerabilities via social media outlets such as Facebook and Twitter, or the Liferay Forums.

Patch Details

You've downloaded the latest release of Liferay, so now what?  In general, the easist thing to do is download the cumulative binary patch that the CST produces and apply it to your installation of Liferay, and you should be good to go.  If you've made modifications to Liferay, or are a developer who is comfortable using the Liferay source code, you can also download the set of source patches that make up the cumulative patch, apply each individually to your copy of the Liferay source code, rebuild, and redeploy.

The CST produces source and binary patches that apply to the latest release of Liferay Portal Community Edition.  The CST will not produce patches for older releases, so it is important that CE users be using the latest CE release if they want to get easy-to-apply fixes for critical security fixes.  Most of the time, the process for applying patches will be straightforward.

Source Patches

Source patches are essentially the output of git diff (which is itself related to the output of the unix diff command).  By virtue of the CST maintaining separate branches for each fix (along with a separate cumulative branch), generating patches using github is trivial.  Each source patch can downloaded and applied to a copy of the Liferay source code from the latest released version of Liferay, using either git apply (if you have a proper git clone of the Liferay source) or the unix patch command if you just have a basic Liferay source tree.

Individual source patches may conflict with one another, as they may touch the same lines in the same file.  If you want all of the fixes in source form, it is usually better to get the cumulative source patch (see below).  The CST does not test all possible combinations of source patches.

If you use the patch command on Windows or Linux, be aware that the line ending differences between OS's might cause trouble (Mac OS X seems to handle it with no special procedures).  You may need to use tools to convert line endings, such as dos2unix, before the source patches can be applied.  Read below for specific instructions for your operating system.

  • Linux (Ubuntu, RedHat, Solaris, Illumos, CentOS, SUSE, ...) and other Unix-based OS's other than Mac OS X
cd $LIFERAY_SRC_HOME ; git apply name-of-downloaded-patch-file

If you don't use git, and just have a basic Liferay source tree (e.g. by downloading a raw .zip file from Github), then you can use the unix patch command:

patch -p1 < name-of-downloaded-patch-file

It is recommended that you download the source from Github (from here).  If you have downloaded the source code from, be aware that SourceForge code sometimes contains Windows-style line endings, and you may need to first convert them to unix-style line endings using something like:

cd $LIFERAY_SRC_HOME; find . -type f  -exec dos2unix {} \;

The dos2unix tool may be installed by default on your Linux distribution, or you may need to install it first (using apt-get, pkg, deb, yum, etc). 

  • Mac OS X
cd $LIFERAY_SRC_HOME ; git apply name-of-downloaded-patch-file

If you don't use git, see above for instructions.

  • Windows

Depending on which tool(s) you are using, you can either use git apply (this is the recommended method if you are using git, some tools supply a bash-like shell tool), or consult your git tool's manual on how to apply patch files.  If you don't use git, and just have a basic Liferay source tree (e.g. by downloading from the Liferay distribution files), then you can use the GNU patch command for Windows:

patch.exe -p1 < name-of-downloaded-patch-file

Once the source patches have been applied, the Liferay source will need to be re-compiled to generate binaries, by following the normal development processes for Liferay.

You can also access the cumulative source patch using Github's "compare" feature.  For example, you can download the cumulative security source patch for Liferay 6.1 CE GA2 (6.1.1) and apply it en masse to your Liferay 6.1 CE GA2 (6.1.1) source base, to get the same result as applying each individual source patch.

Binary Patch

To maximize ease of use, ensure quality, and to minimize maintenance, the CST will maintain a single cumulative binary patch for the latest Liferay release that contains all known vulnerabilities (you can see the 6.1 CE GA2 cumulative source patch, from which the cumulative binary patch is generated).  This avoids the problem of binary patch conflicts, where one patch might clobber another patch's binary changes, resulting in a broken and potentially even more insecure system. 

When new security issues are found, the fixes will be added to the existing binary patch, and a new single cumulative binary patch generated (the old patch may still be available but will not contain all of the latest fixes).

Installation of a binary patch depends on the nature of the fixes (some fixes require changes in your app server, others require changes elsewhere).  Due to this, each binary patch will contain an obvious README file that describes how to install the patch.