--- title: "No Panic, Just a Plan: How Patch Day Went at b13" url: "https://b13.com/knowledge/php-security-vulnerability-patch-day-b13" description: A critical PHP vulnerability, an early release, and headlines everywhere—yet for our clients it was just an ordinary Wednesday. Here’s how we did it. image: "https://b13.com/fileadmin/_processed_/1/f/csm_b13-blog-header-php-sicherheitsluecke-3000x2000_218ef7ad9c.png" date: 2026-10-22 modified: 2026-10-22 lastUpdated: 2026-10-22 --- # No Panic, Just a Plan: How Patch Day Went at b13 [ TYPO3 ](https://b13.com/knowledge/typo3) [ Security ](https://b13.com/knowledge/security) Critical PHP Vulnerability: How We Got Our Clients Through Patch Day ====================================================================== ![Bild von Benni Mack](https://b13.com/fileadmin/_processed_/c/6/csm_benni_4220bf3f2e.webp) Benni Mack 22 October 2026 [ RSS Feed ](https://b13.com/rss.xml) ![A laptop displays a yellow warning triangle with an exclamation mark, set against a background of keys.](https://b13.com/fileadmin/_processed_/1/f/csm_b13-blog-header-php-sicherheitsluecke-3000x2000_bdd555ccea.webp) On 21 October 2026, the PHP project closed two critical security vulnerabilities—a day earlier than planned. We informed our hosting clients before the headlines hit and patched every server that same evening. Here’s how it went, and why it was just an ordinary Wednesday for most of our clients. What Happened --------------- PHP is the programming language TYPO3 runs on—and powers roughly 60% of the whole internet worldwide. It works on the server and builds the page that ends up in your browser every time someone visits. That’s why a vulnerability in PHP doesn’t affect just one website, but potentially every website built on top of it. On 21 October 2026 at 14:00 UTC (4:00 p.m. in Germany), the PHP project released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. They fix two critical vulnerabilities in PHP’s memory management and error handling (CVE-2026–109618 and CVE-2026–109619). In the worst case, they allow remote code execution—meaning attackers could run their own code on the server. The release was originally planned for 22 October. But because the CVE numbers started circulating online on the afternoon of 20 October, the PHP team moved it up by a day. Along with the numbers, an incorrect CVSS score of 10.0 made the rounds. CVSS is the standard scale for rating how severe a security vulnerability is—from 0 to 10, with 10 being the maximum. The actual score is 9.2: critical, but not quite as dramatic as the first posts suggested. According to the[ PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/), no technical details were leaked. Still, it was critical. And moments like these show whether a team is prepared. ![A group of people seated at tables in a room, surrounded by flames, with a speech bubble stating, "THIS IS FINE.](https://b13.com/fileadmin/_processed_/c/0/csm_fine_47a7019a6a.webp) The Day Before: Assessing the Situation at the Open Source CMS Conference --------------------------------------------------------------------------- When the first reports came out, we were at the Open Source CMS Conference 2026 in Utrecht, Netherlands. The topic came up right away during breaks and in the hallways. And since the conference brings together many people who deal with security in open source projects every day, we could assess the situation with them on the spot. One of the people I talked to was[ John Blackbourn](https://www.linkedin.com/in/johnblackbourn/), who has been part of the WordPress security team for many years and has worked on numerous security releases himself. This outside perspective—from another major PHP-based CMS—helped us take a level-headed view. The consensus on site was pretty clear: take it seriously, but don’t panic. A patch had been announced, no working exploit was known, and the dramatic CVSS score from the first posts had to be taken with a grain of salt. What would really matter was how quickly servers got patched after the release—not how loudly people wrote about it beforehand. **For us, that settled it: we weren’t going to wait until our clients read the headlines.** Inform First, Then Patch -------------------------- That same day, we decided to proactively reach out to all of our hosting clients. The idea behind it: if you first hear about a critical vulnerability from a news ticker, you start to speculate. Is my website affected? Do I need to do something right now? Who’s taking care of it? We wanted to answer these questions before anyone had to ask them. So our first message was short and clear: - what happened and how we assess it - that an official fix had been announced - that we would patch our clients’ servers right after the release - and that nobody needed to take action themselves **No alarm, no tech jargon—just the reassurance that the issue was in good hands with us.** A Clear Plan: Who, When, and Which Server ------------------------------------------- While informing our clients, we also set up an internal action plan. For every server we manage, it was clear who would patch it and in which time slot. That way, there was nothing left to coordinate after the release—we could get started right away. At its core, the plan answered four questions: - **Who?** Clear responsibilities for each server and client—no “someone else will probably handle it.” - **When?** An order based on criticality: publicly accessible, high-traffic systems first. - **How?** An agreed process for rolling out the new PHP version and running a functional test afterward. - **What if?** Dedicated contact for special cases, in case a system didn’t behave as expected. A plan like this doesn’t come out of nowhere. Plenty of companies don’t even know which servers are running where, or on which PHP version. On a day like this, they first have to take stock—while the clock is ticking. With b13, that’s never a question: we know every system we manage, so our clients are always in good hands. And the plan works because we’ve been working closely together as a team for years, know our infrastructure inside out, and know who’s best at what. ### Release at 4 p.m., All Clear by Early Evening On 21 October at 4:00 p.m., the fix was out. From that moment on, our plan kicked in: server by server, everything was updated automatically, tested, and checked off. Everyone knew what to do—there were hardly any questions. In the early evening, we informed all of our clients a second time: the new PHP version is installed, the websites are running, and no action is needed. Two short messages, one calm afternoon—and one less thing on our clients’ plates. Why It Wasn’t an Issue for Almost All of Our Clients ------------------------------------------------------ A PHP update sounds simple. Whether it actually is depends on how up to date the rest of the project is. A TYPO3 installation that hasn’t been touched in years is often stuck on an old PHP version. Then a security patch can quickly turn into an upgrade project—right when time is shortest. That wasn’t the case for almost all of our hosting clients. Many of them use our Evergreen Service: we keep their TYPO3 instances continuously up to date—and with that, the server and PHP infrastructure underneath as well. When the patch arrived, they were already running a supported PHP version, and the update was a routine step. **That’s the real takeaway from this day: security isn’t created the night after a headline. It’s built through all the unspectacular updates that come before.** What About You? ----------------- Did patch day go less smoothly for your project? We’ll take care of your hosting—including security updates before you even have to ask. And with our Evergreen Service, your TYPO3 always stays up to date, along with the tech underneath. [ Talk to us about hosting ](mailto:info@b13.com?subject=Hosting) [ Discover our Evergreen Service ](https://b13.com/evergreen) ### Written by: ![Bild von Benni Mack](https://b13.com/fileadmin/_processed_/c/6/csm_benni_66cce9a81f.webp) b13 co-founder and TYPO3 CMS Core Development Lead, Benni Mack, heads our technical practices, setup and maintenance of our technical infrastructure, and coordinates our open-source contribution. His essential tool: TYPO3 Benni Mack CTO [ more from Benni Mack ](https://b13.com/team/benni-mack)