CVE-2025-24904 Overview
CVE-2025-24904 affects libsignal-service-rs, a Rust port of libsignal-service-java that implements the core protocol for communicating with Signal servers. Prior to commit 82d70f6720e762898f34ae76b0894b0297d9b2f8, the library accepted plaintext content envelopes without verifying that the message was authenticated through the Signal end-to-end encryption pipeline. A malicious server or client can inject crafted envelopes that downstream consumers process as legitimate messages. This bypasses both confidentiality and authentication guarantees of the Signal Protocol. The flaw is classified under [CWE-74] (Improper Neutralization of Special Elements in Output).
Critical Impact
Attackers controlling a server or operating as a malicious peer can inject plaintext envelopes that bypass end-to-end encryption and authentication checks in any application built on libsignal-service-rs.
Affected Products
- libsignal-service-rs versions prior to commit 82d70f6720e762898f34ae76b0894b0297d9b2f8
- Downstream Rust applications embedding the Signal service client (for example, Whisperfish and other unofficial Signal clients)
- Any client that processes Content envelopes without checking the was_encrypted flag
Discovery Timeline
- 2025-02-13 - CVE-2025-24904 published to NVD
- 2026-04-15 - Last updated in NVD database
Technical Details for CVE-2025-24904
Vulnerability Analysis
The Signal Protocol relies on Double Ratchet sessions to provide end-to-end encryption and per-message authentication. libsignal-service-rs previously accepted envelopes whose payload was delivered in plaintext, treating them as valid Content messages without enforcing that the payload arrived through an authenticated, encrypted session. The fix introduces a was_encrypted field on the Metadata struct so callers can determine whether the envelope traversed cryptographic verification. The patch also adds a sanity test: if the envelope was plaintext, the decoded content must be a decryption failure error and nothing else.
Root Cause
The root cause is missing enforcement of the cryptographic provenance of inbound envelopes. The library exposed decoded Content payloads to consumers without signaling whether the data originated from an authenticated Signal session or from an unauthenticated transport channel. Because Signal servers relay envelopes between peers, any server-side actor, or a peer impersonating the server path, could deliver crafted plaintext envelopes that consumers would treat as genuine messages.
Attack Vector
The attack is network-reachable and requires low privileges. A malicious Signal server, a network attacker controlling the server endpoint, or a malicious client peer transmits a plaintext envelope to a vulnerable consumer. The consumer decodes the envelope as crate::proto::Content and acts on it as if it were an authenticated message from a verified sender. This breaks sender authentication, allowing message spoofing, and undermines confidentiality assumptions in higher-layer applications.
let message =
crate::proto::Content::decode(plaintext.data.as_slice())?;
+ tracing::Span::current()
+ .record("envelope_metadata", plaintext.metadata.to_string());
+
// Sanity test: if the envelope was plaintext, the message should *only* be a
// decryption failure error
if was_plaintext {
Source: GitHub commit 82d70f6. The patch records envelope metadata for tracing and enforces that plaintext envelopes only ever produce a decryption failure error.
Detection Methods for CVE-2025-24904
Indicators of Compromise
- Inbound Signal envelopes carrying Content payloads without an associated authenticated session state
- Application logs showing decoded messages where Metadata.was_encrypted is false
- Unexpected message events attributed to peers with whom no Double Ratchet session has been established
Detection Strategies
- Audit dependency manifests (Cargo.lock, Cargo.toml) for libsignal-service-rs revisions older than commit 82d70f6720e762898f34ae76b0894b0297d9b2f8.
- Instrument message-processing code paths to assert that Metadata.was_encrypted == true before forwarding content to application logic.
- Correlate Signal client telemetry with server logs to identify envelopes delivered outside of an established session.
Monitoring Recommendations
- Enable the new tracing span field envelope_metadata introduced by the patch to capture per-envelope provenance.
- Forward client-side telemetry to a centralized log store and alert on messages where the encryption flag is absent.
- Track upstream advisories such as GHSA-hrrc-wpfw-5hj2 for any follow-up fixes.
How to Mitigate CVE-2025-24904
Immediate Actions Required
- Update libsignal-service-rs to a build containing commit 82d70f6720e762898f34ae76b0894b0297d9b2f8 or later.
- Rebuild and redeploy any downstream client that statically links the affected library.
- Adjust call sites to consume the new Metadata.was_encrypted field and reject any message where the flag is false.
Patch Information
The fix is published in the upstream repository as commit 82d70f6720e762898f34ae76b0894b0297d9b2f8. The patch adds a was_encrypted field to the Metadata struct and enforces that plaintext envelopes only yield decryption failure errors. The change is an intentional API break, and maintainers note it should be straightforward to resolve in dependent crates. Refer to GHSA-hrrc-wpfw-5hj2 for the full advisory.
Workarounds
- No known workarounds exist; upgrading to the patched commit is required.
- As a temporary compensating control, application code can wrap envelope handling to drop any Content payload that did not arrive through a verified Double Ratchet session.
# Update the dependency to a patched revision
cargo update -p libsignal-service
cargo tree -p libsignal-service | grep libsignal-service
# Verify the resolved commit matches 82d70f6720e762898f34ae76b0894b0297d9b2f8 or later
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


