Ask.FM user database with 350m user records has shown up for sale (UPDATED with Denial from Ask.FM)

“I think it’s probably one of the biggest breaches in a long time, can’t think of any bigger ones,” Pompompurin, the owner of, wrote when asked about a new for-sale listing that appeared on his forum.

A seller called “Data,” who Pompompurin says he will “vouch all day and night for” listed user data from Ask.FM (ASKfm), the social networking site.

Listing on a popular hacking forum. No specific price is listed, and the seller is willing to use a middleman service, which usually indicates that the listing is not a scam.

“I’m selling the users database of and,” Data wrote. “For connoisseurs, you can also get 607 repositories plus their Gitlab, Jira, Confluence databases.”

There are about 350 million records in the database, with about 45 million of them using Single Sign-On login.

The fields in the user database include: “user_id, username, mail, hash, salt, fbid, twitterid, vkid, fbuid, iguid” and the hashes are reportedly crackable.

Data, who joined the forum in March, also provided a list of repositories, and sample git and sample user data.

DataBreaches reached out to Data to ask some questions about when the data were acquired and how. DataBreaches also reached out to Ask.FM last night to ask them some questions.

Ask.FM didn’t reply to either of two inquiries over a 24 hour period, but Data did respond to this site’s questions, with two prefacatory remarks. The first was to berate yours truly for having a protonmail account. The second was a request to please add “Marine Le Pen is a racist fraudster.”

Having dealt with those remarks, let’s turn to the clarification Data provided on the Ask.FM incident.

In response to the first query about initial access, Data replied that there was a vulnerability in Safety Center: the server contained a WordPress site on their ASKFM-NET network.

As to when the hack occurred, Data replied that the server was first accessed in 2019 and the database was obtained on 2020-03-14. Data provided this site with users on the Safety Center and wrote insultingly about a certain ‘lazy’ administrator who allegedly used the same password everywhere.

[Note: Data provided specific and technical details that DataBreaches is not reproducing in this post out of concern that they might encourage or enable others to re-attack Ask.FM. According to Data, Ask.FM is still vulnerable due to a poor response to the 2020 incident.

“Specific parts were taken in 2021, although they assumed the aggressors were kicked off,” Data wrote.  “The buyer will get specific details on how piss easy it is to compromise the morons.”]

How easy is “piss easy,” you wonder? “Just need to open 10 source files and spot either a vulnerability or peek at the heavy password re-use,” Data told DataBreaches.

Ask.FM Knew But Kept Quiet?

When asked whether Ask.FM knew about the breach in 2020, Data was unequivocal in stating that they knew. Ask.FM noticed the March 2020 breach circa June 2020, Data claims, but “was apparently too busy laying off employees to give Answers to the attempt to contact them.”

Data’s claim that Ask.FM knew was based, in part, on Ask.FM burning some specific access the hackers had played around with, like several production AWS credentials provided to DataBreaches.

DataBreaches could find no media coverage or other indication that Ask.FM ever disclosed the March 2020 breach or notified users of it.  If anyone ever received a notification about it, please contact DataBreaches. If Ask.FM replies to inquiries, this post will be updated. 

Because Data invited contacts by private message, it’s not clear how many purchase offers they have received at this point, but they tell DataBreaches that they are now looking more at a single (exclusive) sale.

Updated 9/21/2022: Because there has still been no reply by AskFM, DataBreaches  sent an inquiry to the Irish DPC asking whether AskFM ever reported the March 2020 incident to them under the GDPR. This post will be updated when a reply to that inquiry is received.

Update and Correction of September 23: 

To my surprise, DataBreaches discovered that this site had already contacted about the claimed breach back in December 2021.  They responded, and for some reason (probably linked to a neurological event last year that seriously impacted my memory), I never published anything about it.  Today, I found my draft post from that time still in Drafts, unpublished.

Today, responded to my recent inquiries:

As you were advised in December 2021, Askfm has not suffered any security incidents. We can confirm that this is still the case from our last communication until the present time.

DataBreaches sincerely apologizes to Ask.FM for not remembering the December contact or their response at all. That said, DataBreaches does not apologize for trying to investigate such a large claimed breach. In light of their response today, DataBreaches is now publishing what was sitting in my Drafts folder since December.

Part of previously unpublished draft from December 2021:

….  Over the past week, reached out several times — by email and via their Twitter team — to try to verify or refute claims about a hack that allegedly acquired more than 340 million records. The person who informed about the alleged hack provided this site with samples of data that were purportedly from the firm’s internal network.

As this site routinely does, were given a sample of the records from the larger sample this site had received so they had some sense of the data this site had been provided — at least, in part. If it was not their data, they could have simply responded that they investigated and found it wasn’t their data. But they didn’t respond. Because stonewalling is often an indication that there really has been a breach and the company is trying to cover it up or delay disclosure, asked them why they had not posted anything on their website or notified anyone. While the sample data appeared to be old data to, knowing that people re-use passwords and that the hacker claimed to have internal reports meant that this might need to be disclosed and/or reported to regulators, especially since the hacker claimed to have data on 350 million users that included usernames, email addresses, and easy-to-crack passwords. has headquarters in California and Latvia, and is registered in Dublin for GDPR purposes.

When finally responded, their reply was as follows:

Thank you for sharing this information. We have provided it to law enforcement as it appears to be aiding and abetting an extortion attempt which has no valid foundation; we have had no security incidents and law enforcement has been made aware of your email.

Best regards,
Communications Department

So why didn’t they simply respond to the initial inquiry by saying that they have had no security incident? Or ask for more data so they could investigate?

This site replied:

Thanks for your response. Journalists attempt to verify claims. That is not aiding and abetting anything. I will include your reply if and when I report on the claimed attack.

… End of previously unpublished draft.

But I never did report on the claim or their response, it seems, and truly had no memory of any of it. To say that I was shocked to receive their email referring to past communication would be an understatement.

So Ask.FM denies that there was any breach at all. DataBreaches will not publish the technical details that this site had been provided, but it will be interesting to see if “Data” reveals them. For now, however, DataBreaches considers this claimed breach as “disputed.”

About the author: Dissent

Has one comment to “Ask.FM user database with 350m user records has shown up for sale (UPDATED with Denial from Ask.FM)”

You can leave a reply or Trackback this post.
  1. Ali - September 27, 2022

    They have a very rude team; I discovered multiple vulnerabilities in Ask.FM website during 2021, and then I reported my findings. Unfortunately, I think they throw my report in the garbage, nothing fixed, and even there is no MFA option for all 350 million users! That means a disaster if the leaked data is accurate.

Comments are closed.