Proofpoint has spent since May 2026 tracking a threat cluster it calls UNK_MassTraction, and the campaign is a useful reminder that some of the most damaging email-borne attacks never touch anything DMARC was built to check. The group chains two vulnerabilities in Roundcube, the open-source webmail client widely used by universities and small organizations to run their own hosted mail, to go from a victim simply opening a message to a standing backdoor on the mail server itself. No link needs to be clicked. No credential needs to be typed into a fake page. And no domain needs to be spoofed at any point in the chain.
How the Exploit Chain Works
The entry point is CVE-2024-42009, a cross-site scripting flaw in Roundcube that fails to properly sanitize certain HTML animation event handlers, letting attacker JavaScript execute the moment a crafted email is opened in a vulnerable Roundcube inbox. Proofpoint’s lures were deliberately generic, designed only to get the target to view the message, since viewing is the entire attack surface this bug needs. The JavaScript that fires is a purpose-built browser-side stealer Proofpoint named IceCube, which escapes Roundcube’s iframe sandbox through DOM traversal and gains full access to the page’s DOM and the victim’s live, authenticated Roundcube session. From there, IceCube deploys what Proofpoint calls “helpers” that exploit a second flaw, CVE-2025-49113, a PHP deserialization vulnerability that abuses how Roundcube’s embedded Crypt_GPG_Engine parses input, to install a lightweight webshell the researchers named SquareShell directly on the mail server. As of June 2026, the chain also added a fallback: if SquareShell fails to install, a shell script is executed through the same deserialization flaw to deliver VShell, a memory-resident backdoor, instead of simply giving up.
Both vulnerabilities are old news in patch terms. Roundcube shipped fixes for CVE-2024-42009 and CVE-2025-49113 in versions 1.5.10 and 1.6.11 back in mid-2025. UNK_MassTraction is not exploiting a zero-day; it is exploiting the gap between when a patch ships and when a self-hosted mail server actually gets updated, a gap that at universities running mail infrastructure with limited IT staff can stretch for a year or more.
Who Is Being Targeted
The targeting is narrow and deliberate. Proofpoint has directly observed fewer than ten universities hit, with the actual footprint estimated at a few dozen once related infrastructure is accounted for, concentrated on administrators and professors in physics and engineering departments at major US and Canadian institutions, particularly those with national security ties or research in astrophysics and particle physics. That specificity, combined with a covert relay network shared with other China-aligned clusters, the eventual pivot to VShell, and Chinese-language artifacts left in the phishing emails themselves, is what leads Proofpoint to assess this as a suspected China-aligned espionage operation rather than financially motivated crime.
Why DMARC Has Nothing to Say About This
It is worth being precise about why this campaign sits entirely outside DMARC’s job description, because the reason is different from the account-takeover and adversary-in-the-middle campaigns we have covered before. DMARC, SPF, and DKIM exist to answer one question: did this message actually come from infrastructure the claimed sending domain authorized? They say nothing at all about what the message contains. CVE-2024-42009 is triggered by malformed HTML rendering inside the webmail client, not by anything related to sender identity. An attacker could route this exact payload through a domain with a perfect DMARC record, strict enforcement, and a flawless SPF and DKIM pass, and the exploit would fire exactly the same way, because the vulnerability lives in how Roundcube parses HTML animation events, not in who is allowed to claim a domain.
The second half of the chain makes the gap even more concrete. Once SquareShell or VShell is sitting on the mail server, the attacker has a foothold on infrastructure that the university’s own DMARC record explicitly authorizes to send mail. Any message that server sends afterward will originate from the correct IP, can be signed with the domain’s real DKIM key if the attacker chooses to abuse that access, and will pass DMARC alignment cleanly at any recipient that checks it, because as far as the protocol can tell, it genuinely is the university’s mail server sending genuine university mail. DMARC was built to catch someone forging a domain from the outside. It has no mechanism for noticing that the legitimate server behind that domain has been quietly handed to someone else.
What Defenders Should Do
Patch Roundcube now if you have not already. Versions 1.5.10 and 1.6.11 close both vulnerabilities in this chain, and they have been available for more than a year. If your organization runs Roundcube and cannot confirm its patch level today, treat that as the most urgent item on your list.
Audit for existing compromise, not just future exposure. Because this chain has been active since May 2026 and the underlying bugs have been public for over a year, any unpatched Roundcube instance should be checked for webshells, unexpected cron jobs, or unfamiliar processes, not simply patched and assumed clean.
Restrict and monitor the Roundcube server’s outbound mail path separately from the rest of your infrastructure. A webmail server that suddenly starts sending mail through paths, volumes, or times of day that do not match its normal pattern is a stronger signal than anything DMARC aggregate reports alone will surface, since the mail itself will authenticate cleanly.
Treat DMARC enforcement and webmail patching as two separate, non-substitutable controls. Locking every domain your organization owns to p=reject remains correct and necessary. It does not reduce the urgency of keeping the software that actually processes your mail current, because the two controls protect against entirely different failure modes.
The Takeaway
UNK_MassTraction is not a DMARC bypass in any meaningful sense, because it never needed to go near DMARC at all. It targets the software that renders and stores mail rather than the identity claims that email authentication verifies, and once it succeeds, it inherits the same trusted, authenticated sending path that DMARC was built to protect. Two patches that have existed for over a year would have stopped this campaign cold. No DMARC policy, however strict, would have.
Excello Mail gives you continuous visibility into your DMARC aggregate reports and sending sources, so you can spot unusual patterns even from infrastructure you already trust. Sign up for free to Excello Mail to keep that visibility in place while your team keeps the rest of the mail stack patched.