Skip to main content
Security Auditor — compares the platform version declared in the project’s software stack with the vendor’s release list: it fails when a later fix release of the same release line exists and warns when a newer release line exists.

Security patches

Fix releases carry the security patches for the version you run. Each one skipped leaves a published vulnerability open.

Upgrade debt

Release lines age out of vendor support. Every line skipped makes the next upgrade larger.
This auditor does not fetch the monitored URL. It reads the software stack of the project, finds the platform a visitor supports, and looks that version up in the vendor’s public release list. The first supported platform is Liferay (DXP and Portal); other platforms can be added as new visitors that reuse the same rules and codes.

​
How it works

  1. Select the platform — the first stack entry whose vendor is Liferay (any case) is audited. No stack, or no supported vendor in it, is INFORMATION (100): nothing is audited and the run is not charged.
  2. Read the declared version — an entry without a version is ERROR (502); the release list is not read.
  3. Fetch the release list — https://releases-cdn.liferay.com/releases.json, with a 10 second timeout. A network error, a status other than 200, an unreadable body or a list without releases is ERROR (500).
  4. Find the installed release — among the releases of the declared product (DXP or Portal), by any of its names, ignoring case and repeated spaces: A version that names no release of that product is ERROR (503). 7.4 GA56 is a Portal release, so it is unknown under DXP.
  5. Latest fix release — the release line is the group Liferay publishes the release in (2025.Q1, 7.4). Its latest release is the one Liferay marks as promoted. Lines without a promoted release (7.1, 7.0) use the first release of the list, which is ordered newest first, unless a later entry is plainly higher. An installed release other than the latest of its line is a FAIL (400).
  6. Newest release line — the highest release line of the same product. DXP is compared with DXP lines and Portal with Portal lines, so Portal 7.4 is never told to move to a DXP quarterly release. An installed release on an older line is a WARNING (300).
  7. Aggregate — ERROR wins, then FAIL, then WARNING. A release that is behind on both is a FAIL that lists both findings. The latest release of the newest line is SUCCESS (200).

​
What it audits

Every row maps to one checkRule* method and one CheckCode. CheckCode suffixes use status ranges: 200 success, 300–399 warning, 400–499 fail, 500–599 error. The audited page is not fetched, so there is no 590 (site blocked) code. Example messages for Liferay DXP 2025.Q1.15 LTS while 2025.Q1.28 LTS and the 2026.Q3 line exist:
  • 400 — Liferay DXP 2025.Q1.15 LTS is behind DXP 2025.Q1.28 LTS, the latest release of the 2025.Q1 line.
  • 300 — Liferay DXP 2025.Q1.15 LTS is on the 2025.Q1 release line; the newest DXP line is 2026.Q3 (latest release DXP 2026.Q3.6).
Findings carry the same values in data: platform, product, declaredVersion, installedVersion, releaseLine, latestInReleaseLine, newestReleaseLine and latestRelease.

​
Output documentation

​
Risks and considerations

​
Fix releases

  • A fix release (a Liferay quarterly patch such as 2025.Q1.28, a 7.4 update, a service pack) changes no feature on purpose: it ships security patches and bug fixes for the line you already run. Liferay publishes the vulnerabilities each one closes, so a site that stays behind runs with known, documented holes.
  • This is why an outdated fix release is a FAIL and not a warning.

​
Release lines

  • Moving to a newer release line (for example 2025.Q1 to 2026.Q3) is an upgrade project, not a patch. It is reported as a WARNING so it can be planned.
  • A site on a long-term support (LTS) line gets the warning as soon as any newer line of its product exists, LTS or not. Staying on a supported LTS line is a valid choice; treat the warning as a reminder, and keep the fix releases current.
  • The auditor does not read the end-of-support dates of a line.

​
The software stack is declared, not detected

  • The verdict is only as good as the version in the project’s software stack. Update the stack when the site is patched, or the audit keeps reporting the old version.
  • Only the first Liferay entry of the stack is audited.

​
What this auditor does not check

  • It does not fetch the monitored URL and does not detect the running version from the site.
  • It does not look up vulnerabilities for the installed version; the CVE Auditor does.
  • Hotfixes and patches applied on top of a release are not visible in the stack and are not considered.