CRITICALCVSS 10.0EPSS 0.27CVE-2026-97229CI/CD
CVE-2026-97229 lives in Onigmo, so patching GitLab on your own Ruby fixes nothing
An integer overflow in the size of a compiled Onigmo pattern turns a crafted regex in a CI configuration into unauthenticated code execution on self-managed GitLab.
GitLab's 12 Oct release (19.4.2, 19.3.5, 19.2.8) fixes it by patching the Ruby it bundles in Omnibus and its images. Upstream Ruby shipped the underlying fix on 23 Oct in 3.3.13, 3.4.12 and 4.0.9, together with the bugs behind three sibling GitLab CVEs (CVE-2026-89078, CVE-2026-93577, CVE-2026-110264). Source installs and images that bring their own Ruby stay exploitable after a GitLab upgrade. CISA added it to KEV on 29 Oct.
Alpine's instance shows what that looks like. A newly registered account sent crafted CI configurations on 20 and 21 Oct while the server ran 19.3.4, crashing workers 8 times; 4 attempts got past the initial regex crash and failed at the next stage. The attacker also pulled Alpine's GitLab container image, which suggests tuning to the exact build. Alpine moved to 19.3.6 on 22 Oct and found on 26 Oct it was still vulnerable, because the image used stock Ruby. It rebuilt from scratch and replaced GitLab's secret keys, which reset every password, 2FA enrolment, token and CI/CD variable value.
The Ruby team's scoping matters beyond GitLab: any Ruby application that passes attacker-controlled strings to Regexp.new, Regexp.union, Regexp.compile or a /#{input}/ literal reaches the same bugs. Regexp.timeout does not protect against them, and length limits do not either, because some trigger on short patterns.
# Omnibus or GitLab's image: the fix ships inside
$ cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
# Source install or your own image: Ruby must be
# 3.3.13+, 3.4.12+ or 4.0.9+
$ ruby -e 'puts RUBY_VERSION'
# Any Ruby app: find regexps built from strings
$ grep -rnE 'Regexp\.(new|union|compile)|/#\{' app lib
- [ ]Patch to
19.4.2, 19.3.5 or 19.2.8 from GitLab's packages, or move your own Ruby to 3.3.13, 3.4.12 or 4.0.9 - [ ]If an instance open to sign-ups ran unpatched after 12 Oct, treat CI/CD variable values, runner tokens and integration secrets as exposed
- [ ]Require admin approval for new accounts; Alpine's attacker started from a fresh one
- [ ]Audit other Ruby services that compile user-supplied patterns
Source: GitLab advisory, 12 Oct · Ruby advisory, 23 Oct · Alpine incident report, 28 Oct · CISA KEV, 29 Oct · Patched 19.4.2, 12 Oct
#More this week
CRITICALCVSS 9.8EPSS 0.99CVE-2026-109618CVE-2026-109619CVE-2026-46300RUNTIME
PHP's two exploited RCEs chain with a kernel page-cache bug to root
CVE-2026-109618: PHP uses longjmp() to abort a request on out-of-memory, and some contexts leave request memory uninitialised when that happens (NVD 9.8). CVE-2026-109619: global state can keep pointing into request memory after it is freed, or be repopulated after a reset (NVD 8.1, AC:H). PHP scores both 9.2 under CVSS 4.0. Both landed in KEV on 26 Oct. CISA's entry for CVE-2026-46300, added 28 Oct, says the kernel flaw, which fails to preserve the shared-fragment marker during socket buffer coalescing so ESP input decrypts shared fragments in place, chains with the two PHP bugs to implant webshells and run commands as root.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 109618
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H 109619
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H 46300
- [ ]Upgrade to
8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's backport, then restart every FPM pool and mod_php worker - [ ]Patch the kernel for
CVE-2026-46300 on the same hosts - [ ]Hunt for webshells written since 21 Oct under document roots
Source: PHP release announcements, 21 Oct · NVD · CISA KEV, 26 and 28 Oct · Patched 8.5.12, 21 Oct
HIGHCVSS 8.6EPSS 0.01CVE-2026-76418FIREWALL
ASA and FTD reload on one pre-auth request when any tunnel group uses secondary authentication
Cisco attributes it to logic errors when secondary authentication is configured on a tunnel group; a crafted request to the SSL VPN login reloads the device, and no successful login is needed to reach the code path (AV:N/AC:L/PR:N/UI:N/S:C/A:H). The exposure check is wider than the login page suggests: with tunnel-group-list enable, every tunnel group counts, including DefaultWEBVPNGroup; with the list disabled, DefaultWEBVPNGroup still counts. Fixed releases for every train shipped 28 Oct; KEV 29 Oct. There is no workaround, only the mitigation of removing secondary authentication.
show run webvpn
show run all tunnel-group | i tunnel-group|secondary-auth
- [ ]Upgrade to the fixed release for your train, using the Software Checker in the advisory
- [ ]Until then, remove
secondary-authentication-server-group from every tunnel group, DefaultWEBVPNGroup included - [ ]On FTD, check the deployed remote access VPN policy in FMC or FDM, not only the running config
Source: Cisco advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75, 28 Oct · CISA KEV, 29 Oct · Patched per train, 28 Oct
INFOSUPPLY CHAIN
LiteLLM 1.107.0 shipped an infostealer through a lookalike repository
The chain, per LiteLLM: three developers' GitHub CLI OAuth tokens, which LiteLLM says can end up in its own logs; an exposed internal deployment; an org owner's token used to disable branch protection and force-push; the release workflow pointed at the lookalike Berri-AI/litellm; workflow records deleted at 11:53 to 11:54 UTC. PyPI wheels were live 11:39:51 to 13:23 UTC on 21 Oct; Docker Hub and GHCR tags (v1.107.0, latest, main-latest, main-stable) pointed at compromised indexes from 11:46:56 UTC until as late as 14:20. The source tag is clean. Unscored, because this is a compromised release rather than a flaw, hence INFO.
# Python startup runs cook.pth: inspect without Python
$ find / -path '*-packages/*' \( -name cook.pth \
-o -name cook.py -o -name sitecustomize.py \) 2>/dev/null
$ ls -l /tmp/remote_code_loader.lock
# bad Docker Hub digest, sha256:
# 1bbcb1443bc962e45f5aad53fe3d2c30
# 600e0379715fb6c664cdd3ac126c339e
- [ ]Assume exfiltration if
1.107.0 ran with egress: rotate the instance role, every provider key in the proxy DB, master and virtual keys, and the DATABASE_URL password - [ ]Look in CloudTrail for
GetCallerIdentity from the instance role around install time, then for that role's credentials used from outside your infrastructure - [ ]Rebuild pinned to
litellm==1.106.2; verify images against the cosign key rotated 23 Oct, since the bad 1.107.0 images carry a valid signature from the old one
Source: LiteLLM incident report, 21 Oct, updated 30 Oct