PHP ships two 9.2s today. When would Ruby have told you?

The PHP security team did something unusual this week: they announced a critical release before publishing what it fixes. Today, 21 October 2026, 14:00 UTC, two vulnerabilities, both CVSS v4.0 9.2, with the detail held back until the fix exists. They also reserved the right to go early if the details leak or exploitation shows up in the wild.

That's a good way to run a release. It also leaves a few hours where everybody knows something serious is coming and nobody can do anything yet, which is a fine moment to ask the question in the other direction: when something like that happens in Ruby, how long until your application hears about it?

That turns out to be measurable.

What Ruby has instead

There's no pre-announcement channel. What there is, is ruby-advisory-db, a git repository of YAML files, one per advisory, which bundle-audit reads to decide whether your Gemfile.lock contains anything known to be bad. Today it holds 1,266 advisories.

Every advisory carries its own date: field. The repository's git history says when each file first appeared. The gap between those two is how long your tooling was blind to something that already existed, and it's one command to compute over the whole history.

Three days, and a tail

Over 213 advisories dated in 2026:

	Days from the advisory's date to the database
Median	3
Mean	10.5
p90	27
Worst	192

Three days is good. Better than I expected before measuring, and good enough that for most advisories the honest answer is "you'd have known that week".

The p90 is the number to plan around. One advisory in ten takes more than three weeks to reach the database, and during those three weeks bundle-audit reports your application clean with complete confidence, because the thing it checks against doesn't know yet either.

The three advisories against one gem that this site dealt with last week make the spread concrete inside a single package. Two of them were dated 1 October and were in the database on the 3rd. The third was dated 13 August and arrived on 14 September, 32 days later.

The number I nearly published

The first version of that table used every advisory added to the database since April 2025. It reported a median of 3 days and a mean of 112, with a p95 of 998 days and a worst case of 1,854.

A mean of 112 days is a headline. It's also meaningless, and the ten slowest rows say why:

1854 days  lodash-rails  CVE-2020-8203    advisory 2020-07-15  database 2025-08-12
1708 days  ckeditor      CVE-2021-26271   advisory 2021-01-26  database 2025-09-30
1607 days  ckeditor      CVE-2020-9281    advisory 2021-05-07  database 2025-09-30

Those aren't slow responses to live threats. They're 2020 and 2021 CVEs being imported into the database in 2025, which is maintainers catching up on history and is a good thing rather than a failure. Leaving them in measures the backfill project, not the response time.

Restricting the sample to advisories dated in 2026 removes the backfill and gives the 10.5 above. Same data, same script, one filter, and a figure that's eleven times smaller and actually describes the thing I was asking about.

Your exposure is the database plus your own cadence

The three days is only half of it. The other half is how often you ask.

bundle-audit check --update

That --update pulls the latest advisories before checking, so the tool is never the stale part. What's stale is the schedule. If that command runs in a pre-commit hook, which is where this site has it, your application learns about an advisory the next time somebody commits. On a quiet week that's days. If it runs in CI on every push, same answer with the same hole.

Advisories land on their own schedule. The PHP one is landing at two in the afternoon on a Wednesday, and nobody's branch cares.

So the useful change is small: run it on a timer as well as on a commit. A scheduled job once a day that fails loudly costs nothing and closes the gap between "an advisory exists" and "somebody pushed something". That plus a median of three days is a real answer to the question this post started with.

What a pre-announcement would be worth

Worth noting what PHP is doing here, because Ruby doesn't do it and it's not obvious whether it should.

The upside is real: everybody schedules the upgrade window before the detail is public, so the fix goes out faster once it lands. The downside is the few hours of knowing something is coming, which is precisely when somebody motivated starts diffing commits looking for it. PHP hedged exactly that by reserving the right to release early.

For a Rails shop the practical version is less dramatic and available today. Know where your advisory check runs, know how often, and make sure the answer isn't "whenever we happen to commit".

What this page doesn't cover

Nothing about the PHP vulnerabilities themselves, which at the time of writing are not public. This post uses the announcement as a date and a severity, and takes no position on what the bugs are.

The latency figures measure one hop: from an advisory's stated date to its arrival in ruby-advisory-db. They don't measure the hop before it, which is from a vulnerability existing to anybody writing an advisory at all, and that one is unmeasurable from here and almost certainly larger. Nor do they say anything about severity: a 3 day median across all advisories doesn't promise that the critical ones move faster, and checking whether they do would need a severity field that's present on some of these files and not others.