sec-tools.qlo.in

Is your PHP, WordPress or Drupal site exposed to the October 2026 PHP RCE?

CVE-2026-109618 and CVE-2026-109619 let an unauthenticated request run code on servers running unpatched PHP. Paste a PHP version, a Docker image, a Dockerfile or your PHP settings to see where you stand.

  • 8.5.x needs 8.5.12
  • 8.4.x needs 8.4.27
  • 8.3.x needs 8.3.36
  • 8.2.x needs 8.2.35
  • 8.1 and older No fix

Updating PHP is the only complete fix. Settings and WAF rules reduce exposure but don’t make a server safe. This tool reads what you paste and doesn’t scan anything. Read the caution notes.

Paste php -v output, or name each site like drupal-portal: PHP 8.2.20. Distribution builds such as 8.1.2-1ubuntu2.20 are recognised.

Runs entirely in your browser. Nothing you paste is sent anywhere.

What’s affected

Every PHP installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates mod_php highest risk, with a demonstrated exploit that runs before any application code.

  • Critical 9.2CVE-2026-109618

    Remote code execution via out-of-memory corruption. Out-of-memory handling can leave request data partly initialized, and cleanup then treats it as valid.

    8.28.38.48.5≤ 8.1
  • Critical 9.2CVE-2026-109619

    Remote code execution via stale global state. Request state can outlive its freed memory, and a later request on the same worker may use it.

    8.28.38.48.5≤ 8.1

WordPress, Drupal and other PHP apps

The flaw is in the PHP runtime, not in WordPress, Drupal, Joomla, Magento or Laravel. Updating the application doesn’t help, and the attack can run before any application code. What matters is the PHP version on every server, container and worker that serves the site.

Official wordpress and drupal Docker images name only the PHP branch, such as php8.3. Rebuild them with a fresh pull so they pick up the patched PHP, then confirm with php -v.

Find the PHP version that serves your site

The command-line php and the web server’s PHP can be different builds. Check the one that serves requests.

On a server or in a container

php -v; php-fpm -v 2>/dev/null

Drupal

drush status --field=php-version

Or in the admin at Reports → Status report (/admin/reports/status).

WordPress

wp --info

Or in the admin at Tools → Site Health → Info → Server.

Every pod in an OpenShift or Kubernetes namespace

Replace NS with your namespace, or use kubectl on plain Kubernetes. Paste the output into the version tab.

for p in $(oc get pods -n NS -o jsonpath='{.items[*].metadata.name}'); do echo "$p: $(oc exec -n NS $p -- php -r 'echo PHP_VERSION;' 2>/dev/null || echo n/a)"; done

All images deployed in the cluster

oc get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' | sort -u

Settings the web server actually uses

php-fpm -i | grep -E 'PHP Version|Server API|upload_progress.enabled|memory_limit|post_max_size|upload_max_filesize|fatal_error_backtraces'

If you’re affected

  1. Find every server, container, CI image and developer environment running PHP, and its version.
  2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On Linux, install your distribution’s updated packages: vendors received the patches in advance.
  3. Patch internet-facing sites and Apache with mod_php first.
  4. Rebuild every container image and restart every PHP worker. Running workers keep the old code until they restart.
  5. Confirm with php -v on the web server and run it through this checker again.
  6. On PHP 8.1 or older, move to a supported branch, or use a vendor’s backported packages. PHP 8.2 itself ends on 31 December 2026.

If you can’t update today

These come from the php.net advisory. They block specific attack paths only and don’t make a server safe. Apply them in php.ini, the FPM pool or the web server config, then restart every worker.

  • Turn off session upload progress

    Blocks the confirmed session paths for CVE-2026-109619, not other variants. Don’t rely on .user.ini or ini_set().

    php_admin_flag[session.upload_progress.enabled] = off

  • Remove the PHP memory limit

    Removes the controllable memory-limit failure behind CVE-2026-109618. Keep a container or cgroup memory limit as the safety boundary, and check nothing sets a finite limit back.

    php_admin_value[memory_limit] = -1

  • Keep request bodies small

    8M for sites without uploads, 32M with uploads. Keep upload_max_filesize below it, and enforce size and field-count limits at the web server or proxy too.

    post_max_size = 8M

  • PHP 8.5 only: turn off fatal error backtraces

    Blocks the confirmed fatal-backtrace path only.

    fatal_error_backtraces = 0

About WAF rules. Blocking requests that contain PHP_SESSION_UPLOAD_PROGRESS at the edge covers one path of CVE-2026-109619 across many hosts at once. It’s a useful interim layer, but it doesn’t address CVE-2026-109618, and private DNS or internal-only access doesn’t remove the risk either.

Caution

  • Only an update is a complete fix. The PHP project says there are no complete mitigations. Some notices in circulation describe the upload-progress setting or a WAF rule as the fix. They aren’t.
  • A tag or package name isn’t proof. Images can be retagged or pinned by digest, and the CLI can differ from the web server’s PHP. Only php -v from the PHP that serves requests is conclusive.
  • Distribution packages use their own versions. Ubuntu, Debian and Red Hat backport fixes without changing the PHP number, so 8.1.2-1ubuntu… may be patched. Check your vendor’s advisory.
  • remirepo users: php.net says rpms.remirepo.net didn’t have updates on release day and recommends switching to distribution packages or building from source.
  • “Not affected” covers this release only. It means the version includes the 21 October 2026 fixes. Other advisories may still apply.
  • This is a triage aid, not a security assessment. It’s provided as is, with no warranty. Your security team and the official advisory take precedence.

Sources

Versions, affected setups and stopgaps checked against php.net on 22 October 2026.

Questions

Do I need to update WordPress or Drupal?

Not for this issue. The flaw is in PHP itself. Update PHP on every server that runs the site, then keep your CMS up to date as usual.

Our servers are only reachable internally. Are we safe?

No. Internal access or private DNS reduces who can reach the server, but any request that does reach it can trigger the flaw. Patch internal systems too.

Is turning off session.upload_progress enough?

No. It blocks the confirmed session paths for one of the two CVEs. php.net says updating is the only complete fix.

We run PHP 7.4 or 8.1. What now?

There’s no official release. Use your distribution’s or LTS vendor’s backported packages if available, apply the stopgaps, and plan a move to PHP 8.3 or 8.4.

Does this page send my data anywhere?

No. Everything runs in your browser.