CVE-2023-37580 is a reflected cross-site scripting flaw in Zimbra Collaboration Suite, discovered in the wild by Google's Threat Analysis Group. The payload's job was to steal the Zimbra authentication token.
It is the shortest page in this set because the argument is entirely in the timeline.
Six weeks as a zero-day, then a second wave after the fix
Exploitation began in June 2023, as a zero-day, before any patch existed. Zimbra published a fix on 25 July 2023.
In August 2023 — after the patch — TAG found the flaw being used against a government organisation. Dark Reading characterised the wider picture as multiple distinct advanced groups converging on the same bug.
So the first wave ran while nobody could fix it, and the second wave ran because the fix had made the bug public and shown everyone exactly where to look. Publishing a patch is necessary, and it is also a starting gun. Patching remains the right thing to do; it is simply not a control that helps on either side of the moment you need it most.
The first wave came before a fix existed. The second came because one did.
- The shape of a disclosed vulnerability
It stole a token, not data
This is the detail worth carrying away. The payload was not exfiltrating mail directly — it was lifting the authentication token. Everything the attacker did afterwards looked like a legitimate, authenticated user, because as far as the application was concerned it was one.
That is the same chain as the Canvas breach, where a stolen session was used to call ordinary APIs for four days, and it is why detection that waits for something to look obviously malicious tends to wait a long time.
Reflected, not stored — and it matters
The other three incidents in this set are stored cross-site scripting: the payload sits in a database, waiting for someone to render it. This one is reflected. It needs only a crafted link, and nothing is ever persisted anywhere for an audit to find later.
There is no artefact. No row in a table, no file on disk, no entry in a queue. If you are not watching what executes in the browser at the moment it executes, a reflected payload leaves you nothing to look at afterwards.
A nonce-based policy is what breaks this chain. With script-src 'self' 'nonce-{random}' and no 'unsafe-inline', an injected script carries no nonce, so the browser refuses to run it — and the session it was reaching for is never taken. It does not matter which field the payload arrived in or which bug let it through.
TAG did not name the targeted organisation and there is no aggregate victim count across the campaigns, so neither appears here.
How we can help
The policy is the mitigation and the reporting is the detection, and it is the second half almost nobody switches on. Run CSP in report-only across the internal tools where untrusted content gets rendered, and an injected inline script announces itself the first time it fires — from the real session it fired in, with the page it fired on.
One line of code or config to deploy, and nothing is blocked while you learn what the policy would have caught. Reach out to sales@report-uri.com for a demo or a trial with no commitment.
