AI Pulse: PHP2Shell—What Business Owners Need to Know About the Critical PHP Flaws

By MAJICIAN · October 25, 2026

PHP2Shell is the name being used for two critical security flaws in PHP: CVE-2026-109618 and CVE-2026-109619. PHP is the server-side software behind WordPress and many custom websites. These are flaws in PHP itself, not in a particular WordPress plugin or theme.

For a business owner, the important point is simple: a vulnerable web server may allow an attacker who has no account or password to run code on that server. The PHP project rates both vulnerabilities 9.2 out of 10 under CVSS 4.0 and says PHP users should update immediately.

What PHP2Shell means in plain English

When a web server receives a request, PHP temporarily stores information in memory while it prepares the response. CVE-2026-109618 involves PHP handling an out-of-memory condition before some internal request data has been fully prepared. During cleanup, PHP may treat incomplete data as valid.

CVE-2026-109619 involves internal information that can remain after its underlying memory has already been released. A later request handled by the same PHP worker may use that stale information. The PHP maintainers say carefully prepared conditions can turn these memory errors into remote code execution.

Remote code execution means an attacker may be able to make the server run commands of the attacker’s choosing. Depending on the server and its permissions, that could expose data, alter website files, interrupt service, or create a path for further access. Successful exploitation requires specific conditions, but the potential impact is why these issues are classified as critical.

Who is at risk

The PHP project says all PHP installations serving web requests are in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It considers mod_php the highest-risk setup because a working unauthenticated attack was demonstrated before application code runs. Other server setups are not automatically safe.

WordPress sites deserve particular attention because WordPress runs on PHP. Updating WordPress core, a theme, or a plugin does not update the PHP runtime supplied by the server or hosting company. A fully updated WordPress dashboard can therefore sit on top of an outdated PHP installation.

Older PHP sites are also a concern. PHP 8.1 and earlier no longer receive updates from the PHP project. Some operating-system vendors and paid long-term-support providers issue backported fixes, but the version number may not change when they do, so owners of older sites need confirmation from the host or server administrator rather than guessing.

A site is not affected if PHP is not installed or PHP is not exposed to untrusted web requests. Most public WordPress sites do serve PHP web requests, so their owners should check instead of assuming they are outside the risk.

How to check your site

If you use WordPress, sign in to the dashboard and go to Tools > Site Health > Info. Open the Server section and find the PHP version. WordPress documents this screen as the place to review server and PHP information.

If your host provides a control panel, check its PHP manager or runtime settings for each website. On a server you manage, php -v is a useful first check, but the command-line version can differ from the version serving the website. Confirm the web runtime and package build with the hosting provider or system administrator.

For the currently supported PHP branches, the first fixed releases are:

PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12

If the site reports an earlier release in one of those branches, it needs the security update. If it reports PHP 8.1 or older, ask the provider whether its exact package includes an official vendor backport for both CVE numbers. Request the package or build identifier and the provider’s security advisory; do not accept “we keep everything updated” as the only evidence.

What to do now

Contact the company that controls PHP for the site. On managed hosting, that is usually the host. On a cloud server, VPS, or dedicated server, it may be your developer or IT provider. Ask them to confirm the active web PHP version and whether fixes for CVE-2026-109618 and CVE-2026-109619 are installed.

Before changing PHP versions, take a tested backup of the website files and database. Use a staging copy to check important functions such as forms, payments, logins, search, scheduling, and integrations. Then apply the patched PHP package, restart the relevant PHP or web-server workers, and repeat those checks on the live site.

Review server, web application firewall, and hosting logs for unusual requests, repeated PHP crashes, unexpected file changes, unfamiliar administrator accounts, or unexplained scheduled tasks. The absence of obvious errors does not prove a server is safe, so log review should support patching rather than replace it.

If an intrusion is suspected, preserve logs and backups before cleaning anything. Rotate hosting, database, WordPress administrator, SFTP, SSH, and API credentials from a known-safe device, and have a qualified responder check the server for persistence. Restoring website files alone may not remove access that was added elsewhere on the account.

What if you cannot patch immediately?

The PHP project is clear that updating is the only complete solution. It lists temporary configuration changes that can reduce exposure to demonstrated attack paths, including disabling session upload progress and, for PHP 8.5, disabling fatal-error backtraces, followed by restarting every worker. Those measures do not cover every possible path and can affect application behavior, so they should be handled by someone who understands the server configuration.

A web application firewall can add protection while the server is being updated. Cloudflare says it deployed managed rules for known PHP2Shell exploit attempts, including for Free plan users, and reports seeing attack traffic aimed at its customers, but it still tells customers to patch PHP. A firewall is defense in depth, not evidence that a vulnerable runtime can be left in place.

The practical takeaway

This is a server-level PHP issue with a straightforward first response: identify the PHP runtime that actually serves the website, confirm whether the fixed package is installed, back up and test, then patch promptly. WordPress updates remain important, but they are a separate task and do not correct these two PHP flaws.

MAJICIAN offers website security check-ups for businesses that want help reviewing their website, hosting setup, and next steps.