Validates software stack version against latest releases
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.
Read the declared version — an entry without a version is ERROR (502); the release list is not read.
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).
Find the installed release — among the releases of the declared product (DXP or Portal), by any of its names, ignoring case and repeated spaces:
| Accepted form | Example |
|---|---|
| Release name | 2025.Q1.15 LTS, 7.4.3.132 GA132 |
| Release name with the product | DXP 2025.Q1.15 LTS |
| Target platform version | 2025.q1.15, 7.4.3.132 |
| Release key, with or without the product | dxp-2025.q1.15-lts, 2025.q1.15-lts |
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.
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).
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).
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).
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.
| CheckCode | Status | When it fires | Recommendation | Why it matters |
|---|---|---|---|---|
37A-LatestVersionAuditor-100 | INFORMATION | The project has no software stack, or the stack names no supported platform; nothing is audited and the run is not charged (the check carries notApplicable: true). | Empty stack: add {supported} and its version to the project's software stack to audit its version. Other platforms: if the site runs {supported}, add it and its version to the project's software stack to audit its version. | — |
37A-LatestVersionAuditor-500 | ERROR | The release list could not be fetched or parsed, or has no releases. | Run the audit again; the release list at {releaseSource} answered "{error}". | — |
37A-LatestVersionAuditor-502 | ERROR | The stack entry of the platform has no version. | Set the installed version of {platform} {product} in the project's software stack. | — |
37A-LatestVersionAuditor-503 | ERROR | The declared version names no release of the declared product. | Pick the installed {platform} {product} release in the project's software stack; "{declaredVersion}" names no {platform} {product} release. | — |
37A-LatestVersionAuditor-400 | FAIL | The installed release is not the latest fix release of its release line. | Update {platform} from {installed} to {latestInLine}; it is a fix release of the same {releaseLine} line. | Fix releases carry the security patches and bug fixes for the version you run. Skipping them leaves publicly documented vulnerabilities open on the site. |
37A-LatestVersionAuditor-300 | WARNING | A newer release line (major/minor) of the same product exists. | Plan the upgrade of {platform} from the {releaseLine} line to {newestLine} (currently {latestInNewestLine}). | Older release lines age out of vendor support and stop receiving fixes, and every line skipped makes the eventual upgrade larger and riskier. |
37A-LatestVersionAuditor-200 | SUCCESS | Both rules passed. Message is {platform} {installed} is the latest release of {releaseLine}, the newest {product} release line. | — | — |
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.
| Status | Description | Test logic |
|---|---|---|
| INFORMATION | The auditor does not apply to the stack | No stack, or no supported platform in it (100); the run is not charged. |
| SUCCESS | The installed release is the latest of the newest release line | The installed release is the latest of its line and no newer line of the product exists (200). |
| WARNING | Up to date on fix releases, but on an older release line | The installed release is the latest of its line and the product has a newer line (300). |
| FAIL | A later fix release of the installed release line exists | The installed release is not the latest of its line (400). The 300 warning is listed too when the line is not the newest. |
| ERROR | The auditor could not compare the version | Release list unreadable (500); stack entry without a version (502); version that names no release (503). |
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.
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 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.
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.
This documentation is built and hosted on Mintlify, a developer documentation platform.
Add this auditor to your monitoring setup and start identifying issues on your websites today.