Found a security issue in the peeza app, the relay, or this site? Email [email protected]. Include enough detail to reproduce it: affected component, version, and steps. To encrypt your report, ask and we'll share a key.
We will not pursue or support legal action against researchers who act in good faith within this policy. That means: avoid privacy violations, data destruction, and service degradation. Interact only with accounts you own or have explicit permission to test. Give us reasonable time to remediate before public disclosure. If in doubt, ask first.
Files are encrypted on the sending device and decrypted on the receiving one. The key travels in the link, or sealed to the receiving device. The relay does not receive it. There is one exception, when you ask for it, and two places where you trust our servers: the web page that decrypts in a browser and the first key for a new device. The relay never stores file contents. It forwards ciphertext it cannot read. What the relay keeps and doesn't: how it works and our privacy policy.
The protocol and its cryptography are published: the keys, the sealed format, how a key reaches the receiver, nearby pairing, and what the relay sees. It includes test vectors and a section on limits and exceptions. Read Protocol and cryptography.
What was wrong. In wire version peeza-e2e-v1, the receipt a device sends when a file has fully arrived was sealed the same way every time under the transfer's key. Only the room it was sent in changed. Every delivery of one team share uses one key. So anyone who saw two finished deliveries (our relay forwards them) could build a receipt for a third delivery without the key: a delivery reported that did not happen. Three smaller sealed conversations could also reuse a nonce after a reconnect or a restart. A team device also re-sealed a renamed file's name. Reusing an AES-GCM nonce exposes that key's authentication subkey. Receipts and content shared one key, so in the worst case the same observer could also alter a team share's relayed content without detection. Nothing sealed could be read.
Affected. Every app and the web client, from the 2026-09-28 release (Mac 0.2.66, macOS 12–13 1.0.0-beta.68, Windows 1.0.6, Linux 0.0.3, iOS and Android build 2786) through the last release before the fix.
Fixed in wire version peeza-e2e-v2: Mac 26.10.9, macOS 12–13 26.10.8, Windows 26.10.7, Linux 26.10.15, iOS 26.10.11 (4057) and Android 26.10.9 (4057), published 2026-10-07, and the web client from relay v192, deployed with them. Each purpose now has its own key. The receipt is an HMAC. The conversations take a random nonce per message. A test records every seal in scripted team deliveries, reconnects and restarts, and fails on any key and nonce pair that seals two different inputs. An app on the old version cannot exchange files with an updated one, and says both sides must be up to date. Details in section 14 of the protocol.
Verified. On 2026-10-07 the same reviewer re-ran its reproduction against the fixed format. Neither the apps' engine nor the web client accepted a forged receipt in 100 trials of each variant. The old format accepted 100 of 100. This re-test covers the receipt's construction and the source code. It does not certify the published builds.
Credit. Found by an external assessment of peeza's product and security, done with OpenAI Codex (report of 2026-10-07). peeza was in private beta, with no outside users, at the time.
Transfers are end-to-end encrypted, so we cannot see or scan file contents (the limits of that are in our published protocol). To report abuse of the service, including child-safety concerns, email [email protected]. Our only content remedy is invalidating a share link by its token. We act on lawful reports promptly, and preserve and report as required by law.