Emergency Patch Alert: GitLab's Second 10.0 in Ten Days, and PHP Leaked Before It Patched

This is an emergency off-cycle edition of the Cyber SOTU, because two of the internet's load-bearing walls cracked inside 48 hours. Both bugs are unauthenticated remote code execution — no login, no password, just a crafted request. And both live in the plumbing: not in your app, but in the machinery underneath it. If you run a self-hosted GitLab or anything on PHP, tonight is a patch night.

🦊 GitLab: the regex compiler did it again (CVE-2026-110264, CVSS 10.0)

What happened: Today, October 22, GitLab shipped emergency patches for CVE-2026-110264 — a maximum-severity CVSS 10.0 flaw in its Regular Expression Compiler, the background engine that parses regexes in CI/CD configuration files. An integer overflow, triggered by a specially crafted regular expression, can let an unauthenticated attacker execute arbitrary code on the GitLab server. Sound familiar? It should. Ten days ago, on October 12, GitLab patched CVE-2026-97229 — a CVSS 10.0 unauthenticated RCE in the same component, reported by the same researcher ("joaxcar," via HackerOne). Here's the part that stings: the versions released last week to fix the first bug — 19.2.8, 19.3.5, 19.4.2 — are themselves inside the affected range for this one. If you patched on October 12 and felt safe, patch again. The fixed versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13, and the flaw reaches back through years of releases. GitLab.com is already patched; most GitLab Dedicated tenants are covered. Shadowserver counts 2,700+ internet-exposed GitLab CE instances — and this is now the fourth serious regex-engine fire in about a month, after two 9.9s on September 23.

Why it matters: A GitLab server is the crown jewels with a web interface: source code, CI/CD secrets, deploy keys, and the pipeline that ships your software. Unauthenticated RCE on that box is a supply-chain skeleton key. And "we patched last week" turning out to be false comfort is exactly how mature patch programs still get breached — the fix itself needed a fix.

What to do: Self-managed CE/EE: upgrade to a fixed version now, outside your normal patch cycle — GitLab's own words are "as soon as possible." If you can't upgrade tonight, restrict network access to the instance and disable open sign-up. Then hunt: review recent CI/CD configurations and projects for strange regexes and new accounts, because a 10.0 with a public write-up trail doesn't stay unexploited for long. Source: BleepingComputer via Cybernoz → · Fixed-version table: AHCTS →

🐘 PHP2Shell: the leak beat the patch (CVE-2026-109618 & CVE-2026-109619, CVSS 9.2)

What happened: On October 20, technical details of two critical vulnerabilities in PHP itself leaked — a full day before the coordinated fix. PHP's security team confirmed both on October 21 and shipped an out-of-band release at 14:00 UTC. Both bugs are rated CVSS v4.0 9.2. In plain English: when PHP runs out of memory in the middle of a request, it bails out abruptly — and if that bailout lands while the session upload-progress handler is mid-operation, it leaves the interpreter's internal state corrupted (CVE-2026-109618) or lets one request's state bleed into the next request handled by the same worker (CVE-2026-109619). Researchers at Wiz, who reported the bugs, demonstrated unauthenticated RCE against current WordPress, Drupal, and Joomla images — even a "Hello World" app on a vulnerable PHP version is exploitable — and say every PHP version back to 5.4 is hit by at least one of the two. The fixes are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

Why it matters: This isn't one app — it's the interpreter under WordPress, Magento, Drupal, Joomla, Laravel, and a few decades of custom web code. Shodan-based counts put ~2 million internet-facing PHP servers on affected versions, 99.99% of them unpatched at first check — and roughly 1.37 million (69%) run end-of-life PHP versions that will never receive an official fix. The response tells you how serious it is: New Zealand's NCSC says it's aware of active exploitation reports, Cloudflare deployed emergency WAF rules and reported early attack traffic, Dutch government services (DigiD among them) and major game services took themselves offline defensively, and Japan's prime minister publicly urged admins to patch that night.

What to do: Upgrade PHP to a fixed version and restart PHP-FPM and every long-running worker — a running worker keeps executing the old code. Verify your distro or PPA actually serves the fixed build; some repositories lagged behind the official packages in the first hours. Can't patch yet? PHP published temporary mitigations and calls them incomplete; one partial stopgap is disabling session.upload_progress if you don't use it. Then go find the forgotten PHP: end-of-life 5.x/7.x/early-8.x hosts, CMS stacks, and appliances with PHP baked in — those need an upgrade path, isolation, or retirement, because no patch is coming for them. Anything internet-facing on a vulnerable version should be hunted for compromise, not just patched. Source: OX Security → · Patchstack → · NZ NCSC alert →

📋 Tonight's patch list

The pattern this week is the plumbing fighting back: a regex compiler and a memory bailout — the layer under the application, the part nobody threat-models because it was always just… there. It isn't just there anymore. Patch both, verify the version, restart the workers. I'll see you Sunday for the regular SOTU. 🐱