Docker Hub's October 2026 GhostPat Flaw Explained: When a Token Changes Owners

From 26 August 2024 until the fix on 30 September 2026, the account's personal access tokens (PATs), long passwords that tools use, moved to the new owner and kept working. Whoever already held a token's secret could then act as that owner at the registry.

This flaw is the Docker Hub GhostPat vulnerability, a name given by the researchers who reported it. Docker tracks it as CVE-2026-105445. This guide explains what happened, what Docker changed and how to check your own tokens.

Picture a common setup. A small team keeps its app's container images, packaged copies of the app that servers download and run, under one personal Docker Hub account. The setup is made up, but the problem is real. The build server logs in with a personal access token called ci-deploy.

Later the team converts that account into an organisation so several engineers can share it. Conversion asks for a new owner, and they type their CTO's own Docker ID. Before the fix, ci-deploy quietly became the CTO's token.

Its secret, already copied onto the build server, now acted as the CTO at the registry, within the token's permission level. That reached every repository and organisation she could reach. Nobody was told.

• Registry: the server that stores container images. Docker Hub runs one, and docker push and docker pull talk to it.
• Docker ID: your Docker Hub username.
• Personal access token (PAT): a long random password for tools. It belongs to one person's account and acts as that person.
• Token secret: the string you paste in. Like a physical key, whoever holds it can use it.
• Permission level: how much a PAT may do with repositories. Levels run from Repo Public Read-only, the default, up to Repo Read, Write, Delete.
• Organisation: a shared Docker Hub space run by its owners. Docker's screens spell it organization.
• Organisation access token (OAT): a token owned by the organisation itself, made for automation. Its scopes list exactly what it may do, per repository and in the organisation.
• Rotation means replacing a secret with a new one and killing the old one. Revocation means switching a token off for good.
• Activity log: an organisation's record of events, such as image pushes and token changes.

The Docker Hub GhostPat vulnerability is a flaw in account-to-organisation conversion, tracked as CVE-2026-105445. A CVE is a public ID for a known security flaw. Conversion re-assigned the account's PATs to the new owner by editing each token's owner record. It never rotated or revoked the secret.

Docker's advisory says the named owner was not asked to confirm and was not notified. So someone could convert an account they controlled, name another user as owner and keep a token that now acted as that user.

The CVE record, published on 13 October 2026, scores it 9.4 on CVSS 4.0, a 0 to 10 severity scale, and labels it critical. It files the bug under CWE-266, incorrect privilege assignment. In plain words, the system gave power to the wrong account.

Every token has two separate parts: a record that says who owns it, and a secret that decides who can use it. Conversion changed the record and left the secret alone. The diagram shows both paths, before and after the fix.

The researchers say they tested only with consenting test accounts. They report that the receiving account's inbox stayed empty each time.

Picture a hotel desk that moves your key card from your booking onto another guest's booking, without re-coding the card. Your card now opens their room, and nobody tells them. The booking is the owner record; the card is the secret.

Where the picture breaks: a key card opens one room. A transferred PAT reached every repository and organisation the new owner could reach, within its permission level.

Within its permission level, a transferred token acted as the new owner at the registry. Docker says it gave no access to the Docker Hub website and could not change the password, email address or two-factor settings. Docker treated this as a software supply-chain risk, because a pushed image carries a trusted name.

Docker says it found no evidence that the flaw was exploited. It listed every conversion since 26 August 2024 and examined every push made with a transferred token, about 304,000 in all. Each landed in the converted organisation's or the new owner's own repositories.

Logs show when a token is used, not that it exists. A transferred token that was never used leaves no trace, so Docker treated every transferred PAT as possibly exposed and switched them off. As of 19 October 2026, the advisory gives no count of affected users or tokens.

The timeline, August 2024 to October 2026

What changed in the product

• Conversion no longer transfers PATs. Docker's conversion page now says the account's PATs stop working, and the new owner should create an OAT. It also says the new owner now receives a notification email.
• Docker commits to asking a user for consent before naming them an organisation owner. As of 19 October 2026, the conversion page describes no consent step.
• It also commits to an auditable history of every token ownership change, and to reviewing other flows that change who owns a credential.

Changing the owner is not rotation, because the secret grants access, not the name on the record. Rotation issues a new secret and kills the old one. An owner change only edits a label.

A safe transfer does three things: it switches off the old secret, asks the new owner to agree and writes an audit record. The toy model below runs both versions of conversion against the same copied secret.

import secrets

def new_token(owner):
    return {"owner": owner, "secret": secrets.token_urlsafe(24), "active": True}

def login(store, secret):
    for t in store.values():
        if t["active"] and t["secret"] == secret:
            return t["owner"]
    return None

def convert_buggy(store, token_id, new_owner, audit):
    store[token_id]["owner"] = new_owner          # only the record changes

def convert_safe(store, token_id, new_owner, audit, owner_agreed=True):
    if not owner_agreed:
        raise PermissionError("new owner must confirm first")
    store[token_id]["active"] = False             # old secret stops working
    audit.append((token_id, store[token_id]["owner"], new_owner))

for convert in (convert_buggy, convert_safe):
    store = {"ci-deploy": new_token("team-account")}
    held = store["ci-deploy"]["secret"]           # copy already on the build server
    audit = []
    convert(store, "ci-deploy", "cto-id", audit)
    print(convert.__name__, "| old secret logs in as:", login(store, held), "| audit:", audit)

Run it with python3; it was tested on Python 3.13.16. You should see two lines:

convert_buggy | old secret logs in as: cto-id | audit: []
convert_safe | old secret logs in as: None | audit: [('ci-deploy', 'team-account', 'cto-id')]

