PHP2Shell Explained: Everything You Need to Know

October 21, 2026 started like any other Wednesday for most web administrators. By afternoon it had turned into a global fire drill. The PHP project quietly dropped an emergency patch at 14:00 UTC. Within hours, government portals in the Netherlands, Finland, France, and Canada had pulled themselves offline.

Japanese game servers went dark. 4chan, parts of Wikimedia, and the Internet Archive flipped to maintenance mode. The FBI and the NSA told any organization that couldn’t patch immediately to shut their systems down entirely.

The two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, allow an unauthenticated attacker to run their own code on a server that runs PHP, which still powers roughly 70 percent of the web. Both are rated CVSS 9.2 by the PHP security team, the “critical” band of severity.

What makes this different? It’s that the same bug class was spotted in 2004, flagged again in 2020, and rediscovered in a formal audit in 2024, then left unfixed because nobody could prove it was actually exploitable. It took two independent teams using frontier AI models to finally demonstrate the vulnerability and successfully exploit it. The vulnerable code had been hiding in plain sight for over 20 years.

Key Points

• What: Two critical remote code execution (RCE) vulnerabilities in PHP’s engine itself, not in an application. PHP’s advisory describes CVE-2026-109618 as “RCE via OOM corruption” and CVE-2026-109619 as “RCE via stale global state.”
• Exploited? Yes. Amazon Threat Intelligence recorded an attempt on October 17, before public disclosure; researchers later documented successful command execution on vulnerable honeypot systems. CISA added both CVEs to its KEV catalog on October 26.
• Who is affected: PHP installations serving web requests across Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The affected version range starts at PHP 5.4; exploitability varies by version and configuration.
• Patched? Yes. Fixed releases shipped October 21, 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Updating the package is not enough: restart the PHP workers so the patched code is actually running.
• The catch: PHP’s own release notes are blunt: “There are no complete mitigations, updating is the only safe choice.”

What is PHP2Shell?

PHP is a programming language that runs on servers to build websites. It is the plumbing behind WordPress, Drupal, Joomla, Magento, Wikipedia’s MediaWiki, Laravel, Symfony, Nextcloud, phpMyAdmin, and countless custom sites. According to W3Techs, about 69 percent of websites whose server-side language is known run PHP, which is why headlines rounded this to “70% of the Internet.”

PHP2Shell is the industry nickname for the two vulnerabilities. The name, which spread from exploit tooling credited to Calif researcher Ryan Austin (known online as LCFR) and popularized in a demo video shared by researcher Kirill Firsov, describes what PHP2Shell enables: you send a crafted request to a PHP site, and you get a shell, meaning remote command execution on the server. As Sansec put it, “The exploit tool PHP2Shell, credited to Calif, combines both bugs into one attack that needs no login.”

The critical detail is that the PHP2Shell vulnerabilities sit in PHP’s own memory management and error handling, not in WordPress plugins or sloppy application code. “The flaws are in the PHP engine, so Magento, Shopware and WooCommerce stores are affected even when their own code is clean,” Sansec noted. Wiz’s researchers said the issue compares to Heartbleed, the 2014 OpenSSL bug that hit about two-thirds of the encrypted web.

PHP2Shell disclosure timeline

The coordinated disclosure was originally planned for October 22, 2026. It fell apart on October 20.

According to the PHP Foundation, things started getting out of control around 15:00 UTC on October 20. News about the two vulnerabilities began spreading across forums and social media before the official announcement.

However, some of the information being shared was wrong. People claimed the vulnerabilities had a maximum severity score of 10.0 and shared the wrong release time.

The news first appeared in an anonymous Hacker News post, posts from security firm watchTowr, and a video showing the exploit, reportedly linked to Calif.

watchTowr was also among the first security companies to publicly confirm that the vulnerabilities were real.

PHP reacted within hours. At 19:30 UTC it published an advance notice: “The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSS 9.2.” The notice included a warning that the team reserved “the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.”

The embargo (agreed time during which information or software updates must not be made public) was broken again on October 21. At 07:41 UTC, more than six hours before the planned release, Chainguard published built images containing the PHP fixes.

The PHP Foundation said Chainguard had “unilaterally broke the embargo.” Chainguard had received the fixes early, along with other distributors, so users could update as soon as the patches became public. But publishing the images early meant attackers could download them and study the changes before most PHP users had a chance to update. The Foundation warned, “Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release.”

