In October 2025, someone got into Substack’s systems and quietly pulled out data on hundreds of thousands of users. Emails. Phone numbers. Stripe payment IDs. Profile information. Then they walked out.
Substack didn’t know.
Not in November. Not in December. Not in January.
It took until February 3, 2026, four full months later, for the company to discover anything had happened. And the way they found out almost certainly wasn’t their own monitoring catching an intruder. It was a hacker posting the stolen data publicly on BreachForums the day before.
That timeline is the real story here. Not just that Substack got breached. Lots of companies get breached. The story is that nearly 700,000 people had their information sitting in a criminal’s hands for four months while the company had no idea.
Quick answer: Substack confirmed a data breach on February 5, 2026, after a threat actor posted stolen user data on BreachForums. The breach occurred in October 2025. Exposed data includes full names, email addresses, phone numbers, Stripe customer IDs, user IDs, profile pictures, bios, and social media handles for up to 697,313 accounts. Passwords and payment card numbers were not accessed. CEO Chris Best sent emails to affected users apologizing for the incident. No public statement was posted on Substack’s website.
What Actually Happened
The attacker used what they themselves described as a “noisy” scraping method to pull data out through Substack’s API. That word, “noisy”, is important. In security language, a noisy attack generates activity that’s distinctly different from normal traffic. It’s the opposite of a quiet, low-and-slow exfiltration designed to blend in. Noisy means it leaves traces. It means logs. It means the kind of unusual patterns that a working detection system should flag.
Substack’s detection system apparently didn’t flag it, for four months.
The attacker exploited a vulnerability in how Substack’s API handled access controls. Rather than breaking down a door, they walked through one that wasn’t properly locked. The API, the programmatic interface developers use to interact with the platform โ was returning more data than it should have to someone who wasn’t supposed to have it. The scraper ran, pulled records in bulk, and stopped. The data left the building. The vulnerability sat there.
Then on February 2, 2026, a threat actor using the alias “w1kkid“ posted on BreachForums claiming to have 697,313 Substack user records. They uploaded a CSV file with sample data to prove it was real.
The next day, February 3, Substack’s security team “discovered a problem.”
The company hasn’t publicly clarified whether internal monitoring caught the breach or whether the BreachForums post is what tipped them off. Given that the discovery happened one day after the public posting, the most likely answer is uncomfortable. As we’ve seen in other breaches covered here, including the Berlin Rhysida ransomware attack where a public dark web listing preceded the government’s formal acknowledgment, organizations frequently learn about their own breaches from external intelligence, not internal detection.
The Data That Was Taken
Substack was careful to say what wasn’t taken: passwords, credit card numbers, and financial data. That’s the reassurance buried in every breach notification. It’s also the part that gets repeated so often it can distract from what actually was taken.
Here’s the full list of what the BreachForums posting claimed was in the dataset:
Full names, email addresses, phone numbers, user IDs, Stripe customer IDs, profile pictures, bios, account creation dates, and social media handles.
HIBP, which added the breach to its database on February 6, 2026, confirmed 663,100 records with email addresses and, for a subset, phone numbers as the primary exposed fields alongside publicly visible profile information.
The number that’s been floating around ranges between 663,000 (HIBP’s verified figure) and 697,313 (the hacker’s claim). Substack hasn’t confirmed an exact count.
The Stripe ID Problem Nobody Explained Clearly
Every outlet covering this story mentioned “Stripe IDs” in the exposed data. Almost none of them explained what that actually means in practice.
A Stripe Customer ID is a reference number that links a Substack account to the payment processor Stripe handles. Substack uses Stripe so that writers can receive subscription payments from their readers. When someone pays for a Substack newsletter, Stripe processes the transaction and stores the relationship between the reader’s payment method and their Stripe customer profile.
The Stripe ID in the breach doesn’t give someone your credit card number. That part is accurate. But it does create a verifiable connection between your name, email, and phone number and the fact that you have a Stripe payment relationship. For targeted fraud, that correlation has value.
Security researcher Arvid Kahl put it plainly when the breach was announced: “The issue with data breach notifications like this one from Substack is that financial data and passwords are listed as ‘not leaked.’ Great, now there’s just a list of emails paired with phone numbers. In a world of 2FA and SIM swaps, email + phone IS critical data.”
That’s the part worth slowing down on.
Email Plus Phone Is More Dangerous Than It Sounds
The breach notification emails people received led with reassurances about passwords and credit cards. Those reassurances aren’t wrong. But they frame the risk in a way that undersells what email plus phone number actually unlocks for a sophisticated attacker.
Two-factor authentication (2FA): The extra verification step most platforms require, often works by sending a code to your phone number via SMS. That’s the entire second factor. If an attacker has your email address and your phone number, they know exactly which accounts to target and what number receives the verification codes.
SIM swapping is the attack that turns this into a real threat. A SIM swap is when someone convinces your mobile carrier to transfer your phone number to a SIM card they control. Once they own your number, they receive your SMS verification codes. Combined with your email address, they can request a password reset on almost any account, intercept the verification code, and lock you out. Your inbox, your banking app, your crypto wallet, the path runs through that phone number.
This isn’t a theoretical risk. India saw a 146% increase in SMS-based banking fraud tied to this exact pattern in 2025-2026. The same technique is documented in numerous breach cases. Email + phone is not “limited” data. In the wrong hands, it’s a skeleton key.
For the 663,000 people in this breach, that combination is now in at least one criminal database and likely circulating across multiple Telegram channels and forums, including Russian-language communities where the dataset was reportedly also shared. Understanding what to do about data that’s already circulating is exactly what our guide on whether you can remove your data from the dark web covers.
Why Substack Users Are a Particularly Rich Phishing Target
Most data breach coverage treats all users as interchangeable. A hacked record is a hacked record.
Substack users are not interchangeable from a social engineering perspective.
Substack is where journalists publish. It’s where academics share research. It’s where political commentators, subject matter experts, lawyers, economists, and doctors maintain reader relationships. The bio and publication name fields in the breach aren’t just vanity information. They’re professional identity signals. A hacker with your name, email, phone, Substack publication name, and bio knows exactly what angle to use when they contact you pretending to be someone from your professional world.
A fake email impersonating a newsletter sponsor is much more convincing when the attacker knows your newsletter’s name, your bio, and your professional context. A phishing message impersonating Substack support is far more targeted when the attacker can reference your actual account details rather than sending a generic “verify your account” blast.
Jeremy Turner, VP of Threat Intelligence at Security Scorecard, made the point clearly in the days after the breach: “That extended dwell time signals gaps in monitoring and vendor-related oversight… the threat actor was able to access 697,313 records before being noticed.”
Four months of dwell time means four months in which anyone who wanted to act on the stolen data could have done so quietly, before any warning had been sent to a single affected user.
The Notification Substack Sent and the Statement It Didn’t
On February 5, 2026, CEO Chris Best sent emails to affected users. He apologized, explained that an unauthorized third party had accessed “limited user data,” confirmed the problem had been fixed, and said the company was conducting a full investigation.
He said nothing publicly on Substack’s website, blog, or social media channels. No public statement was posted. The only people who received direct notification were those whose accounts were in the compromised dataset. If your account wasn’t affected, you heard nothing through official channels.
That approach, notify quietly by email, avoid a public announcement, is legal in many jurisdictions, depending on breach notification laws that vary by state and country. But it means the story of the breach spread through media reporting and the HIBP database rather than from Substack itself. For a company whose entire product is built on trust between writers and readers, that’s a choice worth noting.
There’s also an unaddressed question in the company’s communication: the four-month gap. Best’s email said Substack discovered the issue on February 3. He didn’t explain what monitoring failure allowed a noisy API scraping attack to go undetected for four months. The company hasn’t publicly answered whether the BreachForums posting is what triggered their discovery. That silence doesn’t mean the answer is bad. It means the answer hasn’t been given.
How to Check If Your Account Was In the Breach
The clearest way to find out if your email address was in the Substack dataset is through Have I Been Pwned. HIBP added the Substack breach on February 6, 2026, with 663,100 verified records. Enter your email address in the search field. If it was in this breach, HIBP will tell you.
If you have a Substack account and received an email from Chris Best in early February 2026, your account was directly confirmed as affected by the company.
If you didn’t receive an email and HIBP doesn’t flag your address, your account was likely not in the scraped dataset, though Substack’s full user base of over 35 million means the vast majority of accounts weren’t included.
What To Do Right Now
Even if your information is already out there, your response still matters. This is exactly the pattern our dark web data exposure guide is built around: you can’t undo a breach, but you can make the stolen data less useful.
Change your Substack password even if passwords weren’t technically in the breach. It’s the right reset after any security incident involving your account.
Check every other account that uses the same email and phone combination. If you’ve reused that pair for 2FA on banking, email, or investment accounts, those are your highest priority to review.
Switch from SMS-based 2FA to an authenticator app wherever you can. Google Authenticator, Authy, and Microsoft Authenticator generate time-based codes locally on your device. They can’t be SIM-swapped because the code never travels over your phone number. Every account that offers an authenticator app option is worth switching.
Contact your mobile carrier and ask about a SIM lock or port freeze. Most major carriers now offer this as a security option. It prevents your number from being ported to another carrier without extra verification steps that a SIM-swap attacker won’t have.
Watch your inbox for Substack-related phishing. The attacker has your name, publication, bio, and email. A convincing fake email from “Substack support” referencing your actual newsletter name is exactly the kind of message to treat with suspicion. Go directly to substack.com rather than clicking any link in an email that references your account, subscription payments, or account security.
If you believe identity fraud has already occurred as a result of this or any other breach, report it to the FTC at IdentityTheft.gov to get a personalised recovery plan.
The Bigger Problem This Breach Points To
The breach itself, an API vulnerability exploited to scrape user data, is a pattern that’s become almost routine across major platforms. Social engineering and API abuse overtook direct server penetration as the dominant attack method years ago. Substack isn’t the first and won’t be the last.
What’s less routine is a four-month detection gap for a self-described “noisy” attack. Noise in a security context means detectable anomalies. Anomalies that go undetected for four months suggest that either the detection system wasn’t looking at the right signals, wasn’t looking at all, or the anomaly threshold was set far too high to catch bulk scraping at this scale.
The breach also sits in a wider 2026 pattern of API and third-party data exposure. The 153 million driver’s license breach we covered via IDScan.net involved similar dynamics: a vendor sitting in the data supply chain, holding more information than users realised, with a monitoring failure that let exposure run for an extended period before becoming visible. The names and contexts differ. The structural problem is the same.
Frequently Asked Questions
Was my Substack password leaked?
No. Passwords were not part of the breached data according to Substack’s own notification and the BreachForums listing analysis.
When did the Substack breach happen?
The unauthorised access occurred in October 2025. Substack discovered it on February 3, 2026, four months later. Users were notified on February 5, 2026.
How many accounts were affected
HIBP verified 663,100 records. The hacker’s BreachForums claim was 697,313 records. Substack hasn’t confirmed an exact figure.
What data was exposed?
Full names, email addresses, phone numbers (for a subset), Stripe customer IDs, user IDs, profile pictures, bios, social media handles, and account creation dates.
How do I check if I was affected?
Go to haveibeenpwned.com and enter your email address. If your account was directly confirmed by Substack, you would have received an email from CEO Chris Best in early February 2026.
My password wasn’t leaked. Why should I be concerned?
Because email plus phone number is enough to enable SIM-swap attacks, which bypass SMS-based two-factor authentication. That combination gives an attacker a realistic path to your other accounts without needing your password at all.
Sources: