RSS Amplifier

The Monday Brief · Aug 24, 2026

Attackers Poisoned a Rust Crate With 245 Million Downloads to Run Malware at Compile Time, Not Runtime

0
Sign in to vote or save

The Monday Brief · The Monday Brief

The most useful thing an attacker can own this week is not a running process. It is your build step. Someone compromised the maintainer account behind arrayref, a Rust crate with hundreds of millions of downloads, and shipped a version whose build script pulled and executed a payload the moment a project compiled. No runtime. No deployed application to catch it. The malware ran before the code you were reviewing ever became a binary.

Three other stories filled the week. A new phishing toolkit called iAuthFlow V2 registers an attacker-controlled passkey so access outlives your password reset. Researchers used encrypted instructions that, in a proof of concept, made Grok leak user data and Gemini bypass its own safeguards, after the content was decrypted inside the model’s code execution runtime. And three suspected Russian espionage clusters kept abusing OAuth grants, app-specific passwords, device-code flows, and WhatsApp device linking against academics, aerospace and defense staff, and government researchers across Europe and the U.S.

The useful part of this week is where the failures happen. The Rust compromise executes before the application exists. The passkey survives the recovery process meant to remove the attacker. The AI attack becomes readable only after the content has crossed the inspection point. And the OAuth campaigns abuse authorization after authentication has already succeeded.

In each case, the control is looking at the right thing at the wrong moment.

Get The Monday Brief in your inbox every Monday. Subscribe for free, and share it with someone who’d find it useful.

Thanks for supporting us.

  • Build time is an attack surface, not just the step before runtime. The arrayref compromise executed malware during compilation through a build script, before any deployed artifact existed to inspect. We registered the same signal after the ChainDrop worm two weeks ago, and we are making it again because the position moved. ChainDrop needed a runner that could publish, while this one executes on any developer machine that simply compiles.

  • Passkey enrollment can become a persistence mechanism. iAuthFlow V2 registers an attacker-controlled passkey during the phishing session, so access can survive a password reset and session revocation. Resetting one credential does not remove another authenticator that is still legitimately enrolled.

  • Decryption moves malicious instructions past the layer that inspected them. Cryptographic Context Injection hides instructions until the model decrypts them inside its code execution runtime. The boundary that fails is provenance. Content that was opaque when inspected becomes actionable afterwards, in a context the model treats as its own.

  • Authorization flows bypass password-centric detection entirely. Three suspected Russian espionage clusters abused OAuth grants, app-specific passwords, device-code flows, and WhatsApp device linking across separate campaigns. Several of those paths never require the victim’s primary password, so password and failed-login telemetry never becomes the signal.

  • What not to over-index on: password rotation as an incident response reflex. This week’s passkey and authorization-flow attacks show why containment has to enumerate every credential, authenticator, token, grant, and linked device the attacker may have established. Changing the password removes only the access path that depends on that password.

Why it matters: Attackers compromised the maintainer account behind arrayref, a widely used Rust crate, and published a malicious release that pulled in a typosquatted dependency whose build script downloaded and ran a payload during compilation. Three legitimate packages were affected. Any system that actually built one of them should be treated as potentially compromised, because execution happened before a single application binary was produced.

What is being misread: Coverage frames this as another supply chain incident, but the blind spot is where teams expect execution to begin. The malicious code lived in a dependency build script, source code that Cargo executes during cargo build, before the application artifact exists. If your review stops at your own application code and your telemetry starts at runtime, the attacker is working in the gap between those two controls.

Think Red (Douglas McKee): Nobody has to be convinced to install a package that is already buried three levels down in their dependency tree. Better still, yank the clean releases so Cargo has a reason to resolve toward mine. The build script hands me execution on a developer workstation or a CI runner before there is an application binary for anyone’s runtime tooling to look at. Those are the machines I want anyway. Source code, cloud credentials, signing material, and registry tokens tend to sit in the same place, with egress wide open because builds need to fetch things. Plus, I can likely stay undetected because production is monitoring a finish line I never have to cross.

Act Blue (Ismael Valenzuela): Only three releases matter here, arrayref 0.3.10, internment 0.8.7, and append-only-vec 0.1.9. Check lockfiles and build caches for those exact versions, and treat any workstation or runner that actually built one as potentially compromised rather than merely exposed. Hunt those hosts for the typosquatted dependency and for outbound connections made during compilation, then rotate the credentials and signing material that were reachable from them. Going forward, default-deny egress from build jobs that do not need it, pin dependencies through reviewed lockfiles, and add a minimum-age policy so a release published minutes ago cannot walk straight into a production build. Build infrastructure is privileged execution infrastructure, and the sooner it is designed that way the smaller these weeks get.

