Security, audit method · Crypto Enterprise Skip to content

Security

An audit where half the work was proving us wrong.

Auditing means one simple thing: reading through all the code looking for ways to break it, the way someone who wants to harm you would. We did that across the whole product, in house, under one rule. Every suspected flaw is handed to a second analysis whose job is to show that it does not exist. What survives gets fixed, then watched by an automated test.

71

findings recorded

Recorded by the two campaigns of early August 2026 — an offensive audit on the 3rd, a manual code review on the 4th — after deduplication and removal of what was already fixed. Every suspected flaw first faced a second analysis tasked with refuting it; what did not survive is not counted here. The findings still open from the general review of July are not yet merged into this register.

56

fixed

Fixed as of 15 September 2026. Whenever the attack can be replayed by a program, the fix ships with an automated test that replays it on every integration. 13 more are reduced: the application-side fix is shipped, and the risk that survives is written down in the register rather than glossed over.

2

still open

Both are the same defect seen from two sides: a relay's operator label is self-declared, the authority signs it as is, and all path diversity rests on it. What counts as proof that an operator is one has not been settled yet. State as of 15 September 2026. We would rather publish this count than leave it out.

The method, step by step

  1. Step 1: attack

    We read through the whole codebase hunting for flaws. Every questionable behaviour is written down, along with the attack it would make possible.

  2. Step 2: contradict

    Each issue then goes to a second analysis whose job is to show that it is wrong. What did not survive that step is not counted in the 71. That is why we can say the numbers on this page are not inflated.

  3. Step 3: fix and replay

    Of the 71 findings recorded, 56 are fixed and 13 reduced as of 15 September 2026; 2 remain open. Whenever the attack can be replayed by a program, the fix ships with a test that replays it on every integration: if the flaw ever returns, that test fails and says so. The reduced ones are those where the application-side fix is shipped but part of the risk survives: sometimes it depends on a deployment (a flag to set on the relays, an HTTPS certificate on the authority), sometimes on a design decision that has to be designed rather than improvised. The flaw-by-flaw detail is not published today, and we will not pretend otherwise until it is. Write to us and we will answer precisely on the ones that bear on your use.

What the latest round found

In early August 2026, two flaws in the cryptographic core were demonstrated by a program that runs them, not merely described.

The first is fixed. A key-exchange defect let someone holding no key at all get a conversation accepted. The missing check already existed elsewhere in our own code; it was absent precisely where every conversation passes. Fixed on 4 August 2026, with a test that replays the attack on every integration.

The second, rated critical, has been reduced since 13 September 2026. Two colluding relays could mark a message on the way in and recognise it on the way out, which links sender to recipient. Fixing it changed the format of messages on the network: that is done, with version 3 of the header (application 2.3.0, relay v0.12.0 across the whole fleet), at the cost of a deliberate break — a 2.2.0 client and a 2.3.0 client can no longer open a conversation. What remains, and we write it down: relays still accept the old header until strict mode (--strict-header-v3) is set on the fleet, and two colluding relays that sit next to each other keep a tagging channel this construction cannot close. The current network has a single operator, so no third party can exploit it today — but the residual must be settled before relays run by other people join.

We write this here because a security product that publishes only its successes teaches nobody anything.

Default posture

[profile.release]
panic = "abort"

This configuration line tells the software to stop dead the moment it meets a situation it cannot handle, rather than carry on in an uncertain state. The consequence is deliberate: any crash a stranger can trigger counts as a flaw to fix, never as an incident to wave away.

These numbers come from an internal audit, run by the team that writes the software and not by an independent outside firm. So they are not a certification. They are checkable in part: the network code — relays, directory, authority — is published under the AGPL-3.0 licence in the public repository, and anyone can read it or run it again. The application itself is proprietary, and some of the tests that replay the attacks live in the private repository: we do not call them published until they are. We claim no label we do not hold. The day an independent body grants us one, its name and the date will be written here.

Report a vulnerability

If you find a flaw, write to us privately before going public. We fix it first, then the flaw and its fix are published. That is what coordinated disclosure means. Your report is read by the engineers who write the code, not by a support desk.

Security contact

crypto.app.organisation@proton.me

Disclosure policy: the SECURITY.md file in the repository · no PGP key published to date · a person replies

Public history of fixes