PHP2Shell: Critical PHP Vulnerabilities Put Websites at Risk — Patch Now

By · · 6 min read

PHP2Shell Critical PHP Vulnerabilities Put Websites at Risk — Patch Now

PHP powers a large part of the web, including websites and services built with WordPress, Drupal, Joomla, and other PHP applications. A vulnerability in PHP itself can therefore affect far more than one website or plugin.

Wiz Research has reported two critical PHP vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619. Under certain conditions, they can allow an unauthenticated attacker to execute code on an affected server or access sensitive data held in PHP process memory. The PHP project rates the issues at CVSS 9.2 and urges PHP users to update immediately.

The issue became known as PHP2Shell. It is a reminder that a website can be exposed even when its application code appears secure: these flaws are in the PHP engine, below the application layer.

What Is PHP2Shell?

PHP2Shell is the name used for an exploit chain built by combining multiple weaknesses in PHP’s handling of memory and fatal errors.

In some situations, PHP can encounter a fatal error such as an out-of-memory condition while internal request data is only partly set up. The request ends, but some internal state may not be cleaned up properly. If the affected worker later handles another request, PHP may reuse that stale state.

The resulting memory-safety problems can create two serious outcomes:

  • Remote process-memory disclosure, which may expose sensitive data held by a PHP worker.

  • Remote code execution, which could allow an attacker to run code on an affected server.

The memory exposed could include passwords, API keys, authentication tokens, or other information present in process memory. The specific impact depends on the PHP version, server configuration, and request handling. The PHP team confirms that the vulnerabilities can allow unauthenticated remote code execution under certain conditions.

Why WordPress, Drupal, and Joomla Are Mentioned

WordPress, Drupal, and Joomla are widely used PHP applications, so they are useful examples for showing the potential impact. However, the underlying vulnerabilities are in PHP itself not necessarily in those content management systems.

That distinction matters. Updating a CMS, theme, or plugin alone may not fix a vulnerability in the PHP runtime. Website owners and hosting providers need to check which PHP version is actually serving their site and apply the appropriate security update.

The PHP project says affected installations can include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It identifies mod_php as the highest-risk setup for one demonstrated attack path, while remote code execution was also confirmed through application-level paths on PHP-FPM.

What Versions Are Affected?

The supplied research describes affected PHP versions going back to 5.4. The PHP project’s October 21 security advisory provides fixed releases for supported branches:

  • PHP 8.5.12

  • PHP 8.4.27

  • PHP 8.3.36

  • PHP 8.2.35

PHP 8.1 and older no longer receive regular updates from the PHP project. Some operating-system distributors and long-term-support vendors may provide backported fixes, so administrators running older versions should check with their vendor. If no supported fix is available, upgrading to a maintained PHP version is the safer long-term option.

What Should Website Owners Do?

Update PHP as soon as possible. The PHP project says that updating to a fixed release is the only complete remediation. Temporary configuration changes may reduce exposure to certain attack paths, but they do not make an affected installation fully safe.

If your website is on managed hosting, contact your hosting provider and ask which PHP version your site is running and whether the security patch has been applied. Do not assume that the visible CMS version tells you the PHP runtime version.

If you manage your own server, check PHP across every environment that serves public requests. That includes production sites, staging environments, container images, background workers, and separate hosting accounts. After updating, restart the relevant PHP workers or services as required by your platform, then test the website and its critical functions.

Do not apply emergency PHP settings without understanding their effects. The PHP advisory lists temporary mitigations for administrators who cannot patch immediately, but warns that they are incomplete. For example, setting memory_limit=-1 removes PHP’s memory limit and can increase the risk of resource exhaustion. Follow the official advisory or your hosting provider’s guidance rather than copying configuration changes blindly.

What About Websites That Cannot Be Patched Immediately?

Some organisations cannot update at once because they depend on older software, have complex release processes, or need to test compatibility first.

In that case, treat the situation as urgent and use the PHP project’s temporary mitigation guidance while preparing the update. Review request-size limits, upload settings, session upload-progress configuration, and worker behaviour with a qualified administrator. These measures may block specific paths, but they are not a substitute for installing the fixed PHP release.

A web application firewall or hosting-provider rule may add another layer of protection. It should not be treated as proof that the server is safe, because the vulnerability exists in the PHP runtime and mitigation coverage may vary.

The Role of AI in Finding the Flaws

One important part of the PHP2Shell disclosure is how researchers used AI during security research.

Wiz says its researchers used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol during discovery, exploit development, detection, and patch validation. The company reports that Gemini 4 Argon made a significant contribution to this work.

The broader lesson is not that AI independently found and fixed the vulnerabilities. Human researchers, PHP maintainers, and security teams still had to guide the investigation, verify the findings, coordinate disclosure, develop a safe patch, and prepare updates.

AI helped make complex analysis and testing more practical. The PHP Foundation’s account of the response also describes increased use of AI tools alongside human review, reproducible test environments, and security expertise.

That changes the security landscape. Tools that help defenders find hidden flaws can also lower the effort needed to study and adapt attacks. Software teams should expect vulnerability research to move faster and should make patching and dependency management part of regular operations—not tasks reserved for emergencies.

Why This Matters Beyond PHP

PHP2Shell highlights a basic security principle: vulnerabilities in shared infrastructure can affect many products at once.

A company may have carefully secured its website code, restricted administrator access, and kept its plugins updated, yet still depend on a vulnerable PHP runtime. That is why security must cover the complete stack: application, framework, language runtime, server, operating system, hosting platform, and dependencies.

The incident also underlines the value of coordinated disclosure. The PHP project, researchers, vendors, hosting providers, and infrastructure companies worked to prepare patches and guidance before public technical details spread. The PHP Foundation says that updating PHP is the necessary fix and encourages users to install the security releases promptly.

Final Thoughts

PHP2Shell is a serious warning for anyone responsible for a PHP website or service. The vulnerabilities affect PHP itself, and successful exploitation could expose process memory or enable remote code execution under certain conditions.

Check your PHP version. Confirm that your hosting provider has installed the fix. Update supported systems to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or use the appropriate patched package from your operating-system vendor. If you cannot update immediately, follow the PHP project’s temporary mitigation advice while treating the server as still at risk.

Credit: The vulnerability research described here is based on the work of Wiz Research, including its use of Wiz Atlas. The findings and remediation involved collaboration with the PHP team and other security researchers and industry partners