Every year we pay an independent firm to attack Scroogle Mail and publish what they find. Not a summary, not a badge for the homepage - the report. This year's audit was carried out by Aegis Security GmbH of Zurich between 23 February and 10 April 2026, and the full report is now available: download the 2026 audit report (PDF). This post is the plain-English version, written by someone who spent the seven weeks on the receiving end.
What was in scope
An audit is only as honest as its scope, so here it is in full. Aegis had source-code access to the web client, the iOS and Android apps, the desktop apps and Scroogle Bridge, plus a dedicated staging replica of our server infrastructure in the Lausanne datacentre. They tested the OpenPGP-based end-to-end encryption between users, the zero-access storage layer and its Argon2id key derivation, authentication including 2FA and WebAuthn hardware keys, the recovery-phrase flow, session management, our mail transport hardening (TLS 1.3, MTA-STS, DANE), and the internal admin tooling our own staff use. Social engineering of staff and physical attacks on the datacentres were out of scope; everything else was fair game, including things we were nervous about.
The two high-severity findings
We promised the details, so: finding AEG-2026-03 was a session-revocation race in Scroogle Bridge. When you changed your password, Bridge sessions on other devices were revoked - but a window of up to 90 seconds existed in which an already-authenticated Bridge connection could continue syncing before the revocation propagated. An attacker who had already stolen a device would keep access slightly longer than our documentation claimed. The fix ships revocation checks on every sync cycle rather than at connection setup; the window is now under two seconds. Fixed and verified by Aegis on 19 March.
Finding AEG-2026-07 was a content security policy gap in the web client's attachment preview. A crafted HTML attachment could, under specific conditions, execute script in a sandboxed preview frame. The sandbox held - no path to message content or keys was demonstrated - but the defence had one layer where it should have had two. Previews are now rendered from an isolated origin with a stricter CSP, and HTML attachments are inert by default. Fixed and verified on 2 April.
The five medium findings covered rate-limiting on two internal endpoints, an overly chatty error message in the login flow, a dependency pinned to an outdated version, and two hardening recommendations in the admin tooling. All five are itemised in the report with their fixes, all verified closed before publication.
What zero critical does and does not mean
We are pleased with this result, and we want to be precise about it. Zero critical findings means four experienced engineers with source access spent seven weeks trying and did not find a way to read your mail, take over accounts at scale, or defeat the zero-access model. It does not mean such a flaw cannot exist. Security is not a state you reach; it is a process you can either show your working for or not. This is us showing our working - our full security model, past reports and advisories all live on the security page.
Try Scroogle Mail
Audited annually, open-source clients, zero-access storage. If that is how you think email should work, it starts at £2.99 a month.
Create your addressWhat happens next
Both high-severity fixes have already shipped to production - if you use Bridge or the web client, you are running the corrected code now, no action needed. The re-test confirmations are appended to the report. Beyond the annual audit, our bug bounty runs year-round, and we would genuinely rather pay a researcher than read about a flaw somewhere else first: reports go to security@scrooglemail.com, PGP key on the security page.
Next year's audit is already booked. Same deal: full scope, findings published, nowhere to hide. We think every provider that asks for your trust should be doing the same - and if yours will not show you an audit report, that tells you something too.