Security advisories

WSA-2026-001: Custom URL scheme hijack in Wispers Files registration

Medium  ·  Published 2026-05-07

Affected

• Wispers Files for Desktop ≤ 0.8.2
• Wispers Files for iOS ≤ 0.8.2
• Wispers Files for Android ≤ 0.8.2

Fixed in

• Wispers Files for Desktop 0.8.3
• Wispers Files for iOS 0.8.3
• Wispers Files for Android 0.8.3
• Server-side mitigation deployed 2026-05-06

Summary

When adding a new device to your account, Wispers Files delivered a one-time registration token from the website to the local app via the wispers-files:// custom URL scheme. On all major operating systems any installed application may register the same scheme. A malicious app on the victim's device could intercept the callback and submit the captured token to the Wispers Files hub, registering itself as a new device on the victim's account.

By itself, registration produces a placeholder device entry with no access to files — Wispers Files requires a second step ("activation") in which an already-trusted device of the victim cosigns the new device's keys. Achieving file access therefore additionally requires deceiving the victim into activating the rogue device — most realistically by also installing a clone of Wispers Files (a visually convincing impostor) that the victim believes is their own newly-added install, prompts for an activation code, and forwards it to the hub. The realistic full attack is therefore a two-component scenario: a deeplink-intercepting app, plus an impostor app that the victim activates against their existing trusted device.

Attack requirements

1. A malicious application installed on the victim's device that has registered the wispers-files:// URL scheme.
2. The victim initiating a device-registration flow during the malicious app's residence on the device.
3. The operating system routing the callback to the malicious app rather than the legitimate Wispers Files app (silent on iOS where multiple apps share a scheme; via the system chooser on Android where the user would need to pick the malicious app).
4. The victim subsequently activating the registered rogue device — in practice, by being deceived into entering an activation code generated on one of their existing trusted devices.

Impact

If the full chain succeeds, the attacker gains read and write access to the files shared across the victim's connectivity group. If the chain stops after registration (no successful activation), the rogue device remains in the Registered state with no file access; the victim sees an unrecognized device on their account that they can remove.

• Confidentiality: read access to shared files (only after activation).
• Integrity: ability to modify or remove shared files visible to the victim's other devices (only after activation).
• Availability: not affected.

Mitigations applied

The fix is layered:

1. Token binding (PKCE-style). The Wispers Files desktop apps now generate a random per-session secret ("codehalf") at startup, embed it in the registration URL, and submit it together with the token at finalize time. The hub stores SHA256(codehalf || token) rather than the plaintext token. A hijacker who captures only the token via a custom scheme cannot redeem it. This applies to all client platforms and defends the legacy custom-scheme transport.

2. Universal Links / App Links. On iOS and Android the registration callback now uses an HTTPS URL whose routing is verified by the operating system against domain ownership at install time. This defeats scheme-hijack outright for those platforms — a malicious app cannot interpose itself between the browser and the legitimate Wispers Files app.

The server-side change is backward-compatible: tokens issued by older clients (which don't pass a codehalf) continue to work, but those clients remain at the original threat level until updated.

What you should do

• Update Wispers Files to the latest version on every device.
• Review your registered devices on the Wispers Files web console and remove any device you don't recognize.

Exploitation status

To our knowledge, this issue was not exploited prior to remediation. Wispers Files is in early beta with a limited user base, and we have no log evidence consistent with this attack. The issue was identified internally.

Acknowledgments

Identified internally. No external report preceded our discovery.