A new PHP Security Alert deserves attention from anyone responsible for a website, web application, or internet-facing server that runs PHP.
On October 21, 2026, the PHP project released emergency security updates for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. The two issues are collectively known as PHP2Shell. Both can lead to unauthenticated remote code execution under vulnerable conditions, which means an attacker may be able to run code on a server without first logging in. PHP released fixes in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
For website owners, the important point is simple: this is a PHP core issue. Updating WordPress plugins or changing an administrator password does not fix the underlying PHP vulnerability. The PHP runtime itself needs to be updated to a fixed version.
PHP Security Alert: What changed on October 21, 2026?
The PHP project published security releases for the currently supported PHP 8.2, 8.3, 8.4, and 8.5 branches. The project said the vulnerabilities could allow unauthenticated remote code execution and advised users to update immediately. It also stated that updating is the only complete mitigation.
The fixed versions are:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Organizations running PHP 8.1 or older have a different problem. Those branches no longer receive normal security updates from the PHP project. Some operating-system distributions and long-term-support vendors may provide backported fixes, but administrators need to confirm that with their vendor. Otherwise, moving to a supported PHP version is the safer path.
This matters because PHP remains widely used. W3Techs reported on October 22, 2026, that PHP was used by 69.3% of websites where the server-side programming language could be identified. W3Techs also reports PHP on 100% of the WordPress sites in that dataset.
That does not mean every PHP website can be exploited in the same way. Configuration, server software, request handling, hosting architecture, and other controls affect exposure. It does mean website owners should not assume the issue is limited to a small group of unusual systems.
What are CVE-2026-109618 and CVE-2026-109619?
Both vulnerabilities involve problems in the way PHP handles internal state when something goes wrong during request processing.
CVE-2026-109618 relates to out-of-memory handling. PHP has historically used a mechanism called longjmp() to exit certain execution contexts when an out-of-memory condition occurs. The official PHP security advisory explains that, in some situations, PHP can exit while request-related memory is only partly initialized. Later cleanup may then operate on an invalid state. Researchers showed that this condition can be developed into remote code execution.
CVE-2026-109619 involves request-owned internal state surviving after the memory behind it has been freed. A later request handled by the same worker may then access a stale state before normal initialization has fully reset it. The UK National Cyber Security Centre describes both issues as memory-corruption problems that can result in unauthenticated remote code execution under the right conditions.
This is the key PHP vulnerability explained in practical terms: a specially constructed web request can cause PHP itself to enter an unsafe memory state. The problem exists below normal application logic.
That distinction is important for WordPress owners. A vulnerable request may reach the PHP runtime before WordPress code, a security plugin, or application-level logic has an opportunity to handle it.
Why this critical PHP security issue matters
A critical security issue in PHP can affect more than traditional PHP websites.
The PHP project says systems serving web requests through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed may be affected. PHP considers the demonstrated risk particularly significant for Apache mod_php.
The possible consequences include remote code execution, denial of service, and data exposure. Cloudflare says the vulnerabilities affect web servers running PHP 5.4 or later and can be triggered through specially crafted HTTP traffic under vulnerable conditions.
Remote code execution is the most serious outcome because it can allow an attacker to execute commands within the permissions available to the compromised web-server process. What happens after that depends on the server configuration, account privileges, segmentation, installed software, and other security controls.
A compromised web process does not automatically mean an attacker gains unrestricted control over an entire infrastructure environment. It does, however, create a serious entry point that requires immediate investigation.
Is PHP2Shell being exploited?
There is evidence of active exploitation attempts.
Amazon Threat Intelligence reported seeing a PHP2Shell exploitation attempt in its MadPot telemetry on October 17, 2026, four days before the public disclosure. AWS said it later observed additional attempts and saw public proof-of-concept activity followed by broader exploitation attempts after disclosure. AWS also noted that it could not confirm whether all observed attempts would have succeeded against real-world systems.
New Zealand’s NCSC updated its alert on October 22 to state that it was aware of reports of active exploitation.
Cloudflare developed WAF protections before the vulnerabilities became public and deployed those protections ahead of disclosure. AWS also published WAF guidance intended to reduce exposure while organizations complete patching. Both companies still make the same core recommendation: patch PHP.
This distinction matters. A web application firewall can reduce exposure to known attack patterns, but it should not be treated as a substitute for the fixed PHP release.
Global PHP security response
Several national cybersecurity organizations published guidance soon after disclosure.
The UK NCSC asked organizations to identify systems running PHP, prioritize internet-facing environments, update to fixed releases, and assess systems for evidence of compromise where immediate remediation was not possible.
The Canadian Centre for Cyber Security advised organizations to identify affected systems, update them immediately, investigate unexpected processes or outbound connections, and monitor third-party products that may bundle PHP internally.
New Zealand’s NCSC advised organizations to update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 and investigate possible unauthorized access on affected systems.
The consistency across these advisories is useful: identify where PHP is running, patch it, prioritize exposed systems, and investigate signs of compromise.
What WordPress website owners need to understand
WordPress depends on PHP, so PHP maintenance is part of WordPress security.
WordPress.org currently recommends PHP 8.3 or greater. WordPress can still run on some older PHP releases, but WordPress explicitly warns that legacy PHP versions that have reached end of life may expose sites to security vulnerabilities.
That means website maintenance should not stop at the WordPress dashboard.
A site can have the latest WordPress core, themes, and plugins while still running an outdated PHP version at the hosting level.
The reverse is also true. Updating PHP does not eliminate vulnerabilities in WordPress plugins, themes, administrator accounts, or custom code. These are separate security layers and need separate maintenance.
Website owners should know who is responsible for each layer. On managed hosting, the provider may handle PHP updates. On VPS, cloud, dedicated, or self-managed environments, responsibility may sit with an internal administrator, developer, or MSP.
What to do after this PHP Security Alert
Start with the PHP runtime itself.
Ask your hosting provider, administrator, or development team which PHP version each internet-facing website and application is using. Do not check only the main website. Review staging environments, API endpoints, old subdomains, legacy applications, control panels, containers, and third-party software that may include PHP.
Then take the following actions:
- Update supported PHP branches to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 as appropriate.
- If the environment uses PHP 8.1 or older, confirm whether the operating system or LTS vendor has supplied a backported fix. If not, plan an upgrade to a supported branch.
- Prioritize public-facing PHP systems.
- Test critical applications after upgrading, especially older applications with legacy dependencies.
- Review web server, PHP, authentication, endpoint, and outbound network logs for unusual activity.
- Check for unexpected files, processes, scheduled tasks, accounts, or outbound connections.
- Confirm that backups exist and that restoration procedures have been tested.
- Update WordPress core, plugins, and themes separately where applicable.
- Remove plugins, themes, applications, accounts, and services that are no longer needed.
- Use WAF protections as an additional control while patching, not as the permanent fix.
AWS, Cloudflare, PHP, and national cybersecurity authorities all place patching ahead of temporary mitigation.
Do small websites need to worry about PHP vulnerabilities news?
Website size does not determine whether automated scanning reaches a server.
Internet-facing systems are routinely scanned for exposed technologies and known vulnerabilities. Attackers can search broad address ranges and large numbers of domains without selecting each business manually.
That means the question is not whether a company is important enough to be targeted personally. The more useful questions are whether the system is exposed, whether it runs vulnerable software, and what an attacker could access if exploitation succeeds.
For a small business, the impact can still include website downtime, unauthorized changes, stolen customer information, malicious redirects, spam distribution, or compromise of other systems reachable from the server.
This is why PHP vulnerability news should lead to a basic operational process: inventory, assess, patch, verify, and monitor.
PHP security should be part of normal website maintenance
The PHP2Shell disclosure is a useful reminder that website security includes infrastructure below the CMS.
A normal maintenance program should track PHP versions, operating-system updates, CMS updates, plugin and theme updates, account access, backups, TLS configuration, monitoring, and recovery procedures. The exact controls depend on how the website is hosted and what information or business processes it handles.
A website that accepts payments, collects leads, stores customer information, or supports business operations needs an identified owner for those maintenance tasks. Leaving responsibility undefined is itself an operational risk.
Get help reviewing PHP and website security with CyberZEALS
CyberZEALS helps organizations assess internet-facing systems, identify security gaps, review application and infrastructure exposure, and plan practical remediation. If your team is unsure which PHP versions are running, whether exposed systems are affected by the current PHP Security Alert, or whether there are signs that require deeper investigation, CyberZEALS can support vulnerability assessment, penetration testing, security monitoring, and remediation planning based on the environment you actually operate.
- Penetration Testing Services — Identify exploitable weaknesses across applications, networks, and infrastructure.
- Application Testing Services — Test web, mobile, and desktop applications for security weaknesses that could expose business systems.
- Application Security Services — Review application security controls, configurations, and risks across development and production environments.
- Managed Security Services — Monitor systems for security events, suspicious activity, and operational risks that require investigation.
- Cloud Data Center Security — Assess and strengthen security controls across cloud infrastructure and data center environments.
