OVHcloud CLI: five releases swapped for up to 94 minutes on 19 October 2026, and the checksum list was swapped too

94 minutes, and the checksum list was swapped with the files

OVHcloud's founder wrote on X, in French, that the 14:47 version of its command-line tool (Paris time, Monday 19 October 2026) had been compromised and that the company detected and blocked it at 16:21 (the post, translated here). That is 12:47 to 14:21 UTC, or 94 minutes (derived), and 13:47 to 15:21 on UK clocks. It is the longest the swapped files can have been available, and it is the number in the reports. In that window the files that people download from five existing releases, published between 14 April and 16 September 2026, were replaced with a build the company says was made to collect secrets stored on disk.

The detail that matters more is in the public record of the one release where every replaced file is listed. On v0.15.0 six were replaced: five of the nine platform archives and the checksum list, so the published hashes matched the new files. On two older releases the reporter timed the archive and the checksum list three minutes apart (derived from issue 300). A hash published in the same place as the file proves nothing about who changed both. A hash held somewhere else did: a customer's build job that pinned one began failing, and that is how the swap was found.

What this does not establish. The 94 minutes is a ceiling, not a measurement. No source read gives a download count, and the release records suggest the clean-up began about four minutes earlier on three of the five releases (below). Nobody has published an analysis of the swapped binary: the claim that it was built to read secrets rests on the company's statement, and OVHcloud has not said which files it read, where it sent them or how the account was taken. No source read reports a stolen secret being used.

This briefing reads the primary records first: the public GitHub issue that reported the swap, the repository's release records through GitHub's public interface, the Homebrew tap's commit log, the repository's install script, upgrade code and release workflow, OVHcloud's documentation, GitHub's documentation and the founder's post. The Hacker News, the French outlet Next (which quotes a second post from the founder; the thread on X shows only the start of that post, so Next's quotation is the complete text read) and OpenSourceMalware, whose researchers built a timeline from GitHub's server-side records, are read as reports and checked against the primary records where those allow. Everything was read between 11:46 and 12:17 BST on Tuesday 20 October 2026. The post-mortem the company promised was not out at the end of that time.

The day in order, to the minute where the record allows

Times are UTC. Paris was two hours ahead and UK clocks one hour ahead. Each row says where it comes from, because the sources are not equal: GitHub's own timestamps are one thing, a reporter's capture is another, and a founder's post is a third.

Monday 19 October 2026, in UTC, from the public issue, GitHub's release records and Actions run list, and the founder's post (read 20 October 2026).

UTC (BST)	What the record shows	Where it comes from
12:47 (13:47)	First replaced file lands on v0.15.0. The founder's 14:47 Paris time is the same minute.	The reporter's capture in the public issue, and the founder's post
12:47 to 12:57	Six files replaced on v0.15.0: five platform archives and the checksum list.	The reporter's capture
13:01 to 13:04	On v0.14.0 the Linux arm64 archive, then the checksum list. Other files not checked by the reporter.	The reporter's capture
13:08 to 13:11	On v0.13.0 the same two files, the same three minutes apart.	The reporter's capture
about 13:12	Last replacement the reporter saw. v0.11.0 and v0.12.0 are on the company's list; the times of their swaps are in no source read.	The issue's own title, and the founder's list
13:50	The public issue is opened, 63 minutes after the first swap (derived), after a customer's pinned hash failed.	GitHub's timestamp on the issue
14:17 to 14:21	The five release records are last updated: v0.15.0 at 14:17:24, v0.14.0 at 14:17:28, v0.13.0 at 14:17:32, v0.12.0 at 14:21:09, v0.11.0 at 14:21:13. What changed is not stated.	GitHub's release records
14:18	First reply in the issue: the company is on it.	GitHub's timestamp on the comment
14:21 (15:21)	The replaced files are deleted, which is the end of the 94 minutes.	A maintainer's comment ("16:21 GMT+2") and the founder's post
16:00	The tag for v0.16.0 is pushed. It is the first workflow run of any kind since 16 October.	GitHub's Actions run list
16:52	The founder's public warning on X, quoting the affected versions and saying to change every secret on the disk.	The X page
17:16	v0.16.0 is published under a service account rather than a person's, marked immutable.	GitHub's release record and the release page

Four figures follow from the table (derived). The swapping took about 25 minutes. The public issue was opened 63 minutes after the first swap, so about two thirds of the 94 minutes had passed before it. The files were deleted 31 minutes after the issue was opened, and the clean release followed the deletion by 2 hours 55 minutes. The founder's post says the company detected and blocked the build at 16:21 Paris time, which is the 14:21 deletion; the public issue had by then been open for 31 minutes, and the post thanks the customer who raised it.

