Trojans Embedded in .svg Files

Porn sites are hiding code in .svg files:

Unpacking the attack took work because much of the JavaScript in the .svg images was heavily obscured using a custom version of “JSFuck,” a technique that uses only a handful of character types to encode JavaScript into a camouflaged wall of text.

Once decoded, the script causes the browser to download a chain of additional obfuscated JavaScript. The final payload, a known malicious script called Trojan.JS.Likejack, induces the browser to like a specified Facebook post as long as a user has their account open.

“This Trojan, also written in Javascript, silently clicks a ‘Like’ button for a Facebook page without the user’s knowledge or consent, in this case the adult posts we found above,” Malwarebytes researcher Pieter Arntz wrote. “The user will have to be logged in on Facebook for this to work, but we know many people keep Facebook open for easy access.”

This isn’t a new trick. We’ve seen Trojaned .svg files before.

Tags: malware, pornography

Posted on August 15, 2025 at 7:07 AM • 12 Comments

Comments

James N. Kennett • August 15, 2025 8:40 AM

Come back Flash! All is forgiven!

Santana • August 15, 2025 9:52 AM

Hiding code in .svg files is not a problem. But Facebook having CSRF vulnerabilities is.

Mexaly • August 15, 2025 11:40 AM

Facebook is not for me, so, meh.
And don’t even say, “Javascript.”
I wonder if I can rig a little honeypot for this.

lurker • August 15, 2025 1:32 PM

As detestable as JavaScript is, and as evil as obfuscated .js is, this hack relies on the sucker having a valid FB account open while browsing porn. Surely that’s a deathwish …

Clive Robinson • August 15, 2025 3:00 PM

@ Bruce, ALL,

With regards,

“This isn’t a new trick. We’ve seen Trojaned .svg files before.”

Not just SVG files… Which set off a thought…

We’ve seen so many vulnerabilities in different graphics files from BMP, PDF, JPEG, etc, etc, I could not think of any graphics file formats that had not been abused in some way.

Often the weakness is the interpreter in the application used to take the compressed image format and in the process of expanding it to a display format to display it gets abused.

In fact a little more thought gave rise to the realisation that either the more compression in a file or the more compression formats decoded by the application the more likely it is to have exploitable vulnerabilities.

Especially in libraries of code that have high code reuse.

Clive Robinson • August 15, 2025 3:20 PM

@ ALL,

The end of the article closes with two statments,

“Facebook regularly shuts down accounts that engage in these sorts of abuse. The scofflaws regularly return using new profiles.”

Facebook is a private corporate site, thus it’s quite legal to “shut down” accounts it considers objectionable, provided they are not discriminating for some reason.

How ever using the word “scofflaws” is technically and legally incorrect. That is opening a new account is not unlawful / illegal even though the Facebook Terms Of Service might imply it is.

Also consider, the graphic file is “pulled by the user”, not “pushed by the service” thus quote a bit of legislation about malware effectively gets negated …

Thus raising the question of if quite a bit of current anti-malware legislation is actually effective…

cb • August 15, 2025 6:38 PM

What kind of ever-loving idiot writes his browser to load and execute JavaScript (or any executable) from a graphic file? Do all browsers do this? What possible benefit could it have, ever?

Clive Robinson • August 16, 2025 3:13 AM

@ cb, ALL,

With regards,

“What kind of ever-loving idiot writes his browser to load and execute JavaScript (or any executable) from a graphic file? Do all browsers do this? What possible benefit could it have, ever?”

The answer to your three questions in short are,

1, Someone who uses a second parties graphics code library.
2, If the application uses the same second parties graphics code library then very probably.
3, Using a second parties graphics code library takes a lot of heavy lift out for the first party thus “reducing time to market”.

The real issue is,

“Being all things to all men”

Along with

“Highly complex interpretive functionality”.

We’ve seen this before with “log4j” and the vulnerability called “log4shell” back at the end of 2021,

https://www.ibm.com/think/topics/log4j

The underlying issue is similar to the

“Publish or be dammed”

Of academic progression. To get the benefits your name has to be well known.

