Docker Hub reassigned personal access tokens without rotating their secrets for 25 months

September 30, 2026. Two researchers report a flaw in Docker Hub’s identity and access management to Docker. The fix is in production less than four hours later. October 12, 2026. Docker publishes the official advisory, CVE-2026-105445. Why it matters: for twenty-five months, converting a personal account into an organization reassigned personal access tokens to a new owner without rotating or revoking their secrets. An attacker who kept the secret could push or delete images under the victim’s identity.

An identity reassignment that leaves the secret untouched

The flaw sits in an ordinary feature: converting an account into an organization. Docker Hub has no way to move a repository between accounts. To turn alice/app into an organization-owned repository without breaking every existing docker pull, you convert the account and name an existing account as the new organization’s owner.

The problem began on August 26, 2024. From that date, conversion also reassigned the converted account’s personal access tokens (PATs) to the new owner — by changing the token’s owner record without rotating or revoking the secret. The named owner was not asked to confirm and was not notified. Those two gaps together made exploitation trivial:

1. The attacker creates an account and generates a PAT on it.
2. They convert that account into an organization, naming the victim as owner.
3. The PAT is reassigned to the victim, but the attacker still holds the secret.
4. The token now authenticates to the registry as the victim.

Within its scope, a reassigned PAT acted as the victim at the registry level: it could push, pull and delete images in the victim’s repositories and in organizations the victim could access. Because that includes publishing images under a legitimate name, Docker treated the issue as a software supply chain risk and rated it critical. The flaw, classified as CWE-266, did not grant access to the web interface, could not change the victim’s password, email or 2FA settings, and could not take over the account.

Four hours to fix, twenty-five months to notice

The response timeline is a model of responsible disclosure. On September 30 at 11:40 a.m., researchers Peter Molnar and Krisztian Hozak of mptrdev.com reported the issue. Docker reproduced it around 1:30 p.m., deployed the fix around 3:10 p.m. — conversion no longer transfers PATs — and informed the researchers at 4:59 p.m. On October 2 at 5:30 p.m., exposed users were notified by email. On October 8, Docker force-deactivated all transferred PATs, except those their holders asked to keep. The researchers published their analysis as GhostPAT.

The contrast is striking, and it is the lesson. The fix took under four hours. Detection took twenty-five months: the flaw was introduced on August 26, 2024 and only closed on September 30, 2026. An identity vulnerability leaves no visible trace until it is exploited — which is exactly what makes it dangerous.

What the investigation found, and what it could not find

Docker enumerated every conversion since August 26, 2024 and correlated them with registry authentication logs, usage data and token records. Verdict: no evidence of exploitation. Of roughly 304,000 pushes made with a transferred token, every one landed in the converted organization’s own repositories or the named owner’s repositories. In most cases the same person controlled both accounts — the feature’s legitimate use. Static analysis of the highest-risk public images found no malware, no cryptominers, no command-and-control, no credential harvesting, no persistence, no tampering.

The important point is the limit Docker itself acknowledges. Registry logs show when a token is used, not that it exists. A transferred PAT that was never used leaves no trace. The vendor therefore did not rely on detection to decide who was exposed: it treated every token that moved through conversion during the window as potentially affected, whether or not it was observed in use.

Three changes that matter more than the patch

The immediate fix removes PAT transfer from conversion entirely. But the three announced commitments are more structural:

• Mandatory consent before naming an organization owner, with notification.
• An auditable history of every token ownership change, so questions are answered from records rather than inference.
• A review of other flows that change credential ownership, looking for the same pattern.

That is the real takeaway. A flaw in a token’s identity — rather than in its cryptography — is precisely the kind of defect that neither vulnerability scanners nor code audits catch. It patches in hours, but it only surfaces if someone asks the right question: what happens when this token changes hands?

The supply chain does not end at the namespace

This episode sits inside a broader series where trust in a package ecosystem collapses because of an identity, not code. The npm and PyPI ecosystems have seen equivalent campaigns — this blog documented MALFEX, which hid a shellcode loader inside a native npm module that stayed online. The common thread is always the same: the attacker does not break cryptography, they impersonate a publisher’s legitimacy.

That is exactly why signing mechanisms exist. The Sigstore project, carried by Cosign, lets you sign an image and verify that signature before deployment, regardless of what the namespace claims. A ghost PAT can push an image under a victim’s name, but it cannot produce the victim’s signature. The chain of trust shifts from the name to the key:

# Pin an image by digest rather than a mutable tag
docker pull alpine@sha256:9a839e63dad54c3a6d1834e29692c8492d93f90c59c978c1ed79109ea4fb9a54

# Verify the signature before any deployment
cosign verify \
  --certificate-identity [email protected] \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  myorg/app:latest

The operational lesson fits in one sentence: the namespace is a weak signal, the signature is the only strong one. A registry that lets a token change owners without changing its secret is a reminder of how fragile the former is.

Audit your own token lifecycle

The practical countermeasure is a periodic token audit, and it needs no new tooling. Enumerate every personal access token and organization token in your registries, confirm who owns it and when it was last rotated, and revoke anything orphaned, unknown or stale. For automation that acts on behalf of a team, an organization access token with a scoped role beats a personal PAT: its ownership is collective, its scope is auditable, and its lifecycle is no longer tied to one person’s account. GhostPAT survived twenty-five months because nobody asked whether a token’s owner had changed while its secret stayed the same. A one-hour audit that pairs those two questions closes the gap. The asymmetry is worth naming: code review and vulnerability scanning look at what a credential can do, not whose name is attached to it — which is why Docker’s commitment to an auditable history of token ownership changes matters more than the four-hour fix itself.

Verdict

If you publish images to a public registry, assume the namespace proves nothing: a token that changed hands without changing its secret voids the trust placed in a publisher’s name. In practice, move automation onto organization tokens instead of personal PATs, revoke tokens you no longer recognize, and sign your images with Cosign or an equivalent attestation — the signature, not the name, is the real trust boundary. If you consume images, enable signature verification and pin your dependencies by digest, not by tag.

References

• Docker — Docker Hub security advisory: CVE-2026-105445
• GhostPAT — Peter Molnar and Krisztian Hozak
• CVE-2026-105445 — OpenCVE
• ETTAYEB — Artifactory’s Docker cache exposed to RCE (CVE-2026-66384)