Security

Security advisories

Every security vulnerability fixed in Scroogle Mail software is disclosed here once the patch has shipped and users have had a reasonable window to update. We do not sit on fixed bugs, and we do not dress them up: each advisory says what was wrong, who it affected, and how we fixed it. Where a finding came through our bug bounty programme, the researcher is credited.

No known unpatched vulnerabilities as of 2 July 2026. Think you have found one? Report it via the bug bounty programme.
SCR-2026-002 Medium

Stored XSS via member labels in the Family admin panel

AffectedWebmail 4.16.0 - 4.18.1
Fixed inWebmail 4.18.2
Published19 May 2026
Updated26 May 2026
ComponentWebmail (Family admin panel)

A display label set by a Family plan member was rendered without escaping in one view of the family organiser's admin panel, allowing a member of the same family group to run script in the organiser's webmail session. The vulnerable view handles plan administration only and has no access to decrypted message content. Webmail is served centrally, so the fix was live for all users on 14 May 2026; we found no evidence of exploitation in the three days of access logs we retain.

Credit: quietwire, via the bug bounty programme.

SCR-2026-001 Medium

Rate-limit bypass on password reset requests

AffectedAccount API 3.38.0 - 3.43.2
Fixed inAccount API 3.44.0
Published9 February 2026
Updated12 February 2026
Componentapi.scrooglemail.com (password reset)

The per-IP rate limiter on the password reset endpoint honoured a client-supplied X-Forwarded-For header on one internal routing path, letting an attacker spoof source addresses and send an unlimited stream of reset emails to a victim. Reset tokens are 128-bit, single-use and short-lived, so account takeover was not practical; the realistic impact was mailbox flooding. Fixed by stripping the header at the network edge and adding a per-account cap alongside the per-IP one.

Credit: m0rgenrot, via the bug bounty programme.

SCR-2025-004 Low

Scroogle Bridge did not enforce certificate pinning on reconnect

AffectedScroogle Bridge 3.1.0 - 3.2.2
Fixed inScroogle Bridge 3.2.3
Published3 November 2025
Updated3 November 2025
ComponentScroogle Bridge (all platforms)

Scroogle Bridge validated the server certificate against system trust roots but did not enforce its built-in certificate pin when reconnecting automatically after a network change. Exploitation would have required a fraudulently issued certificate from a CA trusted by the operating system, and stored mail remained protected by zero-access encryption throughout. We treated it as a hardening gap rather than an active exposure, and Bridge 3.2.3 enforces the pin on every connection, first or not.

Credit: PfefferSec, via the bug bounty programme.

Older releases predate this advisory process; the programme began publishing in 2025. Advisory counts are also summarised in our annual transparency report, and the underlying security model is described on the security page. To report a new issue, use the bug bounty programme - triage within 3 working days.