Over the past few weeks, two of the most common tools in a self-hosted build pipeline have been attacked almost as soon as their fixes shipped. Neither attack needed a password.
The first was GitLab. In the second week of September, GitLab patched CVE-2026-85706, a flaw rated 10 out of 10 in its commits API. On a self-managed instance with at least one public project, anyone on the internet could read files off the server. The security firm watchTowr saw attempts to exploit it the day after the fix was published, and CISA added it to its list of known exploited vulnerabilities. InfoQ covered the story on 3 October. GitLab.com and GitLab Dedicated, the hosted versions, were already fixed.
The second was JFrog Artifactory, the repository where many companies keep their built packages and container images. InfoQ reported on 28 September that three Artifactory flaws were being used against internet-facing, self-hosted servers. Two of them, chained together, turn an anonymous request into an admin token. The third, CVE-2026-82329, goes straight to admin. It was patched on 28 August, and The Hacker News reported attacks from 1 September. Wiz, which tracked the activity, said attackers got persistent admin access in under five minutes in the cases it saw, then added backdoor accounts, installed malicious plugins to run code, and collected signing keys.
Why these tools are worth attacking
Look at what the GitLab flaw could read. InfoQ lists CI/CD variables, runner tokens, deploy tokens, SSH keys and configuration that helps an attacker move to other systems. CI/CD variables are where teams keep the cloud keys, database passwords and registry logins their builds need. A file read on the source control server is, in practice, a read of most of the keys to production.
Artifactory is worse in a different way. It is the place your deploy process trusts. If someone can change what sits in it, they do not need to break into production. Your own pipeline will carry their code there for them.
None of this is new. In December 2023, CISA, the FBI, the NSA and partners in the UK and Poland warned that Russia's foreign intelligence service had been exploiting a flaw in JetBrains TeamCity, another build server, since September of that year. Build servers have been a target for state-level attackers for years. What has changed is the speed. The gap between a fix and an attack is now counted in hours or days.
The ownership gap
Most companies do not treat these systems as critical. The source control server was set up by the platform team years ago. The artifact repository belongs to whoever set up the build. Security looks after the production estate and the laptops. Patching for developer tools falls into a gap where everyone assumes someone else has it.
Then there is the usual patch cycle. Plenty of companies patch internal tools monthly, or wait for a quiet weekend because developers complain when GitLab is down.
Here is the arithmetic, using illustrative numbers. If you patch on a fixed monthly cycle and a critical fix lands at a random point in the month, you wait about 15 days on average before you apply it, and up to 30. In the two cases above, attacks started one day and four days after the fix. On a monthly cycle, you would have been exposed for roughly 11 to 14 days on average, with attackers already active.
The Dell news shows how far this goes. On 2 October, The Hacker News reported six critical flaws in Dell Container Storage Modules, a set of Kubernetes add-ons for connecting clusters to Dell storage, fixed in version 1.18.0. Dell said a successful attack could give root access on cluster nodes and full control of the storage. These are not developer tools in the strict sense, but they sit in the same blind spot: infrastructure software installed once by one team and then rarely revisited.
The case for and against self-hosting
The honest point in the self-hosted column is that the hosted versions came off better here. GitLab's hosted services were fixed before most customers had read the advisory. JFrog's cloud service was protected by its default configuration for the worst of the three flaws. When you self-host, the patch window belongs to you, and so does the risk inside it.
Self-hosting still has real reasons behind it. Data residency rules, air-gapped networks, very large repositories, build costs at scale and the need to keep source code off third-party servers are all valid. Some regulators expect it. But if you self-host, you have taken on the vendor's operations job, including the fast patch. Most teams agreed to the first part and never staffed the second.
The honest caveat
The risk is not the same for everyone. Both the GitLab and Artifactory attacks targeted instances reachable from the internet. A server that is only reachable over a VPN or a private network was much harder to hit. The GitLab flaw also needed at least one public project. If your instance is private and has no public projects, your risk from this specific bug was lower.
The Dell flaws, as of the reports, had not been seen in active attacks. Managed services carry their own risks too, including outages and less control over upgrades. Moving to hosted tools swaps one set of problems for another rather than removing them.
What to do about it
Name an owner this week. One team, one person accountable for patching source control, CI servers, runners and artifact repositories, with security reviewing them like any production system.
Set a patch target for critical flaws in these tools measured in hours. Something like 24 to 48 hours for anything rated critical, and same day if it is already being exploited. Agree in advance that developers will lose GitLab for an hour when that happens.
Get them off the open internet. If your build tools do not need to be public, put them behind a VPN or an access proxy. That alone would have blunted both recent attacks.
Map what one pipeline credential can reach. Pick your most used CI variable and trace it. If a single token can deploy to production in every region, shorten its life, narrow its scope, or swap it for short-lived credentials issued per job.
If you were running an affected version, assume the secrets were read. Patching closes the door but does not change the locks. Rotate tokens and keys, look for new admin accounts and plugins, and check that recent builds and images match what you expect.
The build pipeline holds more keys than almost any other system you run. It deserves the same care.
