Between 2023 and 2025, a campaign that ESET named Operation RoundPress used cross-site scripting in webmail software to steal credentials, contacts and messages from government and defence targets. ESET attributes it, with medium confidence, to the Russia-aligned group Sednit.
It is on this page next to a ransomware crew and a vulnerability disclosure for a reason. Same mechanism, entirely different motive — and two unrelated kinds of attacker converging on one technique is a better argument than either on its own.
The payload never lands anywhere
The delivery was a spearphishing email, but the email was not carrying malware. It carried an XSS payload, and when the target opened the message in their browser the payload injected JavaScript directly into the webmail page they were already logged into.
From there it read what that session could read. Credentials, contacts, messages. In the MDaemon case the tooling ESET calls SpyPress.MDAEMON went further and set up a bypass of two-factor authentication.
There is no file for endpoint tooling to find, no process to flag, and nothing written to disk. The attack exists as script running in a page for as long as that page is open. This is the cleanest illustration available of an injection that lives entirely in the browser layer, which is exactly the place most security tooling cannot see.
Second factors protect the moment you log in. This arrives afterwards, inside the session that logging in produced.
- Why the 2FA bypass matters
Most of the bugs already had fixes
The campaign started against Roundcube in 2023 and expanded in 2024 to Horde, MDaemon and Zimbra. One of the four, CVE-2024-11182 in MDaemon, was a zero-day at the time and has since been patched — ESET considers it most likely that Sednit found it themselves.
The other three were already known and already patched. The victims simply had not applied the fixes.
That is not an argument against patching, and it is not a criticism of the vendors, three of whom had shipped the fix. It is an observation about the window. There is always a gap between a fix existing and it being applied across an estate, and a control that works during that gap has to be one that does not care which bug produced the injection. A policy that refuses to execute unsigned inline script does not need to know the CVE number.
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.
No victim organisations were named and no volume of stolen mail is public, so there is no figure to quote here. The mechanism is the finding.
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.
