Patching the two critical PHP flaws disclosed on Oct. 21 closes the hole, but it does not remove anyone who got through it first, Spencer Young, SVP International at identity security company Delinea, said in a comment sent to CyberTech Edition on Oct. 23. The UK’s National Cyber Security Centre and Amazon Threat Intelligence give security teams the same instruction in their own guidance: look for evidence of compromise as well as applying the update.
What Delinea’s Young said
“Organisations are racing to apply these emergency security updates before any damage is done,” Young said. In his view the update is essential and covers only half of the work, because teams “also need to check whether attackers have already been inside.”
His concern is what an intruder may have taken while the flaws were open. “If attackers have already exploited these weaknesses, they may have gained access to passwords or digital keys that could allow them back into the system, even after the flaws have been fixed,” he said. A stolen credential keeps working after the code is fixed, so the risk can outlast the patch.
His second point is about reach. “Getting into a website shouldn’t mean getting access to everything behind it,” Young said. “Limiting what each person or system can access helps stop one break-in spreading across an organisation.”
Delinea sells privileged access management and identity security software, so limiting and auditing what accounts can reach is its market. His advice lines up with the official guidance below, which does not depend on any one vendor’s product.
What the NCSC tells organisations to do
The NCSC advisory covers CVE-2026-109618 and CVE-2026-109619. It says the issue “could allow an attacker to trigger an out-of-memory (OOM) condition in PHP that results in memory corruption”, and that under certain conditions the corruption could be exploited for unauthenticated remote code execution. The NCSC says organisations using any version of PHP are affected and encourages all of them to update to the latest fixed version, starting with internet-facing systems.
The advisory goes past patching. Where a system cannot be updated or taken offline immediately, the NCSC says organisations should “assess the system for any evidence of compromise prior to your upgrade or mitigation and look for backdoors installed by an attacker.” The advisory also points readers to NCSC guidance on preventing lateral movement, which is the same ground Young covers when he talks about limiting what each account can reach.
The NCSC also asks teams to keep watching third-party software, because appliances and services can bundle PHP. It notes that NCSC-NL has published an inventory of software products with a PHP dependency that may be affected.
Why the investigation window starts before Oct. 21
Amazon Threat Intelligence moved the start date for that compromise check. In a post published Oct. 21, it reported a PHP2Shell exploitation attempt against its MadPot honeypots dated Oct. 17, four days before public disclosure, as CyberTech Edition covered in Amazon Telemetry Shows a PHP2Shell Attempt Four Days Before Disclosure. Amazon also saw multiple proof-of-concept exploits on the day of release, the earliest around 02:00 UTC, hours before the embargo lifted at 14:00 UTC.
“Start investigations from the earliest known exploitation, not from the disclosure date,” Amazon wrote in its guidance for security leaders. For PHP2Shell, it says to investigate from at least Oct. 17. It adds that upgrading is the only complete remediation for both CVEs and that no configuration-only workaround fully addresses them.
The timeline matters for Young’s argument. A server patched on Oct. 21 or Oct. 22 could have been exposed for several days, and on the day of disclosure Amazon recorded exploitation attempts from several sources. Any secret stored on or reachable from that server during those days is in scope for review. CyberTech Edition’s report on PHP’s advance notice of the two critical flaws sets out the release schedule.
What it means for the security leader
In our reading, the patch ticket and the compromise review are two pieces of work with different owners. The patch belongs to the platform or web team and closes when the version number changes. The review belongs to security operations and identity owners, and it closes only when the team can show that no credential from an exposed host is still usable by someone else.
That review is mostly an identity job. A typical PHP application server holds database passwords, API keys for payment or email services, cloud access keys and session signing secrets, often in environment variables or configuration files. If remote code execution was achieved, an attacker could have read all of them. Young’s point is that those secrets, and the accounts they unlock, are the route back in after the flaw is fixed.
The second half of his comment concerns blast radius. A web server whose service account can reach only its own database gives an intruder far less than one that shares an administrator account with other systems. Our earlier opinion piece, Treat a WAF Rule for PHP2Shell as a Patch-Window Control Only, made a related case about relying on temporary controls.
What to do this week
- Confirm every internet-facing PHP host runs a fixed release, then extend the inventory to appliances and vendor products that bundle PHP, using the NCSC-NL list the NCSC references.
- Review web server logs on exposed hosts from Oct. 17 onward, as Amazon advises, and check application servers for unexpected process execution or file modification.
- List every credential, key and secret stored on or reachable from each exposed host. Rotate them where the logs cannot rule out access, starting with database and cloud keys.
- Check the privileges of each web service account. Remove access it does not need, so that one compromised server cannot reach the rest of the estate.
- If the team cannot do the compromise assessment in house, the NCSC points UK organisations to its assured Cyber Incident Response providers.
Close the patch ticket when the version is confirmed. Close the incident record only after the credential review and the access review are done.
Source: NCSC advisory, Critical security issue affecting PHP
