If your website or server runs PHP, GitLab, Node.js or NGINX, update now. Between 14 and 21 October 2026, all four projects released security fixes, including two critical PHP flaws and a GitLab flaw rated 10.0 out of 10 that can let an unauthenticated attacker run code on your server. National cyber security agencies issued urgent alerts, and some government websites went offline while teams patched.
At a glance: what to update
| Software | Released | Most serious issue | Upgrade to | Urgency |
|---|---|---|---|---|
| PHP | 21 Oct | Two critical code execution flaws (PHP2Shell), CVSS 9.2 | 8.5.12, 8.4.27, 8.3.36 or 8.2.35 | Immediately |
| GitLab (self – managed) | 21 Oct | Unauthenticated code execution, CVSS 10.0 | 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13 | Immediately |
| Node.js | 21 Oct | Brotli decoder flaw permitting code execution (High) | 26.12.1, 24.22.1 or 22.23.4 | This week |
| NGINX | 14 Oct | Five Medium-severity flaws | 1.30.6 (stable) or 1.31.7+ (mainline) | This week |
PHP: PHP2Shell ( CVE-2026-109618 and CVE-2026-109619 )
On 21 October, the PHP project released fixes for two critical vulnerabilities rated 9.2 on the CVSS v4.0 scale. Researchers call them PHP2Shell because a single web request can give an attacker command access to the server.
Any PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Researchers have demonstrated attacks against WordPress, Drupal and Joomla, and a security plugin cannot block them because the attack runs before any website code.
What to do:
- Update to the fixed version for your branch, or install your Linux vendor’s patched package.
- Restart PHP-FPM or the web server, then confirm the running version.
- PHP 8.1 and older no longer receive fixes. PHP 8.2 reaches end of life on 31 December 2026, so plan a move to 8.4 or 8.5.
- As a short-term measure only, setting session.upload_progress.enabled = Off in php.ini blocks the known attack paths.
GitLab: critical patch for self-managed servers
GitLab’s 21 October critical patch fixes CVE-2026-110264, rated 10.0. An integer overflow in the regular expression compiler can let an unauthenticated attacker run code on the server. It affects every version from 7.0 onwards. The release fixes 11 further issues, including an LDAP account takeover, and follows a separate critical patch on 12 October.
What to do:
- GitLab.com and GitLab Dedicated: no action; both are already patched.
- Self-managed: back up, then upgrade to the patched release in your branch. Singleserver installations have brief downtime while database migrations run.
Node.js: Brotli remote code execution risk
The Node.js 21 October security releases fix 10 vulnerabilities. The most serious, CVE-2026-111497 (High), is an out-of-bounds write in the Brotli decoder that permits remote code execution. Applications that decompress Brotli data from untrusted sources are most exposed.
What to do:
- Run node -v, then update within your release line: 26.12.1, 24.22.1 or 22.23.4.
- Rebuild and redeploy containers and serverless functions, which keep the old version until rebuilt.
- End-of-life versions (Node.js 20 and older) receive no fix, so plan a move to a supported line.
NGINX: versions 1.30.6 and 1.31.7
Released on 14 October, NGINX 1.30.6 (stable) and 1.31.7 (mainline) fix five Medium-severity vulnerabilities. Each applies only to certain setups: alias combined with rewrite, HTTP/3, TLS session ticket key rotation, server-side includes with AIO, and string
expression evaluation in recent versions.
What to do:
- Run nginx -v to check your version, then upgrade to 1.30.6 or 1.31.7 or later.
- Run nginx -t to test the configuration before reloading.
- On managed hosting or a CDN, ask your provider to confirm their version.
Security update checklist
- List what you run: PHP, Node.js, NGINX and GitLab versions on every site and server, including staging.
- Patch internet-facing systems first.
- Back up and confirm the backup restores.
- Apply the fixed versions and restart services.
- Test forms, logins, payments and integrations.
- Check logs for unusual activity, such as unexpected admin users or unfamiliar files in upload folders. If you suspect compromise, isolate the server, keep the logs and contact your national cyber security agency.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the nickname for two critical PHP vulnerabilities, CVE-2026-109618 and CVE2026-109619, fixed on 21 October 2026. Both can let an unauthenticated attacker run code on a web server. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
Is my WordPress site affected?
Probably, unless your host has already updated PHP. Every WordPress site runs on PHP, and a plugin update alone does not fix this. Ask your host to confirm the patched version.
How do I check my PHP version?
In WordPress, go to Tools → Site Health → Info → Server. Most hosting control panels also show it in the PHP settings.
What if my website still runs PHP 7.4, 8.0 or 8.1?
These versions no longer receive official fixes. Upgrade to PHP 8.4 or 8.5 after checking that your themes and plugins are compatible. Until then, disabling session.upload_progress in php.ini reduces the risk but does not make the site safe
Do GitLab.com users need to do anything?
No. GitLab has already patched GitLab.com and GitLab Dedicated. Only organisations running their own self-managed GitLab server need to upgrade.
Which Node.js version should I install?
Stay on your current major version and install its patched release: 26.12.1, 24.22.1 or 22.23.4. Jumping to a new major version can break applications, so test before changing.
Does every NGINX server need the update?
Each October fix affects only certain versions or features, such as HTTP/3 or TLS session ticket rotation. Updating to 1.30.6 or later is still the simplest way to be sure you are covered.
Leave a Reply