crates.io dependency-confusion burst — 9 Rust crates targeting AWS, Mysten Labs, Replit, Proton, plus 4 generic-name typosquats, all flagged by OpenSSF Package Analysis on 2026-07-18

What happened

On 2026-07-18 the OpenSSF Package Analysis project — the automated malware-detection pipeline that watches every new crates.io / npm / PyPI / RubyGems / NuGet publish for behavioral signals — flagged 9 Rust crates as malware and pushed advisories through to the GitHub Advisory Database. Every advisory uses the same CWE-506 (Embedded Malicious Code) classification with the two OpenSSF signal boilerplates: "The package communicates with a domain associated with malicious activity" and "The package executes one or more commands associated with malicious behavior." crates.io yanked every listed crate; no patched version exists.

Cluster 1 — Enterprise dependency-confusion pins (5 packages)

| Crate | Versions | GHSA | Target | |---|---|---|---| | mysten-metrics | 9.0.0, 9.0.3 | GHSA-4vwj-fpjf-wmmg | Mysten Labs / Sui blockchain internal instrumentation crate | | amzn-codewhisperer-streaming-client | 99.0.1 | GHSA-92vh-m3v8-jv6h | Amazon proprietary — AWS CodeWhisperer streaming client | | amzn-consolas-client | 99.0.1 | GHSA-7jx2-pf66-g5qj | Amazon proprietary — AWS Consolas internal service client | | replit_ruspty | 1.0.0 | GHSA-943g-w75h-8v9h | Replit's Rust PTY utility (name uses underscore; canonical is ruspty) | | proton-pfff | 99.99.5 | GHSA-2c45-qvwj-8jfx | Proton internal utility (naming shape matches Proton Mail / VPN Rust codebase) |

The 99.x.x and 9.0.x version numbers are the fingerprint of a dependency-confusion pin: pick a version number higher than any plausible internal semver so cargo with a misconfigured registry order picks the public crates.io tarball over the private registry. The mysten-metrics 9.0.x pin is unusual for the pattern (real Mysten internal instrumentation runs at much lower version numbers) — the operator here either knew the internal semver was ~8.x or is running a narrower catchment. For the amzn-* and proton-* crates, the 99.x.x catch-all approach is the standard dep-confusion default.

The presence of two Amazon proprietary internal crate names (amzn-codewhisperer-streaming-client, amzn-consolas-client) targeted in the same burst suggests the operator has visibility into Amazon's internal Rust dependency graph — a leaked internal package list, an OSS build log, or a former employee. The precision of the naming (not "amzn-codewhisperer" but the exact -streaming-client suffix that matches Amazon's internal crate) is inconsistent with a random dictionary attack.

Cluster 2 — Generic-name typosquats (4 packages)

| Crate | Versions | GHSA | |---|---|---| | semantic-search-client | 99.0.1 | GHSA-jfw2-4jxj-8f9c | | supertag | 99.1.1 | GHSA-ppxc-v5qv-9fm6 | | lsh | 99.0.1, 99.1.0 | GHSA-ffmx-5mf5-q3hc | | littest | 0.3.1 | GHSA-9cpx-g2hc-4j42 |

semantic-search-client and supertag follow the same 99.x.x dep-confusion pattern targeting whichever internal package matches the name — the operator is casting a wider net here, hoping a random enterprise has an internal crate under one of these generic slugs. lsh and littest do not use the 99.x.x pattern; both use normal-looking version numbers, which fits a classical name-collision typosquat rather than a dep-confusion race. lsh in particular has legitimate benign homonyms (a small utility crate for list-set operations) — an operator picking this exact name is trying to catch developers who search for the benign crate by memory.

Attack signature — OpenSSF Package Analysis behavioral flags

Every advisory in this burst was flagged by the OpenSSF Package Analysis pipeline, not by a security-vendor blog post. The two behavioral signals reported are:

1. "The package communicates with a domain associated with malicious activity" — the crate's build.rs (or a runtime dependency's) opens a network connection to a domain on the OpenSSF known-bad list within seconds of installation.
2. "The package executes one or more commands associated with malicious behavior" — the crate spawns a shell subprocess (or invokes a syscall pattern that matches a known malware fingerprint) during install or first-use.

OpenSSF Package Analysis does not publish per-crate technical breakdowns (no C2 domain, no command line) in the GHSA record. The raw analysis output is in the OpenSSF malicious-packages repository under the corresponding crate name, but detail depth varies. For any concrete impact investigation, defenders should treat every crate in this burst as a full RCE payload and rotate any credential the build host could reach.

Registry state

All 9 crates have been yanked from crates.io. cargo treats yanked crates as unresolvable for new builds but WILL keep resolving them for lockfiles that were generated before the yank — so a Cargo.lock from 2026-07-18 or earlier that pins any of these names will still download the malicious tarball if the local ~/.cargo/registry/cache was cleared. Private registry mirrors (Artifactory, Nexus, Sonatype) do NOT propagate crates.io yanks and will keep serving the tarballs until you explicitly evict them.

Comparison to earlier crates.io incidents

This is the third major crates.io malware burst of 2026 after the Polymarket SDK typosquats in February and the time utility typosquats later that month. Unlike those earlier campaigns — which targeted specific ecosystem clients — this July burst is a mixed portfolio: 5 enterprise dep-confusion pins against Amazon / Mysten / Replit / Proton internal names, plus 4 generic-name catchments. The operator appears to be running a broader reconnaissance sweep rather than aiming at a single ecosystem's users.