One detail from the release records changes the ceiling. The last-updated stamps on the five releases fall between 14:17:24 and 14:21:13 UTC, with the three releases the reporter named at 14:17 and the other two at 14:21. GitHub's record does not say what changed, and the company's stated deletion time is 14:21 to the minute. If the stamps mark the deletions, the three named releases were clean about four minutes earlier, and 94 minutes is the ceiling only for the oldest two (inference).

The diagram draws the day to scale, with the age of each swapped release underneath.

What was swapped: five of nine archives, and the list that vouched for them

Each release carries nine platform archives and one checksum list. On v0.15.0 the public record lists six replaced files: the macOS archives for x86_64 and arm64, the Linux archives for x86_64 and arm64, the Windows x86_64 archive and the checksum list. Five of nine archives is 55.6 per cent, and six of ten files is 60 per cent (derived). The Linux i386, Windows i386, Windows arm64 and WebAssembly archives were not replaced on any of the five releases: each release now lists those four, with upload times from the day it was published. OpenSourceMalware reads the choice as aimed at the platforms most developers run. The sources do not say why those five were chosen.

The five swapped releases and their neighbours, from GitHub's release records read on 20 October 2026. Age is calendar days from publication to 19 October (derived).

Release	Published, and age on 19 October	Replaced files on the public record	Archives listed now
v0.15.0	16 September, 33 days	Six, 12:47 to 12:57 (the reporter's capture)	4
v0.14.0	31 August, 49 days	Linux arm64 archive and checksum list confirmed; the rest inferred	4
v0.13.0	25 August, 55 days	The same two confirmed; the rest inferred	4
v0.12.0	29 May, 143 days	On the company's list; times and files not captured	4
v0.11.0	14 April, 188 days	On the company's list; times and files not captured	4
v0.10.0	2 March, 231 days	None: the company calls it clean	9, plus the checksum list
v0.16.0	19 October, new	Not applicable: published after the clean-up	9, plus the checksum list

Count with care. Five releases of six files each is 30 files (derived), but the public record confirms 10: six on v0.15.0 and two each on v0.14.0 and v0.13.0. The other 20 are inferred from the company's list of compromised releases and from what is missing now. The reporter's issue names v0.13.0 to v0.15.0, which is three releases. The company names five, and the release records show the same four archives left on all five, so this briefing follows the company.

Who was exposed: the install path decided it

A person was exposed if, between 12:47 and 14:21 UTC on 19 October, they installed or updated the tool on macOS, Linux (x86_64 or arm64) or Windows (x86_64) by a route that fetched a swapped archive and did not compare it with a hash held somewhere else. Having a version from v0.11.0 to v0.15.0 is not enough: those versions were genuine before 12:47. The table sets each route against the record.

Install routes against the record. Basis: the repository's install script, upgrade code, release workflow and release configuration, the Homebrew tap, Docker Hub and OVHcloud's documentation, all read on 20 October 2026.

Route	Exposed in the window?	What the record shows
The official install script	Yes	It downloads whatever archive sits at the release address for the newest release. As read for this briefing, it has no hash, signature or verification step, and it has not changed since October 2025. Until 17:16 UTC the newest release was v0.15.0 (inference from the release order).
A download from the release page	Yes	The page offered the swapped archives and the swapped checksum list.
A build job that fetches from the release address	Yes, unless it pinned a hash held elsewhere	The one job reported to have pinned a hash failed and was the first alarm. A job that read the checksum list from the same release would have passed (inference from the swapped list).
The tool's own upgrade command	Yes on macOS and Linux, per The Hacker News	The command arrived in v0.12.0 (29 May). Its code, as read, has no hash or signature check.
The Homebrew cask	No	The cask in force pinned the original hash for each of its four platforms, and the tap has no commit between 16 September and 17:16 UTC on 19 October. The cask has no Windows entry.
Installing through the Go toolchain, or building from source	No	The v0.15.0 tag still points to its September commit. The source was not changed.
The Docker image	No	Its latest tag was last pushed on 21 September, 28 days before the swap (derived).
Installed earlier and not updated in the window	No	That copy is the original file.
Linux i386, Windows i386, Windows arm64, WebAssembly	No	Those archives were not replaced on any of the five releases.

Six friendly names, and what each one covered

A label that sounds like a control is not one. Six appear in this story, and each did a different job on the day. The pattern is that every label sat on the same release page as the files it described, or covered something other than the files.

Labels in the story and what the record shows about each.

The label	What it suggests	What the record shows
The checksum list	The file you fetched is the one the maintainers published.	Replaced with the files on v0.15.0, and three minutes after the archive on v0.14.0 and v0.13.0, through the same account (the reporter's capture). It matched because both had been changed. Only hashes held elsewhere disagreed: the customer's pinned value and the Homebrew cask.
Verified	Signed, so trustworthy.	The release pages show Verified beside the tag of v0.14.0 and beside the commit under v0.15.0. Those are git objects. The swapped files were attachments, which GitHub lists as a separate thing to lock.
The official install script	The vendor's own, so safe.	It is the first method in OVHcloud's getting-started page, which mentions no hash check, and the script does none.
Latest	The newest good version.	The script's default. Until 17:16 UTC it meant v0.15.0, whose files had been swapped (inference from the release order).
Immutable release	Nobody can change it.	True only of releases published after the setting is on. One of 18 releases in the listing is immutable (derived).
Signed tag and release attestation	A signed record means a safe file.	GitHub says an immutable release gets an attestation of its tag, commit and files. That shows the files match what was published, not that what was published is safe. The v0.16.0 tag shows a signing key marked expired beside Verified, and the page does not say what that means.

Each party has an interest. OVHcloud sells cloud services, publishes the tool and chose the install methods it documents. Its founder's closing line, as Next quotes it, is that the incident is over; the same company promised a post-mortem. GitHub hosts the release pages and sells the platform, and the control that would have locked these files, had it been on when they were published, is its own feature, off until someone switches it on. OpenSourceMalware publishes threat research; its headline names the GlassWorm campaign as the culprit while its own summary calls that link an inference (below). The method is separate from the accusation: a customer who pinned a hash, filed a public issue with timestamps and build evidence, and a company that deleted the files within 31 minutes of that issue and named the affected versions the same day, did what a good report and a good response look like. The gap is in what each label covered.

Release immutability: what it locks, and why switching it on now does not lock these five

GitHub made immutable releases generally available on 28 October 2025 (changelog), which is 356 days before the swap (derived). Its documentation says that once a release is published as immutable its files cannot be modified or deleted and its tag cannot be moved. Only the title, the notes and the pre-release flag can still be edited. An immutable release also gets an attestation, which GitHub describes as a cryptographically verifiable record of the tag, the commit and the files. The setting is switched on per repository or organisation, and GitHub's instructions say plainly that "immutability will only apply to future releases". The changelog is blunter: "Existing releases remain mutable unless you republish them."

Nine releases were published between that date and the swap (v0.8.0, v0.8.1, v0.9.0, v0.10.0 and v0.11.0 to v0.15.0). None was immutable, and five of the nine were swapped, which is 55.6 per cent (derived). GitHub's documentation says repository collaborators and people with write access can create, edit and delete a release, so an account with write access could change any of them. The founder's second post, as Next quotes it, says the problem came from the immutability option not being activated, so that a user with the right permissions could change existing releases directly on GitHub without any check by the company's own pipeline. The pipeline itself, he said, was not affected. That explains how a person with write access could change old files. It does not explain how that account was obtained, or why the company's controls ran only on the pipeline's path.

The releases listing read on 20 October marks v0.16.0 as immutable and the other 17 releases as not, including the five that were swapped. Because the setting covers only future releases, those five remain editable by anyone with write access (GitHub's documentation, applied to this repository: inference). The four archives left on each are protected by access control alone. The founder's line that the option has now been enabled, and that the incident is over, is therefore true of new releases and silent on old ones. The company has not said whether it will republish them.

What nobody has shown: the payload, and how to read a build without running it

Everything about what the swapped binary did comes from the company. The founder said it was a binary whose job is to retrieve secrets on the disk, and that its quality was mediocre but that it could go all the way (translated here from his French). OpenSourceMalware says OVHcloud deleted the files before anyone archived them, so it did not analyse the payload, and The Hacker News says no copy of a swapped archive has been analysed in public. OVHcloud's getting-started page says the tool takes its credentials from a configuration file in the user's home directory or from environment variables, which is where a program looking for credentials would start (inference); the company's advice, to change every secret on the disk, covers far more than that.

What the build record shows is narrower and comes from the reporter, who read the embedded build information of the swapped Linux arm64 binary without running it before the files were deleted. In words: the version string was not a release tag, the recorded source revision was a later commit than the one the v0.15.0 tag points to, the record said the working tree had uncommitted changes, and a build setting was recorded that the release pipeline's builds do not leave. That reads as a plain build on a workstation, not a pipeline run, and the Actions run list agrees that no workflow ran in the window (see below). It is the reporter's and OpenSourceMalware's reading of one binary; the files are gone.

How the account was used: stated, inferred, unknown

The company's statement is that the attacker used the GitHub account of one of its developers. The reporter's table shows that the replaced files were uploaded through a different account from the one that originally published those releases, that the account is not a public member of the organisation and does not appear among the repository's listed contributors. The reporter says that may be a private membership and flagged it rather than assuming. OpenSourceMalware adds that the account has merged work in OVHcloud's documentation repository.

The release pipeline did not run. The repository's Actions run list, as read, shows no run of any kind between 14:38 UTC on 16 October and the v0.16.0 tag push at 16:00 UTC on 19 October, and the release workflow starts only when a version tag is pushed. OpenSourceMalware notes that repository administrators can delete workflow runs, so an empty list is strong evidence, not proof. Uploading release files needs write access. The repository's ownership file names one team for the whole repository, and OpenSourceMalware infers that is how the account got write access (inference: an ownership file names reviewers and does not itself grant permission, and the company has not said).

On who, there are three layers. Stated: an attacker used a developer's account. Inferred: OpenSourceMalware reports that four of the account's personal repositories were rewritten on 5 and 6 March 2026 to add a hidden loader, and that a wallet the loader reads is on public lists for the GlassWorm campaign. Its own summary calls the link between that and the October upload "our inference", and its headline states the attribution more firmly than its text does. The Hacker News adds that nothing from the October binary has been tied to GlassWorm because no copy was preserved. The March history was not re-checked here. If the March date is right, the earliest sign of the account's misuse is 228 days before the swap (derived; OpenSourceMalware says about 228). Unknown: how the credentials were taken, whether one actor held the account throughout, and whether any other token or secret in the organisation was exposed.

Stated and not stated

The table sets what the record states against what it does not, as of the end of reading on 20 October. "Not stated" means not found in any source read, not that the information does not exist.

What the public record states about the 19 October swap, and what it does not.

The question	Stated, and by whom	Not stated
Which files, and when	Six on v0.15.0 from 12:47, two each on v0.14.0 and v0.13.0 (the reporter's capture). Five releases on the company's list.	Times and file lists for v0.11.0 and v0.12.0, beyond what is missing now.
How long they were live	From 14:47 to 16:21 Paris time (the founder).	Per file or per release; whether the three named releases were clean from 14:17.
What the binary did	A binary whose job is to retrieve secrets from the disk, of mediocre quality (the founder).	Which files it read, where it sent them, whether any secret was used. No sample is public.
Who was exposed	The routes in the table above, on five platforms.	Download counts, any named victim, any report of a stolen secret being used.
How the account was used	An attacker used a developer's account (the founder). The pipeline did not run (the run list).	How the credentials were taken, for how long, and whether other tokens were exposed.
Why it was possible	The immutability option was not activated, so a user with the right permissions could change existing releases (the founder, via Next).	Why a contributor outside the public membership had write access.
Who is behind it	A link to GlassWorm is "our inference" (OpenSourceMalware).	Any tie between the October binary and any campaign.
Other repositories	First checks found none affected (the founder).	How that was checked, and the result of the full audit.
The post-mortem	Promised in the coming days (the founder, a maintainer).	Published: none found by the end of reading.

The UK: what the guidance says, and where it stops

UK guidance on software supply chains is written mainly for the people who build and ship software, with a few lines for the people who install it. The documents are the NCSC's implementation guidance for principle 3.1 and for principles 2.1 and 2.2, its blog on dependencies, its third party software example, DSIT's Software Security Code of Practice, the Cyber Essentials requirements v3.3 and the ICO's breach guide. The NCSC, DSIT and Cyber Essentials documents (seven, counting the NCSC's build and deployment pipeline guidance) were searched for the words immutable, attestation, checksum and hash: none contains any of them. The table sets what they do say against this incident, with short exact quotations.

UK guidance as read on 20 October 2026 from the NCSC, DSIT, Cyber Essentials and the ICO, and where each stops.

UK document	What it says	Where it stops
NCSC, Software Security Code of Practice implementation guidance, principle 3.1 (published 7 May 2025)	"Tampering with or spoofing software (and its updates) can occur at various stages of the distribution process." Vendors should provide a trusted download location, and "Code integrity/provenance must be verified to provide confidence in its integrity before installation." Code should be signed through the pipeline.	Written for vendors. It does not say what a customer does when the only published hash sits beside the file, which is the position on 19 October.
Same guidance, principles 2.1, 2.2 and 3.2	Protect the build environment against unauthorised access, control and log changes to it, and implement and publish an effective vulnerability disclosure process.	The change here was a hand upload to old releases outside the pipeline, and the reporter had no private channel. Release permissions and immutability are not mentioned in the text read.
NCSC blog, Software supply chain attacks: check your dependencies (4 June 2026)	Names maintainer account compromise as a technique. Asks for deployments through "controlled CI/CD pipelines rather than developer devices", credentials kept off workstations, "Rotate exposed or potentially exposed credentials." and multi-factor authentication for developer accounts.	About packages and registries, not release pages. Nothing on hashes or locking releases.
NCSC supply chain guidance, third party software providers (reviewed 22 October 2025)	A 2019 example of attackers who "replaced legitimate files in their repositories with their own malware infected versions". "Compromised software is very difficult to detect if it has been altered at the source".	The pattern is the same as 19 October. The advice is to rely on the supplier, and does not offer a customer-side check.
DSIT, Software Security Code of Practice (updated 15 January 2026)	Voluntary, 14 principles, including 3.1 on secure distribution, 3.2 on disclosure and 4.3 on telling customers about notable incidents. It says open-source developers and maintainers "are not considered the primary audience", and that "Any risks associated with open-source code must be managed by end-users or proprietary developers using open-source code in their software."	Whether a free, open-source official client from a cloud supplier counts as the supplier's software is not settled by the text (inference). Its own words put the risk with the user.
Cyber Essentials requirements v3.3 (April 2026)	Software in scope must "have automatic updates enabled where possible", and critical or high-risk fixes go on within 14 days. Malware protection lists "downloads" among sources, and the allow-listing option is "Only approved applications, restricted by code signing, are allowed to execute on devices."	Nothing on checking an update's integrity. The release configuration as read has no signing step, so a plain build would not meet a signing-based allow-list (inference; the swapped file's signing is not stated).
ICO, personal data breaches: a guide	"You must do this within 72 hours of becoming aware of the breach, where feasible."	It applies only if a personal data breach followed, for example a stolen credential used to reach personal data. Running a swapped build is not stated to be one.

The tension worth naming is in the update advice. Cyber Essentials asks for automatic updates where possible and fixes within 14 days, while the NCSC's dependencies blog says to avoid adopting new dependency versions automatically without review. The two are about different things (patches to software in scope, and dependencies in development), and neither names a way to check that a tool's file is the one the publisher made. On 19 October the people who installed fresh or updated within the window, by the routes above, were the ones exposed. That is not an argument against updating. It is an argument for an update path that checks the file against something the person who can change the file cannot also change, which is what the Homebrew cask and the customer's pinned hash did and what the install script did not. The same shape appeared in this site's earlier briefings on a malicious npm release that carried valid provenance, where provenance showed where a release was built and not that anyone had reviewed it, and on Rank Math's 11 hour 10 minute download window, where the version number could not tell an owner whether a copy was affected.

What to do, in the order worth doing

Items 1 to 3 are for anyone who might have run the tool on 19 October. Items 4 to 9 are for anyone who installs or publishes software this way.

What could not be verified

• The payload. Everything about what it read or sent rests on the company's statement. No sample was preserved.
• The swap times on v0.11.0 and v0.12.0. The company lists them; the replacement times are in no source read. Their replaced files are inferred from what is missing now.
• The founder's second post. The thread on X shows only its first lines before a cut; the rest is read from Next's quotation, with a translation made here.
• The meaning of the release-record stamps. GitHub's record gives a last-updated time, not the event. The reading that they mark the deletions is an inference.
• OpenSourceMalware's March history. The rewrite of the account's personal repositories and the wallet link were not re-checked here. The Hacker News says it confirmed one loader file.
• The clean release's attestation. GitHub's documentation says every immutable release gets one. This briefing saw the Immutable label on the v0.16.0 page but did not open an attestation.
• The binaries. None was downloaded or opened. The claim that a clean build also carries a modified-tree marker is The Hacker News's.
• Time-stamped. Read between 11:46 and 12:17 BST on 20 October 2026. The post-mortem, the immutable status of the old releases, the company's list and the issue thread could change within hours.

The question that exposes the gap

Where does the hash your build trusts for a tool actually live, and could the person who can change the download also change it?

Key facts