All insights

PHP2Shell: we’ve patched our servers. Here’s how you can patch yours. 🔐

Astley Digital has patched all managed PHP servers against the critical PHP2Shell vulnerabilities. Here is what server owners should do now.

PHP2SHELL exploit patched on protected server infrastructure

Astley Digital has completed emergency security updates across all servers running PHP in response to the critical vulnerabilities collectively known as “PHP2Shell”.

All affected servers under our management have been patched, the relevant PHP services have been restarted, and checks have been completed to confirm that the updated versions are running correctly.

What is PHP2Shell?

PHP2Shell is the name being used for two critical vulnerabilities in PHP:

  • CVE-2026-109618 — remote code execution through out-of-memory corruption.
  • CVE-2026-109619 — remote code execution through stale internal state.

Both vulnerabilities could allow an unauthenticated attacker to execute code remotely on a vulnerable web server. According to the official PHP security advisory, the affected web-facing configurations include PHP-FPM, Apache with mod_php, PHP-CGI, FrankenPHP and LiteSpeed.

Both vulnerabilities received a CVSS v4.0 score of 9.2, making them critical. The PHP team considers the risk particularly high for mod_php, where a demonstrated attack can be triggered before application code begins running.

What Astley Digital has done

Following publication of the official security updates on 21 October 2026, we:

  • identified every server and service running PHP;
  • applied the appropriate security updates;
  • restarted PHP workers and associated web services;
  • confirmed that the patched versions are active;
  • checked the availability of hosted websites and services; and
  • reviewed relevant monitoring and security information for abnormal activity.

Customers hosted on infrastructure managed by Astley Digital do not need to take any action in relation to this update. We will continue monitoring our infrastructure and the developing threat landscape.

How to protect your own PHP servers

If you manage your own PHP infrastructure, you should treat this as an urgent update.

1. Identify every PHP installation

Check production, staging, development and administrative servers. Remember that one server may contain several PHP versions or use a different version for command-line tasks and web requests.

Start by checking the command-line runtime:

php -v

This result alone is not enough. Confirm the version loaded by every PHP-FPM pool, Apache, LiteSpeed or other service handling web requests. Include containers, virtual machines, control panels, legacy websites and systems that are not normally exposed to the public internet.

2. Install a fixed release

The PHP project has released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with fixes for both vulnerabilities. Use the update process supplied by your operating-system or hosting vendor.

On supported Debian or Ubuntu systems, review and install available updates with:

sudo apt update
sudo apt upgrade

On supported RHEL-compatible systems, the equivalent is commonly:

sudo dnf upgrade

Review the proposed changes before approving them and follow your vendor’s guidance. PHP 8.1 and earlier no longer receive routine security releases from the PHP project. Some operating-system and long-term-support vendors provide backported fixes, so confirm the status directly with your supplier. A version number alone may not show whether a vendor backport is installed.

3. Restart every PHP worker

Installing packages is not enough if existing processes still have vulnerable code loaded in memory. Restart all relevant PHP-FPM pools, Apache or LiteSpeed services, background workers, queue processors and long-running PHP applications. Recreate or restart containers rather than updating only the host.

For example, after confirming the service names used by your system:

sudo systemctl restart php8.4-fpm
sudo systemctl restart nginx

Apache deployments may instead require:

sudo systemctl restart apache2

Service names vary by distribution and configuration. Do not copy a restart command blindly: first confirm which PHP and web-server services are active on your server.

4. Verify the runtime serving websites

After restarting, confirm that the web-facing PHP runtime is patched. Do not rely solely on php -v.

If you create a temporary diagnostic page to inspect the web runtime, restrict access and remove it immediately afterwards. PHP information pages can expose configuration details useful to attackers.

Run website health checks and test important functions such as authentication, payments, uploads, scheduled jobs and background queues.

5. Check for possible compromise

Patching closes the vulnerabilities, but it does not remove anything an attacker may already have installed. Review:

  • web-server, reverse-proxy, PHP and application logs;
  • unexpected or recently changed files in web-accessible directories;
  • unfamiliar processes, scheduled tasks and user accounts;
  • unexplained outbound network connections;
  • changes to SSH keys, configuration files or access controls; and
  • security alerts generated before the patch was installed.

If evidence suggests a server may have been compromised, isolate it and begin a proper incident investigation. Rebuilding from a known-good image and rotating credentials may be safer than attempting to clean the system in place.

6. Do not treat temporary mitigations as a permanent fix

The PHP team has published measures that may reduce exposure when an immediate update is impossible, including disabling session upload progress and changing certain memory and request-size settings. These measures do not completely resolve the vulnerabilities.

Installing a patched PHP release—or a package with a confirmed vendor backport—is the only complete solution. Refer to the PHP project’s current advisory for the full mitigation details.

Staying protected

Critical vulnerabilities are a reminder that server maintenance cannot be treated as an occasional task. Organisations should maintain an accurate system inventory, use supported software, monitor security advisories and keep a tested emergency-patching process.

If you are uncertain whether your server is affected, contact your hosting company or IT provider immediately. Astley Digital customers can contact our support team with questions about this update or the security of their hosted services.

Put this insight to work

Ready for a clearer technology plan?

Tell us what is slowing your organisation down. We will help you identify the practical next step.