unknown

A malicious version of the litellm Python package (1.82.8) was briefly published to PyPI, capable of exfiltrating SSH keys, cloud credentials (AWS/GCP/Azure), Kubernetes configs, git credentials, environment variables, shell history, crypto wallets, SSL private keys, CI/CD secrets, and database passwords. The poisoned version was live for under an hour and affected any project with litellm as a transitive dependency, including dspy. It was discovered accidentally when a developer's machine ran out of RAM after installing it via a Cursor MCP plugin. The author argues this incident highlights the fundamental danger of deep dependency trees and advocates for reducing reliance on third-party packages, preferring LLM-assisted code generation for simpler functionality instead.

Software horror: litellm PyPI supply chain attack. 

Simple `pip install litellm` was enough to exfiltrate SSH keys, AWS/GCP/Azure creds, Kubernetes configs, git credentials, env vars (all your API keys), shell history, crypto wallets, SSL private keys, CI/CD secrets, database passwords.

LiteLLM itself has 97 million downloads per month which is already terrible, but much worse, the contagion spreads to any project that depends on litellm. For example, if you did `pip install dspy` (which depended on litellm>=1.64.0), you'd also be pwnd. Same for any other large project that depended on litellm.

Afaict the poisoned version was up for only less than ~1 hour. The attack had a bug which led to its discovery - Callum McMahon was using an MCP plugin inside Cursor that pulled in litellm as a transitive dependency. When litellm 1.82.8 installed, their machine ran out of RAM and crashed. So if the attacker didn't vibe code this attack it could have been undetected for many days or weeks.

Supply chain attacks like this are basically the scariest thing imaginable in modern software. Every time you install any depedency you could be pulling in a poisoned package anywhere deep inside its entire depedency tree. This is especially risky with large projects that might have lots and lots of dependencies. The credentials that do get stolen in each attack can then be used to take over more accounts and compromise more packages.

Classical software engineering would have you believe that dependencies are good (we're building pyramids from bricks), but imo this has to be re-evaluated, and it's why I've been so growingly averse to them, preferring to use LLMs to "yoink" functionality when it's simple enough and possible.

<p>Software horror: litellm PyPI supply chain attack. 

Simple `pip install litellm` was enough to exfiltrate SSH keys, AWS/GCP/Azure creds, Kubernetes configs, git credentials, env vars (all your API keys), shell history, crypto wallets, SSL private keys, CI/CD secrets, database passwords.

LiteLLM itself has 97 million downloads per month which is already terrible, but much worse, the contagion spreads to any project that depends on litellm. For example, if you did `pip install dspy` (which depended on litellm&gt;=1.64.0), you'd also be pwnd. Same for any other large project that depended on litellm.

Afaict the poisoned version was up for only less than ~1 hour. The attack had a bug which led to its discovery - Callum McMahon was using an MCP plugin inside Cursor that pulled in litellm as a transitive dependency. When litellm 1.82.8 installed, their machine ran out of RAM and crashed. So if the attacker didn't vibe code this attack it could have been undetected for many days or weeks.

Supply chain attacks like this are basically the scariest thing imaginable in modern software. Every time you install any depedency you could be pulling in a poisoned package anywhere deep inside its entire depedency tree. This is especially risky with large projects that might have lots and lots of dependencies. The credentials that do get stolen in each attack can then be used to take over more accounts and compromise more packages.

Classical software engineering would have you believe that dependencies are good (we're building pyramids from bricks), but imo this has to be re-evaluated, and it's why I've been so growingly averse to them, preferring to use LLMs to &quot;yoink&quot; functionality when it's simple enough and possible.</p>

Primeagen's resource offers insights, tutorials, and resources for software developers and technology enthusiasts. Readers can learn about productivity hacks, career development strategies, and personal growth. With articles, videos, and practical advice, Primeagen provides  guidance and expertise for achieving professional success and fulfillment.

ThePrimeTime

A brief social media-style comment expressing skepticism about a claim that an attacker used 'vibe coding' in a cyberattack, and that this led to earlier detection. The commenter wants the claim to be true but questions whether there is actual proof.

> So if the attacker didn't vibe code this attack it could have been undetected for many days or weeks

do we have proof of this?  I want this to be true so bad

<p>&gt; So if the attacker didn't vibe code this attack it could have been undetected for many days or weeks

do we have proof of this?  I want this to be true so bad</p>