Hijacked Maintainer Accounts and Reclaimed Repository Names: What October's GhostAction, OVHcloud and npm Cases Show About Release Controls
Comparing three October 2026 cases, GhostAction, the OVHcloud CLI release swap and npm's SlugFest trusted-publishing gap, on how accounts, names and release settings were exploited.
Background
Three separate events in October 2026 raised the same question for software consumers: how far a release can be trusted when the account, or the repository name, behind it is no longer the one the maintainer controls. They involve a credential-theft campaign on GitHub, a hijacked contributor account at a cloud provider, and a design gap in npm’s trusted publishing. The Machine Herald covered each separately: GhostAction, the OVHcloud CLI release swap, and the SlugFest research. This article compares them.
Two defensive mechanisms frame the comparison. The first is trusted publishing, which The Hacker News reports was introduced in npm in July 2025 as a credential-free way to push packages from a CI/CD platform such as GitHub Actions using OpenID Connect tokens. In that report’s description, the CI/CD provider generates a short-lived token for a specific workflow run, and the npm registry verifies it against a pre-authorized configuration, which removes the need to store or rotate long-lived npm secrets.
The second is GitHub’s immutable releases. According to GitHub’s changelog, once a release is published as immutable its assets cannot be added, modified or deleted, and its tag is protected. The same changelog says that once the setting is enabled all new releases are immutable, while “Existing releases remain mutable unless you republish them.”
GhostAction predates both incidents. The Hacker News reports that it first came to light in September 2025, affecting 817 repositories across 327 GitHub users and exfiltrating 3,325 secrets, including PyPI, npm and DockerHub tokens.
Current situation
GhostAction: stolen account access used to read secrets
StepSecurity reports that on October 8, 2026, attackers operating GhostAction compromised two open-source maintainer accounts and pushed a malicious workflow to 345 repositories in two automated windows. It says the account of Takashi Kitao, author of the 18,400-star game engine pyxel, was used to push the workflow to 27 repositories starting at 13:20 UTC, and that eight hours later the account of Henry Wu (henrywoo), original author of Uber’s athenadriver, was used to push it to 318 repositories between 21:10 and 21:26 UTC.
According to The Hacker News, the workflow, named “Security Audit” or “GitHub Actions Security”, sends a repository’s named Actions secrets, together with credentials found in the working tree and the entire git history, to a hard-coded IP address over plain HTTP. The same report says the attack chain most likely begins with a leaked personal access token from infostealer logs or credential dumps. It also cites Socket as having identified more than 500 GitHub accounts that committed the workflow to tens of thousands of repositories since October 7, 2026, and cites GitGuardian as reporting 772 public repositories belonging to 373 users or organizations between August 31 and September 30, 2026.
StepSecurity says the run’s GITHUB_TOKEN was scoped to contents: read, so the workflow could not push or publish by itself, and that escalation depends on the secrets it steals. It notes that pyxel is published to both PyPI and crates.io and that the workflow was set to send named secrets that include PyPI and crates.io registry credentials. It reports that no malicious package releases had been published from the compromised publishing credentials at the time of writing, and adds that “the absence of abuse so far is not evidence that the credentials are safe.”
OVHcloud: replaced release files without a pipeline run
The Hacker News reports that on October 19, an attacker used a contributor’s GitHub account to replace the download archives on five existing releases of OVHcloud’s command-line tool, v0.11.0 through v0.15.0. The swapped files were live for up to 94 minutes, from 12:47 to 14:21 UTC. On v0.15.0 the attacker also replaced checksums.txt, so the published hashes matched the new binaries. The report says the source code, release tag and build pipeline were not touched, and that the release workflow never ran.
The report states that OVHcloud’s founder, Octave Klaba, wrote that the problem stemmed from the immutability option not being activated, so a user with the right permissions could modify existing releases on GitHub without any checks by the company’s CI/CD pipeline. It says the option is now enabled and that OVHcloud published a clean v0.16.0 as an immutable release. It also says OVHcloud has not said how the account’s credentials were taken, and has promised a detailed postmortem.
The outcomes differed by installation path. According to the same report, the official install script “has never checked a hash”, the CLI’s upgrade command downloads and replaces the binary with no hash check, and a Homebrew cask in force during the window pinned each archive’s original SHA-256, so Homebrew would have refused the swapped files. The incident came to light, per the public GitHub issue, because a customer’s CI pins the SHA-256 of the Linux arm64 archive and began failing. The issue’s author wrote that there was no private vulnerability reporting channel on the repository, so the report was filed publicly.
The report adds that OpenSourceMalware ties the account to the GlassWorm campaign through earlier activity on the account’s personal repositories, and that whether the same actor did both is, in the researchers’ words, “our inference.”
SlugFest: no stolen credentials required
The Hacker News reports that Bloom Security found npm’s trusted publishing recorded a repository’s “owner/repository” name, not the permanent numeric ID GitHub assigns it, until a version was first published from that repository. If a maintainer renamed, transferred or deleted a repository whose binding had never been used to publish, an attacker could create a repository at the freed name, obtain a GitHub OIDC token carrying it, and exchange that token for a publish credential for a package they did not own. The report says Bloom Security found more than 1,500 vulnerable packages, collectively downloaded more than 10 million times, and reported the issue to GitHub on June 6, 2026. Researcher Golan Myers said, “The attack requires no insider knowledge, no credential theft, and no race condition.”
GitHub’s changelog says unvalidated configurations now expire 48 hours after creation and can no longer authorize publishing. “Your configuration becomes validated and exempt from expiry after its first successful publish,” it states, and npm also now rejects trusted publishing tokens from GitHub Actions issue_comment events, in addition to the existing pull_request_target restriction.
Implications
The following points are analysis drawn from the reports above; the sources themselves do not make this comparison.
The entry points differ, but each exploits a binding between a name and a trust decision. In GhostAction, per StepSecurity and The Hacker News, the likely entry point was a leaked token that let the attacker act as a maintainer. At OVHcloud, the entry point was a contributor account whose compromise method has not been disclosed. In SlugFest, no credential was stolen, and the weak point was a registry binding to a repository name. The Hacker News quotes the Bloom Security research as stating that “the binding between a human-readable identifier and the thing it identifies is the most important invariant in any trust system.”
Controls that bound a release to something other than an account were the ones that worked in the OVHcloud case. The release-page files were replaceable because immutability was off, and the changelog says the setting does not retroactively protect releases created earlier. The customer pin and the Homebrew cask pin each relied on a hash recorded outside the mutable release page. The same report notes that the swapped checksums.txt matched the new binaries, so a checksum fetched from the same place as the archive would not have flagged the change. The report also says OVHcloud’s clean v0.16.0 carries a signed release attestation, and that GitHub documents gh release verify-asset for checking an archive against it.
Trusted publishing addresses the secret-theft path that GhostAction targets, with a gap that GitHub has now narrowed. GhostAction’s payload, according to The Hacker News, targets npm and PyPI tokens among other secrets, and StepSecurity says the stolen registry tokens are a path to shipping a malicious version of a library. Trusted publishing is described as removing long-lived npm secrets from CI. SlugFest showed that the configuration step could itself be taken over until a first publish validated it, and GitHub’s 48-hour expiry targets that window. It applies to configurations that have not yet been validated by a first publish.
What the sources tell developers to do. Bloom Security’s guidance, as reported, is to audit trusted publisher bindings, re-create bindings pointing at the current repository name after any rename or transfer, delete bindings when a repository is deleted, and monitor for unexpected publish events. For GhostAction, StepSecurity advises searching for the two workflow filenames, revoking the compromised GitHub credential as well as rotating secrets, and not cutting releases until a repository is cleaned. For the OVHcloud swap, The Hacker News reports advice to rotate every secret readable from an affected machine, ideally from a different machine, and to check a downloaded archive with gh release verify-asset.
Open questions. OVHcloud has not said how the contributor account was compromised or what the binary did, and The Hacker News reports that no copy of a swapped archive has been analyzed in public. For GhostAction, StepSecurity reports no malicious releases from the harvested publishing credentials at the time of writing, and says the exposure window on those tokens stays open until they are rotated.