Business Builder • October 22, 2026 • By Dekena Wade
When the NSA Says Update: Understanding the PHP Security Alert
A guide in plain language to the PHP security warning: how websites work, what failed, what CVE and remote code execution mean, and where AI fits in.
Before you begin: This is a longer read, about 10 to 12 minutes, written for people without a technical background. We’ll unpack the warning, follow a request through a website, and explore how AI is changing the work of finding security flaws.
What happened inside widely used web software and why it matters beyond the technical team
This article discusses the PHP security disclosures and updates released on October 21, 2026. Release information below reflects that announcement; check the linked advisories and your vendor for subsequent guidance.
The National Security Agency (NSA), a U.S. intelligence agency whose cybersecurity mission includes protecting national security systems, issued an urgent warning about critical vulnerabilities affecting PHP. Affected organizations were advised to update immediately or take systems offline if updating was not feasible.
For someone maintaining an affected system, that calls for immediate attention. For everyone else, it raises a question worth unpacking:
What is PHP, and why could a problem in it affect so many different organizations?
For the past month, I have been following cybersecurity discussions more closely, watching researchers describe weaknesses, organizations assess their exposure, and technical discoveries develop into public warnings.
But following the discussion is different from understanding it.
Headlines mention “memory corruption,” “CVE numbers,” and “unauthenticated remote code execution.” Those terms explain the urgency to a security professional. But if you do not work in cybersecurity, you might still be asking what actually happened.
So let’s start with something familiar: opening a website.
Your browser is the front door
Imagine visiting a website and opening your account page.
Your browser sends a request to a server: a computer that provides information or services to other computers.
The server may run software, retrieve your account information, and assemble a response before sending it back.
We often talk about “the website” as one thing. Behind it, several components may be working together:
| Component | Its job |
|---|---|
| Browser | Displays the website and sends your requests |
| Server | Provides computing resources and responds to requests |
| Hosting provider | Supplies infrastructure where the website runs |
| Web server | Receives web requests and sends responses |
| Application | Provides features such as accounts, forms, or shopping |
| Runtime | Executes the application’s instructions |
| Database | Stores organized information |
These components may share one machine or operate across several services.
That matters because a weakness in one component can threaten an application that depends on it, even when the page visitors see looks perfectly normal.
Where does PHP fit?
PHP is a programming language commonly used to build software that runs on the server side of websites.
Developers write PHP instructions. The PHP runtime executes them.
Those instructions might retrieve an article, process a form, or calculate a shopping cart.
A simplified journey looks like this:
Your browser requests a page → the web server receives the request → PHP runs the relevant application instructions → a response returns to your browser.
PHP is one possible technology in that process. Other websites use different languages, and some primarily deliver prepared files without running PHP.
The important distinction here is between application code and the runtime executing it. Both are software. Both need maintenance.
Why has PHP been around so long?
PHP began in 1994, when Rasmus Lerdorf created tools for his personal website. Those early tools evolved into a language for generating web content on a server.
Over time, PHP became part of an extensive ecosystem of applications, hosting services, development tools, and technical expertise.
It is used by websites of many sizes, from small sites to large institutions and businesses with enterprise infrastructure.
Large organizations can, however, face a particularly complicated maintenance challenge. They may operate applications built at different times, maintained by different teams, and purchased from different vendors.
Replacing an established system can require moving data, rebuilding features, checking integrations, and changing business processes. Organizations often maintain existing technology alongside newer systems.
A language’s age alone does not establish its security. Whether software is supported, patched, configured appropriately, and maintained matters much more.
Picture the website as a restaurant
A restaurant provides a useful analogy for what happens behind the screen.
| Website component | Restaurant equivalent |
|---|---|
| Your request | An order |
| Web server | The front desk receiving it |
| Application code | Instructions for preparing it |
| PHP runtime | Machinery carrying out those instructions |
| Working memory | Counter space used during preparation |
| Database | Organized records and stored information |
The analogy is not perfect, but it helps us see where the problem sits.
The reported PHP failures concern how the machinery handles its temporary working space.
What does “memory” mean here?
Computer memory, usually RAM, is working space used while software runs.
It is different from a saved file or a database record.
A program may reserve memory, place information there, use that information, and release the memory when finished. It must track whether the information is ready to use and whether the memory remains valid.
An out-of-memory error occurs when a memory allocation cannot be satisfied, including when a configured limit is reached.
Software should handle that failure safely. A request failing should not become an opportunity for an outsider to execute code.
The danger arises when error handling or cleanup acts on invalid internal data.
Before the technical details: what is a CVE?
Security alerts give vulnerabilities identifiers such as CVE-2026-109618.
CVE stands for Common Vulnerabilities and Exposures. Its identifiers help researchers, vendors, and organizations refer to the same vulnerability.
Think of one as a case number.
| Part | What it tells you |
|---|---|
| CVE | The identification system |
| 2026 | The identifier’s year component, associated with assignment or public disclosure, not necessarily when the flaw first existed |
| 109618 | The sequence number identifying the record |
The final number is not a severity rating, a count of attacks, or a reliable publication order. A larger number does not mean a more dangerous flaw.
What about the “9.2 out of 10” rating?
PHP rated both vulnerabilities 9.2 under CVSS version 4.0. CVSS stands for Common Vulnerability Scoring System and is separate from the CVE identifier.
CVSS describes a vulnerability’s severity using characteristics such as the conditions required for exploitation and its potential impact. A score of 9.2 falls in the Critical range.
It does not mean there is a 92% chance of being hacked.
CVE identifies the issue. CVSS describes its severity.
Organizations still need to determine whether their systems are affected, how exposed they are, and what protections are in place.
What failed inside PHP?
The PHP team identified two critical vulnerabilities:
| Identifier | Failure described by PHP |
|---|---|
| CVE-2026-109618 | An out-of-memory interruption can leave request data partially initialized. Cleanup may then treat invalid data as valid. |
| CVE-2026-109619 | Internal state can persist after its backing memory has been freed. A later request may use that stale state. |
Both can allow unauthenticated remote code execution.
In our restaurant analogy, imagine machinery acting on an unfinished order as though it were complete, or following an old reference after the information behind it has been discarded.
The actual attack involves computer memory. The underlying idea is that software acts on information it cannot safely use.
What does “unauthenticated remote code execution” mean?
Break the phrase into three pieces:
| Term | Meaning |
|---|---|
| Unauthenticated | The attacker does not need to log in first |
| Remote | The attack can reach the system through a network connection |
| Code execution | The system can be made to execute instructions chosen by an attacker |
That is serious because the attacker may be able to move beyond interacting with the website’s intended features and influence what its underlying software executes.
Their reach still depends on the compromised process’s permissions and surrounding defenses. Code execution does not automatically grant unlimited access to every system in an organization.
Is this happening “between the website and the shell”?
The flaw occurs inside the PHP runtime while it handles requests and memory.
A shell is a program that accepts commands. Attackers sometimes try to obtain shell access after compromising a system, but remote code execution does not require an interactive shell.
The distinction is:
Runtime flaw → possible execution controlled by an attacker → possible further access
The hosting provider supplies the environment. The shell is a command interface. Neither describes the location of this memory handling failure.
Why can’t the login page prevent it?
A login page protects particular application features. It cannot necessarily protect the underlying software that processes a request before those features run.
PHP reports a demonstrated attack against Apache with mod_php, which runs PHP inside the Apache web server. In that configuration, the attack can trigger before application code executes. Other PHP configurations serving web requests are also identified as at risk.
An organization can therefore have passwords, account permissions, and carefully written application code while still needing an urgent runtime update.
This is one reason security involves several layers.
Was AI involved in finding these flaws?
Yes. According to OpenAI, security firm Calif identified a critical PHP flaw using GPT‑5.6 Sol through its Patch the Planet initiative. Wiz independently discovered and reported both vulnerabilities, and PHP’s maintainers led the fixes and release.
OpenAI describes roughly two months of coordinated response work before disclosure.
This was research by people using AI tools, followed by validation and work to prepare corrections.
The public conversation may have felt sudden. The investigation and response behind it took longer.
Can AI help attackers, too?
Yes. OpenAI’s account warns that capabilities useful for finding vulnerabilities can also help attackers develop offensive tools and exploits more rapidly.
Two distinctions matter here.
AI does not automatically make a flaw critical. Severity depends on the weakness and what exploiting it allows.
Attacks against many systems existed before modern AI. Automated scanning and exploitation already allowed attackers to target widely deployed software.
AI can accelerate parts of that work. Shared technology creates the possibility of exposure across many organizations; faster exploitation can reduce the time available for defenders to respond.
That combination is what makes timely maintenance so consequential.
Who searches for vulnerabilities, and why?
A vulnerability is a weakness. An exploit is a method or piece of code that takes advantage of it.
Attackers may search for weaknesses to steal information, disrupt services, commit fraud, or obtain access they can sell.
Defenders search for weaknesses so they can be repaired. They include software maintainers, internal security teams, independent researchers, and penetration testers hired to assess systems.
Some organizations offer bug bounties: financial rewards for eligible vulnerability reports. Researchers must follow each program’s scope and rules, and payment is not guaranteed for every finding.
Responsible research includes permission where required, careful validation, and reporting through an appropriate process.
What should affected organizations do?
A patch is a software update that corrects a problem. In its October 21 announcement, PHP listed fixes in:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Operators can also obtain corrected packages through relevant software vendors. Some vendors apply fixes to older releases, so confirm the corrected package with your vendor rather than relying only on the displayed version number. PHP warns that temporary measures do not completely resolve the vulnerabilities.
The organizational task extends beyond downloading an update:
- Locate affected systems. Include applications maintained by outside providers.
- Identify an owner. Establish who is responsible for each system.
- Apply the appropriate correction. Coordinate changes with maintainers or vendors.
- Verify the running software. Confirm that the corrected version is actually in use.
- Assess possible compromise. A successful update does not establish whether an earlier intrusion occurred.
A patch being available and a system being patched are two different things.
What if a website uses another language?
A system that does not run PHP is outside the direct scope of these PHP runtime vulnerabilities. That does not establish its overall security.
The visible interface also cannot tell the whole story. A React interface, for example, can communicate with a PHP backend. One organization may run several applications using different technologies.
The useful question is:
“What software actually runs across this system, and who maintains it?”
Changing languages is not a substitute for understanding dependencies and keeping them maintained.
Why this matters beyond the security team
For engineers, this incident concerns runtime behavior, memory handling, and remediation.
For leadership and audit, it also concerns accountability:
- Do we know where affected software is used?
- Can we reach the teams and vendors responsible?
- Can urgent changes happen outside the routine maintenance schedule?
- What evidence confirms that a correction is running?
- What happens when a system cannot be updated promptly?
These questions connect a technical flaw to business operations.
What drew me into this story was the speed of the discussion. What makes it significant is the coordination required underneath it: researchers identifying the weakness, maintainers developing corrections, providers distributing updates, and organizations making sure those updates reach the systems people depend on.
A security warning becomes protection when someone acts on it and verifies the result.