Summary
The Internet Archive, the nonprofit behind the Wayback Machine, had a brutal October 2024: a data breach, a website defacement, and a wave of DDoS attacks, all at once. Underneath the chaos was an unglamorous root cause. An authentication token sat in plain text in a public config file; the team rotated it repeatedly, but each new token landed right back in the same exposed file, so the leak never actually closed. With it, an attacker downloaded the source code, found more credentials hardcoded inside, and walked out with a database of 31 million users. Weeks later a second token from that same stolen code, for the support system, exposed 800,000 support tickets, some with people's ID documents. It is the lesson that rotating a secret is useless if it goes straight back into a public file, and that one leak unravels everything.
How it happened
The attacks, starting around 9 October 2024, all traced back to exposed authentication tokens. A plaintext GitLab token had been left in a publicly accessible config file (on the dev server services-hls.dev.archive.org) since at least December 2022. The team did rotate the token over time, but each new value was committed straight back into that same public file, so the exposure never actually closed. An attacker used it to download the Internet Archive's source code, which itself contained further embedded database credentials, and exfiltrated a user database of around 31 million users, with emails and bcrypt-hashed passwords (independently verified by Have I Been Pwned, which received the 6.4 GB database, and by a researcher who matched his own password hash). At the same time, a JavaScript defacement popped up announcing the breach, and DDoS attacks, claimed by a group called SN_BlackMeta, knocked the service offline for days.
The most telling part came later. On 20 October, a second secret from that same stolen source code, a Zendesk API token, was used to access more than 800,000 support tickets, some containing personal identity documents. So it was not really a separate breach; it was the same leak's second downstream key. The attacker even sent a mass email through the Archive's own Zendesk (which passed its email-authentication checks), taunting that "even after being made aware of the breach weeks ago, IA has still not done the due diligence of rotating many of the API keys." The breach was not over when everyone thought it was.
The damage
Thirty-one million users had their emails and password hashes exposed, 800,000 support tickets (some with ID documents) were accessed, and the site, a beloved nonprofit run on a shoestring, was defaced and knocked offline for days. The Zendesk twist stung most: a second leaked token meant the incident dragged on through the response itself, with the attacker still inside while the Archive thought it was recovering.
Why Internet Archive still matters
It is the secrets-hygiene lesson, taught several times in one incident. A token in plaintext in a public file led to the source code, which led to more hardcoded credentials, which led to the entire user database. A secret that keeps being re-published to the same public file is a live key no amount of rotation can close, and a token forgotten in another system means the breach is not over until you have rotated everywhere and removed the secret from wherever it leaked. The defences: never hardcode secrets, load them from a vault, scan code, config, and public servers for leaked credentials continuously, rotate immediately on any exposure and make sure the new secret does not land back in the open, scope tokens to least privilege, and build DDoS resilience. It is the same secrets-leak class as the Codecov compromise.
How to fix it
- Rotate every token and credential across all systems immediately, and make sure the new secrets are not committed back into source, config, or any public location.
- Remove hardcoded secrets from source and config, move them to a vault, and force password resets for the exposed user database.
- Add DDoS protection, restore from clean backups, and scan all repos and servers for other leaked credentials before declaring the incident closed.
How to avoid it
- Never store secrets in source or config files; load them from a vault, and scan code, config, and public servers for leaked credentials continuously.
- Rotate any exposed secret immediately, and confirm the replacement is not re-committed to the same public file; rotation without that is theatre.
- Scope tokens to least privilege and short lifetimes so a single leaked token cannot reach source code and databases.
- Build DDoS resilience (scrubbing, anycast) so an availability attack cannot pile onto a breach.
References
- https://www.bleepingcomputer.com/news/security/internet-archive-hacked-data-breach-impacts-31-million-users/
- https://www.bleepingcomputer.com/news/security/internet-archive-breached-again-through-stolen-access-tokens/
- https://www.helpnetsecurity.com/2024/10/10/internet-archive-data-breach/
- https://www.infosecurity-magazine.com/news/stolen-tokens-internet-archive/
Related vulnerabilities
All OpSec →- HIGHOPSEC-MERCEDES-BENZ-2024
Publicly disclosed January 30, 2024, a Mercedes-Benz employee accidentally committed a GitHub authentication token to a public repository, leaving it exposed from September 29, 2023. RedHunt Labs found the token during an internet-wide scan; it granted unrestricted, unmonitored access to Mercedes-Benz's internal GitHub Enterprise Server, allowing anyone to download private source-code repositories that could contain API keys, cloud access keys, database connection strings, blueprints, and SSO passwords. After notification, the token was revoked on January 24, 2024. Mercedes-Benz stated customer data was not affected but could not confirm whether anyone besides the researchers accessed the repositories during the exposure window.
- HIGHOPSEC-SOURCEGRAPH-2023
On July 14, 2023, a Sourcegraph engineer accidentally committed an active site-admin access token in a pull request, and automated secret-scanning controls failed to catch it. On August 30, 2023, an attacker used the leaked token to elevate a newly created account to site-admin and access the administrative dashboard. The attacker raised API rate limits and created a public proxy app granting arbitrary users free access to Sourcegraph's APIs and underlying LLM, with instructions spreading widely online. License-key recipient names and emails, a subset of customer license keys, and community account email addresses were exposed; Sourcegraph stated no private code or passwords were compromised.
- CRITICALOPSEC-MIDNIGHT-BLIZZARD-2024
In January 2024, Microsoft revealed that Russia's foreign-intelligence service, the same APT29 behind SolarWinds, had been reading the email of its senior leadership. The way in was almost insulting in its simplicity: a forgotten, non-production test account with a weak password and no MFA. The attackers guessed the password by spraying common ones across many accounts, then pivoted through a forgotten over-privileged application to grant themselves access to corporate mailboxes, including those of executives and the security and legal teams. It is the lesson that your security is only as strong as the account you forgot about, and that even Microsoft's perimeter fell to a missing MFA checkbox.
- HIGHOPSEC-OKTA-2023
Okta is an identity provider: the single front door thousands of companies use to log their employees into everything. So when Okta's customer-support system was breached in late 2023, the blast radius was a who's-who of security-conscious companies. The entry point was almost mundane. An employee had signed into their personal Google account on an Okta laptop and saved a corporate service-account password into it; the attacker got that password and walked into Okta's support system. There they downloaded diagnostic files that customers had uploaded, some of which contained live session tokens, and used those tokens to step directly into the customers' own Okta environments. It is the lesson that session tokens are as good as passwords, support systems are production systems, and a personal browser profile can be the crack in the wall.
- CRITICALOPSEC-23ANDME-2023
23andMe held the most personal data there is: people's DNA. In 2023 attackers got into more than 18,000 accounts and, through a single social feature, turned that into the genetic and ancestry data of roughly 6.9 million people. The break-in required no flaw in 23andMe at all. Attackers simply took username-and-password pairs leaked from other companies' breaches and tried them, betting, correctly, that people reuse passwords. The accounts had no MFA, and 23andMe did not notice the five-month wave of automated logins. From those footholds, the attackers scraped relatives' data through an opt-in feature, and the fallout, fines, a $50 million settlement, and ultimately bankruptcy and a fire-sale of the DNA database itself, shows that a breach can be fatal even when your own systems were never hacked.
- HIGHOPSEC-MICROSOFT-SAS-2023
Microsoft's AI research team shared open-source training data via an Azure Storage Shared Access Signature (SAS) token committed to a public GitHub repo around July 2020. The token was misconfigured to scope access to the entire storage account with full-control permissions instead of the intended read-only bucket, so anyone with the link could view, delete, and overwrite files. Wiz researchers discovered it in June 2023, finding 38 terabytes of exposed internal data including two employees' workstation disk backups with secrets, private keys, passwords, and over 30,000 internal Teams messages. Writable pickle-format models created a model-poisoning supply-chain risk; Microsoft revoked the token and reported no customer data was exposed.