Two minutes later, at 07:43 UTC, Cloudflare recorded the first attacks hitting customer sites. Cloudflare’s CTO Dane Knecht posted on X: “We are seeing early attacks emerging and are updating mitigations as new vectors show up.” He added: “This is a STOPGAP only. Patch as soon as @ThePHPF releases the update at 14:00 UTC today.”

At 13:34 UTC, the GitHub security advisories went live. At 14:00 UTC, the four patched releases dropped. Sansec had predicted “mass attacks to start within 15 minutes of the release.” Mass exploitation, in the Log4Shell sense of one request that works everywhere, did not materialize. But real attacks did, and they had started even before the vulnerabilities became public: Amazon Threat Intelligence later found a PHP2Shell exploitation attempt in its MadPot honeypot telemetry dating to October 17, four days before disclosure, and concluded that php2shell “is now seeing broad exploitation attempts in the wild.”

On October 26, CISA added both CVEs to its Known Exploited Vulnerabilities catalog. Per Tenable, the remediation due date for US federal agencies was October 29, an unusually tight window that reflects how seriously regulators took it.

Key dates

Date	Event
2004	Stefan Esser discovers the first PHP memory-limit RCE; he never releases the exploit. Commercial exploit vendors CORE and Immunity later build private ones.
March 2020	Bug #78876 reported to PHP: long variables in multipart/form-data cause out-of-memory conditions.
2024	An OSTIF-funded Quarkslab audit rediscovers the OOM issue; exploitation is not proven, and work on a fix stalls.
July 30, 2026	OpenAI invites Calif into its “Patch the Planet” program; the PHP audit begins.
August 1, 2026	Calif researcher Ryan Austin finds the first OOM-fatal trigger and a path to RCE against WordPress.
August 11, 2026	Calif reports an RCE to PHP; OpenAI independently reports the same root cause the same day.
August 19 to 24, 2026	Wiz independently discovers both vulnerabilities using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol; confirms unauthenticated RCE against Drupal and WordPress; reports to PHP on August 24.
September 21, 2026	PHP acknowledges the reports and begins building a coordinated fix across all supported branches.
October 17, 2026	First observed exploitation attempt (Amazon MadPot honeypot).
October 20, ~15:00 UTC	CVE identifiers leak with an incorrect CVSS of 10.0; watchTowr confirms the vulnerabilities are real.
October 20, 19:30 UTC	PHP publishes advance notice; release moved up one day.
October 21, 07:41 UTC	Chainguard publishes patched images early, breaking the embargo.
October 21, 07:43 UTC	Cloudflare observes the first post-leak attacks.
October 21, 13:34 to 14:00 UTC	Advisories and fixed releases (8.5.12, 8.4.27, 8.3.36, 8.2.35) go public; sites worldwide go dark or scramble to patch.
October 23 to 26, 2026	CISA ships a SIGMA detection rule; Karimi documents working RCE on honeypots; Trail of Bits confirms working exploits; Dream Research reports PHP2Shell chained with a kernel flaw for root; CISA adds both CVEs to KEV.

Affected websites and services

The impact was global. Following warnings from CERT-EU and national cyber agencies, several organizations took their websites offline as a safety measure. These included the Dutch government portal Overheid.nl, the Dutch House of Representatives website, Finland’s public-facing government web services and websites of local government offices in France known as prefectures. Reuters reported that these shutdowns were precautionary while organizations waited for the PHP security updates.

Canada also warned that some government websites might become temporarily unavailable while security updates were being applied. In Japan, games including Granblue Fantasy, Umamusume: Pretty Derby, Princess Connect! Re and Shadowverse: Worlds Beyond went into emergency maintenance. Capcom later suspended the online features of Street Fighter V and temporarily stopped selling the game while it worked on the PHP fixes. Japanese gaming report | Capcom notice. The Wikimedia Foundation also took supporting services such as Phabricator offline. Something Awful shut down its forums, 4chan switched to read-only mode, and the Internet Archive temporarily took its portal offline.

The number of potentially exposed systems is also high. Security researcher Silas Cutler estimated that more than 1.3 million internet-facing PHP hosts could be vulnerable, while a Shodan search by Henk Poley found over 1.9 million hosts running PHP, according to Tenable’s analysis. These are estimates, not confirmed counts of vulnerable servers.

