AI SECURITY · ARCHITECTURE · OCTOBER 21, 2026
PHP’s Critical Flaws Reinforce Why Assume Breach Must Be the Default
Getting inside is only the beginning. What can an attacker do next, and what will still stop them?
By Kerry Panchoo · 8 minute read
The PHP flaws disclosed on October 21 show how a stranger on the internet could get a website’s server to run their instructions. Fixing that way in is urgent. But we also need to ask what the attacker could reach after getting inside—and what would still stop them.
PHP’s security risks were known long before this disclosure. Its history includes repeated serious flaws that could expose information or let an attacker run their own code. In 2012, CVE-2012-1823 affected certain PHP-CGI setups, allowing attackers to obtain source code or execute instructions on the server. In 2024, CVE-2024-4577 exposed certain Windows PHP deployments to remote code execution.
The October 21 flaws are the latest entries in a long history of security issues, rather than the first warning that PHP carries risk. The affected setups and causes differ, but the professional responsibility is familiar: account for that history when choosing the technology, keep it updated, and limit what an attacker could do if another flaw is found.
What the vulnerabilities enable
CVE-2026-109618: an attacker can turn a memory-limit failure into a way to run their own code. PHP is the software that processes requests for a PHP website. An attacker can send a specially constructed web request—for example, one resembling a form submission or file upload—that makes PHP use up its allowed memory. The dangerous part is how PHP handles that failure: it can stop halfway through preparing internal data, then try to clean up that unfinished data as though it were valid.
Researchers showed that an attacker could manipulate this mistake to make the server execute instructions of their choosing. This is called remote code execution. In demonstrated Apache configurations using PHP’s mod_php module, the attack works before the website’s own code runs. The attacker therefore does not need to pass the website’s login checks. Read the PHP advisory.
What could they use it for? They could act as the account running the website: read accessible configuration files for database passwords, use the site’s database access to steal customer records, or alter writable files to leave malicious code behind. These are possible consequences of that access; the actual reach depends on the permissions and connections granted to the website.
A memory-handling failure can become a route into the service. What the attacker can reach next depends on the access given to that service.
CVE-2026-109619: an attacker can exploit leftovers from one request when the server handles another. A PHP worker is a server process that handles a succession of web requests. Normally, it clears information belonging to a finished request before handling the next one. This flaw can leave the worker holding references to memory that has already been released for reuse.
An attacker can exploit a reachable error or interrupted operation in one request to leave those references behind. A later request handled by the same worker can make PHP use them as though they were still valid. By influencing what occupies that memory, an attacker may expose information from the process or redirect its execution into their own code. Demonstrated paths involve error handling or the feature that tracks file-upload progress. Exploitation depends on the server setup and reachable operations; PHP-FPM deployments require suitable conditions. Read the PHP advisory.
What could they use it for? Information exposed from memory could help an attacker investigate the application or obtain sensitive data present there. If they achieve code execution, they could use the website’s existing access to extract records, change data, or install a persistent backdoor where files are writable. Their purpose is to turn an ordinary web request into a foothold inside the service, then exploit whatever that service is trusted to access.
The attacker initially gets the permissions of the account running the website. That may let them read application files, connect to a database, or write to an uploads folder. It does not automatically give them control of every account or computer. The damage grows when that account can reach more than it needs.
The immediate action is to update PHP. The fixes announced on October 21 are in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Some operating-system suppliers provide the fixes within their own packages without using those exact version numbers. Ask your hosting provider or administrator to confirm that the relevant fixes are installed. Changing settings alone does not reliably close every route described in the advisories.
Getting in and causing damage are different problems
There are two problems to solve: stopping an attacker from getting in, and limiting what they can do if they succeed. These PHP flaws are mistakes in the software that runs the website. Keeping the application’s source code—the human-readable instructions written by developers—off the server would not fix these particular mistakes.
Once inside, an attacker can try to use whatever the website already has permission to use. A settings file might contain a database password. That password might let them copy customer records. If they can change a file the website later runs, they may leave a backdoor: malicious code that lets them return. They may also send requests to connected services using the website’s existing access, without changing any application files.
Being able to read code and being able to change it create different risks. Reading it can reveal where valuable data lives and how business processes work. Changing it can let an attacker alter those processes—for example, silently changing where information is sent. Restricting both kinds of access makes the attacker’s work harder, even when another weakness has already let them in.
How AI can help an intruder
An intruder does not necessarily understand a system when they first enter it. An AI assistant can help them read unfamiliar code, explain settings, and trace how one service connects to another. That could help them identify where customer data is stored, how payments are handled, or which passwords unlock another system. The AI can be wrong, and the attacker still needs access and working methods. The concern is that investigating an unfamiliar system can take less effort.
This concern reaches beyond PHP. Python programs, JavaScript, Ruby applications built with Rails, and shell scripts—the command sequences used to operate servers—can all contain useful instructions or powerful access. Settings files and deployment instructions can expose the same kind of knowledge. These specific PHP flaws do not affect all those technologies. The shared risk is what an attacker can learn, change, or operate after entering a production system: a system serving real users and real data.
Architecture is a choice between imperfect options
As an architect, my job includes deciding how to reduce risk before something fails. Assume Breach means designing on the assumption that an attacker may get inside. We should still work to keep them out. We must also make sure one compromised website cannot automatically become access to every database, payment control, monitoring tool, and backup.
About a year ago, we saw firsthand how effectively large language models—the technology behind many AI assistants—could investigate unfamiliar code and operating instructions. We recognized how that ability could help an intruder understand a system. We did not know about the specific PHP flaws disclosed on October 21.
For that reason, we stopped writing new application code in Python and PHP. Our new builds have used Go, Rust, and TypeScript. These are lesser-of-evils decisions: choices among imperfect options, intended to make an attacker’s life harder. Go and Rust can be delivered as compiled programs, which do not present the original source in the same directly readable form. That can add an obstacle; it does not make them impossible to analyse or exploit. TypeScript usually becomes JavaScript, so choosing it does not remove the readable-code concern. None of these choices protects a password left exposed or an account granted too much access.
Every choice needs an explanation of what could go wrong. Security teams call this a threat model. In plain language: if an attacker controls this part of the system, what can they read, what can they change, and what still prevents them from going further?
We treat production source and executable scripts as additional exposure to assess and minimize wherever practical. If a service does not need a file, a password, or permission to change its own code, it should not have it. Approved releases should be protected from casual rewriting, unexpected changes should raise an alert, and permission to install a new version should sit outside the running application’s control. These protections matter for scripts and compiled programs alike. The aim is to remove opportunities and add obstacles, with evidence that those obstacles work.
Why removing PHP from production is difficult
For about six months, we have explored how to remove PHP from the production sites we manage. Our reliance on WordPress makes that difficult: WordPress and much of its plugin ecosystem run on PHP. Removing PHP therefore means finding other tools that provide the publishing features, flexibility, and integrations those sites need. The challenge is replacing what the business relies on while removing the technology we want to move away from.
It is not lost on us that we still use a platform whose broader risks we recognized months ago. Recognizing a risk does not make it disappear, and planning a migration does not protect today’s users. We remain responsible for applying security fixes and limiting the damage an intrusion could cause while we find a workable replacement.
This is another lesser-of-evils decision. Staying brings risks; a rushed move can introduce new ones or remove functions the business needs. A replacement must be easier to maintain, meet the users’ needs, and show how it limits an attacker’s access. A new language or platform name is not enough to establish that.
The professional standard
Anyone recommending systems that use AI should be able to explain their security decisions in language the people relying on them can understand. If you champion a production technology, explain how an attacker could abuse it, why its benefits justify the risks, and what would still protect the business after a successful intrusion.
I am skeptical of claims of AI expertise that cannot meet that standard. Understanding how AI helps attackers should change how we design systems. The professional obligation is to make deliberate choices, explain the tradeoffs, and test the protections. That judgment applies to my own decisions too.
Consider a website that can change the bank account used for payments. If an attacker takes over the website and it can approve that change by itself, the attacker may be able to redirect money. Requiring approval through a separately protected system creates another barrier. The same principle applies to releasing new code, gaining more powerful passwords, turning off security alerts, and deleting backups. A compromised service should not hold all the keys needed to remove the protections around it.
Applying fixes closes known ways in. Limiting permissions reduces what an intruder can reach. Separate approval makes dangerous changes harder. Monitoring that the compromised application cannot switch off helps expose suspicious activity. Backups the attacker cannot overwrite or delete give the business a way to recover; restoring from them must be practised. These measures work together. Changing the programming language is only one part of the decision.
If an attacker takes over this service tomorrow, what can they do—and which protections will still stop them?