> ## Documentation Index
> Fetch the complete documentation index at: https://docs.37audits.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Latest Version Auditor
> Compares the platform version declared in the software stack with the releases its vendor publishes
**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.
Fix releases carry the security patches for the version you run. Each one skipped leaves a published vulnerability open.
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:
| 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`.
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.
| 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`.
## Output documentation
| 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`). |
## 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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.