Scans software stack for known security vulnerabilities
Select the platform — the first stack entry whose vendor contains 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). A version that is not written the way Liferay names its releases is ERROR (503). In both cases the advisories are not read.
| Accepted form | Example |
|---|---|
| Quarterly release | 2025.Q1.15, 2025.Q1.15 LTS |
| 7.x GA release | 7.4 GA132, 7.4.3.132 GA132 |
| 7.x update, fix pack or service pack | 7.4 U92, 7.3 U35, 7.2 FP20, 7.1 SP8, 7.0 DE102 |
Read the security reports — Liferay publishes its security reports (LSV issues) on the customer portal at https://support.liferay.com/security-vulnerabilities. The auditor reads a snapshot of them exported from that page and bundled with it (see Keeping the reports current). A report counts when Liferay classified it as a Confirmed Vulnerability or an Advisory, put it in the DXP category and rated it above None; the library CVEs Liferay marked Not Exploitable, False Positive or Ignored do not. Without a snapshot the auditor falls back to the public advisory feed at https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/rss, which lists only the 20 most recent advisories and stopped in November 2025.
Match the version — each report names the release lines it affects (DXP 2025.Q1, 7.4 DXP (7.4.13)), the last release Liferay checked (2025.Q1.27) and the releases that fix it (2025.Q1.28). The installed release is affected when its line appears in the report and no fix of that line is at or below it (see Version matching).
Rate each vulnerability — the CVSS base score of the report is compared with the fail threshold, 7.0 (the start of the "High" CVSS rating). Many reports carry Liferay's rating but no score; the rating then decides:
score at or above the threshold, or no score and rated Critical or High: FAIL (400), one finding per report
score below the threshold, or no score and rated Medium or Low: WARNING (300), one finding per report
neither a score nor a rating: WARNING (301), one finding per report
Aggregate — ERROR wins, then FAIL, then WARNING. A version affected by high and low vulnerabilities is a FAIL that lists all of them, the highest score first. A version no report affects 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-CVEAuditor-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 vulnerabilities. Other platforms: if the site runs {supported}, add it and its version to the project's software stack to audit its vulnerabilities. | — |
37A-CVEAuditor-500 | ERROR | The security reports could not be read: the snapshot is empty, or the fallback feed could not be fetched or parsed. | Run the audit again; the advisory feed at {advisorySource} answered "{error}". | — |
37A-CVEAuditor-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-CVEAuditor-503 | ERROR | The declared version is not written as a version of the platform. | Pick the installed {platform} {product} release in the project's software stack; "{declaredVersion}" is not a {platform} version. | — |
37A-CVEAuditor-400 | FAIL | A vulnerability whose CVSS score is at or above the fail threshold, or that is rated Critical or High without a score, affects the installed version. One finding per report. | Update {platform} {product} {version} to a release that fixes {id}; the advisory at {advisoryUrl} lists the fixed versions. | The details of a published vulnerability are public, so attackers scan for sites still running the affected version. A high-severity one can let them take over the site or read customer data. |
37A-CVEAuditor-300 | WARNING | A vulnerability whose CVSS score is below the fail threshold, or that is rated Medium or Low without a score, affects the installed version. One finding per report. | Plan the update of {platform} {product} {version} to a release that fixes {id}; the advisory at {advisoryUrl} lists the fixed versions. | Lower-severity vulnerabilities are still public and are often chained with others to reach a serious attack. Each one left open widens what an attacker can try. |
37A-CVEAuditor-301 | WARNING | A vulnerability whose report has neither a CVSS score nor a severity rating affects the installed version. One finding per report. | Read the advisory at {advisoryUrl} to judge the impact of {id} on {platform} {product} {version}, then update to a fixed release. | Without a severity score the risk is unknown, not low. Until someone reads the advisory, the site may be exposed to a serious flaw nobody prioritised. |
37A-CVEAuditor-200 | SUCCESS | All rules passed. Message is None of the {advisoriesCompared} {platform} security reports published up to {date} affect {platform} {product} {version}. | — | — |
Example for Liferay DXP 2025.Q1.27, which LSV-1793 (CVSS 9.3, fixed in 2025.Q1.28) and LSV-1424 (CVSS 6.9) cover:
400 — Liferay DXP 2025.Q1.27 is affected by LSV-1793 (CVSS 9.3, fail threshold 7.0): Unauthenticated Remote Code Execution via JSONWS API.
300 — Liferay DXP 2025.Q1.27 is affected by LSV-1424 (CVSS 6.9, below the fail threshold 7.0): CAPTCHA Bypass for Gogo Shell.
A report without a score reads (rated Critical by Liferay, no CVSS score; fail threshold 7.0) instead.
Audit message — 6 of the 292 Liferay security reports published up to 2026-09-28 affect Liferay DXP 2025.Q1.27; 1 at or above CVSS 7.0 (worst: LSV-1793, CVSS 9.3).
Findings carry the same values in data: id (the LSV key, or the CVE when the fallback feed is used), severity (the CVSS score, absent when the report has none), rating (Liferay's rating, when present), cveIds (the CVE ids the report names, when any), url (the report page), title, platform, product, declaredVersion, failThreshold, advisorySource and advisoriesCompared.
| 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 | No advisory compared affects the installed version | None of the advisories read lists the installed version among its affected versions (200). |
| WARNING | Only lower-severity or unrated vulnerabilities affect the installed version | At least one report affects the version, and none has a CVSS score at or above 7.0 or a Critical or High rating (300, 301). |
| FAIL | A high-severity vulnerability affects the installed version | At least one report with a CVSS score at or above 7.0, or rated Critical or High, affects the version (400). The 300 and 301 warnings are listed too. |
| ERROR | The auditor could not compare the version | Reports unreadable (500); stack entry without a version (502); version that is not a version of the platform (503). |
Once a CVE is published, its description and the affected versions are public. Scanners pick up vulnerable sites within days, long before most teams schedule the update.
Liferay fixes a vulnerability in a later release of the same line (a quarterly patch, a 7.4 update). The advisory names the fixed versions, so the fix is usually a patch update and not an upgrade project.
The reports are read from a snapshot bundled with the auditor.
The audit message and data.advisoriesCompared say how many reports were compared and the date of the newest one. Use the Latest Version Auditor alongside this one: a version that is behind on fix releases is exposed to the older reports too.
The comparison is done by rules, so the same stack and the same reports always give the same result. A report lists Jira version names; these are the forms and what they mean:
| Name in the report | Meaning |
|---|---|
DXP 2025.Q1, 7.4 DXP (7.4.13), 7.0 EE (7.0.10) | The whole release line is affected |
2025.Q1.27, 7.4.13-u92, 7.4.3.132 CE GA132 | A release Liferay checked; its line is affected |
fix 2025.Q1.28, 7.4.13-u93, 7.4.3.112-ga112, 7.2.10-dxp-5 | The first release of that line that is not affected |
fix DXP 2024.Q1 | The line is fixed from its first release |
A release is affected when its line appears in the report, through an affected name or through a fix of that line, and no fix of the line is at or below it. A line without a fix is affected in full. Reports rarely name Portal among the affected versions but do list the Portal release that fixes them, so for Portal the fix is what says the line was affected.
DXP releases are compared with DXP lines and Portal releases with Portal lines. A Portal 7.4 GA100 is compared as 7.4.3.100.
A name that is not one of these forms (Commerce 2.1) is skipped.
The fallback feed is matched the same way as before: its lines are prose (Liferay DXP 7.4 U35 through U92, and older unsupported versions), read as inclusive ranges per product.
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. Other vendors in the stack are not audited.
Hotfixes and patches applied on top of a release are not visible in the stack and are not considered.
It does not fetch the monitored URL and does not detect the running version from the site.
It does not look up vulnerabilities of third-party libraries, plugins or custom code beyond the library issues Liferay confirmed in its own reports.
It does not tell whether a later release exists; the Latest Version Auditor does.
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.