Skip to main content

SEC.CFG.PATCH_EOL — The server runs a release series that is out of support

  • Category: security
  • Severity: high
  • Level: 0
  • Confidence: deterministic
  • Downtime class: none — the finding is about the server's version, not about a statement
  • Stability: stable
  • Suites: audit
  • Applies to: PostgreSQL 18, MySQL 8.4

The finding is about the future, which is why it does not wait for a CVE​

An out-of-support server is not insecure the moment support ends. Nothing changes on that day: the same queries return the same rows, and no scanner finds anything new.

What ended is the supply of fixes. When the next vulnerability in that engine is found — and one will be — supported series receive a patch and this one does not. The interval between a fix existing for everybody else and an exploit existing for the rest is measured in days.

So the rule reports a countdown that has already started, rather than a defect you can reproduce. That is also why there is no configuration change that answers it: the remediation is a major upgrade, planned and scheduled.

Why high and not critical​

critical is reserved for exposure that has been demonstrated — a credential in the open, a grant that hands the database to anybody who asks. Nothing here is known to be exploitable today.

A team that has to plan a major upgrade needs to know it is overdue. Telling them the building is on fire spends the weight that a real fire will need.

What the rule reads​

-- What the server answers, and what the rule reads.
SHOW server_version;   -- 13.22
-- PostgreSQL 13 left support on 2025-11-13: no further minor release
-- will ever carry a fix for it.
-- The same question on a series still inside its window.
SHOW server_version;   -- 18.4
-- PostgreSQL 18 is supported until 2030-11-14.

There is no SQL that fixes this, which is unusual for a finding and worth saying plainly: the remediation is a major upgrade, planned and scheduled, and no setting substitutes for it. The examples show the READING rather than a repair because that is the entire surface a database exposes here -- the rule judges what the instance says it is.

Where the dates come from, and what they can and cannot say​

The verdict is reached offline, from resources/data/eol.json, which this package ships. That is deliberate: a check that had to reach the network would be unusable on a CI runner without egress, and would answer the same question differently on two days.

Three files can answer, in a fixed order:

  1. a path you configure in sqlens.security.advisories.path
  2. resources/data/eol.json published into your own application
  3. the copy bundled with the package

The file that actually answered is named in the finding. Without that, a refresh that landed somewhere nothing reads would look exactly like a refresh that changed nothing.

The dates record premier support for MySQL rather than extended. Extended support exists, is purchased separately, and is not what most projects are on — recording the later date would let a server that stopped receiving routine fixes read as supported.

What it says when it cannot tell​

Three answers are not findings about your server but statements about the check:

SituationWhat you get
the series is not in the data at allundetermined — the server is newer than the file, or older than anything it records, and neither is a verdict
the version string could not be readundetermined, naming the string
no advisory file could be readundetermined, naming which path was tried and why it failed

None of them is a pass. A version with nothing to hold it against is not a version in support.

False positives​

A vendor-patched build that carries security fixes past the upstream date reads as out of support here, because the version string is all a server offers and it does not distinguish a distribution's backports from upstream's own releases. That is the honest limit of an offline check: the alternative would be trusting a build suffix, which anybody can set. Such a server is suppressed through the baseline once, with the reason recorded.

  • SEC.CFG.TLS_DISABLED — another finding about the server itself rather than about anything a migration wrote.