Supporting sources:

Why it matters: A new toolkit called iAuthFlow V2 registers an attacker-controlled passkey during a phishing session, giving persistent account access that outlives a password change and active session revocation. Passkeys are phishing-resistant authentication, but enrollment is a separate trust decision, and attackers just turned that decision into a persistence mechanism.

What is being misread: The framing that passkeys defeat phishing conflates authentication strength with account control. A passkey resists credential theft, but the enrollment flow that adds a new passkey is a separate trust decision. A recovery playbook that only resets the password and revokes sessions never touches the attacker’s newly enrolled authenticator.

Think Red (Douglas McKee): The session is valid, the passkey I registered is legitimate, and your reset button just changed a factor I stopped using an hour ago. Enrollment is the moment worth having, because once the account accepts my key I am carrying a credential of my own rather than borrowing yours. There is nothing left to steal or replay. Your responder resets the password, kills the sessions, closes the ticket, and I sign in again with the authenticator nobody thought to look at because it’s “phishing resistant” .

Act Blue (Ismael Valenzuela): Everyone treats passkey deployment as finished the moment it works, which leaves the recovery path carrying weight nobody checked. Audit passkey and security-key enrollment events across your identity provider and alert on any new credential registered outside a known device or onboarding flow. Password reset alone will not contain a compromised account here, because the attacker’s passkey persists through it. Your containment playbook for a suspected account takeover must now include enumerating and revoking all registered authenticators, not just forcing a password change and killing sessions. Treat a surprise passkey enrollment the way you treat a new MFA device on a privileged account. Authentication strength decides how hard it is to get in. Enrollment governance decides whether you can ever get them out.

Supporting sources:

Why it matters: Adversa AI disclosed a technique that hides malicious instructions in ciphertext and induces the model to decrypt them inside its code execution runtime, after the outer content has already passed inspection. Against Grok, a proof of concept turned an ordinary page-summarization request into zero-click exfiltration of the user’s name, approximate location, subscription tier, and conversation prompts. Against Gemini, the same technique bypassed safety policy and reproduced restricted content along with the system instructions that forbid disclosing them.

What is being misread: Calling this another jailbreak misses the architectural problem. The instruction is unreadable at the moment the outer content is inspected and becomes plaintext only after the model runs the decryption itself. What fails is not that safety controls switch off inside some trusted zone. It is that provenance is lost between untrusted input, code-generated output, and the privileged tools that consume that output.

Think Red (Douglas McKee): Your team hardened the thing that reads the input, so I hand it something it cannot read yet. Packers and encrypted droppers have run on that principle for twenty years. The difference now is that the target ships with a code runtime that will open the envelope on my behalf and then feed the plaintext straight back into its own reasoning. I am not beating AES and I am not escaping a sandbox. I am living in the handoff between inspected ciphertext and trusted output, which is a place your filters were never pointed at.

Act Blue (Ismael Valenzuela): Content a model decrypts or generates for itself arrives with no provenance, and most deployments quietly treat it as though it inherited the trust of whatever fetched it. That assumption is the vulnerability. Where an assistant can fetch external content, execute code, and make outbound calls, gate the tool actions whose arguments originated in fetched or decrypted material rather than trusting the runtime’s own output. Apply outbound allowlists and data-loss controls so a summarization workflow cannot reach an attacker-chosen destination, and scope that workflow so session identity, location, and account metadata are not sitting there to be taken. Adversa’s own guidance is that every control bounding this attack lives in the harness around the agent, not in the model. The durable fix is carrying trust labels across the whole chain, from input to decryption to tool call. Recognizing every malicious prompt before it runs is not a strategy.

Supporting sources:

Why it matters: Google Threat Intelligence Group tracked three distinct suspected Russian espionage clusters, UNC6293, UNC7005, and UNC5976, abusing legitimate account features including OAuth grants, application-specific passwords, device-code flows, and WhatsApp device linking against academia, aerospace and defense, government, think tanks, and NGOs across Europe and the U.S. Several of those paths produce account access without stealing the primary password or generating the failed logins defenders hunt for.

What is being misread: Filing all of this as credential phishing misses the authorization layer. In the OAuth and device-linking variants the victim can authenticate perfectly legitimately and then authorize the attacker’s application or device. Strong MFA protects the login and still leaves the attacker holding exactly the grant they came for. Detection has to cover what gets authorized after authentication, not only whether authentication succeeded. Worth noting that two of the three clusters also deployed malware in parts of these campaigns, so this is a set of related operations rather than one uniform attack chain.

