RVA CYBER

Security advisory · Web applications

Advisory · CVE-2026-109618 · CVE-2026-109619

Critical PHP Vulnerabilities: Patch Due Today at 10 a.m. ET

PHP has scheduled an emergency security release to fix two critical flaws that may allow attackers to take over a web server without logging in. If you run a PHP website, plan to patch today. If you can’t patch quickly, consider taking exposed sites off the public internet until you can.

RVA Cyber · October 21, 2026 · Written before the release; facts current as of 8:47 a.m. ET

At a glance

  • Confirmed: On October 20, the PHP security team gave advance notice of a release fixing two critical vulnerabilities, both rated 9.2 on version 4.0 of the Common Vulnerability Scoring System (CVSS).
  • Possible impact: CERT-EU, the cybersecurity service for EU institutions, says the flaws could allow remote code execution: an attacker running their own commands on your server, with no login required.
  • Going offline: CERT-EU advises organizations that can’t patch right away to consider isolating internet-facing PHP applications until a fix is in place.
  • Still unknown: PHP will publish the affected versions, the fixed versions, and the technical details only when the release goes out.

What we know

PHP’s official notice says the security release is “scheduled for Wednesday, 21 October 2026 at 14:00 UTC.” That is 10:00 a.m. Eastern. The notice says all PHP users should “prepare now so they can upgrade as soon as the release is available.”

PHP also says it may release earlier if details of either vulnerability become public or if attacks show up in the wild. Watch the official PHP news page instead of assuming the 10 a.m. time is fixed.

CERT-EU’s advisory identifies the flaws as CVE-2026-109618 and CVE-2026-109619. Citing reports that details have leaked, it says the flaws could affect every PHP version from PHP 5 onward. Neither PHP nor CERT-EU had confirmed the affected versions at the time of writing.

Why the urgency? Each flaw is rated 9.2, which is critical. Reports say details have already leaked. PHP runs a large share of public websites. Together, those make it likely that attackers will start scanning for vulnerable servers soon after the details become public.

When will the patch be available?

  • Upstream PHP (source code and official Windows builds): October 21 at 10:00 a.m. ET, or earlier if PHP speeds up the release.
  • Linux distributions, control panels, and hosting providers (for example Ubuntu, Debian, Red Hat, cPanel, Plesk, and managed hosts): these usually ship patched packages after the upstream release. The delay can be hours or days. Check each vendor’s security advisory.

Will it require a reboot?

PHP hasn’t published restart guidance for this release yet. However, PHP runs as ordinary software, not as part of the operating system, so installing a patched PHP should not require a full server reboot. What you do need to restart is every process that runs PHP. Until those restart, they keep running the old, vulnerable code:

  • PHP-FPM: restart every installed version and pool, for example systemctl restart php8.3-fpm.
  • Apache with mod_php: restart Apache. Restarting Apache does not restart separate PHP-FPM pools.
  • LiteSpeed (lsphp), long-running PHP workers, and queue daemons: restart these too.
  • Containers: rebuild your images with the patched PHP and redeploy.

After restarting, confirm that the PHP serving web traffic reports the fixed version. The command-line php -v can differ from the build your web server actually uses.

What to do now

  1. Inventory. List every internet-facing system that runs PHP, including WordPress, Drupal, Magento, and Laravel sites. Note where each one gets its PHP: a distribution package, a control panel, a container image, or a hosting provider.
  2. Line up a maintenance window. Be ready to patch and restart PHP services right after the release.
  3. Decide on exposure. For any public site you can’t patch quickly, follow CERT-EU’s advice and consider pulling it off the public internet, or putting it behind a VPN or an allowlist, until it’s fixed.
  4. Patch, restart, verify. Install the fixed version, restart PHP services as described above, and confirm the running version.
  5. Watch for compromise. Once details are public, check web and PHP logs for unusual requests, unexpected new files in web directories, and unfamiliar processes.

About interim workarounds: One independent researcher suggests that turning off PHP’s session.upload_progress.enabled setting may reduce exposure if you don’t use it. Treat that as unconfirmed. The researcher couldn’t reproduce the exploit, and PHP hasn’t published the root cause. It does not replace patching.

Sources