There is also a technical reason why so many websites were affected. The flaws are in PHP’s request-handling code, which processes incoming HTTP requests, manages memory and handles errors. This code runs before WordPress, Drupal, Magento or any other PHP application starts executing its own code. That is why updating your CMS or plugins alone is not enough. You must update PHP itself on the server.

How the vulnerabilities were discovered

Back in 2004, PHP security researcher Stefan Esser discovered a serious security flaw in how PHP handles memory limits. He believed the issue was too dangerous, so he never shared his exploit publicly.

His discovery showed that an attacker could force PHP to use more memory than allowed and take advantage of what happens when PHP runs out of memory and crashes. In other words, this type of attack has been known for more than 20 years.

In 2020, PHP bug #78876 showed that specially crafted multipart/form-data requests could cause PHP to run out of memory (OOM).

In 2024, security firm Quarkslab found a related OOM (out of memory) issue during an external security audit funded by OSTIF. Around the same time, a PHP core developer working with the PHP Foundation independently discovered early signs of the same memory-related problem.

For a broader explanation of why flaws can survive testing and remain unnoticed, see our guide to how software vulnerabilities arise and why they go unnoticed.

So why was it never fixed? The PHP Foundation explained in its post-mortem that “In 2024, a potential exploit for the OOM problem was theorized, but no concrete vectors were found and other concrete issues with clear impact overshadowed these concerns.”

Fixing it wasn’t easy either. Some changes could break backward compatibility, introduce new denial-of-service risks, or cause problems with third-party extensions. The Foundation admitted that “The PHP security team, operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice.”

As a result, work on the fix kept stopping and restarting for months. The Foundation later described it as “a structural failure, caused by both the security team’s decision process and its lack of resources.”

The 2026 discovery changed everything. In July 2026, OpenAI invited Calif to join its Patch the Planet initiative, an AI-assisted security audit program. The PHP Foundation then connected Calif with the project.

Calif researcher Ryan Austin started by looking for older bugs similar to the one Stefan Esser discovered in 2004. Just a few days later, he found a way to trigger the vulnerability and achieve remote code execution (RCE). Austin wrote that he found the first trigger “only a few days after starting the audit and asking the right questions related to Stefan’s earlier findings.”

Around the same time, Wiz, a cloud company, independently discovered both vulnerabilities using its Atlas tools, Gemini 4 Argon, and GPT-5.6 Sol. Its researchers confirmed that unauthenticated RCE against Drupal on August 20 and WordPress on August 21, then reported their findings to PHP on August 24.

Wiz’s quoted: “With 70% of the Internet affected, the impact of PHP2Shell cannot be overstated. It marks an AI inflection point.” And “With frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work.” Wiz also noted that “what AI changed was the ability to understand the weaknesses and turn them into a working exploit.”

How PHP2Shell works

The setting. Every PHP website handles requests through worker processes. The two most common setups are Apache’s mod_php, where PHP runs inside the Apache web server process, and PHP-FPM, which uses a separate pool of PHP workers. Each request has a memory limit (memory_limit), set to 128 MiB by default, and a request body size limit (post_max_size), set to 8 MiB by default. These limits are meant to protect the server, but PHP2Shell finds ways around them.

Step 1: Trigger an out-of-memory abort on demand. An attacker needs to make a specific memory allocation fail at the right moment. Calif found two ways to create this memory pressure. First, by bypassing post_max_size: PHP checks the Content-Length header before processing a POST body, but chunked HTTP/1.1 requests, HTTP/2 requests without a Content-Length header, or requests expanded by a decompression filter can deliver more data than PHP expects. Second, through multipart file uploads: an upload part with an empty filename (filename="") contains no file data and does not count toward max_file_uploads, but PHP still creates six entries for it in the $_FILES array. A deeply nested field name like files[a][b] forces PHP to create multiple hash tables and string keys for those entries. Calif found that “hundreds of these records can occupy more than the default 128 MiB PHP heap while their complete HTTP body remains below the default 8 MiB post_max_size.” This allows an attacker to make a specific memory allocation fail.