In Open Source this means getting as many people to use your code as you can. To do this it has to work seamlessly for as many people as possible. Thus you put in everything anyone could possibly want behind a simple interface this has three side effects

1, Covers many edge cases
2, Large often disparate code base
3, High complexity

Which frequently results in hidden or unpredictable vulnerabilities.

But the point to note is that the more disparate edge cases you cover the more likely it is that your program logic for “ease and flexibility” to be implemented as an interpreter of some kind that is “Turing Complete” thus introduces variations on the “Halting Problem” and Kurt Gödel’s “undecidability” theorems. Which is dangerous enough when acting on “controlled tested input” but is open to all sorts of issues when it acts on “uncontrolled untested input” such as files downloaded from the Internet

In some graphics files they are actually programs… See PDF which is based on PostScript. Which is described by some as

“The language Postscript is what computer scientists call a “back-assward” programming language.”

Of a similar type to the Forth “Stack Based Reverse Polish Notation” Programming language.

Bear • August 16, 2025 1:23 PM

Actually shouldn’t we take the compression out of the image format entirely? Remember, a program should do exactly one thing and do it well. Image display programs should not be trusted to do decompression.

We’re already using compression when we store and transfer files, so why should graphics formats have their own error-prone and likely exploitable compression systems making them incompatible with all other graphics formats?

We should all use PPM, or TIFF, or some other completely uncompressed format. Sure, it takes up acres of space if you store it without compression and acres of bandwidth if you transmit it without compression, but it doesn’t matter because NOBODY is ever going to have to do that. We can store and transmit image.ppm.gz and it’ll be the the same size and bandwidth as a compressed lossless graphics format and decoding it for display on the far end will have the same speed as decoding for display any other compressed lossless graphics format.

The advantage is that the image data itself CANNOT BE NOT A SECURITY PROBLEM BECAUSE IT IS ‘PLAIN OLD DATA’ THAT NEVER GETS EXECUTED BY ANYTHING. We would never have to worry about how to extract the image from an exploitable or exploited format. We would never have to worry about something non-obvious being hidden in the image data.

If somebody manages to exploit the decompression, you don’t have to get rid of your image data or subject it to any dodgy conversion process, because your image data is not part of the problem. it doesn’t become obsolete when a new version of a graphics format comes out. Either they fix the compression/decompression program maintaining backward compatibility, or you can extract the never-a-problem image data and compress it again with a different compression utility.

If you have to convert compression, you do it in an absolutely standard way using the same well-used, actively developed, frequently audited compression software that you use to decompress and compress everything else, not with some funky graphics conversion program using proprietary formats with codecs you can’t audit, and special use commands which you haven’t practiced and can easily get wrong, and not in a way that can lose any image clarity or introduce any image artifacts.

lurker • August 16, 2025 2:18 PM

@Clive Robinson
“Thus you put in everything anyone could possibly want behind a simple interface this has three side effects

1, Covers many edge cases
2, Large often disparate code base
3, High complexity”

That sounds like the Linux kernel …

Ismar • August 17, 2025 7:10 AM

This is unlikely to work against FB due to:
“ Facebook’s Mitigations (Why It’s Mostly Patched)

CSRF Tokens:
Modern Facebook APIs require per-request tokens (fb_dtsg), making unauthorized requests fail.
SameSite Cookies:
Facebook now uses SameSite=Lax/Strict cookies, preventing cross-tab CSRF.
Frame Busting & X-Frame-Options:
Facebook blocks embedding Like buttons in iframes from untrusted domains.
Content Security Policy (CSP):
Prevents unauthorized script execution from external sources.”

ROFL • August 17, 2025 12:46 PM

Wow. Thanks for pointing this out. It doesn’t seem so interesting when you dig into the linked article. It just seems that the SVG format is too eager to support things you’d think you wouldn’t need (like internal scripting).

I think security focused people should roll-out their own limited support of systems like this that do too much for no reason.

Thanks again for the heads-up, I hadn’t realised how I was using only a minor subset. Ah well.

Stay safe online everyone and happy hacking!

Trojans Embedded in .svg Files

Comments

Leave a comment Cancel reply