In March 2024 JetBrains shipped TeamCity 2023.11.4 to fix CVE-2024-27198 and CVE-2024-27199 and its advisory told customers that the finder would publish full technical details within 24 hours of the announcement. What does a 24-hour window change about how the customer notice is written, and where would copying this be a mistake?

The situation they were in

CVE-2024-27198 is an authentication bypass in TeamCity On-Premises before version 2023.11.4, scored CVSS 9.8: reachable over the network, no credentials, no user interaction. A build server is a high-value target because it holds the deployment credentials for everything it builds, so the blast radius of one compromised TeamCity instance is every artefact it signs and every environment it can push to.

Rapid7 found and reported both issues. Rapid7's published timeline states that JetBrains asked to release the patches privately and Rapid7 declined, citing its own disclosure policy. JetBrains' advisory named Rapid7 and said plainly that the full technical details would be public within 24 hours. CISA later added CVE-2024-27198 to its Known Exploited Vulnerabilities catalogue, and JetBrains reported receiving multiple reports from customers whose servers were compromised because they could not patch in time.

What the 24-hour clock changes about the notice

A silent patch buys time only while nobody else holds the details. Once a third party has them and a policy that says publish, the interval between your release and working exploit code is set by that third party, not by your customers' change-management calendars. The notice stops being a record and becomes an operational instruction with a deadline on it.

That forces four things into the top of the document, in this order:

1. The fixed version number and the single action, before any narrative. An operator who reads one line must still patch correctly.
2. The exposure condition - here, whether the server is reachable from the internet - so a reader can decide in 30 seconds whether they are in the fast lane or the slow one.
3. A mitigation for operators who cannot restart a build server today, because a build server is exactly the machine with a six-hour queue on it. Without this, the people most at risk have nothing to do with the notice.
4. The detection signal, so a customer who patches on day three can still answer "was I hit between release and patch".

Stating the 24-hour window publicly is itself a trade-off: it tells attackers the same thing it tells operators. The alternative, saying nothing about the clock, leaves customers budgeting a normal patch cycle for a window that is about to close.

What it cost them

The honest cost is that the patch, the advisory and the exploit arrived inside one working day for most of the world, which is less time than many organisations need to approve an emergency change to a build system. The customers who were compromised were, by JetBrains' own account, the ones who could not move inside that window. No wording would have saved all of them, and wording that led with the version and the exposure condition saved some.

Where copying this would be a mistake

• If you found the bug yourself and hold the only copy, you set the clock. Stage the rollout, give large customers private notice, and publish details on your own schedule. Compressing voluntarily is self-harm.
• If your product auto-updates or runs as a managed service, the patch lands before the advisory and the advisory's job is reassurance plus a log-check procedure, not urgency.
• If the vulnerability needs authenticated access and an unusual configuration, a 24-hour framing trains your customers to discount your severity ratings. Spend urgency only where exploitation is cheap.

Common weak answers

• "Ask the finder to delay." This had already been tried and refused. A disclosure policy you do not control is a constraint, not a negotiation.
• "Publish nothing and patch quietly." Quiet patching is what makes the third party's publication maximally damaging: your customers learn the severity from the exploit write-up rather than from you.
• "Add a severity score and let teams prioritise." A score is a number to argue about. The exposure condition and the one action are instructions to execute.