Step 2: Interrupt PHP before it finishes cleaning up. When a memory allocation fails, PHP triggers an emergency abort called a bailout, then moves to error handling and request shutdown. The problem is that some PHP code records an operation before fully creating the data. If an OOM error interrupts this process, PHP can be left with incomplete data. One example is PHP’s hash table insertion code. PHP increases the table’s element count and its “used slots” counter before fully initializing a new entry. Think of a librarian recording a book before putting it on the shelf. If PHP runs out of memory during this process, the record exists, but the shelf slot may still contain old data. During request shutdown, PHP trusts the element count and tries to process or free that old memory. This is the use-after-free.

Step 3: Make the leftover state matter, twice over. The next part depends on how PHP is running. With mod_php, if the fatal error happens during request startup, Apache still runs PHP’s request shutdown process, which destroys the malformed $_POST and $_FILES tables. The Apache worker survives and can handle another request. This is what PHP means when it says it demonstrated an exploit “where an unauthenticated request can trigger the attack before any application code runs.” PHP-FPM works differently: a startup failure kills the worker, so exploitation needs another approach. Calif’s writeup explains how the session upload progress feature can help. This feature lets websites show file upload progress bars and can open and update a session while PHP is still processing the request body. If a fatal error happens during this process, PHP skips the normal cleanup of session globals. The request’s memory is freed, but the PHP-FPM worker keeps session pointers pointing to that freed memory. A second multipart request can then reach the same worker and make PHP use that leftover state. Wiz’s deep dive identifies four related bugs: an upload-progress unserializer use-after-free, a remote process-memory disclosure, a fatal-error backtrace use-after-free, and an OPcache type confusion.

The information leak. PHP2Shell can also expose parts of PHP’s process memory, not just allow code execution. This memory may contain database passwords, session tokens, API keys, and other secrets. The issue is application-agnostic, meaning attackers don’t need to find a

Is PHP2Shell being exploited?

Yes. Researchers have reported exploitation attempts, working exploits and at least one campaign that combined PHP2Shell with a separate Linux kernel vulnerability.

• October 17 – Before public disclosure: Amazon detected a PHP2Shell exploitation attempt through its MadPot honeypots. It could not determine how the attacker learned about the vulnerability. Amazon advised security teams to check their logs from October 17, rather than starting from the public disclosure date.
• October 21 – Attacks after disclosure: watchTowr began seeing exploitation attempts through its Attacker Eye honeypot network. Cloudflare also detected attacks from 07:43 UTC on release day. It reported that attackers were changing their payloads to try to get around its protections.
• October 24 – Successful exploitation: Researcher Adel Karimi showed that PHP2Shell could run commands on three test servers running PHP 8.4.26. These servers were honeypots set up to attract attackers. The results matched CVE-2026-109618. Karimi also noted that the servers used a single-worker Apache mod_php setup, which made the attack easier to carry out.
• October 26 – Exploits tested against real applications: Trail of Bits confirmed that PHP2Shell could be exploited on unpatched PHP 8.2 through 8.5. Its tests demonstrated shell access on MediaWiki, Symfony, Laravel and phpBB.
• A separate campaign targeting firewalls: Dream Research also found signs of attacks on 24 internet-facing firewalls. The attackers used PHP2Shell along with another Linux flaw called Fragnesia (CVE-2026-46300) to gain full control of the firewalls. Some of these firewalls appeared to be used by a US government-related organization. The attackers also had to adjust the exploit for each firewall software version because the memory addresses were different.

The debate is about how widely PHP2Shell can be exploited, not whether it works. Early reports, including Sansec’s October 21 assessment, suggested that large-scale attacks were less likely because successful exploitation depends on the target’s configuration and memory layout. Security researcher LiveOverflow (Fabian F.) tested PHP2Shell using AI agents and challenged the idea that its complexity makes it too difficult to exploit. His findings highlighted three important points:

• An AI agent can help build an exploit when it is given a representative target environment, such as a Docker image.
• memory_limit=-1 is not a complete mitigation; LiveOverflow found another way to trigger PHP’s bailout() path.
• Exploit complexity should not be confused with safety. A known vulnerability can still be exploited on real systems when an attacker can tune the attack to the target.

His main warning was that AI can make it much faster to adapt an exploit to different targets. This doesn’t mean every PHP website is equally easy to attack or that the same request works everywhere. PHP configuration, memory layout, and the way PHP runs still matter. But for defenders, the message is simple: don’t delay patching just because an exploit is difficult to carry out.

