Back to blog
/Cybersecurity News / Application Security/6 min read

PHP2Shell: Two Critical PHP Vulnerabilities Put Web Servers at Risk

Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, could allow attackers to execute code on vulnerable web servers without authentication.

Two critical PHP vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, could allow attackers to execute code on vulnerable web servers without authentication. Here's what website owners, developers, and businesses need to know.


Your Website Could Be Vulnerable Without Anyone Logging In

Imagine an attacker gaining the ability to execute code on your web server without knowing a username or password.

This is the potential danger posed by PHP2Shell, the name given to two critical vulnerabilities affecting the PHP runtime.

On October 21, 2026, the PHP development team released emergency security updates addressing these vulnerabilities. Both received a CVSS v4.0 severity score of 9.2 out of 10 — Critical.

The vulnerabilities are tracked as:

  • CVE-2026-109618: Remote code execution through out-of-memory corruption.
  • CVE-2026-109619: Remote code execution through stale internal request state.

Because PHP powers a wide range of websites, content management systems, and business applications, these vulnerabilities deserve immediate attention from organizations running affected versions.

What Is PHP2Shell?

PHP2Shell refers to two memory-safety vulnerabilities in the PHP runtime engine.

Unlike a typical application vulnerability caused by insecure login logic or insufficient input validation, these flaws exist in the underlying technology responsible for executing PHP applications.

Under certain conditions, an unauthenticated attacker can exploit vulnerable PHP request processing to achieve remote code execution (RCE).

Remote code execution means that an attacker may be able to execute instructions on a vulnerable server remotely.

Depending on the server's configuration and the permissions available to the PHP process, successful exploitation could result in:

  • Unauthorized access to sensitive files and information.
  • Compromise of hosted websites and applications.
  • Modification of website content.
  • Disruption of business services.
  • Further compromise of connected systems.

The severity of the issue comes from the potential to exploit affected systems without first authenticating as a legitimate user.

Importantly, an affected PHP installation is not necessarily compromised. Exposure depends on the installed version, configuration, and whether the vulnerabilities have been patched.

Understanding the Two Vulnerabilities

Although both vulnerabilities can potentially lead to remote code execution, they involve different problems in PHP's internal memory handling.

CVE-2026-109618: Out-of-Memory Corruption

PHP must manage memory while processing incoming web requests.

When an operation runs out of memory, PHP may interrupt the operation and begin cleaning up the current request.

In vulnerable versions, certain unexpected memory conditions can leave internal request data improperly initialized.

If the cleanup process later uses that invalid state, memory corruption can occur.

Under exploitable conditions, this behavior may allow an attacker to execute code within the affected PHP process.

CVE-2026-109619: Stale Internal State

PHP maintains internal information while processing requests.

Some of that information temporarily references memory belonging to a specific request.

In vulnerable versions, certain references may remain after the associated memory has been freed.

A later request handled by the same worker may interact with this stale information, producing unsafe memory behavior.

Successful exploitation may again result in remote code execution.

Why These Vulnerabilities Are Unusual

Developers often focus on preventing SQL injection, cross-site scripting, broken access control, and insecure authentication.

These are essential security practices.

However, PHP2Shell demonstrates that even applications with carefully designed security controls can be exposed when their underlying runtime contains a critical vulnerability.

Secure application code cannot replace the need to patch vulnerable infrastructure.

Which Websites and Applications Are Affected?

The PHP project warns that PHP installations serving web requests are at risk when running affected, unpatched versions.

Relevant environments include:

  • PHP-FPM
  • Apache with mod_php
  • php-cgi
  • FrankenPHP
  • LiteSpeed configurations using PHP

Organizations should pay particular attention to publicly accessible web servers.

Potentially exposed applications include websites and systems built with:

WordPress: Websites and e-commerce stores running on affected PHP installations.

Laravel: Custom business applications, customer portals, APIs, and internal management platforms using vulnerable PHP runtimes.

Drupal and Joomla: Content management systems hosted on affected PHP environments.

Custom PHP applications: Proprietary platforms handling customers, payments, operations, or sensitive business information.

Using WordPress, Laravel, Drupal, or Joomla does not automatically mean a website has been compromised. The key factor is whether the underlying PHP environment is vulnerable.

Which PHP Versions Should You Update To?

The PHP project released the following security versions on October 21, 2026:

PHP BranchSecurity Release
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

Install the patched version for your supported branch, or a newer version that includes the fixes.

PHP 8.1 and older versions no longer receive security releases directly from the PHP project. Organizations using these branches should upgrade or verify whether their operating-system or long-term-support vendor provides an appropriate backported security patch.

