> ## 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. # CVE Auditor > Compares the platform version declared in the software stack with the vulnerabilities its vendor publishes **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. A published CVE tells attackers exactly which versions to look for. The audit tells you when yours is one of them. 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. | 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` | 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](#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](#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. | 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`. ## 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** | 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`). | ## 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](/auditors/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: | 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 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.