decrypted · 30 october 2026 · vulnerabilities and patching · supply chain · ai and llm security

GitLab's perfect-ten flaw is being exploited, and the fix hid in the runtime

A maximum-severity flaw in GitLab, the platform many UK firms use to hold source code and run their build pipelines, is now being exploited, and the clearest account comes from a victim that chose to publish it. CISA put CVE-2026-97229 on its KEV list, the catalogue of flaws known to be exploited in real attacks, on 29 October. GitLab shipped fixes on 12 October, so for most of this month the gap was a patching problem, not a zero-day.

What the flaw does

GitLab scores it 10.0 on CVSS, the zero-to-ten severity scale. The fault is in the code that checks regular expressions, the pattern-matching rules found in CI/CD files, the automated pipeline that builds and ships code. GitLab's advisory says an unauthenticated user could execute arbitrary code on the server by sending a crafted pattern. Picture a post room where a clerk reads every address label aloud: this is a label that, once read, makes the clerk hand over the keys to the building.

What Alpine Linux saw

The Alpine Linux project published its own account. On 20 and 21 October a newly registered account sent crafted configurations to its GitLab server, still running 19.3.4. The worker processes crashed eight times, and in four of them the attacker got partway through the exploit before failing. The attacker also downloaded Alpine's GitLab container image. Alpine found no evidence of code execution but could not rule it out, so it rebuilt the server from scratch. It says its packages and the 21 October releases were not tampered with.

The fix that was not in GitLab

Here is the trap. The bug sits in Onigmo, the regular expression engine inside Ruby. GitLab's fix is a set of patches to the Ruby it bundles, not a change to its own code. Alpine moved to 19.3.6 on 22 October, but its image used standard Ruby, so the update changed nothing. Anyone running GitLab on their own Ruby needs 3.3.13, 3.4.12, 4.0.9 or later. GitLab's fixed releases are 19.2.8, 19.3.5 and 19.4.2, and Alpine had stepped to 19.3.4 on 13 October, one release short.

The Secure by Design lesson

Two decisions would have changed this. First, a build server that accepts configuration from any newly registered account is exposed by design. Close open self-registration, and keep the server behind a VPN or an allow-list. Second, prove patch status rather than assuming it: a version label told Alpine it was safe when it was not. Ask your platform team or supplier which runtime ships inside the product, and check for the fixed Ruby, not just the release number. The cost is an afternoon and some friction for outside contributors. Skipping it risks what a GitLab server holds, which Alpine lists as password hashes, 2FA secrets (the seeds behind second-check codes), CI/CD variables, runner tokens and private repositories. Alpine also warns that a successful exploit leaves no crash and no web log trace, so absence of evidence is weak.

Also this week

Supply chain: a counterfeit Claude Code extension. Cursor said a modified "Anthropic.claude-code" 2.1.313 sat on its extension marketplace for about 11 hours on 29 October, and that Anthropic did not build it. Cursor says at most 5,000 users were affected. The extension collected host details, appended an attacker's key, labelled svc-telemetry, to the file that controls SSH (the encrypted way administrators log in to servers), and set up persistence. BleepingComputer reports that researchers at Phorion found bugs that stopped the SSH step working on macOS and Windows, though reconnaissance data was still sent. Cursor says uninstalling is not enough: search for svc-telemetry and rotate credentials from a trusted machine. The design lesson is that an editor extension is privileged software installed with one click, and deserves supplier-grade scrutiny.

Breach: Binance. TRM Labs puts the theft at about $6.36 billion from Binance wallets on 29 October, most of it in around 20 minutes, and attributes it with high confidence to North Korea's TraderTraitor group. TRM says the likeliest cause is compromise of the signing infrastructure behind a hot wallet, and that Binance has not published a root cause. BleepingComputer reports that Binance links the theft to a compromised engineer's laptop, while its co-CEO said the attacker did not simply use one engineer's permissions. Treat the laptop link as Binance's account, not settled fact. For UK finance and fintech firms, the lesson is that no single workstation should be able to reach a route to money.

AI security: poisoned models on Hugging Face. Pluto Security found 31 malicious repositories across seven Hugging Face accounts, posing as small Qwen2 test models and aimed at servers running Xinference and GPUStack. The trick is the trust_remote_code setting: the Python shipped with the model runs the moment it loads, here installing a crypto miner and in some versions a reverse shell. BleepingComputer counts downloads, not confirmed infections, and notes a second wave appeared after takedowns. A model is not a data file but a program with a friendly name, so pin trusted sources and never enable remote code by default.

Sources

If you want a second pair of eyes on how your build pipeline and its runtimes are patched, get in touch.