Logo

Critical-CVE Patching Checklist

The three critical CVEs disclosed in October 2026 (php2shell in PHP core, CVE-2026-110264 in GitLab, and the http2shell Brotli flaw) share a pattern: unauthenticated, maximum-or-near-maximum severity, and a trap where “I patched last week” does not mean “I’m safe.” This checklist is the step-by-step we use internally to close them out across a fleet, without missing the instance nobody remembers.

The full checklist is right below, free to read and share.

Leave your email if you also want a heads-up on the next security issue that matters, with practical guidance on how to handle it. No sales call, unsubscribe anytime, and the checklist stays open either way.

Please provide a valid email address.
You must agree before we can add you to the list.

The administrator of your personal data provided here is Devopsity sp. z o.o (al. Zwycięstwa 96/98, 81-451 Gdynia). Your email ... Read more

1. Inventory every affected surface

You cannot patch what you have not listed. For each technology, write down every instance, including the ones that are easy to forget.

  • PHP: every host, container, and managed runtime that serves PHP, with the exact version the web tier (PHP-FPM / mod_php) actually serves, not just the CLI. Include staging, admin panels, and legacy boxes.
  • GitLab: every self-managed instance, including Geo secondaries, staging, DR standbys, and demo servers. (GitLab.com and Dedicated are already fixed.)
  • HTTP front door: reverse proxies, load balancers, and CDNs terminating or re-encoding traffic (the http2shell / Brotli path).
  • A forgotten internet-facing instance on a vulnerable version is a full unauthenticated entry point. The inventory is the real deliverable of this step.

2. Confirm the version each surface actually serves

  • PHP: check php-fpm -v (the web tier), not only php -v (the CLI): they can differ.
  • GitLab: read /opt/gitlab/embedded/service/gitlab-rails/VERSION (package/Docker), the Helm APP VERSION column, or GET /api/v4/version.
  • Record the version before and after for every instance. Auditors (ISO 27001 A.8.8, SOC 2 CC7.1) will expect a dated record.

3. Patch to the fixed version for your branch

  • PHP: supported branches (8.2–8.5) go to the patched release (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) and restart PHP-FPM. PHP 8.1 and older are end-of-life and get no patch: those are an upgrade/migration decision, not a patch.
  • GitLab: upgrade within your minor line (19.5→19.5.1, 19.4→19.4.3, 19.3→19.3.6, 19.2→19.2.9, 19.1→19.1.9, 19.0→19.0.10, 18.11→18.11.13). The 12 October trap: if you patched then (19.4.2/19.3.5/19.2.8), you are still exposed to CVE-2026-110264 and need one patch higher. 18.10 and older have no fixed release: upgrade to a supported line.
  • HTTP layer: apply the vendor fix for the Brotli/decompression path and restart the proxy.
  • Pin exact versions across the fleet so every node lands on the same build.

4. Mind the gotchas

  • GitLab 19.4.3 and 19.3.6 include database migrations: a single-node server stays down until they finish; multi-node can use the zero-downtime procedure.
  • There is no reliable workaround for any of the three short of patching or taking the host offline. A WAF may blunt some payloads but is not a substitute, because the trigger is handled before your app runs.
  • EOL versions (PHP ≤ 8.1, GitLab ≤ 18.10) are the ones that turn a patch into a migration project. Plan those separately; do not leave them public and untouched.

5. Verify and check for compromise

  • Re-check the served version on every instance after patching (repeat step 2).
  • Confirm the host is not already compromised: unexpected processes, new cron entries, modified web-root files. For GitLab, run its published detection rules over the logs.
  • If you find signs of a successful attack, treat the host as compromised and rotate everything it held: CI/CD variables, runner tokens, deploy keys, access tokens.

6. Record it for compliance

Keep a dated record per instance: version before/after, patch date, any downtime, detection results, and any secrets rotated. This is your evidence for ISO 27001 (A.8.8 technical vulnerability management, A.8.32 change management) and SOC 2 (CC7.1, CC8.1).

The hard part of these events is never the single supported server you think about first: it is the EOL host nobody owns, and the “I patched last week” instance that is still exposed. If you want a second pair of eyes on your exposure, our Security & Compliance team can run a quick check; for the end-of-life hosts that cannot simply be patched, that is a migration and modernisation conversation.

Contents