What if the BEAM ecosystem got hit by a worm?

The first clue is almost invisible.

A developer kicks off a routine build: mix compile. Everything passes. But in the flood of log lines, a message appears that no one remembers writing. It looks technical, harmless — gone before they can copy it. They shrug. Builds are noisy.

By late morning, another developer opens a pull request. The CI pipeline takes a little longer than usual. Nothing fails. Green checkmarks all around. But buried in the logs, one warning looks… off. It mentions an internal module they’ve never seen before.

“Has anyone else noticed this?” they ask in the team channel, attaching a screenshot.

Most people scroll past. One replies: “Probably just a transient thing. Let’s keep an eye on it.”

You, the person on call for security this week, make a note. Nothing urgent — yet.

Then things escalate. A second project shows the same odd line in its build logs. Different team, different repository, but the same dependency has just released a new patch version. Within hours, the maintainer pushes two more “hotfix” releases. Fast. Too fast.

At 16:00, the first real alarm rings: cloud credentials used from an unusual location. At 16:30, someone spots a new GitHub workflow file committed to a repo without explanation. By 17:00, you’ve connected the dots: these incidents trace back to the same freshly updated Hex packages.

What began as a strange log line is no longer a curiosity. It’s the start of a worm.

When the worm spreads

At first it’s just your team’s builds. But then reports start surfacing elsewhere.

On the Elixir Forum, another developer posts: “Anyone else seeing strange behavior after today’s updates?” Replies pour in within minutes. It’s not just you.

• A payment processor notices phantom transactions. Their system, built on BEAM, is leaking credentials.
• A logistics company’s routing service starts failing — trucks sit idle while packages pile up in warehouses.
• A streaming platform goes offline during peak hours because a key dependency won’t start without “phoning home.”

Then the worst notification hits your desk: wallets draining from your company’s crypto platform. Real money vanishing. Every second means more losses.

You freeze deploys, rotate keys, pull dependencies. Too late. The worm has already spread beyond your reach.

This could happen here

Last month, this did happen elsewhere. A worm started with a stolen publish token, slipped a malicious payload into a popular package, and spread by harvesting tokens from build systems. Within a day, hundreds of packages were infected (StepSecurity analysis).

Could the BEAM world (Erlang, Elixir, Gleam) face the same? Yes. We’re smaller, which helps — projects here tend to have fewer transitive dependencies than in ecosystems like npm. That makes blind compromise through deep dependency chains less likely. But it also gives a false sense of safety. One compromised, widely used package could still ripple through hundreds of projects. And we lack defenses that bigger ecosystems are already building.

We’re not alone in this. Every open-source ecosystem — from npm to PyPI to crates.io — faces the same class of supply-chain risks. The difference is simply whether the defenses are in place before or after the first big incident.

Today’s reality:

• Account security: 2FA optional, not enforced. No WebAuthn.
• Publishing: Long-lived API keys in CI. No trusted publishing (short-lived OIDC tokens) at all.
• Scanning: No automated malware detection at publish time.
• Provenance: No package signatures or build attestations.
• Warnings: No registry-fed alerts in mix or rebar3.

The good news: a plan exists

The Erlang Ecosystem Foundation’s Ægis Initiative is our roadmap to change the ending:

• WebAuthn-backed 2FA, required for publishers.
• Trusted publishing via CI, no static keys.
• Sigstore/SLSA provenance to verify builds.
• Registry scanning and advisories surfaced in tooling.
• Transparency logs and SBOMs for visibility.

Together, these measures make an incursion harder in the first place. And if one does slip through, stronger authentication, early detection, and the tools we’re building — backed by the EEF’s role as a CNA — give us the ability to react properly and stop it before it spreads too far.

But none of this builds itself. Some work has started; much more needs funding.

How to help

If your company runs BEAM in production, sponsoring Ægis is not charity — it’s insurance against the day the scenario above stops being fiction.

👉 Learn more and sponsor milestones: Ægis Security Initiative

We’ve been lucky so far. But luck runs out — and worms don’t knock before they enter. Fund prevention now, or face the worm later.