Critical PHP RCE Vulnerabilities: Patch Now (CVE-2026-109618, CVE-2026-109619)

By James Tran, Chief Information Security Officer

ServLogi is aware of two critical remote code execution (RCE) vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, publicly disclosed on October 21, 2026. Either lets an attacker run arbitrary code on a server running PHP. Public proof-of-concept code exists, and patching is the only complete fix. Our SOC is actively scanning for exploit attempts, and ServLogi managed services have been patched, or paused where a patch cannot be applied without client interaction.

Who is affected

The vulnerabilities affect every PHP version from PHP 5 onward. If PHP runs anywhere in your ServLogi environment, treat it as in scope until patched. That includes workloads in Sovereign Enclaves, applications behind Government Gateways, containers and images you bring to the platform, and Deployable Data Center units that run your software.

The PHP project has released fixes for these branches:

Only supported branches (8.2 and later) receive fixes. If you run 8.1 or earlier, plan an immediate upgrade to a supported branch.

Where this touches ServLogi

ServLogi hosts run on dedicated, single-tenant bare metal, and your team owns the operating system and software inside its boundary. PHP is therefore mostly a customer-side fix. Managed services have been patched, or paused where a patch needs your action.

What to do now to defend against CVE-2026-109618 and CVE-2026-109619

Patching is the only complete fix. Find every system that runs PHP, then work through these steps:

1. Inventory every system running PHP. Include bundled installs you may not think of as PHP servers: CMS instances, admin panels such as phpMyAdmin, and legacy applications.
2. Patch immediately to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you run PHP-based software such as WordPress or Laravel, also check for fixes from its vendor.
3. If you are on PHP 8.1 or earlier, upgrade to 8.2 or later. End-of-life versions will not receive official fixes.
4. If you cannot update right away, apply the PHP Foundation's published measures to reduce exposure to specific attack paths. They do not make an installation safe, so schedule the update.
5. Reduce the blast radius. Restrict public access to PHP applications that do not need to be internet-facing, tighten boundary rules at your gateway, and confirm monitoring is on.

If you operate under an authorization such as FedRAMP High, CMMC, CJIS or HIPAA, also do the following:

• Run the patch through your normal change-control process, and record the date and version for your assessor.
• If you cannot patch within your required remediation window, document the exception in your plan of action and milestones (POA&M) and tell your ISSO or compliance lead.
• Use package repositories and base images that your organization has approved.

Patching your hosts and containers

Check your current PHP version:

php -v

Ubuntu and Debian:

sudo apt update
sudo apt install --only-upgrade 'php*'

CentOS, Fedora, Rocky Linux, AlmaLinux. These distributions were still releasing patches when this advisory was written, so check the notice for your distribution first, then run:

sudo dnf upgrade 'php*'

1. Restart PHP-FPM or your web server after updating so the new version is loaded.
2. If your distribution does not yet offer a patched package, read its security notice below, or move to a supported PHP branch from a repository you trust.
3. Updating the whole system is good practice, but it can introduce breaking changes. Test first where you can.

Containers. Update the PHP version in your base image or Dockerfile to a patched release, rebuild, push, and redeploy. Images already stored in a registry stay vulnerable until you do.

WordPress, Drupal, Laravel and other PHP software. Updating the application alone may not update PHP. Check with your software provider for patched PHP and any application-level updates.

What ServLogi is doing

Under our shared responsibility model, ServLogi secures the platform layer and inherited controls, and you secure the application and software inside your boundary. We are taking these actions:

• Actively scanning. Our SOC is actively scanning for attempts to exploit these vulnerabilities.
• Patching managed services. Managed services have been patched, or paused where a patch cannot be applied without client interaction. A paused service stays paused until you work with us on the update.
• Confirming what is unaffected. Government Gateways, Active Containment, the Government Portal and the Enterprise Portal are unaffected.
• Posting updates. Progress and status updates will be available in the Trust Center.

Hardware isolation does not cover this. AMD SEV-SNP memory encryption and signed launch measurements protect a workload from the host and prove what booted. They do not stop an attacker who reaches your own PHP code over the network, because that code runs inside the isolated workload. A verified launch measurement is not a substitute for patching.

Need help?

Customers can reach federal operations and compliance engineering through the Client Portal or by requesting a briefing. If you are moving a legacy PHP system onto ServLogi, the Transition Program can help you patch it before cutover.

If you believe a ServLogi resource is compromised or being used for abuse, follow the disclosure process on our Security page. Include an IP address, a timestamp, and a description or logs of what you saw.

CVE-2026-109618, CVE-2026-109619 FAQs

Does this affect me? Assume yes until you have checked. Any server that runs PHP is in scope, including CMS installs, control panels, and forgotten internal tools.

Would my systems really be a target? Attacks are opportunistic. Attackers scan for any reachable server that is still vulnerable. Compromised servers are commonly used for crypto mining, phishing and spam hosting, botnets, DDoS, credential and data theft, and as a foothold for ransomware.

How do I check my PHP version? On standard Linux distributions, run php -v.

Which versions can be patched? Only 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There is no patch for 8.1 or earlier.

Do I need to reboot after updating? Ideally yes. At minimum, restart PHP-FPM or Apache to cycle out processes still running the vulnerable code. This step is commonly missed.

Are there temporary workarounds? The PHP Foundation publishes measures that reduce exposure to specific attack paths. They do not make PHP safe. Update as soon as possible.

Will ServLogi patch my PHP? No. Under the shared responsibility model, ServLogi secures the platform and the inherited control baseline. You secure the operating system and software you run inside your boundary, so updating PHP in your workload is your responsibility. ServLogi has patched its managed services, or paused them where a patch needs your action.

Why is my managed service paused? Where a patch could not be applied without your involvement, we paused the service rather than leave it exposed. Contact ServLogi to coordinate the update and return it to service.

How do I confirm I am fully patched? Compare your version with the fixed list. If you installed PHP through your OS package manager, the version number may not change, so check the package changelog for CVE-2026-109618 and CVE-2026-109619. Then restart PHP-FPM or Apache.

How do I know whether I was exploited? Patching closes the hole but does not remove an attacker who got in earlier. Patch first, restart the service, then review logs for unexpected processes, new files, and outbound connections. An attempt is not a compromise, and many will fail, especially against patched servers.