Skip to main content
Security Auditor — compares the platform version declared in the project’s software stack with the vendor’s security reports: it fails for each vulnerability whose CVSS score is 7.0 or higher (or that the vendor rated Critical or High) and warns for the others.

Known vulnerabilities

A published CVE tells attackers exactly which versions to look for. The audit tells you when yours is one of them.

Severity first

High and critical vulnerabilities fail the audit; lower ones are warnings, so the urgent fixes stand out.
This auditor does not fetch the monitored URL. It reads the software stack of the project, finds the platform a visitor supports, and compares that version with the vendor’s security reports. 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 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.
  2. 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.
  3. 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.
  4. 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).
  5. 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
  6. 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).

​
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 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.

​
Output documentation

​
Risks and considerations

​
Published vulnerabilities

  • 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.

​
Keeping the reports current

  • 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.

​
Version matching

  • 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:
  • 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 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. 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.

​
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 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.