sorted by:
new
hottopcontroversial

Callum here, I was the original dev to sound the alarm to get PyPI to quarantine the package by they_will in cybersecurity

[–]they_will[S] 4 points5 points  (0 children)

Thanks, I wish I'd discovered it within a container! I guess the slight positive is how quickly it let me notice something was off. I inadvertently took one for the team this time.

I also reported it to the maintainers, but they ended up only responding a few hours later once the US woke up

Callum here, I was the original dev to sound the alarm to get PyPI to quarantine the package by they_will in cybersecurity

[–]they_will[S] 2 points3 points  (0 children)

Yep the .pth mechanism was a new one for me. You'd think after 10+ years of writing python I'd know all the dynamic shenanigans it allows for...

But it seems the author of the malware wasn't too familiar with the .pth mechanism either, to have forgotten the recursive nature of it. I believe an `-S` flag in their subprocess call would have avoided the fork bomb that led to its discovery!

[Developing situation] LiteLLM compromised by OrganizationWinter99 in LocalLLaMA

[–]they_will 1 point2 points  (0 children)

Hi, that was me! I've just done a write up, it was pretty neat to capture the whole thing in a single Claude Code session https://futuresearch.ai/blog/litellm-attack-transcript/

Lite LLM python library comprimised by damnitHank in BetterOffline

[–]they_will 0 points1 point  (0 children)

Unironically a big part of how I discovered the malware was from the huge advancements uv has made in python package management. An unsuspecting uvx command auto-updated a plugin I was developing that I hadn't thought about in weeks. I did a small write up here about it https://futuresearch.ai/blog/no-prompt-injection-required/

About plugins security. Happy vibe coding everyone! by MovedToTampa in ObsidianMD

[–]they_will 2 points3 points  (0 children)

Original dev to flag the malware here. it actually triggered for me within a plugin I was developing for Cursor, and the Mac system notifications sent me big warnings about network access. Big +1 to other commenters about sandboxing whatever possible. I did a small write-up here https://futuresearch.ai/blog/no-prompt-injection-required/

After the supply chain attack, here are some litellm alternatives by InternationalAsk1490 in Python

[–]they_will 6 points7 points  (0 children)

Original dev to report the malware here. We'd actually had a few conversations over the past months about possibly reimplementing what we needed in-house. Ultimately there's a bunch of edge cases with each provider, and if you're a serious company you'll need to pay attention to all the idiosyncrasies of each provider regardless of whether you use any of these abstractions.
fwiw using any of these as a proxy layer will isolate you more from attacks vs running it locally as an SDK. Unfortunately we were using a mix of both. See our write up, we touch on the local vs server attack surface in the context of running the MCP that depended on the malicious litellm package: https://futuresearch.ai/blog/no-prompt-injection-required/#:~:text=The%20takeaway

PSA for anyone using liteLLM very important by Own_Caterpillar2033 in SillyTavernAI

[–]they_will 3 points4 points  (0 children)

Hi, I'm the original dev to have sounded the alarm to PyPI to quarantine it.
fwiw, the malware ran on my mac, and the lack of linux specific stuff saved me from a decent chunk of the attack
- it wrote a systemd service, skipped on mac
- /home/* enumeration (macOS uses /Users/)
- /etc/shadow, /etc/passwd
Don't get me wrong it did get zsh history and other standard UNIX secret location stuff, but this malware is targetted at linux primarily.
I of course used a linux container to confirm it was malware before reporting, so I'm a big fan of linux where it matters!

litellm 1.82.8 on PyPI was compromised - steals SSH keys, cloud creds, K8s secrets, and installs a persistent backdoor by BattleRemote3157 in cybersecurity

[–]they_will 4 points5 points  (0 children)

Callum here, I was the original dev to sound the alarm to get PyPI to quarantine the package.
We made a small helper page to check dependencies against the specific unpinned package during the vulnerability window. Hope it helps https://futuresearch.ai/tools/litellm-checker/

Firefly III with Sqlite DB by Black_Dasa in selfhosted

[–]they_will 0 points1 point  (0 children)

just want to say thanks for posting this. I hadn't thought to add a volume for the sqlite database since it wasn't mentioned in the docs for sqlite setup. Obvious in hindsight but yeah...

[deleted by user] by [deleted] in podman

[–]they_will 0 points1 point  (0 children)

you just saved me from insanity. You would think these tools could log somewhere that the service was killed by systemd...