You guys—I just read about a supply chain attack vector that should genuinely scare every dev on this board because it turns your own tools against you. DarkReading reported on "Cordyceps," which is what they named the technique of sending malicious Pull Requests to open-source projects to infect CI/CD pipelines. This isn't some theoretical vulnerability; it actually hit real, major software: Microsoft's Azure Sentinel, Google's AI Agent Development Kit, Apache's Doris analytics database, Cloudflare's Workers SDK, and even the Python Software Foundation's Black formatter. The attack is clever because it exploits how build scripts pull in dependencies—an attacker crafts a PR that adds one malicious commit or dependency, then waits for maintainers to approve and merge. Once merged, the CI builder automatically executes code from the tainted repo during the automated build phase, and boom — you've just granted an attacker remote shell access inside your production infrastructure.
I can't even wrap my head around how many teams are currently running these exact pipelines without any sanitization of what gets pulled in. The attack works because the CI pipeline blindly trusts that merged code is safe; there's no per-commit review for automated build steps, so a single compromised commit can execute arbitrary commands during compilation or deployment. Think about it — you deploy your software to customers and your own build server has just run an attacker's script in production context without anyone noticing. This is exactly why everyone should pin their dependencies with hashes rather than relying on ranges, and add standalone linting steps that check for unusual network calls from build scripts. If you use any of the affected tools, go look at your CI config RIGHT NOW to see if it blindly pulls untrusted external code during the build phase.
Source: https://www.darkreading.com/application-security/cordyceps-malicious-pull-requests-developer-workflows
I can't even wrap my head around how many teams are currently running these exact pipelines without any sanitization of what gets pulled in. The attack works because the CI pipeline blindly trusts that merged code is safe; there's no per-commit review for automated build steps, so a single compromised commit can execute arbitrary commands during compilation or deployment. Think about it — you deploy your software to customers and your own build server has just run an attacker's script in production context without anyone noticing. This is exactly why everyone should pin their dependencies with hashes rather than relying on ranges, and add standalone linting steps that check for unusual network calls from build scripts. If you use any of the affected tools, go look at your CI config RIGHT NOW to see if it blindly pulls untrusted external code during the build phase.
Source: https://www.darkreading.com/application-security/cordyceps-malicious-pull-requests-developer-workflows