From the abstract:
We present two practical attacks that break the integrity properties of Signal in its advertised threat model. Each attack arises from different features of Signal that are poorly documented and have eluded formal security analyses. The first attack, affecting Android and Desktop, arises from Signal’s introduction of identities based on usernames (instead of phone numbers) in early 2022. We show that the protocol for resolving identities based on usernames and on phone numbers introduced a vulnerability that allows a malicious server to inject arbitrary messages into one-to-one conversations under specific circumstances. The injection causes a user-visible alert about a change of safety numbers, but if the users compare their safety numbers, they will be correct.
The second attack is even more severe. It arises from Signal’s Sealed Sender (SSS) feature, designed to allow sender identities to be hidden. We show that a combination of two errors in the SSS implementation in Android allows a malicious server to inject arbitrary messages into both one-to-one and group conversations. The errors relate to missing key checks and the loss of context when cryptographic processing is distributed across multiple software components. The attack is undetectable by users and can be mounted at any time, without any preconditions. As far as we can tell, the vulnerability has been present since the introduction of SSS in 2018. We disclosed both attacks to Signal. The vulnerabilities were promptly acknowledged and patched: the first vulnerability was fixed two days after disclosure, while the second one was patched after eight days. Beyond presenting these devastating attacks on Signal’s end-to-end security guarantees, we discuss more broadly what can be learned about the challenges of deploying new security features in complex software projects.
On the timeline and patched versions, from the paper:
We disclosed our first attack to Signal on 2025-09-22, with a proposal for mitigation. They acknowledged the issue and adopted our patch for the Desktop version [49] on the same day and for the Android version [18] on 2025-09-24. The patches, which make clients reject messages coming from a PNI address, were deployed in versions v7.74.0-beta.1 [4] and v7.58.0 [3] for Desktop and Android, respectively. The iOS version was unaffected.
We disclosed our second attack to Signal on 2026-01-20, with proposals for mitigation. They acknowledged the issue and discussed possible mitigations with us. Signal released a patch for the Android version [47] on 2026-01-28. The patch was deployed in version v7.72.2 [10] for Android. It performs plain-text validation for SSS-wrapped messages. This addresses the second issue and is sufficient to prevent our second attack. The iOS and Desktop versions were unaffected.
After investigating whether other projects that are based on libsignal were also vulnerable to our attacks, we discovered that Whisperfish [74] was vulnerable to our first attack and signal-cli [20] was vulnerable to our second attack. We contacted both projects’ developers on 2026-02-05, The developer of signal-cli promptly patched the code on the same day. This patch was deployed in signal-cli v0.13.24 [8] and in the unofficial library it uses, libsignal-service-java v2.15.3 unofficial 137 [9]. The developers of Whisperfish acknowledged the issue on 2026-02-06. After discussing mitigations, a patch was introduced on 2026-02-28 on the main branch of Whisperfish [78,77].
The paper: