On Wednesday, I was patching. Not a big platform with a hundred thousand vehicles behind it, just one small system I run for a customer in the fleet space. And I was dealing with the same question for the clients I currently work with as CTO and advisor. If you run software for fleets or transport companies, there is a good chance you spent some part of the week the same way. And if you did not, you might want to check why.
This article covers what happened and what it means for three groups of readers: the companies running fleets, the vendors building fleet management and transport management systems, and the investors buying those vendors. The short version: this week was a dress rehearsal for how software security works from now on.
The Short Version
- If you run a fleet: your fleet management system and your TMS are operational infrastructure, so your vendor’s security posture is your operational risk. Ask your vendors three questions this week.
- If you invest in or acquire fleet software companies: this week handed you a new due diligence question and a short checklist to go with it. Jump to the checklist.
- If you build fleet or transport software: this part is longer, because most of the work sits with you. Start with the seven lessons.
What Happened This Week
On Tuesday, details about two critical remote code execution vulnerabilities in the PHP core leaked before their coordinated disclosure, and the PHP team shipped its fixes a day earlier than planned. The PHP Foundation has published a frank account of how the whole disclosure unfolded, from the first warning signs in a 2024 audit to the AI-assisted reports in August and the leak this week. What matters for our industry:
- The flaws are about as bad as it gets. The two vulnerabilities, now known as PHP2Shell, allow unauthenticated remote code execution, and they trigger before your own application code even runs. One crafted request to a PHP endpoint can be enough to take over the server.
- AI found them. Several security teams found the bugs with the help of frontier AI models, after the underlying weakness had been sitting in PHP for years.
- The attacks came before the patch. Amazon recorded a first exploit attempt four days before the fix shipped. The comfortable window between “patch available” and “first attack” simply did not exist this time.
- Public bodies pulled the plug. Here in Germany, the city of Mainz, the Federal Ministry of the Interior and several state offices for the protection of the constitution were offline for a while. When the agencies responsible for protecting the state pull their own websites, you know you are not looking at a routine Patch Tuesday.
What got a lot less attention happened on the very same Wednesday: Node.js shipped fixes for a flaw in its bundled Brotli decoder that can permit remote code execution. Fittingly, the advisory credits OpenAI’s Codex Security team with the report, so AI found this one too. It is rated high rather than critical, but nobody would call Node.js legacy technology, and that will matter in a moment.
What This Means for Fleet Operators
For fleet operators, this part is short. Your fleet management system and your TMS are operational infrastructure. They hold live vehicle positions, driver data, customer addresses and delivery schedules, and if they go down, your dispatchers are back to phone and spreadsheet within the hour. That makes your vendor’s security posture your operational risk.
So ask your vendors three simple questions this week:
- Were you affected by PHP2Shell or the Node.js vulnerability?
- When was the last affected system patched?
- How do you know you found every affected instance?
A vendor who answers all three calmly and with specific dates is in good shape. A vendor who has to get back to you on the third one is telling you something. Enterprise customers with a procurement and compliance department will ask these questions anyway, and smaller operators should feel free to borrow them. And while you are at it: your company website, your driver portal and that WordPress installation for recruiting probably run on PHP as well.
What This Means for Buyers and Investors
If you are evaluating a fleet management or TMS company for an acquisition right now, this week has handed you a great due diligence question: Show me how you handled PHP2Shell. The answer tells you more about the state of the engineering organization than most architecture diagrams, because it is a real, recent and dated event that nobody had time to prepare a slide for. As I argued in The Fleet Management M&A Situation in 2026, technology risk is increasingly being priced into valuations, and the speed of response to security events is part of that risk.
Here is the short checklist I would work through:
- Time to patch. When did they learn they were affected, and when was the last production system patched? Ask for timestamps from tickets or deployment logs instead of recollections. Hours are good, days are a yellow flag, and “we are still working on it” is a red one.
- Inventory. Could they tell within an hour which systems ran PHP or Node.js, including container images and third-party components? A software bill of materials is a good sign. A frantic search through servers is a bad one.
- Version currency. What share of the platform runs on language, framework and library versions that are still supported? Everything on end-of-life versions is deferred migration cost, and it belongs in the valuation.
- Build pipelines. Can every production system, including the old platform nobody touches anymore, be rebuilt and redeployed from source today? Ask for a demonstration.
- Breach readiness. How would they find out whether they were compromised before the patch, and who decides about a GDPR notification? If nobody knows, the risk sits with their customers, and after closing with you.
- Customer impact. Did they have to take customer-facing systems offline, and what did that do to their customers’ operations?
Asking these questions is easy. Judging whether the answers hold up is harder, and that is where an independent technical assessment pays for itself.
What This Means for Fleet Management and TMS Vendors
Here it gets more interesting. Many fleet management and TMS vendors that have been on the market for a long time run substantial parts of their platforms on PHP. I cannot name names, because I know this mostly from technical due diligence work under NDA, but it is no secret that a lot of our industry’s platforms grew up in the PHP era of the web.
For those vendors, this week meant updating in a hurry, and some of it was certainly rushed. And this is where our industry differs from the ministries and city websites above. They could pull the plug for a day, and apart from some annoyed citizens, nothing much happened. A fleet management or transport management system has become operational infrastructure for its customers. Dispatchers plan tours in it, drivers get their orders through it, customers track their deliveries with it. Take it offline and the 40-tonne trucks stand still in the yard. For most FMS and TMS vendors, switching off is no longer an emergency brake they can pull. The only way out of that dilemma is to be fast enough that you never face it.
So what should vendors take away from this week? A word of honesty before the list: most of these lessons are not specific to fleet management. They apply to almost any SaaS platform, and to most software systems in general. What I try to do here is put them into the context of our industry, with its long-lived platforms, its customers’ deep operational dependency and its many acquisitions, because that context changes how hard each lesson hits. Here are my conclusions.
Lesson 1: The New Normal Hits Every Stack
During my time at Webfleet, a vulnerability serious enough to pull the engineering leadership into a room about our stack came up maybe once a quarter, sometimes only every half year. We had time to assess, plan the rollout and sleep on it. Those were the days. 😅
That rhythm is over. The reason is the same shift I described in From CTO to Developer (and Back): Navigating the AI “Zeitenwende”: AI models now find vulnerabilities much faster than human researchers did, and they help write the exploits just as fast. OpenAI has already said it expects similar findings to increase sharply in the coming months. If your organization still treats a critical vulnerability as an exceptional emergency, you will be in emergency mode a lot. Plan capacity for it, treat it as recurring operations work, and build the processes below around that assumption.
And if you run your platform on Java, .NET or Node.js, please resist the temptation to feel smug about those PHP shops with their old technology. The Node.js flaw came out on the same day, in one of the most modern and widely used runtimes there is. Next week it might be .NET or Java, the other two big enterprise technologies in our industry. Or Go, or Rust, or whatever else you run. Switching technologies does not make you safe. The question is no longer whether your stack will be hit, but when, and how fast you can react when it happens.
Lesson 2: Automate the Detection
Waiting until you read about the next vulnerability on a news portal cannot be the answer for a modern software vendor. By the time it makes the headlines, the exploits are already circulating. Detection has to be automated, and the toolbox for that exists:
- Know what you run. An up-to-date inventory of every runtime, framework and library in production, ideally as a software bill of materials (SBOM) per service. Remember that PHP and Node.js also hide in places nobody checks first: container base images, CI pipelines, admin panels and third-party software that bundles its own runtime, not just your application repositories.
- Scan continuously. Tools like Dependabot or Renovate for dependencies, and scanners like Trivy, Grype or OSV-Scanner for container images, will tell you within hours whether a new CVE affects you.
- Subscribe to the right feeds. Advisories from CERT-EU, the BSI and the projects you depend on should land in a channel someone actually watches.
- Route alerts to owners. An alert nobody owns is a log entry. Every affected component needs a team that is responsible for patching it.
- Let AI do the triage. Ideally, an AI-supported process checks automatically whether a new vulnerability actually affects your configuration, warns the responsible team and prepares the fix, semi-automatically or fully automatically.
Lesson 3: Keep Your Build Pipelines Alive
This one sounds boring, and it is the one I worry about most in our industry. Many vendors run legacy systems that have been in maintenance mode for years. As I described in Why Fleet Management Migrations Take Three Years (If You Are Lucky), old platforms in fleet management tend to live much longer than anybody planned. For those systems, the build pipeline has often quietly rotted away, or it never existed in the first place.
Now imagine you have to swap out a central component on such a system within hours. A library, a framework, or as this week, the underlying language runtime. If nobody can build and deploy that system reliably anymore, you are stuck. Rebuilding a pipeline under pressure takes days, and as we have just seen, you do not have days.
Your build pipeline is software too, and it needs to be maintained like software. A simple test: rebuild and redeploy every service regularly, even if nothing has changed in the code. If that is a non-event, you are ready. If it turns into a project, you have found your next priority.
Lesson 4: Stay on Supported Versions
Back to my small customer system. It was affected by both vulnerabilities: by PHP2Shell because it runs on Coolify, an open source platform-as-a-service that is itself built on PHP, and by the Node.js issue because the backend of the project itself is written in Node.js. I was able to patch both within a short time, for one simple reason: I was already on current, supported versions, so the update was small.
That is the point many vendors underestimate. The PHP project only patched the supported release lines: PHP 8.1 and older no longer receive updates from the PHP project, and PHP 8.2 itself reaches end of life on 31 December 2026. On the Node.js side, Node.js 20 reached end of life in April and gets no fix. If your platform still sat on PHP 7.4 or 8.1 this week, you had two options, both bad: rely on backports from your distribution or vendor (given the severity, the PHP team even published minimal source backports for 7.4 to 8.1 this time), or make a big version jump with all its breaking changes under maximum time pressure. Backports can save you in an emergency, but they are not a strategy.
Staying on supported versions of your languages, frameworks and libraries is a security measure. It turns an emergency migration into a routine update.
Lesson 5: Build Defense in Depth
You also have to accept that you will not be able to patch every vulnerability before it is exploited. The time window is simply too short. That is why you should never rely on a single line of defense, and certainly not on the hope that your own stack is free of bugs. The usual layers of defense in depth are well known, they are just not consistently applied:
- Web application firewalls in front of every public endpoint. They can block known attack patterns before you have patched, which is called virtual patching. Akamai shipped detection rules for PHP2Shell, and Vercel deployed firewall rules for the Node.js flaw on the day of the release.
- Network segmentation, so that a compromised customer portal cannot talk directly to your telematics ingestion, your databases or your internal tools.
- Least privilege for every process. A web worker does not need root, and it does not need access to secrets it never uses.
- Egress filtering. A compromised server that cannot open outbound connections to arbitrary hosts has a much harder time downloading tools or sending your data anywhere.
- Intrusion detection and runtime monitoring. A PHP or Node.js worker that suddenly starts a shell is a very strong signal, and monitoring for exactly that was one of the recommendations this week.
- Immutable infrastructure. Read-only containers that are rebuilt rather than patched in place make it much harder for an attacker to settle in.
- Mitigations you can switch on fast. PHP’s interim recommendation was to disable a single feature,
session.upload_progress, until a patch is available. You can only use mitigations like that if you can roll out a configuration change to all systems within minutes. - Tested backups, for the day all the other layers fail.
Let me be realistic here: hardly any FMS or TMS vendor will put all of these layers in place, and for most of the typical platforms in our industry that would be neither affordable nor proportionate. But the risk calculation has changed. A layer that looked like gold-plating back when a critical vulnerability came along every few months may well be worth its cost when the next one arrives within weeks and the first attacks show up before the patch. And for an industry that cannot simply switch its systems off, every layer that buys time is worth more than it is elsewhere. It is time to redo that risk assessment, and for many vendors the honest result will be to extend their defense perimeter by some of the measures above.
Lesson 6: Prepare to Find Out You Have Been Breached
The uncomfortable consequence of everything above: at some point, an attacker will get in before you have patched. With PHP2Shell, the first attempts came four days before the fix, and Amazon explicitly recommends investigating back to 17 October instead of starting on the day of the patch. So beyond keeping attackers out, you need a way to find out quickly whether one got in.
In fleet management, that question comes with a deadline. Our platforms store personal data at scale: driver data, working hours and, above all, location data that shows where a person was at any minute of their working day. A compromised FMS is therefore very likely a personal data breach under the GDPR. In the usual setup, the fleet operator is the controller and has to notify the supervisory authority within 72 hours of becoming aware of the breach, while the FMS vendor, as the processor, has to inform its customers without undue delay. Neither of you can meet that deadline without a reliable way to tell whether you were compromised at all.
That capability has to be in place before the incident:
- Logs that survive an attack. Web server, application and system logs, shipped to a separate system the attacker cannot wipe, and kept long enough to look back several weeks.
- A known-good baseline. Checksums of your deployed code and images, so you can tell whether files have changed. With immutable containers, comparing against the image is easy. With servers patched by hand, it is guesswork.
- Detection of the obvious signs. Web shells, unexpected processes started by your web workers, new cron jobs or user accounts, unusual outbound connections.
- A rehearsed playbook. Who investigates, who decides whether this is a reportable breach, who talks to customers, and which external forensics partner you call. Deciding this at two in the morning on day two is too late.
None of this is glamorous, and it will never show up in a product demo. But it is the difference between telling your customers “we checked, we are clean, and here is the evidence” and telling them “we don’t know”.
Lesson 7: Use AI to Fight AI
The final conclusion is maybe the most important one. Finding all affected components, pulling new base images, updating or replacing libraries and then fixing the code that breaks because something is no longer supported in the new version: all of this has to happen very quickly now. New PHP versions remove features that old code relies on, Node.js does the same, and so does every other piece of software. This is exactly the kind of work where AI coding agents shine. For a security event, the workflow is straightforward: an agent searches every repository for the affected runtime or library, proposes the upgrade per service, runs the tests before and after the change, and hands each fix to an engineer for review as a separate pull request.
A company with an AI-supported software development lifecycle can go from “new CVE published” to “all systems patched” significantly faster than one doing all of this by hand. AI is part of the problem, so it has to be part of the solution. The companies that try to survive in an AI-powered threat landscape without AI on their own side, swimming against an ever faster stream of vulnerabilities by hand, are the ones that will have the hardest time.
Conclusion
PHP2Shell will not be the last vulnerability of this kind, and probably not even the biggest one this year. Which technology was hit this time is almost beside the point. What matters is how fast your organization can find out whether it is affected, build a fix and roll it out, how well you are protected for the hours in between, and whether you can tell afterwards if someone got in. Automate detection, keep your pipelines alive, stay on supported versions, build defense in depth, prepare for the breach, and put AI to work on your side.
If you are running a fleet management or TMS company and you are not quite sure how your organization would hold up next time, or whether anyone can still build that old platform, that is exactly the kind of question I look at in my work as a fractional CTO. And if you are on the other side of the table and want an independent view on how a target’s answers to the checklist above hold up, that is what I do in technical due diligence. Get in touch if you want to talk it through.
