A recent post on the underground forum DarkForums claimed that the messaging service Max had been hacked and 142 GB of user data stolen. The alleged attacker, using the handle CamelliaBtw, said they had exploited an unknown 0-day vulnerability and exfiltrated around 15.4 million records. Within days, the Max team publicly refuted the claims, and the poster admitted the breach was fabricated. The incident illustrates how fake data breaches can damage reputations, confuse users, and create real security risks.
False claim of a Max messenger hack on DarkForums
In the DarkForums post, the supposed attacker stated that they had discovered a 0-day vulnerability in Max’s media-processing engine during beta testing in early 2025. In cybersecurity, a 0-day is a software flaw unknown to the vendor and security community, with no official patch available, making it highly valuable to both attackers and defenders.
According to the narrative, this vulnerability allowed the insertion of a malicious payload into the metadata of a sticker pack. This resembles known attack techniques where harmful code is hidden inside additional data in images, documents, or other files and is executed when a vulnerable application processes them.
The author further claimed that this technique granted persistent access to Max’s infrastructure and enabled a long-term, stealthy data exfiltration operation. They said they had attempted to contact Max through its bug bounty program but received no response, and therefore decided to publish the data.
As supposed proof, the post promised to release the first 5 GB of stolen data via torrent and shared sample records allegedly linked to State Duma deputy Nikolay Brykin. These details helped the story gain rapid traction in social networks and messaging channels.
How Max debunked the alleged data breach
Max’s press office quickly labeled the DarkForums publication as “another fake”. The service’s security team presented several technical inconsistencies that contradicted the attacker’s story and the published “evidence.”
Infrastructure mismatch. Max stated that it does not use foreign cloud storage, including Amazon Web Services (AWS). All user data, according to the company, is hosted on servers located in Russia. The DarkForums post, however, described an architecture allegedly relying on foreign cloud infrastructure, which does not align with Max’s actual deployment model.
Password hashing inconsistency. The leaked fragments referenced bcrypt password hashes. Max’s engineers clarified that the platform does not use bcrypt for password storage. Password hashing is a standard security practice where passwords are stored as cryptographic “fingerprints” instead of plain text. The hash format is often a strong indicator of which service a dataset belongs to. In this case, the format did not match Max’s real implementation.
No signs of large-scale exfiltration. The security team reported that log analysis showed no suspicious activity indicative of a 142 GB data transfer or of a long-term compromise. In addition, there was no record of any bug bounty submission by a user named CamelliaBtw.
Data structure did not match reality. The samples included fields such as location, date of birth, email, tax ID, social security equivalents, “account levels,” and specific username formats. Max stated that it does not collect or store these categories of personal data, does not classify users by levels, and does not use usernames in the format shown. This strongly suggests that the information originated from another source or was artificially generated.
After these clarifications were made public, CamelliaBtw admitted that no vulnerability and no hack existed and that the DarkForums post had been intentionally false. The poster also claimed they did not expect the story to spread so widely across Telegram channels.
Why fake data breaches are on the rise
The Max case fits into a broader trend where fake leaks and staged “hacks” are used as tools of information pressure, extortion, or simple attention-seeking. Underground marketplaces and forums act as amplifiers: their audiences are predisposed to believe dramatic breach stories.
Motivations vary. Some actors aim to damage a company’s reputation or manipulate markets. Others try to monetize attention by selling alleged “exclusive access” to non-existent databases. In some scenarios, criminals first publish fabricated samples and then approach the organization with ransom demands, betting that it cannot immediately verify the authenticity of the alleged breach.
Real risks for users during fake leak campaigns
Even when a breach is fictitious, the resulting information noise creates genuine danger for users. Cybercriminals often exploit heightened anxiety to launch phishing campaigns, posing as “security support” and urging users to “urgently change their password after the leak.” Following such links can lead to real account compromise, malware infections, or credential theft.
Frequent false alarms also erode trust in digital services and complicate the work of incident responders. When users see constant headlines about leaks—some real, some not—it becomes harder to distinguish legitimate security notifications from manipulation or scams.
How to verify reports of hacks and data leaks
Both users and organizations need a simple, repeatable process for validating breach claims, especially when messaging apps and platforms handling large volumes of personal data are involved.
1. Check official communication channels. The first step is to consult the service’s official website, verified social media accounts, status pages, or technical blogs. Major providers typically publish timely advisories about confirmed incidents and recommended user actions.
2. Examine the alleged dataset. The structure and content of leaked records often reveal whether a breach is genuine. Red flags include fields that the service does not collect, inconsistent database schemas, or use of technologies the platform does not rely on—such as the mismatch between bcrypt hashes and Max’s actual password storage method.
3. Look for independent technical analysis. Large-scale, real data breaches rarely go unnoticed by the security community. They are often followed by reports from incident response teams, CERT organizations, or threat intelligence companies, including indicators of compromise (IOCs). The complete absence of external analysis for a supposedly “massive” leak should raise doubts.
4. Be skeptical of unsolicited advice and links. Users should avoid following links or installing software promoted in chats and channels claiming “exclusive insider information about a hack.” If there is any concern, it is safer to manually open the official app or website, change the password through the standard interface, enable multi-factor authentication, and ensure that the application is up to date.
Incidents like the fabricated Max messenger hack highlight the need for critical thinking in response to high-profile cyberattack claims, especially those originating from anonymous forums and accompanied by limited technical detail. For users, the most effective defense remains consistent digital hygiene: unique, strong passwords, multi-factor authentication, regular software updates, and cautious handling of security-related messages. For companies, transparent and prompt communication, along with mature monitoring and incident response processes, makes it significantly harder for both real attackers and opportunistic hoaxers to exploit fear of data breaches for their own ends.
