Skip to main content
Security Auditor — places the platform version declared in the project’s software stack in its vendor’s service life: it fails when the release line is past, or within six months of, its end of life, and warns when end of life is within a year or the line is already in Limited Support.

Patch stream

A release line past its end of life receives no security patches. Every vulnerability published after that date stays open on the site.

Upgrade lead time

A platform upgrade takes months. Knowing the date a year ahead keeps the site supported without an emergency migration.
This auditor does not fetch the monitored URL. It reads the software stack of the project, finds the platform a visitor supports, and looks the installed release line up in the service-life policy the vendor publishes. The first supported platform is Liferay (DXP and Portal), against the Liferay Service Life Policy; 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 (101): 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. Find the installed release — https://releases-cdn.liferay.com/releases.json is fetched with a 10 second timeout (a network error, a status other than 200 or an unreadable body is ERROR 500) and the declared version is matched against the releases of the declared product (DXP or Portal) by any of its names, ignoring case and repeated spaces, exactly like the Latest Version Auditor: 2025.Q1.15 LTS, DXP 2025.Q1.15 LTS, 2025.q1.15, dxp-2025.q1.15-lts, 7.4.3.132 GA132, 7.4.13-u92. A version that names no release of that product is ERROR (503). The release line is the group Liferay publishes the release in (2025.Q1, 7.4).
  4. Liferay Portal — Liferay publishes no service life for Portal (the community edition): only its latest GA release receives fixes. A Portal release is a WARNING (302) with no dates.
  5. Service-life dates of the line — for DXP, the line is looked up in the table of the Liferay Service Life Policy bundled with the auditor (the policy page serves the table as an image behind a bot challenge, so it cannot be read at audit time). The bundled edition is the 2026 table, read on 2026-10-05, covering DXP 7.0 to 2026.Q4; the 100 check names the edition in every result. A quarterly line that is newer than the table gets its dates from the policy rules: the first release of the line (2026.q2.0) publishes its general availability date in release.properties (since 2026.Q1); a non-LTS quarterly line has one year of Premium Support and no Limited Support, and the Q1 line of each year is LTS with three years of Premium Support followed by two years of Limited Support, each phase ending the day before the anniversary. A DXP line that is in neither place is ERROR (504).
  6. End of life — the last day of Limited Support when the line has that phase (7.x and LTS lines), otherwise the last day of Premium Support. The day count is from the day the audit runs (UTC).
  7. Thresholds — end of life in the past is FAIL (400); end of life in at most failDays days (default 180) is FAIL (401); in at most warningDays days (default 365) is WARNING (300). A line past its Premium Support but still in Limited Support is WARNING (301), listed next to the end-of-life finding when both apply.
  8. Aggregate — ERROR wins, then FAIL, then WARNING. A line in Premium Support with more than warningDays days left is SUCCESS (200).

​
Preferences

Both are optional per-URL preferences; an unset, unreadable or non-positive value takes the default.

​
What it audits

Every row maps to one checkRule* method and one CheckCode. CheckCode suffixes use status ranges: 100 information, 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 messages for an audit run on 2026-10-05 with the default thresholds:
  • 400 — Liferay DXP 2025.Q3.5 reached end of life on 2026-09-02 (33 days ago): the 2025.Q3 line receives no fixes or security patches.
  • 401 — Liferay DXP 2025.Q4.3 reaches end of life on 2026-11-25, in 51 days (fail threshold: 180 days).
  • 301 — Liferay DXP 7.3 U36 left Premium Support on 2024-10-12; the 7.3 line is in Limited Support until 2027-10-12 (critical security fixes only).
  • 302 — Liferay Portal 7.4.3.132 GA132 (Community Edition) has no vendor service life: Liferay fixes only the latest GA release of Portal.
  • 200 — Liferay DXP 2026.Q1.13 LTS is in Premium Support until 2029-03-17; the 2026.Q1 line reaches end of life on 2031-03-17 (1624 days left).
Findings carry the same values in data: platform, product, declaredVersion, installedVersion, releaseLine, lts, communityEdition, generalAvailability, endOfPremiumSupport, endOfLimitedSupport, endOfLife, daysToEndOfLife, datesSource (table or release.properties rule), failDays and warningDays.

​
Output documentation

​
Risks and considerations

​
End of life is a security date

  • After its end of life a release line gets no patches of any kind. Every vulnerability Liferay publishes from then on is open on the site for good, which is why an end-of-life line is a FAIL and not a warning.
  • Limited Support only brings fixes for critical vulnerabilities. A site on 7.3 today still gets those until 2027-10-12, but no hotfix for anything else; the 301 warning marks that phase.

​
The table is a snapshot

  • The dates of the 7.x and quarterly lines come from the 2026 edition of Liferay’s Service Life Policy table, read on 2026-10-05. Liferay can revise its policy; the 100 check names the edition the audit used.
  • A quarterly line newer than the table is dated from its general availability date with the policy rules, which may differ by one day from the date Liferay later publishes.
  • Liferay Portal (community edition) has no published service life, so no date is reported for it.

​
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 upgraded, or the audit keeps reporting the old line.
  • 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 say whether a later fix release exists; the Latest Version Auditor does.
  • It does not look up vulnerabilities for the installed version; the CVE Auditor does.