"one of the oldest pieces of security advice in the book"
Rule 1: Don't use intrinsically unsafe operating systems and software.
Rule 2: There is no rule 2.
The Russian espionage crew that turned simply reading an email into a security risk has expanded beyond Zimbra, with Proofpoint saying it's now pulling the same half-click trick against Microsoft Outlook Web Access. Proofpoint says the cyber group it tracks as TA488, or "Laundry Bear," began exploiting CVE-2026-42897, a cross- …
They aren't running scripts intentionally. If you just include JavaScript in a message, clients, including webmail, won't run it. You need to find vulnerabilities like this which allow you to bypass the intentionally not-running they do. Those vulnerabilities tend to be easier to find in webmail which is usually built in the same JS you're trying to inject rather than standalone clients which can and often do use HTML rendering without any JS support.
That's right! When an Ajax-driven webmail client displays a HTML email message, it has to separate its own HTML, CSS and JavaScript from the HTML, CSS and JavaScript that is included in the message. A bit of a tightrope, really. Plain text email messages are immune, of course. And the old SquirrelMail avoids a lot of problems by being written in pure PHP without any JavaScript.
Which is why I disable javascript when viewing HTML pages. If the fucking idiot is giving the email client the ability to run any kind of javascript anywhere, they are still a fucking idiot. Ditto the server for serving javascript ridden gobshite in the first place. FFS, it's not rocket science.
Thank goodness we had all that faffle about Trusted Computing and requiring that the hardware include security checks and so on and, wait, what ?
All that hassle to try and keep from running Linux (because that's what it was for) and you're telling me that a stupid browser implant can survive device rebuilds ?!?
Just a question : can that browser implant also survive replacing the disk and reinstall from scratch ?
Because if it can, those guys need to switch hats and go work at Redmond.
Maybe then we'll finally get actual security in the Windows world.
It survives in the server-hosted email inbox, so as soon as the user opens their email again, there it is.
"survives <snip> even a complete device rebuild because the foothold resides in the compromised mailbox rather than on Windows itself"
Pouring one out for Zimbra. It was a gamechanger for the small biz I was network/server/CTO/developer at.
Publishing business, mid-2000s, 20 Macs (OSX 10.3 Panther burned in the brain) and 30 Windows machines. Interop between MS and Macs was genuinely awful in those days but e-mail/groupware was escpecially problematic for Macs as the M$ version was deliberately knobbled and didn't support many aspects of on-prem Exchange at the time (MAPI and extensions IIRC). Our original in-house Exchange server from ~1999 was on its knees
Trying to find self-hosted groupware to handle 50GB mailboxes that was cross-platform and handling 50GB mailboxes was a real challenge. This was before cloud and externally-hosted Exchange so Zimbra turned out to be an excellent solution at that time for people with massive mailboxes full of hi-res images being flung around.
Once it executes, it has two persistence methods where it injects JavaScript into other areas. One of those is client side, so clearing cache for the site will eliminate that. The others are in cached messages which it has modified, so unless you clean or delete those as well, it can come back from that. There are also some settings which it changes to open the account to compromise even after it's been cleaned if they have another account on the same mail system. Therefore, cleaning this infection out requires knowing the multiple locations it modifies and either deleting or carefully removing the infection from them. See the Proofpoint summary for the details.