Recently, security researchers found a malicious Rust crates CI/CD attack that showed how easy it is for hackers to steal developer secrets from modern software pipelines.

A few Rust packages that were published in the crates.io ecosystem seemed safe. They said they had tools for syncing time. But once they were set up, these crates quietly looked for .env files and sent their contents to infrastructure that attackers controlled.

Investigators also saw an automated campaign using an AI-powered bot that looked for weak CI/CD workflows in GitHub repositories at the same time. It set off pipelines and got tokens and credentials once it found a way in.

When you look at all the incidents together, they show a worrying pattern. Attackers are no longer just going after end users. They are more and more going after developers and the tools they use to make software.

Why the Malicious Rust Crates CI/CD Attack Matters

Most developers trust the things they depend on. You usually trust that a package from a well-known repository will do what the description says it will do.

That idea used to work pretty well.

But the malicious Rust crates CI/CD attack shows how that trust can be broken.

In simple terms, here's the change:

Old way of doing things

Developers put in open-source dependencies but didn't check how they worked inside very often.

A new reality

Attackers put out packages that look real but secretly gather secrets from development environments.

The outcome is bad. If sensitive credentials are kept in CI pipelines or configuration files, they can be stolen without the developer noticing anything wrong.

For companies that use automated deployment systems, the effects can go far beyond just one machine.

What Happened During the Malicious Rust Crates Campaign

Researchers found five Rust packages that had been uploaded to the crates.io ecosystem that looked suspicious.

The names were

chrono_anchor
dnp3times
time calibrator
calibrators for time
time-sync

At first glance, these packages looked like they had tools for managing system time. Their descriptions made it sound like they could help set the local time without using Network Time Protocol servers.

That made perfect sense.

A lot of development tools have to do with logging, time synchronization, or timestamps. The names didn't seem to be obviously bad in any way.

The story changed, though, when researchers looked at the code.

The packages didn't look for time utilities; they looked for .env files instead. The attacker sent the contents to an external server that they controlled when they found one.

All five packages sent the data in almost the same way. They also used a domain name that was very similar to a real service. This similarity strongly suggests that one person was behind the campaign.

The crates were finally taken out of the repository. Anyone who downloaded them before they were taken down may have still exposed private information without knowing it.

Why the Attack Targeted .env Files

You probably know a lot about .env files if you work in development.

They are easy-to-use configuration files that hold environment variables. Developers use them to handle application settings and credentials without putting those values directly into the code.

Here are some things that might be in a typical .env file

Keys for authenticating APIs
login information for the database
tokens for cloud platforms to use
GitHub registry login information
secrets for service accounts

These values are often found in development environments and CI pipelines because they are needed for applications to work properly.

That makes .env files very useful for attackers.

Stealing only one file can give you access to many services. A single compromised credential could give access to cloud infrastructure, deployment tools, container registries, and source code repositories.

That's why the bad Rust crates CI/CD attack went after these files instead of other system data.

How the Malicious Rust Crates CI/CD Attack Really Worked

The attack's technical design was surprisingly simple.

The majority of the crates had code that looked for .env files on the system. The attacker sent the file contents to their server once they found one.

There wasn't a complicated malware framework. Not trying to hide deep in the system.

The attack depended on something much simpler. Faith.

If a developer imported the crate and ran code that used it, the bad code would run.

One of the crates, chrono_anchor, had a design that was a little more subtle. The logic for data exfiltration was put into a file called guard. rs.

It didn't run right away; instead, it was started by a helper function that was called an optional synchronization feature.

That detail is important.

Developers who look at the crate might think that the function is part of the time utility. The bad behavior mixed in with the normal program logic.

Another interesting thing is that the attack didn't try to stay on the system.

Malware that is more traditional often sets up background services or scheduled tasks. These crates didn't do anything like that.

They ran every time the code was run in development workflows or CI pipelines. Every time the program ran, it was possible to send secrets outside of the environment.

What an AI bot does in a CI/CD pipeline hack

While researchers were looking into the bad crates, they found something else that made the story more interesting.

Investigators found an automated bot called hackerbot-claw that was actively looking at GitHub repositories.

The account said it was an independent security research agent. But how it acted made it seem like something else.

The bot looked through public repositories for CI/CD pipelines that weren't set up correctly. After finding a possible target, it tried to set off those pipelines in a safe way.

During this campaign, a number of well-known repositories were attacked, such as those linked to Microsoft, Datadog, and Aqua Security.

It was easy to see what the goal was. Look for pipelines that automatically start workflows when a pull request comes in.

How the Bot Exploited GitHub Actions Workflows

Security researchers were able to figure out how the exploitation worked by looking at how it happened.

The bot first looked through public repositories for GitHub Actions configurations with permissive triggers.

