Malicious commits breached 5,561 repositories

Opening position

5,561 GitHub repositories received malicious CI/CD commits within a 6-hour window. The commits were styled to match routine bot maintenance activity. Beyond the repository count and the window duration, additional scope details are not confirmed.

The relevant property is not the volume. The relevant property is the disguise. The commits were accepted into repositories at a rate consistent with automation. That rate is only achievable when the receiving systems treat the commit author as trusted by default.

This is not a story about a clever exploit. This is a story about identity boundaries that were never enforced. If a commit looks like a bot, and the pipeline trusts bots, the pipeline executes the commit. The disguise is the payload.

What actually failed

Malicious commits entered 5,561 repositories and were not rejected at the point of ingestion. The commits resembled routine bot maintenance. Whether the commits were authored under a legitimate bot identity, a spoofed identity, or a compromised identity is not confirmed. What is confirmed is that the commits were not stopped.

The receiving repositories did not differentiate between a maintenance commit and a malicious commit carrying the same surface characteristics. Author string, commit message format, and file scope appear to have been sufficient signals for the commits to pass without challenge. Whether branch protection, required reviews, or signed-commit enforcement were present on the affected repositories is not confirmed.

CI/CD systems attached to these repositories would execute on commit by default. Whether any of the 5,561 repositories triggered downstream builds, published artifacts, or propagated the change to dependent systems is not confirmed. The failure observable from the available facts is at the ingestion layer. The commit was accepted. Everything after that point is not confirmed and must be verified per repository.

Why it failed

The commits were accepted because the repositories treated the appearance of a bot identity as equivalent to the authority of that identity. Appearance is a string. Authority is a verified signature tied to a key the repository owner controls. These are not the same thing, and the affected repositories did not enforce the difference.

A commit author field is metadata. It is set by whoever creates the commit. Without signature verification enforced at the branch level, the author field carries no trust value. The 5,561 repositories accepted commits where the trust decision was based on metadata that the attacker controlled. The control that would have stopped this, required signed commits with verified keys at the protected branch level, was either absent, not enforced, or bypassable. Which of these applied per repository is not confirmed.

The second failure is the assumption that bot traffic is low-risk traffic. Bots commit frequently, in small diffs, with predictable messages. Human review fatigue treats this pattern as background noise. Automated review treats this pattern as a known-good shape. Both responses convert a high-frequency identity into an unmonitored ingress path. When the identity is impersonated or compromised, the monitoring gap is the attack surface. The 6-hour window is consistent with an actor moving faster than human review and within the trust envelope already granted to automation.

Mechanism of failure

The mechanism is the substitution of appearance for authority. A repository configured to trust commits from a bot identity is configured to trust a string. The string is set by whoever produces the commit. Anyone who can produce a commit with that string is, from the repository’s enforcement perspective, that bot. The signature is the only object that converts a claim into a credential. The signature was not the gating condition.

This is identity drift, not control failure in the conventional sense. The control was not present to fail. The repositories operated as designed. The design treated a low-friction author label as a sufficient trust anchor. When 5,561 repositories share that design property, any actor who can match the label inherits the trust of every bot they impersonate. The 6-hour window is consistent with scripted commit production. Whether a single actor or coordinated actors produced the commits is not confirmed.

The drift compounds at the automation layer. CI/CD pipelines configured to trigger on commit do not re-verify the author. The pipeline’s trust was inherited from the repository’s trust. If the repository accepted the commit, the pipeline accepts the work. Every layer downstream of the ingestion point operates on the assumption that ingestion enforced something. Ingestion enforced metadata matching. Whether any pipeline executed, what it executed, and what it produced is not confirmed and must be verified per repository.

Expansion into parallel pattern

The same mechanism exists wherever a system uses identity appearance as the enforcement signal. Service accounts identified by name in access policies without bound key verification fail by the same path. The policy grants permission to a label. The label is asserted by the calling process. If a process can assert the label, it inherits the permission. The cryptographic binding between the label and the entity authorised to use it is the only object that converts the policy from a suggestion into a control.

Webhook receivers that validate sender identity by source field or user-agent string carry the identical exposure. The receiver trusts what the sender claims about itself. Any actor that can reach the endpoint and replicate the claim is, to the receiver, the trusted sender. The corrective control in both cases has the same shape as the missing control in the GitHub case: signature verification against a key the receiver controls and the sender cannot forge.

The pattern generalises to any environment where automation runs against high-frequency, low-variance traffic from a labelled source. The label is cheap to produce. The verification is comparatively expensive to enforce. Systems that optimise for throughput drop the verification first. The 5,561 repositories are a count of systems that made that trade in this disclosure. The count of systems across the broader ecosystem that have made the same trade and have not yet been targeted is not confirmed.

Hard closing truth

Identity is the boundary. If the identity is a string the attacker can write, the boundary is decorative. Required signed commits with verified keys, enforced at the protected branch level, is the primitive that converts the boundary from decorative to operational. Any repository that runs CI/CD on commit and does not enforce this is in the same condition the 5,561 were in before the commits arrived.

Audit commit history across every repository under management for the 6-hour window referenced in the disclosure. Compare commit signatures against the keys registered for the asserted bot identities. Any commit from a bot identity without a verified signature against a controlled key is suspect and must be handled as such until proven otherwise. Whether the disclosure has published specific signatures, file paths, or commit message contents associated with the malicious commits is not confirmed. Absence of those indicators does not narrow the audit scope. It widens it.

Bot traffic is not low-risk traffic. It is the traffic least likely to be reviewed and most likely to be trusted. That combination is the attack surface. Treat every automated identity as a privileged identity. Enforce signature verification, scope tokens to the minimum the automation requires, and apply the same review threshold to automation commits that is applied to human commits. A control that is not enforced is not a control. 5,561 is the count of repositories that have now established this. The next count is a function of how many operators act before the next window opens.