Rust project warns of coordinated attacks on prominent developers
The Rust Foundation alerts crate owners and team members to a campaign using fake job offers and impersonated companies to compromise accounts.
What to know
- Rust developers and crate maintainers are being targeted by a coordinated social engineering campaign using fake job offers and impersonated companies to compromise accounts and publish malware.
- Attackers use video calls to trick targets into installing malicious payloads disguised as missing codecs or clipboard commands, leveraging fake LinkedIn profiles to establish credibility.
- The Rust team recommends enabling MFA, verifying account activity, being suspicious of cold outreach, and initiating any calls with new contacts on trusted platforms.
“A video call is set up for something positive — maybe for a job, maybe for a project, maybe for a contract opportunity — and then that's used as a vector to either get the target to install something on their computer (such as a purportedly missing audio codec) or execute another command.”
Rust project, Security issuer · Rust Blog · Sep 16
Rust project / Rust Foundation Security issuer
How it unfolded 1 development · click the chart to see its coverage posts
-
1
Rust team issues mitigation guidance and support contacts
The project advised developers to enable MFA, verify account logins, be suspicious of unsolicited contacts, and to reach out to help@crates.io or security@rust-lang.org if they had account concerns.
“Be appropriately suspicious of cold outreaches, and ensure that any calls you have with new people are on platforms you trust — ideally, try to be the one who sets up the call on a platform you already use.”
— Rust project -
R
⚠️ We believe that there is an ongoing campaign targeting owners of popular crates and rust-lang team members that is attempting to compromise devices and accounts in order to use them to publish malware. See our blog post for details: https:// blog.rust-lang.org/2026/09/17/ targeted-attacks/
2 more of the top 3 · 43 posts in this stretch
-
recently, systemd-the-organisation looked at introducing rust as a part of systemd-the-init. luca boccassi, one of the senior maintainers[1] of systemd-the-both, [raised some good points about it](https://github.com/systemd/systemd/pull/43551#issuecomment-5445121831). i've stripped what i'll describe as somewhat _extreme_ exaggerations around…
-
It's not a bad design choice just because it has consequences. Rust also doesn't have the financial backing of languages that seem to be able to afford a kitchen sink in their std lib. Python also suffers from stdlib rot from people not maintaining parts of it, and C++ can't fix their stdlib speed deficiencies because of ABI issues and backward…
-
-
background
Attackers use fake company profiles to appear legitimate — The advisory detailed that attackers create new company profiles with plausible LinkedIn presences designed to pass initial scrutiny, allowing them to initiate seemingly professional contact with Rust developers.
-
background
Rust project discloses coordinated malware campaign targeting developers — The Rust project published a security advisory warning of an ongoing campaign targeting rust-lang members and owners of popular crates. The attackers set up video calls under pretenses of job offers, projects, or contracts, then use those calls to socially engineer targets into installing malware or executing commands via fake audio codecs or clipboard manipulation.
What people are saying 21 voices from 3 sites · best of 43 · verbatim
- Sep 20
-
C
The Rust team warns of a social engineering campaign targeting core members and owners of popular packages https:// blog.rust-lang.org/2026/09/17/ targeted-attacks/
- Sep 19
-
If systemd is happy to reinvent the C wheels, they should have no problem reinventing the Rust wheels. So their "Rust pulls in too many deps" argument falls flat ?
-
Wait, wasn't the best language with the brightest future among all the other languages? The rust fanatics have beeing saying so for so much long time
- Sep 18
-
> That being seemingly acceptable for an LSP server has honestly turned me off the entire LSP ecosystem. This is absolutely not a flaw with LSP; it's a flaw with specific LSP servers, most prominently rust-analyzer and elixir-ls. There are lots of LSP servers that don't have this problem, (at the risk of no-true-scotsman, I'd say every good LSP…
-
XML is still used today, in fact I've made multiple commits to different XML files this week alone. In fact, I've found it easier to work on with AI. I don't see XML going anywhere anytime soon.
-
> This is a mess but mostly it is not a PL problem. It is a build system problem with some ramifications into PL/compilers. I think there would be less of a mess if there were more capability-oriented library design, such that code could be sandboxed without heavyweight virtualization (no need for hardware VMs or OS containers or restricted…
-
> Instead of just blindly downloading the latest version the package author has uploaded My `Cargo.toml` for applications are generally very specific on which version they rely on, and rely on my `Cargo.lock` to make updates an explicit step. cargo is not updating dependency versions behind your back, it requires either explicit steps (manually…
-
That is the argument against using dependencies — there is also an argument for using them, and the optimal point on the spectrum is somewhere in between, to the right of most C projects but to the left of many Rust projects.
-
I agree that the culture of implicitly trusting large numbers of dependencies¹ is dangerous. > i'm unsure there is a way "out" at all, really, especially as both programs and programming have become more and more complex. I think that the best available approximation of a way out is to replace implicit, unexamined trust in dependencies with using…
-
The C ecosystem only fares as well as it does because it did so badly upstream that the distros had to develop their own C package managers... and the assumptions they make about dynamic linking and build processes do very much make them C package managers. (See…
-
The systemd repository contains quite a large number of things, a lot of them implemented from first principles in order to avoid failure cases in existing solutions or libraries (and probably ending up discovering others :D). So that's the main reason it's that large. And I think it also clarifies that for low level code it's wiser for a project…
-
Do you think that's hyperbole when we're discussing dependencies in the hundreds? I just cloned the `systemd` repo, it contains over 1M lines of just C code.
-
Beyond modularity, they also speed up the build process, sometimes significantly. Naively counting dependencies is a terrible metric to base opinions on; the alternative is: do **you** want to write the hundreds of thousands of lines of code you're depending on instead?
-
Ironically, the C ecosystem fares really well here, since I can just use my distro's package manager to manage dependencies. Instead of just blindly downloading the latest version the package author has uploaded, it's subject to my distro's policies - and I even get the choice of which distro's policies I prefer! Debian Stable keeps packages…
-
> every now and then i'm reminded of the build.rs file[2] and how normalised it is, even to me, and it makes me shiver a bit. I don't think there's anything wrong with running arbitrary code during the build. If you're a developer, you're almost certainly building the package with the intention to run it right after. If you're a distro maintainer…
-
So... This is a mess but mostly it is not a PL problem. It is a build system problem with some ramifications into PL/compilers. But mostly it is a build system problem. And largely a build systems interactions with other build systems problems. And the sad reality is that there is a lot of work to be done there. But there are no easy solutions…
-
I’d recommend posting the output of the dependency analysis somewhere—they can be pretty subtle and I don’t think the count of dependencies is always that helpful. For instance, sometimes a single project will distribute 10 or 20 crates because they make the crates modular.
-
Dependency Cooldowns in Rust: https://cooldowns.dev/#cargo (And other programming languages)
- Sep 17
-
Any config file these days will be JSON. Serializing objects to disk? Json. Python, PHP, java, go, ruby, c# and and ofc JS all ship json in their stdlib. The question is really: which languages don't ship json parsing
-
This is legitimately scary. Any piece of software that depends on open source (which is almost *every* piece of software) has a network of human beings who are potential attack vectors - everyone with publishing rights to any of the packages in the dependency network for that software. I guess our best defense right now is [dependency…
-
Wow. I'm not in any way prominent, but I'm glad I'm already doing things which would make me think twice about something like a "missing codec" message, and treating cold outreach as inherently spammy/scammy. Now to expedite retrofitting my development setup so my only Rust toolchains exist inside Docker containers so I can trust that I don't…