---
title: Tip: after the PHP emergency update, prove the new build is the one serving traffic, and only use PHP's stopgaps where you truly can't patch yet | ctxsec
url: https://ctxsec.com/items/tip-php2shell-verify-and-stopgaps
description: ""
status: "how-to (from PHP's Oct 21 advisory)"
published: 2026-10-21
---

> 

[← Tips & Guides](/tips) · [markdown](/items/tip-php2shell-verify-and-stopgaps.md)

how-to (from PHP's Oct 21 advisory)

2026-10-21

### Tip: after the PHP emergency update, prove the new build is the one serving traffic, and only use PHP's stopgaps where you truly can't patch yet

1. **Check what's live, not what's installed.** `php -v` only shows the CLI. Restart every FPM pool, Apache with mod_php, FrankenPHP/LiteSpeed and long-running workers (Octane, queue, Swoole), then hit a protected phpinfo or version endpoint on each pool and look for 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distro's patched package version.
2. **Distro packages:** vendors got the fix early, so compare the package changelog for CVE-2026-109618/109619 rather than the upstream version string.
3. **Containers:** rebuild from updated `php:` base images and redeploy; a running container doesn't change when the tag does.
4. **Can't patch today?** PHP's partial measures, set where apps can't override them (php.ini, FPM pool `php_admin_value`, server config, not `ini_set()` or `.user.ini`): `memory_limit=-1`, `post_max_size` 8M (32M if uploads are needed) with `upload_max_filesize` below it, `session.upload_progress.enabled=0`, and on 8.5 `fatal_error_backtraces=0`, then restart every worker. Pair with a container or cgroup memory limit, but PHP warns not to use `RLIMIT_AS`/`RLIMIT_DATA`. Hiding errors with `display_errors` or `@` does not help. These narrow known paths only; they don't make PHP safe.

Sources: [php.net security advisory, Oct 21](https://www.php.net/archive/2026.php#2026-10-21-5)
