This week a PHP patch shipped a day early because the embargo leaked, kernel bug reports landed on public mailing lists before anyone had a fix, a GitLab flaw rated 10.0 turned out to reach back to a version from 2014, and a certificate authority announced it is leaving the TLS business while Chrome prepares to stop trusting one of its roots on Tuesday. Different stories, different vendors, one pattern: none of these dates were set by the people who have to act on them.
Most IT organizations still run their infrastructure on an internal clock. There is a monthly patch day, a change advisory board that meets on a fixed weekday, a maintenance window that was negotiated with the business years ago and that nobody really wants to touch again, and honestly, for a long time that worked, because the outside world was polite enough to mostly fit into it.
That world is gone. Not because anybody decided it, but because the clocks that matter now belong to someone else.
Look at what happened between Saturday and Friday. On October 17, according to Amazon Threat Intelligence as quoted by Tenable, the first exploitation attempt against what is now called PHP2Shell hit its honeypot network, four days before public disclosure. On October 20 a post on Hacker News announced the two flaws, was taken down, and screenshots spread anyway. The PHP project moved its release to October 21, "a day earlier than the original embargo," as Huntress put it, and Tenable quotes Amazon a little later with "php2shell is now being broadly exploited in the wild." On the same day GitLab shipped fixes for CVE-2026-110264, CVSS 10.0, affecting self-managed installations back to version 7.0, "released in 2014," with no interim workaround. On October 23 Cyber Security News reported that six vulnerability reports from Trend Micro's Zero Day Initiative ended up on public mailing lists, two of them KSMBD issues rated 9.0, with no fix in mainline and no CVE at the time of writing.
And in parallel, the trust layer moved. Mozilla and Chrome blocked compromised intermediate certificates with trivially guessable keys on the day the weakness was found. A few days later the issuing CA announced its exit from the global SSL/TLS business, Mozilla had already decided on October 20 to stop trusting the affected root, and Chrome's distrust is expected to reach users on the morning of October 27, Pacific time.
None of these dates were in anybody's change calendar. Yes I know, some of this is bad luck, a leak here, a mistake there. But if your process only works when nobody leaks, nobody makes a mistake and every vendor ships on schedule, then you don't have a process. You have a hope with a calendar attached.
This week showed three clocks that run independently of anything an IT department decides.
The disclosure clock. Coordinated disclosure is still the norm and it still matters, but this week showed how fragile the timing has become. An embargo can end with a forum post. A report can go to the wrong list. An attacker can be four days ahead of the advisory. The VMware Cloud Foundation team wrote it plainly at the start of the month: "Malicious actors use automated tooling to weaponize zero-days and newly disclosed security flaws within hours of disclosure." Hours. Not change-board cycles.
The trust clock. Trust is not a property of your servers, it is a decision somebody else makes about them. When Chrome tells operators they "must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store," your internal timeline is irrelevant. And here is the part I find most interesting: according to the CA's own estimate reported by The Hacker News, about 97% of the affected certificates were issued via ACME, so automated. And still Chrome told the CA, as The Hacker News reported, that "standard ACME clients do not replace certificates outside their renewal window" unless they support ACME Renewal Information or "someone steps in by hand." That is exactly what is happening this weekend. Admins are swapping certificates manually that were supposedly handled by automation.
The vendor clock. Vendors are speeding up because they have to. VMware moved to monthly software updates, as The Register reported, "in part to address bugs found by AI," and Broadcom delivers Express Patches for VCF 9.1 monthly through VCF Operations, between the larger releases. That is the right direction. But Broadcom's Prashanth Shenoy also admitted to The Register that customers struggled to keep up, because "it takes time to test the impact of patches," and that they need "room to breathe." The vendor clock got faster, the customer clock did not.
If the clocks are not yours, the honest answer is not to work harder inside your maintenance window. It is to own the four things that decide how fast you can react when someone else's clock rings.
Inventory: you can only patch what you know is there. PHP2Shell is a perfect example. The patch was out within about a day. The hard question was a different one: where are we actually running PHP? Huntress was very direct about it, "PHP is everywhere," including in vendor appliances and Windows software that bundles php.exe or php-cgi.exe, in control panels and in the usual CMS suspects. Trust is no different. BleepingComputer cited Mozilla's Dennis Jackson: the built-in curl on macOS may keep trusting the compromised intermediates because its bundle doesn't check revocation. The same article listed several other trust stores as still pending. Browsers are the easy part. Appliances, Java keystores, container images, backup agents and that one script with curl in it, those don't get a Chrome update. If you don't know how many trust stores you have, you don't know how long you are exposed.
Trigger: automation you can't start on demand is just a schedule. This is my favorite lesson of the week. ACME was supposed to solve certificate pain, and for routine renewals it does. But the moment you need everything renewed now, a client that only wakes up in its renewal window is not automation, it is a timer. Let's Encrypt already recommends ARI because "ARI allows Let's Encrypt to tell your client when to renew," and with default certificate lifetimes going to 64 days in February 2027 the same logic gets more important, not less. The same applies to patching. A pipeline that can only run on the second Tuesday is a calendar entry with extra steps. The test is simple: can you trigger it, for one component, today, without opening a project?
Priority: decide before the advisory, not after. When a CVSS 10 for GitLab, two critical PHP flaws under active exploitation and a certificate distrust all land in the same week, the bottleneck is not the patch. It is the conversation about what goes first. That conversation does not belong in a Monday CAB meeting after the weekend is already lost. It belongs in a pre-agreed rule: internet-facing and actively exploited goes immediately, with a defined emergency path and a named person who can say yes. Huntress gave exactly that advice for PHP, patch internet-facing systems first.
Rehearsal: the emergency path must be a path you have walked. GitLab's advisory mentions that two of the fixed releases include database changes that mean downtime on single-node servers. PHP 8.1 and older no longer get official releases, only minimal source backports, so for some environments the realistic options are backports, mitigations or taking the system offline. Not decisions you want to make for the first time on a Saturday night. If you have never actually run an out-of-band change on your platform, from download to rollback, then your emergency process exists on paper only. This is also where I would put tools like virtual patching. They buy time, and that is valuable. But time is only useful if you use it for the real fix, otherwise you have just moved the clock, not owned it.
Partly, yes. Inventory, prioritization and tested change paths have been on every security checklist for twenty years. What changed is the margin. When disclosure was predictable and certificates lived for a year, a weak inventory or a slow CAB cost you some risk and an audit finding. When exploitation starts before the advisory, when trust decisions are made in a day and when your vendor ships monthly partly because AI finds more bugs, the same weakness costs you the weekend, or worse.
Many organizations still look in the wrong direction. They ask whether the vendor is fast enough, whether the CA is trustworthy enough, whether the open source project handled the leak well. All fair questions, none of them yours to answer. The question that is yours: when the next clock rings, which of the four do we already own, and which ones do we only assume?
On a private cloud this becomes very concrete. The platform gives you the tooling: lifecycle management, monthly Express Patches, live patching, health checks. What it can't give you is the decision. Who may trigger a patch outside the window, which workloads are internet-facing, which appliances carry their own trust store, which emergency path has actually been tested. That part tends to stay vague until a week like this one.
If most answers are "it depends," that is not a failure. It is a to-do list, and it should be written down this month, not discovered next time.
Nobody can control when the next embargo leaks or when a browser decides a root is no longer trustworthy. You can control whether that moment hits an organization that already knows what it runs, can pull the trigger and has decided what comes first. Waiting for the change window is also a decision. It is just the one that someone else's clock makes for you.
#DecideOrGoHome
At comdivision we spend most of our time in exactly these questions: VCF lifecycle, patch and certificate processes, and the operating model behind them. If you want to compare notes on how your team handles the next out-of-band week, reach out to me.