PHP2Shell patches

The fixes shipped October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The same fixes are in PHP 8.6.0 RC4 for anyone testing the next major branch.

Fixed PHP versions

Use this table to identify the first fixed release for each branch. For unsupported branches, check whether your distribution or hosting provider has issued a security backport.

PHP branch	Status	Fix
8.5.x	Supported	Update to 8.5.12
8.4.x	Supported	Update to 8.4.27
8.3.x	Supported	Update to 8.3.36
8.2.x	Supported, but reaches end of life on December 31, 2026	Update to 8.2.35, plan the 8.3+ upgrade
7.4, 8.0, 8.1	End of life, no official release	Use PHP’s minimal source backports, or a distribution/LTS vendor package
5.4 through 7.3	End of life, no fix from the PHP project	Upgrade to a supported branch

After patching

Two operational warnings from the patch rollout. First, updating the package is not enough: Google Cloud guidance with input from Mandiant notes that PHP-FPM, Apache, and other services keep the old, vulnerable code in memory until they are restarted.

Restart every PHP worker after patching. Second, PHP 8.4.27 and 8.5.12 shipped with a regression that can crash applications using the SimpleXML extension (tracked as php-src issue #24488); PHP traced it to a separate garbage-collector fix, and a fix was merged but had not shipped in a release as of October 26. And on October 26, PHP also shipped rebuilt Windows builds (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) to fix a separate Brotli vulnerability, CVE-2026-111497.

Official security guidance

• PHP (security advisory, October 21): The PHP team urged users to update immediately, saying, “All PHP users are strongly encouraged to update immediately.” It also warned that “There are no complete mitigations, updating is the only safe choice.” PHP identified Apache mod_php as the highest-risk setup.
• CISA (alert, updated October 23): CISA said, “They strongly urges organizations to immediately patch” the two PHP vulnerabilities. It asked organizations to inventory all PHP installations, noting that PHP “is often a component of other software and prevalence may not be directly observable.” The agency also advised prioritizing internet-facing systems, taking unpatched systems offline, using a WAF for temporary protection and watching for “PHP worker processes launching shells or downloading tools.” CISA published a SIGMA detection rule and added both CVEs to its KEV catalog on October 26.
• FBI and NSA: Both agencies advised organizations that could not patch immediately to take affected systems offline. The FBI’s October 23 alert said organizations should “take the system offline until it can be fully mitigated.” The NSA gave the same advice in its October 21 advisory. The FBI also asked organizations to check for PHP installations, preserve logs and monitor for suspicious activity.
• CERT-EU (advisory 2026-018): CERT-EU recommended patching affected systems immediately. Organizations unable to patch should consider isolating internet-facing PHP applications from public networks until the fix is installed and verified.
• Other national cybersecurity agencies: The UK’s NCSC, Australia’s ACSC, Canada’s Cyber Centre, New Zealand’s NCSC and Singapore’s CSA also issued urgent warnings. The UK NCSC advised organizations that could not apply temporary protections to “consider taking the system offline until it can be fully mitigated.” New Zealand’s NCSC also warned that it was “aware of reports of active exploitation.” The Dutch NCSC published an operational GitHub repository with affected software lists, detection guidance and response information.

Temporary mitigation

CVE-2026-109618 mitigation

• Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration. Note this trades security for availability risk, and LiveOverflow’s testing found at least one alternative bailout trigger, so treat this as a speed bump.
• Set a low post_max_size: 8M if you do not need uploads, 32M if you do, keeping upload_max_filesize below it.
• Enforce web-server-level limits on decoded request size, input field count, multipart part count, header count, and nesting depth, including for requests without a usable Content-Length.
• Use container or cgroup memory limits as an availability boundary, but do not substitute RLIMIT_AS or RLIMIT_DATA, which can cause the vulnerable allocation failure.

CVE-2026-109619 mitigation

• Set session.upload_progress.enabled=0 and restart every worker, configured via php.ini or pool config, not ini_set() or .user.ini.
• On PHP 8.5, set fatal_error_backtraces=0 and restart workers.
• Remove invalid or deprecated per-request settings that emit diagnostics before initialization, and fix attacker-reachable fatal errors and timeouts.

Cloudflare Protection

Cloudflare deployed default WAF rules for all customers including the free tier, explicitly as a stopgap; the rules cover known exploit vectors and only protect traffic routed through Cloudflare. Sansec suggests blocking multipart/form-data outright at the web server for applications that never need file uploads. And if a system truly cannot be patched or isolated, the FBI, NSA, CISA, and CERT-EU all converge on the same last resort: take it offline.

Detection and indicators

There is no file hash to scan for here; the indicators are behavioral and network-side. Security teams should:

• Hunt from October 17, not October 21. Amazon specifically recommends this because attackers were already exploiting the vulnerability before it became public.
• Look for the request shape: large or anomalous multipart/form-data POSTs containing many parts with empty filenames (filename="") and deeply nested field names such as files[a][b]; chunked HTTP/1.1 or HTTP/2 requests delivering far more bytes than any declared Content-Length; requests combining a session ID with the PHP_SESSION_UPLOAD_PROGRESS field.
• Look in logs: out-of-memory or fatal errors occurring during request startup rather than during script execution, and PHP-FPM workers exiting unexpectedly (the FPM code path exits the worker when request startup fails).
• Look at the host: the CISA alert singles out “PHP worker processes launching shells or downloading tools.” CISA’s SIGMA rule for this is in the CISA SIGMA Rules GitHub repository, and the NCSC-NL php2shell repository aggregates operational detection content.
• If you see probing, capture first: Mandiant-informed Google Cloud guidance says to capture worker memory from servers showing signs of probing before restarting them, because the restart erases the evidence.
• Vendor tooling: Wiz Sensor customers on version 1.0.12768 can enable a built-in response policy to auto-terminate processes showing PHP2Shell exploitation behavior; Elastic has published detection coverage; Tenable shipped Nessus plugin 369483 plus Web App Scanning plugins 115719 through 115722.

For the wider steps involved in investigating and containing a suspected compromise, see our guide to responding to a cybersecurity incident.

Additional Risks to Watch

1. WAF evasion: Cloudflare reported attackers changing their payloads to bypass protections. Its default rule also had a gap for sites that changed PHP’s default session.upload_progress.name value.
2. Limits are not full protection: LiveOverflow demonstrated that setting memory_limit=-1 does not block every route to PHP’s bailout() mechanism. PHP also says configuration changes cannot fully mitigate PHP2Shell.
3. Another issue affects patched versions: PHP disclosed CVE-2026-115560, a separate remote code execution issue involving session upload progress. It can affect patched PHP releases under a specific combination of session settings. PHP’s interim advice is to keep session.upload_progress.enabled=0 until the issue is addressed in a regular release.
4. Attackers may chain vulnerabilities: Dream Research reported PHP2Shell being combined with the Fragnesia kernel flaw (CVE-2026-46300) to gain root access on firewalls. Patching PHP does not fix a separate kernel vulnerability, so affected systems need to be checked for other weaknesses too.

What security teams can learn

PHP2Shell is a reminder not to dismiss a vulnerability just because it is difficult to exploit. Related memory-management issues had been discussed in 2004, reported again in 2020 and examined in a 2024 audit. A working route to remote code execution was not demonstrated then, and work on a fix stalled. Calif and Wiz later showed what was possible. AI helped with the research, but understanding PHP’s history and internals was important too.

The disclosure also shows how quickly a patch process can break down. PHP planned to release the fixes on October 22, but details leaked on October 20. Patched Chainguard images then appeared more than six hours before the public release. The PHP Foundation said attackers could study those binaries while other users were still waiting to update.

Finding every affected system is not always straightforward. PHP can be bundled in hosting control panels, appliances and third-party products, not just websites managed by an organization’s own team. CISA warned that PHP may be present where its use is not obvious, so check servers and containers and ask suppliers which PHP versions their products include.

After patching, restart PHP-FPM or Apache workers and verify that they are running the fixed version. If you suspect a server was already compromised, capture relevant worker memory before restarting; the restart may erase evidence. AI can also help attackers adapt exploits, but it does not make every PHP server equally easy to compromise. The PHP version, configuration and memory layout still matter.

About the Author

Mayank Mehra

Administrator

Mayank Mehra is a cybersecurity professional with 8+ years of hands-on experience in application security, penetration testing, vulnerability assessment, and AI security. He holds CEH, CAPEN, and CRTP certifications and specialises in identifying and mitigating security risks across applications and AI-powered systems.

Visit Website View All Posts