5 min read ยท 1,203 words
This article was written with AI. It was drafted from the sources it cites and checked against the full text of those sources before publishing. How we make articles
Anil Madhavapeddy opened a public pull request to fix a path traversal bug in an OCaml web library, and the attack arrived before the release did. “I noticed probes in my live webserver logs with the exact bug pattern just minutes after opening the PR to fix the issue,” writes Madhavapeddy, a professor of computer science at Cambridge and core maintainer of the OCaml compiler (InfoQ).
That is the pressure behind a quieter change: QEMU shortened embargoes on vulnerability reports to account for increasingly rapid and automated discovery, InfoQ reports (InfoQ). An embargo is the quiet period in which a project fixes a flaw before anyone publishes the details. What happens to that practice when a hint is enough?
What the QEMU policy says
That QEMU shortened embargoes is InfoQ’s summary; the policy text is more pointed. QEMU’s security process limits the confidential period “strictly to the minimum required to develop and publish a suitable patch and allocate a CVE” (QEMU). The reason it gives is specific. Given how widely AI and LLM agents are used for security auditing, the maintainers consider that any disclosure originating from automated tools is “highly likely to be independently re-discovered, potentially many times over in a very short timeframe” (QEMU).
The consequence is written as a default: the maintainers “will generally reject requests for arbitrary embargoes unless high severity, extenuating circumstances can be demonstrated” (QEMU).
Two more lines show how far the process has moved. Triage of confidential issues “may also be performed by one or more automated tools and/or AI agents run by the project” (QEMU). And if no maintainer can produce a patch in reasonable time, the project may publish a low-severity issue with no patch at all (QEMU).
The study behind the worry
How much does a description help an attacker? One study put a number on it. Researchers collected 15 one-day vulnerabilities and gave a GPT-4 agent the CVE description for each; it exploited 87% of them. Without the description, the same agent managed 7% (arXiv).
With the description: 87%. Without it: 7%.
Every other system tested, including GPT-3.5, open-source LLMs and the ZAP and Metasploit scanners, scored 0% even with the description (arXiv).
On this article’s reading, the gap between 87 and 7 is the whole argument about embargoes. The description, not the model, is the scarce input. An embargo works only while the description stays private, and a public pull request, a commit message or a question on a mailing list can each stand in for one.
Madhavapeddy draws the same conclusion from experience. “It looks to me like our security processes need to invert somewhat,” he writes, because one person searching for the class of issue “is sufficient to alert someone else’s agent and let them get exploit code” (InfoQ).
He also tested it on himself. Before examining the patch, he pointed his own agent at the affected code, and it “trivially created an exploit to probe a local live server in under a minute” (anil.recoil.org).
What it costs maintainers
Reports are arriving faster than the people who handle them can work. Nick Craig-Wood, creator and maintainer of rclone, described the change in a Hacker News thread: “In the first 10 years of the rclone project we received about 20 security disclosures through GitHub. We had to deal with over 40 in the last month!” (InfoQ).
On this article’s arithmetic, that is a change of two orders of magnitude. Twenty disclosures in ten years is about one every six months; forty in a month is more than one a day, roughly 240 times the earlier rate.
The reports are not noise. Craig-Wood puts the hit rate at “about 75% of them have a nugget of something which needs looking at” (Hacker News). At that rate, about 30 of the 40 reports in a month needed real work. The queue behind them has slowed all the same. He writes that GitHub’s CVE assignments, which once took two to three days, now run at three to four weeks, “so I have to send the point releases out with CVE-PENDING in the changelog which isn’t ideal” (Hacker News). On the same arithmetic, three to four weeks against two to three days is a wait roughly seven to fourteen times longer.
Access to defensive tooling is uneven as well. Madhavapeddy writes that Project Glasswing has expanded to 150 organisations across 15 countries, including the Linux Foundation, “but ‘mom and pop’ maintainers still don’t have access” (anil.recoil.org). When he asked a frontier model to look for related flaws, it refused, he writes, because he does not have that access (anil.recoil.org).
The objection: speed can break openness
If a public fix is itself the leak, one response is to ship the fixed binary before the source. Adrian Mouat, who works in developer relations at Chainguard, sees where that leads and rejects it, writing that it “breaks the fundamentals of Open Source” (InfoQ). His description of the bind is blunt: “Users are put at risk and have nothing they can do about it” (InfoQ).
On this article’s reading, the study’s numbers answer part of Mouat’s worry. If exploitation falls from 87% to 7% without a description, the useful secret is small and short-lived: the days between a fix existing and a release shipping. That argues for shrinking those days, not for hiding source.
What maintainers can do now
Madhavapeddy suggests three approaches, as InfoQ summarises them: private vulnerability discussions, faster continuous releases, and rapid protocol-level mitigations (InfoQ). The third means building in controls, such as short-lived credentials and revocable capabilities, that can switch off a vulnerable operation without waiting for every client to upgrade (InfoQ).
Madhavapeddy’s own first remedy is to “develop the fixes somewhere really private out of the reach of AI,” and he points to GitHub’s temporary private forks as one place to do it (anil.recoil.org).
For a project without QEMU’s resources, this article’s reading of those sources comes down to four steps:
- Develop security fixes in a private fork, and open the public pull request only when the release is ready to cut.
- Write down an embargo default, as QEMU has, so each reporter’s request is measured against a published rule.
- Rehearse a same-day point release. The window that matters is the one between the fix becoming visible and users being able to install it.
- Ship with a placeholder if the identifier is late. Craig-Wood’s CVE-PENDING changelog entry is unglamorous and it keeps the release moving.
If you maintain a project, the test is quick to run on yourself. Count the hours between your last security fix becoming visible in a public branch and the release that carried it. Madhavapeddy saw probes within minutes of his pull request; QEMU shortened embargoes because it expects the same. That count is the exposure your own process leaves open.