Black October: The Week AI-Assisted Offensive Research Broke the Internet

If your technology team has been acting strangely over the past few weeks — meetings at odd hours, a Friday night deploy, that tense silence in the infra channel — there is a very concrete explanation. The global security market has already named the period: Black October.

No ransomware group coordinated anything. No specific brand was targeted. What happened was more unsettling: between October 20 and 23, 2026, several of the technologies that hold up the modern internet disclosed critical flaws simultaneously.

On October 21 specifically, all of this landed at once: PHP's critical fix, the Node.js security release, GitLab's maximum-severity patch, and the poisoned LiteLLM package on PyPI. A single day that forced much of the market to rewrite its week.

And here is the part that changes the game over the medium term. A meaningful share of these discoveries came out of AI-assisted offensive research. Bugs that had been sleeping in source code for years — waiting for someone with the time, patience and depth to find them — were identified, tested and published in a fraction of the time that would have taken before. In GitLab's case, the flaw reaches installations going back to version 7.0: it sat there for over a decade without anyone seeing it.

The practical conclusion is uncomfortable: the window between "the flaw exists" and "the flaw is being exploited" has collapsed. The monthly patch cycle that worked in 2023 does not work anymore.

What follows is case by case: what breaks in your business, the technical detail that matters, and the step-by-step mitigation.

1. PHP: Unauthenticated RCE Across 70% of the Internet

CVE-2026-109618 and CVE-2026-109619 — disclosed October 21, 2026, rated critical by the PHP project itself.

The business impact

PHP runs behind more than 70% of the world's websites: WordPress, Drupal, Joomla, Magento, and that internal system nobody has touched since 2019 because it works.

An attacker needs no login, no leaked password, no social engineering. They send specially crafted requests and start executing commands with the privileges of the web process. Translated into business consequences: reading wp-config.php with your database credentials, dumping your customer base, planting a persistent webshell, and hijacking checkout. In e-commerce, the classic pattern is injecting a skimmer into the payment page — the site keeps working perfectly while card data leaks out.

Under Brazil's LGPD (and the same logic applies under GDPR), a customer database exfiltrated this way is a reportable security incident. And reporting requires knowing what actually left — which, without adequate logging, is exactly the question nobody can answer.

The technical detail

These are use-after-free memory corruption flaws (CWE-416). The PHP project describes CVE-2026-109618 as RCE via OOM corruption: when the process exceeds its memory limit, PHP is interrupted mid-request with internal structures only partially initialized. Manipulating that state allows code execution.

The highest-risk vector is mod_php, but code execution was also validated against PHP-FPM — so running FPM does not take you off the list.

How to tell if you are exposed: every unpatched install is. What is worth checking is whether your own application is cancelling out the stopgap mitigation:

// The official mitigation is memory_limit = -1 (no limit, so the OOM path
// is never reached). Any library that reimposes a finite limit at runtime
// reopens the memory corruption condition:
ini_set('memory_limit', '256M');   // common in WP plugins, PDF generators and import routines

If your php.ini sets memory_limit = -1 but a plugin calls ini_set() with a finite value, you are back in the vulnerable state without noticing.

How to tell if you are exposed — look for this pattern in your code:

const zlib = require('node:zlib');

app.post('/webhook', (req, res) => {
  // compressed body from an external source, decompressed without validation
  const payload = zlib.brotliDecompressSync(req.body);
});

That is what puts you in the vector: decompressing attacker-controlled Brotli. It applies to libraries doing it under the hood too — middleware that honors inbound Content-Encoding: br, and HTTP clients fetching compressed content from external sources.

How to tell if you are exposed — and why the naive check misleads:

$ cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
19.4.2
# Looks current: it is the October 12 patch.
# And it does NOT fix CVE-2026-110264. Only 19.4.3 and up do.

Step-by-step mitigation

1. Inventory. Run php -v on every host, including containers and the CLI PHP (which is frequently a different version from the one serving web traffic).

2. Upgrade to a safe branch:

   Branch	Minimum safe version
   8.2	8.2.35
   8.3	8.3.36
   8.4	8.4.27
   8.5	8.5.12

3. Restart the services. systemctl restart php8.x-fpm plus Apache/Nginx. Without a restart, the old process stays vulnerable in memory — this step is skipped alarmingly often.

4. Be careful checking the version on a distro. Debian, Ubuntu and RHEL backport the fix while keeping the old version number. Validate against your distribution's advisory (apt changelog php8.x or the vendor errata), not against php -v alone.

5. If you cannot patch today, the official advisory describes partial mitigations: memory_limit=-1 applied so the application cannot override it, a low post_max_size, and a container/cgroup memory limit. The advisory explicitly warns against RLIMIT_AS and RLIMIT_DATA. These are stopgaps, not fixes.

6. Running PHP 7.x, 8.0 or 8.1? There is no patch — those branches are end of life. The recommendation is to isolate those servers from the public internet until they are modernized. That is not an overreaction: it is the only real mitigation when no fix is coming.

7. Audit. Look for files created or modified in the webroot over the last 15 days, and for anomalous large-body requests in the logs from that period.