Affected packages (9)

Impact

• Any host that installed any of the 9 Rust crates below should be treated as fully compromised — every GHSA record flags OpenSSF Package Analysis signals communicates with a domain associated with malicious activity and executes one or more commands associated with malicious behavior, no patched version exists, and the crates are unrecoverable (crates.io yanks are permanent — the tarballs are gone from the public registry but private mirrors may still cache them)
• Enterprise dependency-confusion pins (5 packages): mysten-metrics@9.0.0,9.0.3 (Mysten Labs / Sui blockchain internal utility), amzn-codewhisperer-streaming-client@99.0.1 (AWS CodeWhisperer client — Amazon proprietary internal crate), amzn-consolas-client@99.0.1 (AWS Consolas internal service client), replit_ruspty@1.0.0 (Replit's Rust PTY tool), proton-pfff@99.99.5 (Proton internal utility). The 99.x.x and 9.0.x version numbers are the fingerprint of a dependency-confusion pin: pick a version higher than any plausible internal semver so a cargo build with a misconfigured registry order picks the public crates.io tarball over the private registry's
• Generic-name typosquats (4 packages): semantic-search-client@99.0.1, supertag@99.1.1, lsh@99.0.1,99.1.0, littest@0.3.1. semantic-search-client and supertag follow the same 99.x.x dep-confusion pattern targeting whichever internal package matches the name; lsh (name collision with a real, benign crate that provides list-set utilities) and littest are more classical name-collision typosquats
• Every impacted host has already executed the malicious payload — the OpenSSF Package Analysis findings ("communicates with a domain associated with malicious activity") indicate the crate contacted attacker infrastructure the first time cargo build resolved it. A build cache (~/.cargo/registry/cache) holding a downloaded tarball is a strong indicator that install-time execution completed
• Amazon proprietary internal crate names (amzn-codewhisperer-streaming-client, amzn-consolas-client) being targeted this specifically indicates the operator has visibility into Amazon's internal Rust dependency graph — a leaked internal package list, an OSS build log, or a former employee is the most likely source
• The Mysten Labs mysten-metrics name matches the real internal instrumentation crate used across the Sui blockchain codebase — any Sui-adjacent Rust project resolving mysten-metrics from crates.io instead of from Mysten Labs' internal registry has now installed the payload

What to do

1. 1Grep every Cargo.toml and Cargo.lock for each name in the packages map below. Any match is a supply-chain incident: rotate every credential the build runner could reach and re-image the build host
2. 2If you had mysten-metrics in a Cargo.lock: this indicates a misconfigured internal-registry resolver for a Mysten Labs / Sui integration. Audit your .cargo/config.toml to ensure [source.crates-io] is not preferred over your private registry for Mysten Labs' internal crate names. Rotate any Sui / Mysten API keys the build environment could reach
3. 3If you had amzn-codewhisperer-streaming-client or amzn-consolas-client in a Cargo.lock: these are Amazon proprietary internal crate names — the presence of a public crates.io resolution for either is definitionally a dep-confusion compromise. Escalate to Amazon Security and rotate any AWS credentials, IAM roles, and CodeWhisperer / Consolas API keys the affected host had access to
4. 4If you had replit_ruspty in a Cargo.lock: replace with the canonical ruspty upstream, review your build host for shell activity during the compromise window, and rotate every credential the Replit workspace could reach
5. 5If you had proton-pfff in a Cargo.lock: this maps to a Proton (Proton Mail / Proton VPN) internal crate name. Escalate to Proton Security if you were doing an integration; rotate any Proton API keys the build environment could reach
6. 6For any of the generic-name crates (semantic-search-client, supertag, lsh, littest): remove the dependency, audit for legitimate first-party parents (lsh in particular has legitimate benign homonyms — verify you were not targeting one of them), and rotate every credential the CI environment could reach
7. 7Verify none of the 9 listed crates still resolves via your private mirror — internal Artifactory / Nexus / Sonatype instances routinely cache crates.io tarballs and will keep serving the malicious versions after the public yank. Cargo does not honor crates.io yanks against a private mirror
8. 8Run cargo audit in CI against the RustSec advisory database — the OpenSSF Package Analysis feed and GHSA records feed into RustSec within 24-48 hours

References

• GitHub Advisory Database — recent Rust malware advisories

  github.com
  GitHub
• GHSA-4vwj-fpjf-wmmg — mysten-metrics malware advisory

  github.com
  GitHub
• GHSA-92vh-m3v8-jv6h — amzn-codewhisperer-streaming-client malware advisory

  github.com
  GitHub
• GHSA-7jx2-pf66-g5qj — amzn-consolas-client malware advisory

  github.com
  GitHub
• GHSA-943g-w75h-8v9h — replit_ruspty malware advisory

  github.com
  GitHub
• GHSA-2c45-qvwj-8jfx — proton-pfff malware advisory

  github.com
  GitHub
• GHSA-jfw2-4jxj-8f9c — semantic-search-client malware advisory

  github.com
  GitHub
• GHSA-ppxc-v5qv-9fm6 — supertag malware advisory

  github.com
  GitHub
• GHSA-ffmx-5mf5-q3hc — lsh malware advisory

  github.com
  GitHub
• GHSA-9cpx-g2hc-4j42 — littest malware advisory

  github.com
  GitHub
• OpenSSF Malicious Packages repository

  github.com
  OpenSSF