A Token From 2023 Still Had Admin Access In 2026

A security company called Strix wanted to use Baseten for model inference. Baseten is a serious company, valued around $13 billion, with a lot of other serious companies depending on it.

Before handing over their data, Strix did what security companies do. They ran their own scanner against Baseten's domain. No credentials. No source code. Just the domain.

Twenty five minutes later they had a live GitHub token with admin and push rights on Baseten's main product repository, the repository driving their cluster deployments, and their Homebrew tap. Plus read and write access to several private repos, including some scoped to individual customers.

The writeup hit the Hacker News front page on September 15 with more than 230 points.

Baseten handled the disclosure well, which we will get to. But the mechanics of how that token came to be sitting there deserve every founder's attention, because the same mistake is sitting in a lot of smaller companies right now.

It started with recon, the boring part of any security test. Enumerate the hosts, read the certificate logs, map everything attached to the domain.

That turned up a Harbor container registry on a subdomain. Harbor groups container images into projects, and one of those projects was set to public.

Public meant anyone could list the repositories, request an anonymous pull token, and download real image manifests and blobs. No login required. One of those images was the main application image.

The scanner pulled it. Inside, it first found a pair of AWS keys, tested them with a read only identity call, and got back an invalid token error. Dead credentials. It kept going.

Then it checked the image configuration, not just the filesystem layers, and found a GitHub personal access token sitting in the build history. One read only request to GitHub confirmed the token was alive and belonged to a bot account inside the company's organization.

The build step that leaked that token ran on March 3, 2023. It still worked when it was found in July 2026.

Three years and four months. An entire company lifetime for most startups.

Nobody made a dramatic mistake here. Somebody needed a build to fetch a private dependency from GitHub, so they passed a token in as a build argument. The build worked. Everyone moved on. That is how it always goes.

The part that turned a small mistake into a critical one is that the token had far more access than the job required. Fetching a private dependency needs read access to that one dependency. This token had admin on the product repo.

Permissions accumulate quietly. Somebody grants a bot broad access to unblock a Friday deploy, and three years later nobody remembers it can delete branches on your main repo.

Probably, in a smaller form. You may not run Harbor, but ask yourself a few questions.

Do you push Docker images anywhere, including Docker Hub or a cloud provider's registry? Is any of it public, including the one you made public in month two to test a deploy?

Does your CI hold tokens with more permission than the job needs? Is a founder's personal access token, with no expiry, doing production work?

Has anyone ever pasted a key into a build argument, an environment file on a branch, or a Slack message to a contractor?

Here is the uncomfortable version. If someone pointed a scanner at your domain tonight with no inside knowledge, what would they find in twenty five minutes?

For most early stage companies, nobody has ever checked.

None of this needs a security hire. Block ninety minutes and work through it.

1. List every place you have ever published a container image. Check whether any project or repository is public, including old tags and things you forgot you made.
2. Inspect image build history, not just files. Running docker history with the full output flag shows the commands that created each layer, and build arguments can be recorded there with their values intact. Deleting a credentials file does nothing if the history still holds a copy.
3. Inventory every token, key and service account with access to your code or infrastructure. Write down what each one is for and what it can do.
4. Kill anything you cannot explain. If nobody knows why a token exists, rotating it beats finding out later.
5. Add expiry dates to what remains. A token that expires in ninety days stops mattering in ninety days.
6. Move secrets out of build arguments and into secret mounts, which exist so the value never persists into the image.

Then put a date on the calendar and do it again in six months.

The pattern is familiar because it is reasonable in the moment. Your build needs a private repository. You pass a token as a build argument. Git authenticates. The build goes green.

Two things then go wrong quietly.

Docker can record build arguments in the image metadata, including the actual value. This is documented behavior that Docker warns about, but the warning lives in a page nobody reads on the day they are trying to unbreak a build.

Second, commands that write authentication into a global Git configuration persist that credential into the image filesystem. Fix how the token arrives and you can still be saving it on the way out.

The fix is not complicated. Use a secret mount so the value exists during the build step and is gone afterward, and make sure whatever consumes it does not write it back down.

Then revoke the old token, because changing the Dockerfile does nothing about images people already pulled.

Worth studying, because you will be on the receiving end of one of these eventually.

The report went in late on July 13. By the next morning the registry project was private. By 4:34 that afternoon the security team had confirmed the issue as critical, rotated the token, and asked the researchers to securely delete the images they had pulled. Remaining findings were closed out by July 17. In September they were told about the public writeup in advance and sent a draft.

Under eighteen hours from report to remediation on a critical finding. No lawyers, no arguing about severity.

Most companies do this badly. They go quiet, dispute the finding, or threaten the researcher, and the story becomes the response instead of the bug.

Write your disclosure process down before you need it. One page: an email address a human reads, a promise to respond within one business day, and a commitment not to pursue researchers acting in good faith.

Here is what founders underestimate. The first real consequence of weak secret hygiene is usually not a breach. It is a deal.

The moment you sell to a company larger than yours, a security questionnaire arrives. It asks about credential rotation, access reviews, secret management and vulnerability disclosure. Answer badly and your deal sits in review for two months while your runway does not pause.

Strix ran this scan because they were evaluating a vendor. That is becoming normal. Your prospective customers, and increasingly their automated tools, will look at you before they sign.

If you are planning to sell to companies bigger than you, put security review on your go to market timeline next to pricing and onboarding. Map it wherever you keep that plan, whether that is a spreadsheet, a Notion doc, or a tool like Foundra that walks first time founders through go to market step by step.

Doing the ninety minute audit now is much cheaper than doing it during a deal.

• A scanner pointed at a domain with no credentials found a live GitHub admin token in about 25 minutes, inside a public container image.
• The leaked token came from a build step dated March 3, 2023 and still worked in July 2026.
• The credential was in the image build history, not the filesystem, so file cleanup would not have caught it.
• Over permissioned build tokens turn small leaks into critical ones. Fetching a dependency needs read access to that dependency, nothing more.
• Inspect image build history, check which registries are public, inventory every token, and set expiry dates.
• Enterprise buyers now scan vendors before signing, so this reaches your sales cycle before it reaches your incident log.

We are pre revenue with two engineers. Is this really worth ninety minutes? Yes, because it is ninety minutes once rather than a rebuild later. The inventory you produce also answers most of the first security questionnaire you receive, so the work gets reused.

What is the single highest value change if I only do one thing? Put expiry dates on tokens. Most of these incidents involve a credential that outlived the person, project or company reason that created it. Expiry converts a permanent exposure into a temporary one without any process discipline.

How do I check whether a container image contains a secret? Inspect the layers and the image configuration. Command line tools show build history with full commands, and open source scanners like TruffleHog search layers for credential patterns. Check both, since a secret in build metadata will not show up in a file scan.

Someone emails saying they found a vulnerability. What do I do? Reply within one business day, even if the reply only confirms receipt. Ask for reproduction steps, fix or rotate first, then confirm. Do not debate severity before you have contained the issue.

Does rotating the token fix everything? It fixes that credential. It does not fix the image that leaked it, which may already be downloaded, or the pattern that put it there. Rotate, change the build, then check your other images for the same pattern.

1. Strix: We wanted to use Baseten for inference. We ended up with admin access to Baseten GitHub repos
2. Hacker News discussion: We got admin access to Baseten's production GitHub in 25 minutes
3. Docker docs: Build variables and how build arguments are recorded
4. Docker docs: Build secrets and secret mounts
5. GitHub docs: Managing your personal access tokens