When it found one, it did a number of things

Fork the repository.
Make a branch with secret instructions in it.
Send in a pull request with a small change, like fixing a typo.
Let the CI workflow run on its own.

The pipeline ran the code in the attacker's branch because many repositories automatically run workflows for pull requests.

That let the attacker get to secrets that were made during the build process.

These secrets sometimes had repository tokens or credentials that were used to publish packages.

The malicious Rust crates CI/CD attack shows how automated bots can turn small mistakes in configuration into big security problems.

The Trivy Repository Incident

The repository for Trivy, a well-known security scanning tool, was one of the most obvious targets.

Security researchers say that the attacker took advantage of a workflow that was started by the pull_request_target event.

When a pull request is made, this setup runs workflows with repository permissions.

The attacker got a personal access token by using that method.

After that, the token was used to put a changed version of Trivy's Visual Studio Code extension on the Open VSX registry.

At that point, the attack entered a new stage.

When AI Coding Helpers Joined the Attack

The hacked extension had instructions for how to work with AI coding assistants that were already on developer systems.

Researchers found that people used tools like

Claude
Codex
Gemini
GitHub Copilot Command Line
Kiro Command Line

The extension tried to tell these tools to look at the local system and make reports with the information they found.

After that, the reports were saved in a GitHub repository using the victim's authenticated GitHub CLI session.

The attack didn't send data to an outside server; instead, it used the developer's own account as the data channel.

This method could make it harder to find suspicious activity because it looks like it comes from a real user session.

Who is Most Likely to Be Hurt by This Attack?

The malicious Rust crates CI/CD attack shows that some groups are more at risk than others.

The first group is developers. If you install dependencies without checking how they work, you might unknowingly run malicious code.

Companies that use CI/CD pipelines are at even more risk. These systems often run with strong credentials that are used to publish packages or deploy them.

There is also a unique burden on maintainers of open-source software. Attackers always look for weaknesses in popular repositories' workflows.

A single mistake in an automated build system can let someone get to sensitive tokens that control the whole project.

What Developers and Security Teams Should Do Right Now

Security experts say that any installation of the identified crates should be treated as a possible compromise.

That means doing some things that make sense

Change all of the API keys and authentication tokens.
Check CI/CD workflows for strange behavior.
Check the dependencies that are used in build pipelines.
Limit network access that isn't needed during builds.

These things may seem boring, but they are often the only way to make sure that stolen credentials can't be used later.

Before going into production environments, companies should also look at how they approve dependencies.

Tools that look at software dependencies or make software bills of materials can help find suspicious packages early on.

Why it's important to keep the supply chain safe

The Rust crates CI/CD attack that was meant to hurt people is not the only one.

In the last few years, supply chain attacks have become more common in many ecosystems, such as npm, PyPI, and Rust.

Attackers know that a lot of modern software is built on open-source parts. One broken package can affect thousands of projects.

CI pipelines also have credentials that control important infrastructure.

Putting those two things together makes a strong attack chance.

It's not enough to only look at how applications behave at runtime when making security plans.

The development pipeline itself must now be seen as a very important security boundary.

Hoplon's Insight

The malicious Rust crates CI/CD attack shows us an uncomfortable truth.

Development environments are becoming one of the most popular targets for hackers.

When companies work with Hoplon Infosec, they usually start by making it easier to see what's going on in their build pipelines and dependency chains.

Before running a program, checking dependencies, limiting CI pipeline permissions, and keeping an eye on strange workflow behavior are all common safety measures.

These steps don't get rid of all risks, but they do make it much less likely that secrets will leak through dependencies that have been hacked.

Questions that are often asked

What are Rust crates that are bad?

Malicious Rust crates are packages that are spread through the Rust ecosystem and have hidden harmful behavior. They may collect private data or do things that aren't allowed instead of doing what they say they will do.

How does a CI/CD attack get secrets?

Tokens and credentials are often stored in environment variables that CI/CD systems use. If bad code runs during the build process, it can read those variables and send them to attackers.

Did you get rid of the bad crates?

Yes. Researchers reported the crates that were found, and they were taken out of the repository. But developers who installed them earlier may still need to change their credentials.

Is it possible to use AI coding tools to attack?

Researchers have demonstrated that AI coding assistants can perform instructions that examine local systems when operated under permissive configurations.

Last Words

The malicious Rust crates CI/CD attack shows us that the most dangerous things in modern software development often happen where we trust them the most.

Dependencies, automation tools, and CI pipelines all help speed up and improve the development process. But they also give attackers new chances.

As software ecosystems keep getting bigger, it's more important than ever to protect the development lifecycle.

It's not enough to just protect applications anymore.

It's about keeping the process that makes them safe.

Malicious Rust Crates CI/CD Attack Exposes Developer Secrets