October was a brutal month for cybersecurity. Almost every day we discovered a new vulnerability, and almost every night we found ourselves patching exposed systems. Ever since AI started being used at scale to analyze code and hunt for vulnerabilities, the number of CVEs has grown exponentially.
What is a CVE? From Wikipedia:
The Common Vulnerabilities and Exposures (CVE) system, originally Common Vulnerability Enumeration, provides a reference method for publicly known information-security vulnerabilities and exposures. The United States’ Homeland Security Systems Engineering and Development Institute FFRDC, operated by The MITRE Corporation, maintains the system, with funding from the US National Cyber Security Division of the US Department of Homeland Security.[3] The system was officially launched for the public in September 1999.
The Security Content Automation Protocol uses CVE, and CVE IDs are listed on MITRE’s system are the basis for the US National Vulnerability Database.
Today, though, I want to talk about iCVEs đ . Not the âintelligentâ kind, but the sadly “ignored” kind.
CVE-2026-109618 e CVE-2026-109619
Itâs late in the evening on October 20th, and X is buzzing about a massive PHP vulnerability. Supposedly it lets an attacker gain administrative access, fairly easily, to any server running PHP. The attack comes in over HTTP/HTTPS, right through the front door, using a ânormalâ browser, with no way to defend against it. I dig deeper, and itâs very serious. Itâs exactly as described. đ„¶
The next day, October 21st, NIST publishes the CVEs, and I start alerting some of our customers that a critical issue has hit PHP. In case you didnât know, PHP powers the vast majority of the websites we visit every day. One customer in particular still runs a major part of its internal management system on PHP. Itâs a large company, and Iâll come back to them shortly.
RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
By late afternoon on the 21st, the news is spreading like wildfire, and some government agencies go as far as recommending that organizations âdisconnect their servers from the network.â
Letâs update PHP!
Why worry? When a CVE comes out, the vendor usually releases a patch quickly. You install the update and sleep soundly.
How many people regularly run Windows Update on their servers? Many. How many periodically run “apt upgrade” (or the equivalent) on Linux? Some. And how many update all their installed software, not just the operating system, such as PHP, Node.js, or the .NET Framework? Few. Very few. Thatâs why I call them âignoredâ CVEs.
This time, though, things are different. PHP released updates only for versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. What about everything else? Nothing. Youâre on your own. Those versions are too old, long obsolete, and nobody has any interest in maintaining them anymore. But when those old versions are running a business, it becomes a serious problem. A very serious one.
There are millions of legacy PHP systems out there, all vulnerable unless theyâre upgraded.
Letâs update PHP! (take two)
Itâs nearly evening on October 21st, and weâre brainstorming with that large customer running PHP. The system is internal, but itâs accessed from thousands of distributed endpoints. If an attack came, it wouldnât arrive from the Internet. It would come indirectly, through a compromised PC.
I want to pause on this point for a moment: having your systems isolated from the Internet, or protected in various ways, is no excuse for ignoring vulnerabilities. Most successful attacks start by compromising a PC (phishing) or stealing VPN credentials.
We quickly conclude that the system has to be upgraded, and it certainly canât be disconnected from the network.
Weâre talking about tens of thousands of PHP 5 files that rely on extensions that are no longer available. Even the syntax has changed, from ” <? ” to ” <?php “. A straight upgrade from PHP 5 to PHP 8 simply isnât feasible. A brave colleague says: âLetâs do it with Claude!â My thought is that the codebase is so large and so customized that the risk of AI going off the rails is huge. But itâs late, and this is a desperate attempt, so I decide to go along with it. I steer the AI toward very specific tasks and strip the codebase of every unnecessary file.
By 2 a.m. weâre done, and everything works perfectly. Bless you, Claude. The definitive bugfix was then wrapped up early the next afternoon. đ
Why it went well
Aside from a healthy dose of courage, this was still a case with a way out. The old PHP versions couldnât be patched, but a newer, working version existed. It âonlyâ required adapting the code. No re-engineering was needed.
Why it can go badly
Letâs take two random examples đ Dynamics NAV:
Dynamics NAV
The final version of Dynamics NAV was released in December, 2017. Mainstream support ended January 10, 2023, and its extended support (e.g., security updates) period is ending on January 11, 2028. The following changes related to availability of Dynamics NAV products are effective April 30, 2031:
- Service Plan (e.g., EP, AP) coverage ends for Dynamics NAV product
- Subscription licenses for Dynamics NAV (via SPA/DPL) are no longer renewable
- Additional perpetual users on existing Dynamics NAV systems can no longer be added
- Subscription use of Dynamics NAV via SPLA licensing (not to be confused with Solution Provider
Agreement (SPA) program) is expected to end
Or the more ârecentâ Business Central On-Premises:
Business Central 14
Dynamics 365 Business Central on-premises (Fixed Policy) follows the Fixed Lifecycle Policy.
- Start Date Sep 30, 2018
- Mainstream End Date Oct 10, 2023
- Extended End Date Oct 14, 2025
Do you have any idea what it means to migrate a customer from NAV to BC because of a security emergency like the one I just described? The changes are so deep and the re-engineering so extreme that yes, the best option would probably be to disconnect the system from the network.
Conclusion
Waiting for a CVE before updating your systems is like quitting smoking once you can no longer breathe. Sometimes it works out. Sometimes it goes very, very wrong. It shouldnât take regulations like NIS2 to remind us how important cybersecurity is. Plain common sense should be enough.
Today, a company running its core business on NAV seriously risks losing credibility and trust in the eyes of its supply chain and stakeholders. Upgrading isnât an IT project. Itâs a matter of survival.