Some vendor-maintained PHP packages can be secure even when their displayed version numbers differ from the upstream releases. Verify the actual patch status through the package vendor's security advisory.

What Should Website Owners Do Right Now?

If your organization operates a PHP-based website or application, the priority is to identify affected installations and apply the relevant patches.

1. Identify Your PHP Version

Ask your hosting provider or technical team which PHP runtime is used by your production website.

For administrators with server access, the following command can help identify the installed PHP command-line version:

php -v

However, the command-line version might differ from the version actually serving web requests.

Check your web-server configuration, PHP-FPM workers, containers, and managed hosting environments separately.

2. Apply the Latest Security Updates

Upgrade affected PHP installations to a fixed release or install the security updates supplied by your operating-system vendor.

Before deployment, create appropriate backups and assess application compatibility.

Apply patches as urgently as possible, especially on internet-facing servers.

3. Check Docker Containers and Hosting Environments

If your applications run in Docker, Kubernetes, or other containerized environments, updating PHP on the host server may not update the runtime inside your containers.

Review your application images, rebuild them using patched PHP packages or base images, and redeploy the updated services.

Also check third-party appliances or bundled applications that include their own PHP runtime.

4. Review Your Security Logs

Security updates address the underlying vulnerabilities, but patching alone cannot determine whether a server was previously compromised.

Review relevant web-server logs, PHP logs, application logs, and security-monitoring alerts for unusual activity.

If you suspect an intrusion, preserve evidence and involve an incident-response professional.

5. Do Not Rely Only on Your Firewall

Web application firewalls, monitoring tools, and access restrictions can help reduce exposure.

However, the PHP development team explicitly warns that there are no complete mitigations for these vulnerabilities other than applying the security fixes.

Temporary protective measures should not be treated as replacements for patching.

If your organization cannot patch an exposed server promptly, assess whether the affected service should be isolated or temporarily taken offline until it can be secured.

What Does PHP2Shell Mean for Businesses?

A critical vulnerability in a widely used runtime is not simply a developer problem.

For businesses, an affected application may support essential activities such as:

  • Receiving customer orders.
  • Processing payments.
  • Managing deliveries and logistics.
  • Storing customer information.
  • Operating administrative dashboards.
  • Communicating with clients and partners.

A successful server compromise could affect business continuity, data confidentiality, and customer trust.

This is why cybersecurity must extend beyond secure application development to include vulnerability management, dependency updates, infrastructure monitoring, and incident-response readiness.

Frequently Asked Questions

Does PHP2Shell affect every PHP website?

Not necessarily. The risk depends on the PHP version, whether relevant security patches have been installed, and the deployment environment. Website owners should verify the runtime actually serving their applications.

Does HTTPS protect against PHP2Shell?

No. HTTPS protects communications between users and web servers, but it does not fix vulnerabilities inside the PHP runtime.

Can updating WordPress or Laravel fix PHP2Shell?

Updating application frameworks and content management systems remains important, but PHP2Shell requires updating or patching the underlying PHP runtime.

Are older PHP versions safe?

Unsupported PHP branches may lack upstream security fixes. Organizations using legacy installations should consult their vendors about backported patches or plan an upgrade.

Is a web application firewall enough?

No. A firewall can be part of a broader defense strategy, but it is not a complete solution for these vulnerabilities.

Final Thoughts: Security Requires Continuous Attention

PHP2Shell is an important reminder that cybersecurity does not end when an application is deployed.

Even a well-developed application can become vulnerable when the software supporting it contains a critical security flaw.

Organizations should maintain an accurate inventory of their technology, monitor vulnerability disclosures, apply security patches, and regularly assess their applications and infrastructure.

The best time to identify an exposure is before it becomes a security incident.

How Dalguard Can Help

At Dalguard, we help organizations strengthen the security of their web applications and digital systems through professional cybersecurity assessments.

Our services include:

  • Web application security assessments.
  • Vulnerability identification and risk analysis.
  • API and authentication security reviews.
  • Access-control assessments.
  • Security reporting and remediation guidance.

If your business depends on a PHP-based application, understanding your exposure is an important first step toward protecting it.

Contact Dalguard to discuss your application security requirements.

Dalguard — Secure by Design. Protected by Expertise.


Official References

  1. PHP Security Advisory — October 21, 2026
  2. Canadian Centre for Cyber Security — PHP Critical Vulnerabilities
  3. NHS England — Critical Vulnerabilities in PHP
  4. Netherlands NCSC — PHP2Shell Operational Information

This article provides general cybersecurity information based on publicly available advisories as of October 22, 2026. Security guidance may change as new information becomes available.