Exposing 17.5 Million Accounts to Scammers: Instagram Data Breach

Malwarebytes, a cybersecurity company, reported an Instagram data breach on January 9th. Cybercriminals stole sensitive data from 17.5 million Instagram accounts. This article explains what information was stolen, how it happened, what Instagram did about it, and how this could have been prevented.

What (actually) happened?

Malwarebytes was monitoring dark web activities and found a post by the user Solonik on January 7th. The post stated that he had information on 17.5 million Instagram users that he scraped in 2024.

The information included usernames, full names, emails, phone numbers, follower and following counts, and even physical addresses. It’s a lot of personal identifiable information (PII) that could cause serious damage to users… and it already has. Multiple users reported being bombarded with Instagram password reset notifications.

Why 2022 ghosts can still haunt you in 2026

The initial breach, or as Instagram calls it, a leak, happened in 2022. The post that Malwarebytes caught on was a repost on the dark web from 2024, but that didn’t make it any less dangerous. The leak’s old, but the damage is new and real.

That same data was breached back in 2022 and leaked in June 2023 on BreachForums by the user vanz. Also, the data was leaked to another forum in 2024 as new data, to create attention and to try to sell it again.

The data had records that looked like API responses (hello structured JSON fields), so it looks like the leak came from an exposed API endpoint. Considering stories like Max Verstappen’s FIA breach or JLR’s API attack, it’s not far-fetched that this was also an API security problem. Also, Gartner stated that over 50% of security incidents in 2025 will be attributed to APIs.

Prevention, not reaction is the key to trust

Instagram put out a statement on X:

“We fixed an issue that let an external party request password reset emails for some people. There was no breach of our systems and your Instagram accounts are secure. 
You can ignore those emails — sorry for any confusion.”

Instagram might technically be right that your account is safe, but it doesn’t really matter to their users who receive password reset notifications at 03:00 a.m. and battle phishing daily.

In the user’s eyes, the trust is gone. And once it’s gone, it’s really hard to get it back, especially if you’re gonna turn a blind eye on it.

So what should Instagram have done? The following would be a start:

• Avoid downplaying the issue. Handle it like a breach instead of “just” an abuse or incident. Even though there was no data exposure from their servers, users still get account reset triggers, which significantly degrade user experience and trust, and rightfully open discussion about data safety.

• Design a secure architecture (threat modeling) that includes abuse scenarios. Third-party actors shouldn’t be able to spam account reset triggers. Current Instagram settings allow cybercriminals to spam account resets with just a single piece of (often public) information: Instagram handle, email, or phone number–an oversight affecting  17.5 million users. Social engineering breaches are still breaches and they should be handled accordingly.

• Implement a security strategy. A security strategy helps to prevent these kinds of breaches. “We fixed it” isn’t a security strategy; it’s firefighting. Sure, there will sometimes be unforeseen problems and companies need crisis management. But that’s not a long-term strategy.
  Instagram’s response was worse than firefighting–they simply ignored the fire. Their “There’s no problem” statement was a slap in the face for many users who had to deal with continuous account password resets.

• Security audits aren’t a one-time thing; it’s an ongoing process. It’s like basic hygiene; you can’t do it quarterly and call it a day. Just because some APIs functioned perfectly during one audit, it doesn’t mean that they’ll have the same status forever. They need to be checked repeatedly. It’s like having a checklist for a procedure. Most of the time, you won’t have any problems. But every once in a while, that checklist will find a problem and then it will be worth its weight in gold. Just ask Captain Sully, who used a checklist to land a plane on the Hudson River safely.

• Zero-trust architecture. A zero-trust architecture can be best described by “never trust, always verify.” It assumes the worst and always wants verification.
  For example, if you leave your phone on your work desk while going to the bathroom and someone else takes it, they might send embarrassing messages in your Slack channel. It’s all fun and games until a really malicious actor gets access to your account. They would take your account IDs, change your passwords, take your card information, and do so much damage that your head would spin. That’s why a two-factor authentication would be a step in the right direction for all Instagram users.

How Treblle could have helped

If this leak was caused by an exposed endpoint, permissive data returned in responses, or a password-reset flow that could be spammed at scale, the underlying issue is the same: teams lacked continuous, runtime visibility into what APIs were live, what data they returned, and how they were being abused.

Treblle is built to close that gap by turning every API request and response into documentation, security signals, and real-time governance insights. Here’s how Treblle could have helped Instagram prevent the data leak:

• Make the real API surface visible (before it becomes “unknown”)
  Treblle auto-detects endpoints and generates API documentation with real-time updates, so teams can quickly see what is actually running and avoid blind spots that lead to shadow endpoints and forgotten versions. It also supports API Catalog style discoverability, so “which API does this?” is not a Slack question.

• Detect abuse patterns early, not after the data circulates
  Treblle’s API Security runs automated checks on every request and supports threat detection, intrusion prevention, threat levels, and custom alerting. In a scenario like mass enumeration or password-reset spamming, you want the platform to flag abnormal request patterns and risky traffic, for example, unusual sources, missing auth signals, or insecure transport while it is happening.

• Catch PII exposure at the moment it leaks
  Treblle’s API Compliance analyzes API requests and responses to identify sensitive or regulated data, flags PII and other high-risk fields in responses, and keeps detailed logs of flagged requests for audits and investigations. That means if an endpoint starts returning emails, phone numbers, or addresses where they shouldn't, you get an immediate signal and a trail you can trace back to the exact request and payload.

• Keep controls consistent as teams and APIs scale
  Sprawl problems often start with good intentions and end with drift. Treblle’s API Governance is designed to enforce shift-left and runtime security through automated rule enforcement across design, performance, and security, so the standards do not depend on manual reviews or individual teams remembering the checklist.

Treblle would not replace secure architecture decisions, but it would materially reduce the likelihood and blast radius of this kind of incident by improving discovery, tightening runtime security detection, and making sensitive-data exposure visible immediately rather than years later.

There’s no security without observability

API security failures are preventable. Mass assignment vulnerabilities, privilege escalation flaws, and broken access controls can all be detected and mitigated before they're exploited, but only if you have visibility into what your APIs are actually doing.

With Treblle, you have complete visibility into every request, response, and data flow across your API infrastructure and in real time.

Organizations handling sensitive data can't afford blind spots. API Intelligence provides the visibility needed to detect threats in real-time, not days, weeks, or, in Instagram’s case, years after the fact. Download our API security checklist to stay ahead of emerging threats and build long-term API resilience.