Weekly · Urbans Post
GitLab fixed a perfect 10.0 remote code execution bug in its CI/CD engine on October 12, and a researcher already published a working proof of concept. It lands the same week a separate, unrelated PHP crisis is eating up every security team's attention. GitLab disclosed CVE-2026-97229 on October 12, a flaw in the regular expression compiler that powers its CI/CD pipeline configuration.
GitLab itself rated it 10.0 on the CVSS scale, the maximum possible score, because an attacker doesn't need a password, a token, or a cookie to pull it off. According to reporting from The Hacker News and BleepingComputer, the bug lets an unauthenticated user execute arbitrary code on a self-hosted GitLab server. Here's what actually has to happen for the attack to work.
An attacker needs permission to push a branch to a public project on the target GitLab instance, something plenty of open, semi-open, or loosely permissioned internal GitLab instances allow by default. From there, according to a proof of concept published by security researcher Jonah Burgess, they craft a CI/CD pipeline configuration containing a specially designed regular expression, paired with a repository path that uses certain Unicode characters. That combination tricks Ruby into recompiling the regex after GitLab's own size check has already passed, triggering an integer overflow.
The overflow redirects the regex engine's execution path straight into a command-execution function. The final move is unauthenticated: a request to the CI lint endpoint, no token or login required. The command runs as GitLab's own git system account, not as an administrator.
That limits the damage. It doesn't eliminate it. GitLab patched the issue in versions 19.4.2, 19.3.5, and 19.2.8, all released October 12.
The flaw affects every version in the 19.2, 19.3, and 19.4 branches up to those fixes, both Community Edition and Enterprise Edition. That's a narrower window than some circulating claims suggest: this bug lives in recent releases, not a decade-plus of them. (A separate, much older GitLab flaw, CVE-2021-22205, did stretch back across releases going to version 11.9. It was also rated a perfect 10.0, after GitLab revised its severity in 2021 once it confirmed unauthenticated attackers could trigger it.
The two bugs get conflated online constantly: same maximum score, same "any outsider can do this" profile. But they are different vulnerabilities, five years apart.) No one has reported this CVE being exploited in the wild as of this week. But a public PoC changes that math fast.
Scanning and exploitation attempts typically follow within days of code going public. And GitLab runs the development pipeline for a huge share of the software industry, from solo founders self-hosting a cheap instance to enterprises running it behind their own firewall. If your CI lint endpoint is internet-facing and your version falls inside that patched range, you are exposed until you upgrade.
GitLab's patch landed in the same stretch of October as a much larger emergency. A critical PHP vulnerability pair, nicknamed php2shell and tracked as CVE-2026-109618 and CVE-2026-109619, that Fortune reported could affect roughly 70% of websites running on PHP. Both bugs carry a 9.2 severity score on the CVSS 4.0 scale.
One triggers when PHP runs out of memory mid-request and later treats the half-finished data as complete. The other lets leftover data from one visitor's request linger in memory, where the next visitor's request can trip over it. The fix shipped on October 21 across PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
The PHP story is the bigger number, given how much of the web still runs on older, unsupported PHP branches that will never get this patch. But GitLab's bug matters in a different way: it's not a website-serving flaw, it's a hole in the system that builds, tests, and ships the code behind those websites in the first place. Compromise a CI/CD pipeline and an attacker isn't defacing a page.
They're potentially inserting themselves into every deploy that pipeline touches going forward. If you're running a self-managed GitLab instance on 19.2, 19.3, or 19.4, the fix is straightforward. Upgrade to 19.2.8, 19.3.5, or 19.4.2 now.
In the meantime, check whether your CI lint endpoint needs to be reachable from outside your network at all. GitLab.com's own SaaS instance was patched as part of the same release and isn't something self-hosted customers need to act on themselves. For founders who don't run their own instance but rely on vendors who do, this is a reasonable week to ask your vendors a direct question: are you current, and was your CI lint endpoint ever exposed.
Two maximum-severity-adjacent bugs landing back to back isn't a coincidence worth reading into. But the software supply chain has more entry points than most teams track day to day, and this week gave two of them away at once. Also read: NAND flash shortage is quietly doubling SSD and laptop prices • Recursive says AI built most of its new Flint coding model • Demis Hassabis now says AGI could arrive in just two to three years This article is posted in Technology News , check it out for more related stories.
Source: Startup Fortune
