26 October, 2026
In AppSec preparation is 99% of the battle
October 20th, PHP.net has published an advanced notice of two critical vulnerabilities in the PHP engine. PHP is the technology that powers the world wide web as 70% of the websites are running on PHP. As opposed to many organizations out there, we have a healthy skepticism towards raw CVE severity scores. Ever heard of the story “the boy who cried wolf”? Same thing. Various publications have demonstrated that the centralized database of all vulnerabilities (or the NVD) contains significant noise with very inconsistent severity scoring. So every vulnerability report runs through our triaging process that involves analyzing several factors that can help us assess the risk. The PHP2shell vulnerability was immediately flagged as no existing control could stop it and the loss magnitude was maximal. So early in the morning on October 21st we started preparing for “emergency patching”.
In this blogpost, we will describe a key set of best practices that made our day relatively straightforward. Here is a list of key activities you should have in place for effective emergency patching:
- Threat intelligence and a risk-based triaging process.
- Up-to-date and easily accessible asset inventory.
- Risk profiles with key risk scenarios.
- Automation to build and deploy in a secure manner.
- Clearly defined roles and responsibilities within the team.
- Regular incident response simulations.
- Communication protocols and mail templates to notify all stakeholders and customers.
- Security training for the responsible team members.
AI is changing the patching discipline
Frontier AI models can find and weaponize vulnerability exploits in minutes. We have heard this and we might have even seen some examples. So we knew we have to seriously reduce our patching turnaround times. However October 21st 2026 is the day when the new reality hit us with hard numbers. We have to patch within minutes on a very short notice!
A brief recap of events
PHP foundation has reported a major vulnerability that could inject a backdoor before the application started. PHP maintainers reacted swiftly and prepared a patch to be released in the early afternoon. A security research firm predicted that the mass exploitation is about to begin 15 minutes after the patch. The patch itself contained the necessary clues how to exploit it so attackers could easily take this information and craft the exploit. Security researchers have predicted that the exploit will start about 15 minutes after the patch was released. To make things worse, ChainGuard has decided to release their patched images earlier. So it was game over for “security by obscurity”. Cloudflare also declared that the vulnerability exploitation has already started several hours before the patch.
Emergency patching protocol
Imagine professional firefighters in the middle of the night in their barracks. An alarm wakes them up notifying them there is a fire. Everyone in the team knows exactly what to do. They have established protocols and procedures. They have trained for these. Now switch “fire” with “vulnerability” and “professional firefighters” with “team Codific”. We knew exactly what we had to do. We had our list of assets, automation to build and deploy, responsible team members with well-defined roles, communication protocols, risk profiles, etc.
The essentials of patching in the age of AI are not really changing. If any, they are actually getting easier. During a crisis you can always count on your favorite LLM to give you some tips and tricks. To make our life easier we have for instance crafted scripts to quickly check whether the patch was correctly applied as in the haste you might oversee a critical detail. What changes with AI is the notice period and the time you have to patch. Preparation is most of the battle in this case and on October 21st 2026 all of that paid off massively for our team. Once the patched base images were available, all our systems were patched within 1.5 hours, and our forensic analysis found no evidence of a breach. You can read the full timeline here.
Key security activities for patching in the age of AI
Asset inventory
Everything starts with a clear view of what you have and where. A detailed, up-to-date asset inventory is a must-have: you can’t manage what you don’t know. Quite frankly, we put together our first asset inventory about 10 years ago, when we were getting ready for our very first ISO 27001 certification audit. I had no idea what it should look like. Judging by what our asset inventory looks like today, some might say I still don’t. But that doesn’t matter. What matters is having the following key elements in place.
- Your asset inventory is as up-to-date as possible. 100% is really hard to reach; during recent events we found 2 assets that weren’t listed. That’s why you need regular checks built into other activities (e.g., patching, backup checks, onboarding, offboarding) to keep the inventory updated.
- Key stakeholders in your team can find the asset inventory in under 60 seconds, so make sure the right shortcuts are in place (e.g., Slack bookmarks).
- The list is a single source of truth, but it’s easy to copy and use as a checklist. We use our asset inventory for periodic patching, backup checks and other operational activities, so being able to pull an up-to-date version into a spreadsheet is very handy.
- Each asset has a clearly defined owner.
- Each asset has a criticality label.
Threat intelligence
Once you know what your assets are you need to track any emerging threats to your assets.
The first step with threat intelligence is to collect intelligence from the right sources. Here is a non-exhaustive list of typical sources you should follow:
- Vulnerability feeds: NVD/CVE, EUVD (ENISA’s vulnerability database, relevant under the CRA), and CISA’s Known Exploited Vulnerabilities (KEV) catalog.
- Exploitation signals: your WAF or CDN vendor’s notices (Cloudflare flagged php2shell attacks early) and researcher and threat-intel firms.
- Community and early warning: national CERTs (CERT-EU, CCB in Belgium) and security social media.
Once you have that in place, you need to match incoming advisories against your assets. In other words, is a specific threat relevant?
The real challenge is to triage the threat and figure out the risk it represents. Ask the same questions every time. Is it reachable? Is it exploitable without authentication? Is it already exploited in the wild? The answers determine the next steps.
Application risk profiles
Most people think about risk as High / Medium / Low. That is fine for an asset criticality label. Risk analysis is a more advanced topic. The approach I’d recommend is FAIR (Factor Analysis in Information Risk). The approach is well thought and it is one of the few out there that has a solid science behind it.
At this point you might say, oh god, I have heard of that and that quantitative risk analysis is too complex, we’re not doing that. That’s understandable. However what you absolutely need to have is a list of your threat events that you fear the most. I like to call them risk scenarios. Risk scenarios allow teams to quickly zoom in on the most feared events. In all honesty, we still work with High/Medium/Low though we are shifting towards a quantitative approach to have the dollar value.
So, back to our emergency patching. After Cloudflare declared seeing the vulnerability exploit attempts, we had to make a swift decision to take our systems offline. “Better safe than sorry” is a good call, however some of our products had high availability needs. Meaning taking a system offline literally will cost us money. Having the risk scenarios in place we now could make a rationalized decision which systems to take offline. Here is another example. Keeping your WordPress website that has no customer data is a good call. Even if the loss event frequency was quite likely to happen, the loss magnitude was acceptable.
Build and deploy automation
This one is trivial. You should automate your build and deploy pipelines. However there are some gates you should place to make sure you don’t end up with more risk.
When it comes to the build pipeline, it should be entirely automated, but contain security checks. You should break your build pipeline if a critical vulnerability is present in the codebase or in its SBOM. The modern SAST and SCA tools allow you to seamlessly integrate those checks into the build pipeline. You should also have automated unit and integration tests in place to check for any regressions when it comes to functionality, but more importantly security. All these checks in your build pipeline allow you to make sure that the patch does not break any functionality and does not introduce any new vulnerabilities.
Your production deploy pipeline should be automated, but not everyone should be able to launch the deploy obviously. It should require someone with a dedicated role to launch the deploy. However from that launch decision onwards the rest should be completely automated.
Once those key ingredients are in place, patching is relatively straightforward. Apply the patch, build and deploy. In the case of php2shell, it was all about rebuilding the base container images that would up the PHP version to a patched version. And then rerunning the entire build and deploy automation.
Clearly defined roles and responsibilities
Having clearly defined roles and responsibilities will save you a lot of headache when the crisis hits. This is one of the key preparation ingredients. Rehearsing crises using table-tops or even full crisis simulation as a game might feel tedious, but it is going to pay off, trust me.
You might wonder at this point how on earth are you going to prepare for all possible events? Although emergency patching seems like a reasonable one to prepare for. This is going to happen more and more. Well, here is a tip from me. Every crisis is unique, however many crises share common elements.
For instance, you might have prepared for a server being wiped out entirely, for example because a data center is destroyed. We have actually prepared for this scenario, since some of our customers in the Middle East are hosted in data centers in Dubai. That preparation includes clear roles for communicating the incident, a procedure to set up a secondary server from backup, and forensic capabilities on standby. Those building blocks are reusable. The php2shell response needed several of them: we communicated with customers during crisis, took instances offline, brought them back once patched, and stood ready to restore from backup had we found signs of exploitation.
Security training
Here is an analogy for the security training and how serious you should be taking it. Consider a professional athlete in some sports, e.g., Hyrox. The athlete spends most of his time in training. The competition takes a small portion the time. Now contrast that to our daily life. We expect our teams to remember an OWASP Top 10 training from 2 years ago they took during their onboarding process.
A great training program should be continuous. Obviously, we cannot expect our teams to be more involved in training than the actual job, that’s where my analogy breaks. However security training should be a regular activity. Our sales teams for instance have a monthly cybersecurity awareness training looking into various topics. In fact, the selection of the topics is not as important as the awareness itself.
Emergency patching activities in OWASP SAMM
OWASP SAMM is a maturity framework to measure and improve your application security program. Essentially SAMM is a collection of best practices across the entire spectrum of application security structured as a maturity framework. Lately some believe that with the whole agentic AI approach SAMM is not as relevant. Well, it turned out that SAMM is more relevant than ever. Looking back at the set of activities we had in place to patch all our systems that fast we cannot dismiss the fact that nearly all of those are firmly part of the OWASP SAMM framework. The figure above provides an overview of the activities we had to perform for emergency patching and their mapping on OWASP SAMM. Asset inventory and threat intelligence are less explicit in the SAMM model, however they are clearly mentioned in several activities across the board.
Conclusion
In October 2026, PHP disclosed two AI-flagged vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Known as “php2shell”, they allow unauthenticated remote code execution. In plain language: attackers can easily abuse them to take full control of the server a PHP application runs on. Despite a mass worldwide panic, our team had prepared extremely well for this type of event. We were able to patch all the affected assets within 1.5 hours of patches becoming available. Looking back at this event and despite facing a downtime of several hours for some of our systems, we strongly believe that the entire patching process went as smoothly as it can.
