Malicious VSCode extensions infect Windows with cryptominers
-
Software is the leading cause of all computer viruses.
All people who use software will fucking die, smh.
-
It also helps its as easy as clicking a button to install an extension... and i wonder how many even bother checks the source of the extension?
It's also kinda "trusted" in corporations. The one I work for have github blocked for some reason, but any user cam install VS code and extensions by itself.
-
Minification isn't the same as obfuscation, though. The only way I can think to obfuscate HTML would be to replace every element with a custom element.
Minification is a form of obfuscation. It makes it (much) less readable.
Of course you could run a formatter over it. But that's already an additional step you have to do. By the same reasoning you could run a deobfuscator over more obfuscated code.
-
Such tricks were was predictable, as VSCode extensions, letting arbitrary JS run on your system, are an obvious security risk.
Recently I used Zed editor instead, it's smooth, but this also has extensions, only these are fewer and in rust ( maybe a higher barrier, targeting less users, so far... ). What's the solution here - is there some intrinsically safer sandboxed system ?The collaborative sharing nature of these platforms is a big advantage. (Not just VS Code Marketplace. We have this with all extension and lib and program package managers.)
Current approaches revolve around
- reporting
- manual review
- automated review (checks) for flagging or removal
- secured naming spaces
The problem with the latter is that it is often not necessarily proof of trustworthyness, only that the namespace is owned by the same entity in its entirety.
In my opinion, improvements could be made through
- better indication of publisher identity (verified legal entities like companies, or of persona, or owned domain)
- better indication of publisher trustworthiness (how did they establish themselves as trustworthy; long running contributions in the specific space or in general, long standing online persona, vs "random person", etc)
- more prominent license and source code linking - it should be easy to access the source code to review it
- some platforms implement their own build infrastructure to ensure the source code represents the published package
Maybe there could be some more coordinated efforts of review and approval. Like, if the publisher has a trustworthiness indication, and the package has labeled advocators with their own trustworthiness indicated, you could make a better immediate assessment.
On the more technical side, before the platform, a more restrictive and specific permission system. Like browser extensions ask for permissions on install and/or for specific functionality could be implemented for app extensions and lib packages too. Platform requirements could require minimal defaults and optional things being implemented as optional rather than "ask for everything by default".
-
Kate >>> VSCode
Who is Kate?
Kate the editor? Or is there an IDE called Kate?
-
Who is Kate?
Kate the editor? Or is there an IDE called Kate?
-
HTML Obfuscator
Fucking what
Maybe to build one of those shitty websites where you can't select text because every letter is in its own element.
-
The collaborative sharing nature of these platforms is a big advantage. (Not just VS Code Marketplace. We have this with all extension and lib and program package managers.)
Current approaches revolve around
- reporting
- manual review
- automated review (checks) for flagging or removal
- secured naming spaces
The problem with the latter is that it is often not necessarily proof of trustworthyness, only that the namespace is owned by the same entity in its entirety.
In my opinion, improvements could be made through
- better indication of publisher identity (verified legal entities like companies, or of persona, or owned domain)
- better indication of publisher trustworthiness (how did they establish themselves as trustworthy; long running contributions in the specific space or in general, long standing online persona, vs "random person", etc)
- more prominent license and source code linking - it should be easy to access the source code to review it
- some platforms implement their own build infrastructure to ensure the source code represents the published package
Maybe there could be some more coordinated efforts of review and approval. Like, if the publisher has a trustworthiness indication, and the package has labeled advocators with their own trustworthiness indicated, you could make a better immediate assessment.
On the more technical side, before the platform, a more restrictive and specific permission system. Like browser extensions ask for permissions on install and/or for specific functionality could be implemented for app extensions and lib packages too. Platform requirements could require minimal defaults and optional things being implemented as optional rather than "ask for everything by default".
In principle I'd like to see specific permissions - so for example playing with gui enhancements should be a lower trust barrier than adjusting and running code, but afaik (correct me if wrong) neither js nor rust have a built-in security architecture that could implement this. Maybe certain types of extensions could just be custom script language without filesystem access, but that's harder to do.
About source code linking, last time I heard (maybe they fixed it?) it seemed that trick vscode extensions can link to arbitrary (safe-looking) source repos, which didn't actually produce the extension.
I'm less convinced about slowly accumulating publisher trust, as this could be a barrier to honest new contributors, while big actors with a longterm profit or geopolitical motive could game such a system anyway (as they do for social media).
I do trust the scala tools (build Mill, lang-server Metals, compiler) which adjust my code, having seen them evolve over many years.
and like the separation of functions (lang-server / editor), so we are less dependent on any one big-tech solution.
So I suppose a fundamental issue is what to trust less - big corps with a reputation but lock-in power, or an ecosystem of small contributors which might include tricksters. No perfect balance. -
Nine VSCode extensions on Microsoft's Visual Studio Code Marketplace pose as legitimate development tools while infecting users with the XMRig cryptominer to mine Ethereum and Monero.
ExtensionTotal researcher Yuval Ronen has uncovered nine VSCode extensions published on Microsoft's portal on April 4, 2025.
The package names are:
- Discord Rich Presence for VS Code (by
Mark H
) - 189K Installs - Rojo – Roblox Studio Sync (by
evaera
) - 117K Installs - Solidity Compiler (by
VSCode Developer
) - 1.3K Installs - Claude AI (by
Mark H
) - Golang Compiler (by
Mark H
) - ChatGPT Agent for VSCode (by
Mark H
) - HTML Obfuscator (by
Mark H
) - Python Obfuscator for VSCode (by
Mark H
) - Rust Compiler for VSCode (by
Mark H
)
Yo, @[email protected], check the article again. Prettier, a very popular extension, heads the list now:
Prettier — Code for VSCode (by prettier) – 955K Installs Discord Rich Presence for VS Code (by Mark H) – 189K Installs Rojo — Roblox Studio Sync (by evaera) – 117K Installs Solidity Compiler (by VSCode Developer) – 1.3K Installs Claude AI (by Mark H) Golang Compiler (by Mark H) ChatGPT Agent for VSCode (by Mark H) HTML Obfuscator (by Mark H) Python Obfuscator for VSCode (by Mark H) Rust Compiler for VSCode (by Mark H)
- Discord Rich Presence for VS Code (by
-
Yo, @[email protected], check the article again. Prettier, a very popular extension, heads the list now:
Prettier — Code for VSCode (by prettier) – 955K Installs Discord Rich Presence for VS Code (by Mark H) – 189K Installs Rojo — Roblox Studio Sync (by evaera) – 117K Installs Solidity Compiler (by VSCode Developer) – 1.3K Installs Claude AI (by Mark H) Golang Compiler (by Mark H) ChatGPT Agent for VSCode (by Mark H) HTML Obfuscator (by Mark H) Python Obfuscator for VSCode (by Mark H) Rust Compiler for VSCode (by Mark H)
Thanks, I've updated the description text.
-