Two CVEs from one advisory, two KEV listing dates 25 months apart. The audit form reads them as independent rows.

Most KEV listings are read as fresh-threat signal. The catalog lists a CVE, the deadline starts, the operator either patches inside the window or breaks the row on the audit form. The reading assumes the catalog date approximates the start of the exposure window. For most entries that approximation is close enough to be useful. For CVE-2024-27199 it is off by 25 months.

JetBrains shipped TeamCity On-Premises 2023.11.4 on March 4, 2024 against two CVEs in the same auth filter. CVE-2024-27198 (CVSS 9.8, authentication bypass, full unauthenticated admin) and CVE-2024-27199 (CVSS 7.3, path traversal that reaches 15+ admin endpoints including certificate upload and HTTPS-port reconfiguration) share an attack surface, an advisory, an affected version range, and a fix. The two bugs are reached through different bypass mechanisms; they are not the same vulnerability scored twice. They were exploited together. BianLian ransomware operators were chaining them within days of disclosure to create admin accounts, run commands under the TeamCity service account, and pivot to PowerShell when their Go-language backdoor failed.

CISA added CVE-2024-27198 to KEV on March 7, 2024 — three days after the advisory. CISA added CVE-2024-27199 to KEV on April 20, 2026, with a May 4 federal due date. Twenty-five months between two catalog listings against one advisory. The agency published no explanation for the gap. The most parsimonious read: ongoing opportunistic exploitation of the long tail of unpatched internet-facing instances, not a newly discovered technique. CISA has been adding older CVEs in batches throughout 2026. The exposure evidence for 27199 was always in the record; the catalog row was not.

The structural problem is what the second catalog row encodes for the two populations reading it. For the operator who upgraded TeamCity in March or April 2024, the May 4 deadline is closed already — the change record from two years ago names a fix version that closes both CVEs, and the audit form reads “deadline met” against both. For the operator who did not upgrade, the May 4 deadline is the first federal forcing function against a vulnerability whose exposure window opened 25 months earlier. The catalog row is identical in both cases. The audit form is identical in both cases. The operational posture is not identical, and the form has no field for the difference.

The PCI and FedRAMP narratives compound it. PCI Requirement 6.3.3 writes a one-month patch clock against the advisory date, not the KEV date — the clock has been running for two years on any unpatched host in scope. The BOD 22-01 narrative writes against the catalog date, so the May 4 deadline reads as on-time for any FCEB operator who patches this month. The same operator, the same host, the same CVE: one framework reads compliant-against-deadline and the other reads 24-months-late-against-advisory. The form fields are independent. The exposure window is not.

The narrow remediation question has one answer: TeamCity On-Premises below 2023.11.4 is vulnerable to both CVEs and has been for two years. If you upgraded in 2024 the May 4 deadline is closed. If you did not, the upgrade path is the same one JetBrains documented in March 2024 — 2023.11.4 or later, or the stand-alone security-patch plugin if the full upgrade is blocked. The wider question is what the audit infrastructure does with a catalog row whose listing date trails its advisory date by 25 months. The catalog writes one row. The change record writes one ticket. The SI-2 narrative writes one closure date. None of those carry “the bug was already public for two years.” The operator working from the row alone gets a fresh deadline; the operator working from the advisory gets the original clock. Both are reading authoritative sources. They disagree about when the window opened, and the form cannot encode the disagreement. The editorial corpus keeps arriving at this from different angles: the catalog row is not the exposure window, and the audit narrative needs a field the schemas do not have.