The Pipeline as a Line of Defence: What the OVHcloud and LiteLLM Cases Teach

Between 19 and 21 October 2026, two tools used every day in build and deployment pipelines were replaced by versions that steal credentials. One was the command-line interface of a European cloud provider. The other, an open-source library with more than 20 million downloads a week, according to Datadog Security Labs.

Neither case started with a failure in the pipelines of the people using those tools. But in both, the consumer's pipeline was the right place to stop the intrusion.

19 October: the OVHcloud command-line interface

For 94 minutes, from 14:47 to 16:21 (Paris time), the official ovhcloud-cli binaries published on GitHub, versions 0.11.0 to 0.15.0, were replaced with tampered builds designed to collect secrets stored on disk. According to IT-Connect, the checksums file was rewritten as well: anyone comparing the download with the value published on the release page itself got a perfect match.

OVHcloud founder Octave Klaba explained the cause publicly: GitHub's release immutability option was disabled, which allowed a sufficiently privileged account to modify published releases without going through the build pipeline. OVHcloud's own pipeline was not compromised. The option has been enabled and version 0.16.0 was released signed and immutable.

The most useful detail is how it was detected. According to IT-Connect, the alarm came from a customer's continuous integration pipeline, which had the file's SHA-256 fingerprint on record. The fingerprint changed without warning, the build failed, and the customer opened a public issue on the repository.

21 October: the LiteLLM release workflow

Two days later, LiteLLM version 1.107.0 was published to PyPI and as Docker images with code that harvests credentials and opens the door to remote execution. The project's official report describes a sequence that went through several barriers.

GitHub branch protection rejected the first attempt to change the private release workflow. A credential from a privileged developer account overrode that protection and applied the change. The modified workflow then built from a repository with a name almost identical to the official one. The production approval was satisfied with the credential of a second account. And a third account deleted the run records.

The version was available for about two hours before it was pulled. The official source tag on GitHub did not contain the malicious files. The compromised images, according to the report itself, carried a valid signature made with the project's previous key. The report warns that parts of the analysis are still under review.

The project had already hardened its process after an incident in March: releases from a private repository, trusted publishers, immutable Docker tags and signed images. As the report puts it, the attacker had to compromise multiple independent security controls to succeed.

What the two cases have in common

Three points run through both incidents.

1. The proof came from the same place as the artefact. At OVHcloud, the checksum was rewritten with the binary. At LiteLLM, the signature was valid. Verifying against proof published through the same channel that was compromised proves nothing.
2. The defence that worked was on the consumer's side. A pipeline that pins versions and fingerprints stops the silent change, because it compares against a value recorded before the attack.
3. Credentials with power over publishing were the way in. In both cases, legitimate accounts did what the build pipeline existed to control.

The scale of the problem

The automation running in pipelines has grown faster than the attention it gets. According to GitHub's Octoverse 2026, 45 billion GitHub Actions jobs ran in the twelve months to September 2026, against 14 billion in the previous period.

Every job that downloads a tool, an image or a library is an entry point. The question is no longer whether the pipeline is fast. It is what the pipeline accepts without asking.

Four practices that need no new tooling

1. Pin versions and fingerprints. Build tools, base images and dependencies enter the pipeline with an exact version and a checksum recorded in the repository itself. A silent change then breaks the build, as it did for the OVHcloud customer.
2. Verify at the source, not on the same page. Prefer immutable releases and provenance attestations verified with the provider's tooling, rather than the checksum published next to the file.
3. Separate who changes the workflow from who approves production. Changes to the release workflow itself should go through review, and production approval should not depend on a single account. Run records should be protected from deletion.
4. Inventory the pipeline's credentials. Know which secrets each workflow uses, with what permissions, who can read them and when they are rotated. In the OVHcloud case, the advice to those affected was to change every secret on disk: that is much easier when you know which ones they are.

None of the four removes the risk. Together, they shrink the window in which a tampered tool can get in unnoticed.

Conclusion

Both incidents lasted hours, not days, and still had global reach, because these tools flow automatically into thousands of pipelines. In both, the provider reacted quickly and explained publicly what happened. The lesson for consumers is different: the pipeline is not only the way code goes out to production. It is also the first place where what comes in can be checked.

When it makes sense to reinforce the in-house team is covered in DevOps as a Service, when it makes sense, and the path to production was covered in CI/CD pipeline setup in two hours. To review what the pipeline accepts today without checking, it is possible to book a Clarity Session, with no commitment.