What just happened? In the buggy run, the copy on the build server logs in as cto-id, and the audit list stays empty. In the safe run, the same copy fails, and the trail records who moved what.

Docker's advisory says users it did not email on 2 October were not exposed and need not act. A short token review is still worth doing, because a token with no expiry date stays usable until someone switches it off.

1. 1

   Check for Docker's 2 October email

   Its subject was Docker Hub Vulnerability Identified & Resolved, and in India it arrived early on 3 October. It listed affected tokens by description and creation date.

2. 2

   Open your token list

   Sign in to Docker Home, select your avatar, then Account settings, then Personal access tokens. Note each token's permission level, status, created date and last used date.

3. 3

   Revoke or narrow what you cannot explain

   Deactivate or delete tokens you do not recognise or no longer use. For a token you keep, you can lower its permission level later, but not change its expiry.

4. 4

   Look for strange organisations

   Check the account switcher for organisations you do not remember joining. That can mean someone named you as an owner.

5. 5

   Move automation to OATs

   Give each build server an organisation access token limited to the repositories and scopes it needs, with an expiry date.

6. 6

   Read the activity log

   Organisation owners open Docker Home, select the organisation, then Activity. Tag Pushed events, meaning a new image version arrived, can name the PAT or OAT that pushed it.

After moving a build job to an OAT, check the login from that server. With an OAT, the username is the organisation name. The secret comes from standard input, so it is never typed on the command line.

# On the build server; DOCKER_OAT holds the organisation access token
printf '%s' "$DOCKER_OAT" | docker login --username YOUR_ORG_NAME --password-stdin
echo "exit code: $?"
docker logout

A working OAT prints Login Succeeded, then exit code: 0. A switched-off or wrong secret prints an error and a non-zero exit code. In a build script that stops at the first error (bash set -e), a failed login ends the job before the echo line. We ran this with Docker CLI 29.8.2 against a local test registry, not Docker Hub, so Hub's error wording may differ.

In the team's case, the CTO's email listed ci-deploy, and Docker switched it off on 8 October. The team created an OAT for its three app repositories with a 90-day expiry. The build was green again within 20 minutes (made up).

Beginners can stop here. The rest is for engineers: how the two token types differ, how to review tokens by rule and how to tell this story in an interview.

Use a PAT when a person works by hand, and an OAT when a machine works for the team. A PAT acts as you wherever you have access. An OAT acts only for its organisation, on the repositories you list.

The old ci-deploy PAT could act as the CTO in every organisation she belongs to. The new OAT can touch only the three app repositories, so a leak stops there.

Treat the token list as an inventory and flag risky tokens by rule, not by memory. The script below checks a list copied by hand from the token page, using fields Docker shows there.

from datetime import date

today = date(2026, 10, 19)
tokens = [  # copied by hand from Account settings, Personal access tokens
    {"name": "laptop-cli", "level": "Repo Read-only",
     "last_used": date(2026, 10, 18), "expires": date(2027, 1, 10)},
    {"name": "old-test", "level": "Repo Read & Write",
     "last_used": date(2025, 6, 2), "expires": None},
    {"name": "release-bot", "level": "Repo Read, Write, Delete",
     "last_used": None, "expires": None},
]

for t in tokens:
    problems = []
    if t["expires"] is None:
        problems.append("no expiry")
    if t["last_used"] is None:
        problems.append("never used")
    elif (today - t["last_used"]).days > 90:
        problems.append("unused for 90+ days")
    if "Write" in t["level"]:
        problems.append("can push: give machines an OAT")
    print(t["name"], "->", ", ".join(problems) or "looks fine")

What just happened? Tested on Python 3.13.16, it prints three lines. The laptop token looks fine. The other two are flagged for no expiry and push rights, and for being unused or never used.

laptop-cli -> looks fine
old-test -> no expiry, unused for 90+ days, can push: give machines an OAT
release-bot -> no expiry, never used, can push: give machines an OAT

The 90-day cut-off is our choice, not a Docker rule. Pick one that matches how often your jobs run.

What the activity log can and cannot tell you

Docker Home keeps organisation activity logs for 90 days and lets you query up to 30 days at a time. The Docker Hub audit logs API covers about the same window, the last 3 months, up to 31 days per request, which suits scripts. Docker's page describes no way to see older events. So on 19 October 2026, your own logs reach back only to about late July 2026, not to August 2024. These limits are from Docker's docs as of 19 October 2026.

Activity logs need a Docker Team or Business plan. Event descriptions can name the Docker username, PAT or OAT behind an action. They cannot show a token that was never used, which is why Docker switched off every transferred PAT.

Tell it as a story about credential ownership. Interviewers want to see that you separate who owns a secret from who holds it.

1. 1

   State the bug in one line

   Conversion changed a token's owner record but kept its secret, so whoever held the secret could act as the new owner.

2. 2

   Name the missing checks

   No consent, no notification and no rotation. Consent or rotation would have blocked misuse, and notification would have let the new owner spot it.

3. 3

   Describe a safe transfer

   Revoke old secrets, ask the receiver to confirm, issue new credentials only to them and write an audit record.

4. 4

   Limit the damage from a leak

   Give machines scoped tokens with expiry dates, so a leak reaches a few repositories for a short time.

5. 5

   Show how you would spot misuse

   Log which token pushed each image and alert on pushes from unfamiliar tokens. Admit the gap: an unused token leaves no log.

6. 6

   Close with the trade-off

   Forced deactivation breaks running jobs, as it did for the team's build. Give owners notice, an opt-out window and a clear path to a new token.