In plain English
- Vulnerability: a flaw in software that someone could use to do something the software isn't meant to allow.
- Exploit: a working method, often a small program, that uses a vulnerability.
- Patch: the fix a software maker publishes for a vulnerability. It only protects you once it's installed.
- Use-after-free: a memory bug where a program keeps using memory it has already released, which an attacker can sometimes use to take over the program.
- Firmware: the software built into hardware that runs before the operating system starts.
- PHP: a programming language that runs a large share of websites.
- IoT (Internet of Things): devices such as sensors, meters and controllers connected to a network.
- Day-zero (zero-day): a flaw attackers can use before any fix exists.
Your website runs on software that somebody else looks after. When a security fix comes out, the hosting company, IT partner or firm that sold you the booking system tells you it's on the list for next week, and a month ago that would have sounded fine. AI tools now find software flaws faster than they did even a few weeks ago, so is next week still soon enough, and what should you be asking the people who patch your systems?
This week OpenAI published figures for its new security model, GPT-6 Cyber. It says the model found 81 previously unknown vulnerabilities in Firefox that Mozilla rates high severity, and that in the Linux kernel it produced 948 working exploits, against 166 for the model before it. A companion post puts the cost at about $1,279 per working exploit. OpenAI also sent 304 critical findings, with proposed patches, to the kernel's maintainers, the people who write and review the fixes.
The obvious reading of these figures is that AI now does the finding and people are left with the fixing. I'm not sure it's as binary as "finding is fast, fixing has a human bottleneck". I think this is more of a commentary on the process of where we are right now, because it was different a week ago. What changed was the GPT-6 Cyber results and the PHP flaws.
Two weeks ago, the flaws in the news were in PHP, the language a lot of websites run on, and attackers were using them within days of the fixes coming out. The PHP project released fixes for two critical flaws on 21 October, and five days later the US cyber agency CISA added both to its list of flaws known to be used in attacks. A site running PHP was only safe once whoever looks after it had installed the fix.
For Matt Webb, who has hosted his own blog since 2000, keeping up was no longer worth it, and he shut down his web servers in October. He wrote that he was "no longer confident in keeping my own server secure with years of PHP/CGI/apps all on the open internet", and that patching was possible, "but the calculus of whether it is worth my time just tipped."
Mozilla's fixes for the Firefox bugs have started shipping. Its Firefox 159 security advisory on 27 October credits OpenAI with 41 high-severity bugs, and 31 of them are use-after-free errors. That kind of memory bug can let a bad actor take over the browser and break the privacy contract between Mozilla and the user. Mozilla positions Firefox as one of the most privacy-forward browsers, so if Firefox had 81 high-severity bugs that nobody had found, what does that mean for browsers that aren't as privacy-focused?
Patching is slower still inside a big organisation, and I saw why when I worked inside a large company that runs its own IT. It had a lot of infrastructure and IoT tied into it, and local partners who help operate it. Enterprise IT lags behind somewhat in terms of what's allowed to be patched and updated, and it has to move slowly because there are too many moving parts. I know first-hand that some of the local partners don't get up to date as often as they should, and have no awareness of it. In tech companies this might not be an issue. Other corporates might not have the in-house capability, the budget approval or the knowledge.
Some fixes can't be installed at all until another company acts. A firmware flaw published on 22 October has a fix in the public source code, yet a server owner, as The Hacker News put it, "has nothing to install until the maker of their firmware ships a BIOS or UEFI update".
Something has been going back and forth in my head: should we stop worrying about day-zero vulnerabilities, the ones with no fix yet, and worry about day-zero possibilities, the things we don't know about? Is that just hyperbolic? I don't know. The evidence is clearer on another risk, the time between a fix being published and someone installing it. ENISA, the EU's cybersecurity agency, citing Verizon's breach report, says that "from late 2022 to late 2023, 60% of breaches exploited known vulnerabilities for which patches were available but not applied".
Two people who work in security wrote about this on LinkedIn. Sundari Parekh, a global chief information security officer, wrote that the honest answer to "Are we protected?" is rarely that the patch is already in, and Nicholas Torres, who assesses suppliers' security, asked who updated your firm's website this week.
Sundari Parekh, global chief information security officer · LinkedIn
Nicholas Torres, supplier risk assessor · LinkedIn
Whether next week is soon enough is a really difficult question to answer, because I'm not the expert here; the IT provider or supplier is. I have no control over when a fix arrives, and surely they have no control over it either. So I'd ask less about how fast they fix things and more about what measures are in place: either through the contract or through discussions with the vendor, I would want to know what systems they have in place to secure my data while a fix is being procured. Ask the suppliers and IT partners you depend on two questions: do any of your products bundle software like PHP, and what protects our data until a fix is installed? The UK's National Cyber Security Centre (NCSC) asks organisations to chase suppliers whose products bundle PHP. If you run a PHP site yourself, the PHP project says versions 8.1 and older no longer get updates from the project, so moving to a supported version comes first. And when Firefox, Chrome or Safari asks you to restart for an update, do it that day.
*Kit Library members can copy an email to send each supplier asking what their product depends on and what protects their customers' data until a fix is installed.*