2. Node.js: The Risk Lives in a Library You Never Chose

CVE-2026-111497 — security release of October 21, 2026, fixing 10 vulnerabilities, 4 of them rated high.

The business impact

Node.js underpins APIs, microservices, admin dashboards and cloud portals at most companies that modernized their stack in recent years. It is typically the layer that talks to the database, the payment gateway and internal services — compromising the Node process usually means access to the credentials for everything it consumes.

Worth noting that the Brotli flaw was not the only one: the same release fixed two TLS certificate hostname validation bypasses (CVE-2026-105483 and CVE-2026-106069) and a DNS name truncation flaw (CVE-2026-105482). In practice, that means your application could accept as legitimate a certificate that is not — opening the door to traffic interception between services.

The technical detail

CVE-2026-111497 is an out-of-bounds write in the Brotli decoder bundled with Node. Malformed compressed input causes the decoder to write past its internal buffer, leading to a crash, process memory disclosure and, under certain conditions, code execution.

The key point for sizing your risk: you are only exposed if your application (or one of its libraries) decompresses attacker-controlled Brotli data. A server that merely compresses responses is not in the vector. The risk sits with anyone accepting Content-Encoding: br on inbound requests or fetching compressed content from external sources.

A public PoC has existed since less than a day after the release — so far demonstrating only the crash, not code execution. Severity is disputed: Node rates it high, while Ubuntu's security team treated it as medium.

Step-by-step mitigation

1. Upgrade:

   Branch	Minimum safe version
   22.x	22.23.4
   24.x (LTS)	24.22.1
   26.x	26.12.1

2. On Node 20, 23 or 25? Out of support, no fix. Migrating to a supported line is the only path.

3. Rebuild your container images. This is the real blind spot. Running node -v in production and seeing a patched version means nothing if your Dockerfile still points at an old base image — the next deploy reintroduces the flaw with your CI/CD's stamp of approval. Pin the base image tag, rebuild and republish.

4. Edge mitigation while the rebuild is pending: strip the Content-Encoding: br header from untrusted inbound traffic at the reverse proxy or WAF, or disable Brotli decompression at the application layer.

5. Review your TLS integrations. If your application calls internal services by IP, the certificate validation flaws in this same release are worth a pass through your connection logs.

3. Self-Managed GitLab: CVSS 10.0, and 10.0 Is the Ceiling

CVE-2026-110264 — critical patch published October 21, 2026.

The business impact

If your company hosts its own GitLab instance, handle this before anything else on this list.

A GitLab server does not just hold code. It holds your proprietary source, your CI/CD variables with production secrets, your deploy tokens and the keys that publish to your cloud. Compromising GitLab is not compromising one system — it is being handed the keyring for all the others, with the documentation on how to use them attached.

The worst case here is not a data breach: it is malicious code injected into your product, distributed to your customers through your own signed pipeline. That is precisely how LiteLLM fell in the same week.

The same release also fixes CVE-2026-15723 (CVSS 8.2, account takeover via OmniAuth-to-LDAP linking) and CVE-2026-112212 (CVSS 7.5, OAuth/OIDC discovery cache poisoning) — 12 fixes in total.

The technical detail

This is an integer overflow in GitLab's regular expression compiler, allowing code execution by an unauthenticated user. The flaw reaches installations going back to version 7.0 — more than a decade of exposure.

Two warnings separate those who actually fixed it from those who think they did:

• There is no workaround. GitLab published no configuration-based mitigation. Upgrading is the only fix.
• The October 12 patches do not solve it. If you applied 19.2.8, 19.3.5 or 19.4.2 in that window and considered the matter closed, you are still vulnerable.

Step-by-step mitigation

1. Upgrade today to 19.5.1, 19.4.3, 19.3.6, or the backport for your line: 19.2.9, 19.1.9, 19.0.10 or 18.11.13.
2. Take the web interface off the public internet. VPN or IP allowlist only. For most companies there is no real reason an internal GitLab should be exposed to the world.
3. Audit the logs before calling it closed — production.log and gitlab-rails, looking for anomalous requests to unauthenticated endpoints in the period before the patch.
4. If there is any sign of access, rotate everything GitLab was holding: CI/CD variables, Project and Group Access Tokens, Runner tokens, deploy keys and registered SSH keys. The patch closes the door; it does not invalidate what was already copied.
5. On GitLab.com (SaaS), the vendor has already mitigated it — but steps 3 and 4 still apply if you have integrations holding long-lived secrets.

4. What No Patch Fixes: The Keys Already Copied

The week was not only about outdated software. It exposed the link no update resolves: credentials.

LiteLLM 1.107.0 — poisoned on PyPI and Docker Hub

A widely used library for integrating applications with AI models. On October 21, 2026, malicious wheels and official Docker images were distributed after attackers used stolen GitHub credentials to publish the release. It is the project's second supply chain compromise this year.

