Bitchat Fixed Its 2025 Identity Flaw, but Later Faced 10 Serious Findings
Bitchat’s most prominent July 2025 security weakness should no longer be described as an unpatched flaw in the current app. The project replaced the original identity and key-exchange design, while subsequent releases recorded another round of security work.
That progress does not turn the early warning into a false alarm or establish that Bitchat is suitable for every sensitive conversation. The accurate current picture is narrower: the demonstrated impersonation path belonged to an immature 2025 implementation, but later official notes disclosed fixes for three critical and seven high-severity audit findings.
What the July 2025 research actually demonstrated
The original finding concerned authentication, not the mathematical strength of an encryption algorithm. In the early Favorites system, Bitchat retained an identity key and peer identifier for a contact, yet the identity key did not authenticate the ephemeral keys used for a conversation.
Alex Radocea’s July 7 analysis documented how a person positioned between two users could present a trusted contact’s identity key alongside attacker-controlled ephemeral material. The receiving client could then display the attacker as the previously favorited contact, creating a practical impersonation route despite the presence of encrypted transport.
This distinction matters because encryption and identity verification solve different problems. A message can be encrypted so that nearby observers cannot read it while still being delivered to an attacker whose key was accepted under another person’s identity. Calling the early implementation “encrypted” therefore did not answer the central question of whether a user could reliably know who held the other endpoint.
A later technical assessment from Trail of Bits agreed that the demonstrated man-in-the-middle attack and weak identity authentication were legitimate, consequential design problems. It also separated that defect from the broader difficulty of making manual key verification usable and from the stronger per-message forward-secrecy properties expected of mature secure messengers.
The evidence available from that episode supports a serious identity flaw. It does not support treating every speculative issue circulating at the time—including an alleged buffer overflow—as an independently confirmed critical vulnerability. Severity labels require a defined finding, affected version, exploit conditions and assessment method; those details were not established for every claim attached to the initial coverage.
The protocol changed after the warning
The project responded quickly to the identity criticism. Radocea subsequently updated his account to note that Bitchat added a development warning and moved to end-to-end cryptography based on Noise, a framework designed to bind authentication and key exchange according to a specified handshake pattern.
That change is more substantial than replacing one cipher with another. The original failure arose because the long-term identity presented to the user was disconnected from the keys protecting the active exchange. An authenticated Noise handshake addresses that architectural gap by making possession of the relevant static key part of establishing the encrypted session.
It would nevertheless be inaccurate to conclude that adoption of a recognized framework automatically secured every surrounding component. Packet parsing, storage limits, notifications, keychain behavior, blocked-user handling, replay windows and data deletion all sit outside the narrow cryptographic handshake. A messenger can implement sound session establishment and still expose users through mistakes elsewhere in the application.
Later releases reveal a broader security workload
The project’s official GitHub release history shows that security work continued well beyond the first identity repair. Version 1.5.0 listed mitigations for storage-exhaustion denial of service, announcement flooding, timestamp validation, keychain errors, blocked-user notifications, app-switcher snapshots and Noise compliance; version 1.5.4 later recorded fixes for three critical and seven high-severity audit findings. The same page identifies version 1.7.1 as a subsequent security-and-reliability release.
Those entries provide the clearest new value missing from the original account: Bitchat did not remain frozen in its July 2025 proof-of-concept state, and the maintainers report remediation of later audit findings. At the same time, a release-note claim is not a substitute for a public assessment containing scope, test dates, affected components, exploitability and retest results. The notes establish that fixes were shipped, but they do not give readers enough information to independently judge each finding or the audit’s total coverage.
The later count must also be kept separate from the original impersonation demonstration. “Three critical and seven high” describes a subsequent audit-fix entry; it should not be retroactively assigned to Radocea’s July 2025 report. Combining the two episodes would blur different code versions, findings and assessment methods.
What users can reasonably conclude now
The 2025 impersonation demonstration remains important historical evidence, not a reliable description of the latest build. Anyone evaluating Bitchat should first identify the exact platform and installed version, because conclusions drawn from the early Favorites implementation do not map cleanly onto releases using authenticated Noise sessions and later hardening.
For ordinary experimentation, the maintenance record shows an active project that responded to public criticism and continued addressing security defects. For journalism, research or incident response, claims should name the affected version and distinguish a demonstrated attack from a potential code defect, an audit finding and a maintainer-reported fix.
People whose safety depends on resisting targeted interception face a stricter decision. They should not treat “decentralized,” “offline” or “end-to-end encrypted” as a complete security evaluation, and should prefer a messenger with a mature protocol, published audit scope, clear verification model and a long record of remediation. If Bitchat is used in that setting, contact verification should occur through a separate trusted channel, and the absence of a public retest report should remain part of the risk assessment.
Also read:
Subscribe to our newsletter
Get the latest Web3, AI, and crypto news delivered straight to your inbox.