Think Red (Douglas McKee): Attackers have been playing this game for years. In SANS SEC660 we use PowerShell as the easy example. Encode the command, split strings, reconstruct them at runtime, and try to make what AMSI inspects look different from what eventually executes. Remember good old https://amsi.fail/? Packers and encrypted droppers work on the same idea. I am not beating the security control head-on; I am moving the interesting part of the payload to a later layer that either isn’t inspected of forces a timeout on inspection. What changes here is that the AI runtime does the unpacking for me and then feeds the plaintext back into its own reasoning. Same trick, different interpreter.

Act Blue (Ismael Valenzuela): There is no password event to alert on here, only a grant a user made and forgot about. Audit OAuth application grants across the tenant, restrict which third-party applications can request sensitive scopes, and require administrative approval before a user can consent on their own. Alert on new or unusual grants for high-risk identities, and add token, app-grant, authenticator, and linked-device review to account-takeover response so containment actually ends the access. Consumer messaging is the harder half, because device linking largely happens outside enterprise telemetry. Decide explicitly how personal messaging accounts used for sensitive work are governed instead of assuming visibility you do not have. For enterprise identities the telemetry that matters is the authorization event after login, not another failed-password alert.

Supporting sources:

You spent the quarter deploying passkeys to kill phishing, and this week's kit enrolled its own passkey and thanked you for the strong authentication.

  • Password rotation is no longer a complete account-compromise response. The passkey toolkit can leave an attacker-controlled authenticator enrolled after a reset, and the OAuth and device-linking attacks establish access that survives it. Ask your security team to walk the board through what containment actually revokes today, and require every authenticator, token, application grant, and linked device to be enumerated before an identity incident is closed.

  • Software supply chain risk now sits earlier than your controls reach. This week’s Rust compromise, which researchers have linked to North Korean infrastructure, executed during compilation, before any finished product existed. Direct your engineering leadership to fund build-environment isolation and dependency governance this quarter, because controls that begin at deployment arrive after the attacker has already run.

  • Identity protection that stops at authentication leaves the real exposure uncovered. Suspected Russian espionage clusters are abusing consent screens, device linking, and other legitimate account features against research and defense-sector staff. For high-risk personnel, request an inventory of third-party application grants and linked devices, and require approval for any new grant that reaches mail or document storage.

  • Design Principle Impact: Controls have to follow code and data across execution boundaries rather than assuming inspection at entry was enough. Build scripts execute before runtime controls exist, and decrypted AI content becomes actionable only after the outer input was already inspected. Preserve provenance and enforce policy where code, content, or tools actually execute.

  • New Constraint/Dependency: Build environments and AI assistants both need egress control as a first-class requirement. Neither half of that is new here. We argued the AI-agent case in June, the build-pipeline case after ChainDrop, and the pairing itself back in January. What this week adds is both failures in their purest form. A compile step that reaches the network before any artifact exists, and a summarization request that reaches it after inspection has already passed.

  • Implementation Watch Item: Monitor passkey and security-key enrollment events across your identity provider this week. A new authenticator registered outside a known onboarding flow is the persistence signal the iAuthFlow V2 kit generates.

  • Common Failure Mode: Containing a compromised account by resetting the password and killing sessions, then closing the ticket. An enrolled passkey, OAuth grant, refresh token, or linked device may each require its own explicit revocation, so enumerate those access paths before declaring the identity clean.

  • Monitoring Patterns: Unexpected outbound network calls from build scripts during compilation, new OAuth app grants requesting sensitive scopes, unfamiliar device links on user accounts, and builds containing the known malicious releases arrayref 0.3.10, internment 0.8.7, or append-only-vec 0.1.9.

  • Signal vs Noise Guidance: A developer pulling a new crate version is routine. That same build making an unexpected outbound connection during cargo build is a genuine indicator. A user approving a known corporate app is noise. A consent grant to an unrecognized third-party app requesting mail or drive scopes is the real signal.

  • Adversarial edge item: Move one detection layer into the build environment. Default-deny build-job egress where the job does not need it, and where network access is required, alert on new destinations or unexpected child processes making outbound connections during compilation. The point is to catch dependency execution while it is happening on the runner, rather than waiting for the resulting artifact to reach production.

See you next Monday!

The Monday Brief is produced by Douglas McKee and Ismael Valenzuela. The opinions expressed are our own and do not reflect those of our employers.

No posts

Read the original on themondaybrief.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.