The technical detail that matters most: the stealer executes at Python startup. All seven wheels shipped files (cook.pth, cook.py, sitecustomize.py) that run when the interpreter starts — you did not even need to import LiteLLM to be compromised. The payload harvests cloud, SSH, CI/CD, browser and AI tooling credentials, and establishes an hourly remote code execution channel. Exfiltration goes to a lookalike domain, litellm[.]dev.

How you picked up the poisoned version — and how to detect it:

# An unpinned requirements.txt resolved to 1.107.0 during the window:
litellm

# Detection (the stealer runs at Python startup, no import required):
find / \( -name "cook.pth" -o -name "cook.py" \) 2>/dev/null

Mitigation: pin version 1.106.2 (the last safe one), remove cook.pth, cook.py and sitecustomize.py from site-packages, rebuild containers from a clean image, and rotate every reachable credential from a machine known to be clean — rotating from inside the compromised host just hands over the new keys. Customers on LiteLLM's private enterprise registry were not affected.

Railway and Zeabur — customer secrets accessed

Railway: unauthorized access to internal systems between October 20 and 22, including decryption of a subset of stored customer environment variables. The preliminary report puts it at up to 1.85% of workspaces. Railway classified the case as part of a campaign targeting AI inference providers and advised all users to rotate secrets — including ones removed from the platform in the past, since deleting a variable does not revoke the key behind it.

Zeabur: two incidents, in August and October. The October one hit shared clusters across nine regions, roughly 321,000 accounts and about 3.2 million environment variable records. Zeabur has announced it will shut down operations between December 1 and 31, 2026 — if you have workloads there, this stopped being a security problem and became a migration deadline.

The rule most companies get wrong

Patching closes the door on the next intruder, but it does not revoke a key that has already been copied. A secret exfiltrated before the patch stays valid after it, and will stay valid until someone rotates it manually. Attackers know this and frequently wait weeks before using what they collected — precisely because the company has already filed the incident as resolved.

Mandatory rotation, in this order:

1. AI API tokens (OpenAI, Anthropic, Google Cloud) and payment gateway keys — the fastest to monetize, and the declared targets of this campaign;
2. Production database credentials;
3. GitHub/GitLab access tokens and SSH keys;
4. Cloud provider keys (AWS/GCP/Azure) and webhooks with shared secrets.

The Checklist to Hand Your Technical Team

Copy this and send it to whoever owns IT, or to the vendor running your site. Every question asks for a concrete answer — not an "everything's fine."

1. Inventory. Have we listed every server, site and API running PHP and Node.js, including the ones nobody has touched in years?
2. Upgrades. Are the installed versions on the safe branches, and were the services restarted after patching?
3. GitLab. If we self-host, did we apply the October 21 patch — and not stop at the October 12 patches, which do not fix CVE-2026-110264?
4. Containers and CI/CD. Have our Docker images and pipelines been rebuilt, so the next deploy does not reintroduce the vulnerable version?
5. End of life. Does any environment run PHP 8.1 or older, or Node 20/23/25? What is the plan and the deadline, given that no fix is coming?
6. Key rotation. Did we rotate credentials for the exposed services — from a clean machine — and not just apply the patch?
7. Audit. Did we review logs from before the patch looking for exploitation attempts, or are we assuming there were none?

If the answer to any of these is "I think so," the answer is no.

What Black October Teaches Beyond This Month

Patching is hygiene, not strategy. What changed in October 2026 was not the number of flaws — it was how fast they go from unknown to mass-exploited. AI-assisted offensive research is available to both sides of the counter, and the side doing the exploiting does not need to get a maintenance window approved.

Plenty of companies believe they are protected because the site "is still up." That is exactly the problem: silent flaws take nothing down. They hold doors open for exfiltration — and when they finally surface, they surface as a regulatory notification, not as a monitoring alert.

Black October was this week's emergency. But what actually fails companies in a security audit is almost never the CVE in the headlines — it is the same recurring issues, the ones that were there before October and will still be there after. We collected the 10 that come up most often in our penetration tests into a free 10-page PDF: The 10 flaws that fail companies in security audits.

Sources and References

PHP (CVE-2026-109618 / CVE-2026-109619)

• Official advisory: Security advisory: Critical remote code execution vulnerabilities, update now — php.net
• GitHub Security Advisory: GHSA-w8hw-w9fx-j79w
• CVE records: CVE-2026-109618 | CVE-2026-109619
• Government alert: Canadian Centre for Cyber Security — AL26-026
• Supported versions: php.net/supported-versions

Node.js (CVE-2026-111497 and others)

• Official security release: October 2026 Security Releases — nodejs.org
• CVE record: CVE-2026-111497
• Support schedule: Node.js Releases

GitLab (CVE-2026-110264)

• Official critical patch: GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
• CVE record: CVE-2026-110264

Supply chain and cloud

• LiteLLM — technical analysis: Datadog Security Labs
• LiteLLM — incident coverage: The Hacker News
• Railway — secret rotation guidance: BleepingComputer
• Zeabur — incident disclosure: zeabur.com/blogs
• Zeabur — shutdown announcement: BleepingComputer

Connect with the author for networking and more technical research: LinkedIn | X/Twitter