PHP2Shell, LiteLLM, GitLab: Find What You Need to Patch

Posted by bigfish2026 1 day ago

Counter65Comment13OpenOriginal

Comments

Comment by Nickste 21 hours ago

The interesting thing about the eMudhra issue is that it's not just your cloud environments that you need to be worried about. Think about this scenario:

Developer runs `pip install ruff` with pip < 26.2.2 on a public wifi network at their local coffee shop. Wifi network is spoofed, forwards all traffic except pip. Intercepts the pip requests and returns a malicious package. Machine is instantly compromised.

So any local development environment is also very susceptible to this kind of attack until pip, certifi, node, etc. get upgraded.

We've got good tools for finding this kind of issue CI/CD and our cloud environments. But good luck finding and patching every virtual environment on your local machine.

Comment by gradyfps 20 hours ago

Do pip / certifi / node bundle their own trusted certificate authorities? Surely you should just be able to remove the compromised intermediate certificates from whatever store you're using and pip / certifi / node refer to the operating system's CA store and prevent that.

Comment by Nickste 19 hours ago

pip (and Python more broadly) rely on certifi for certificates, which bundles its own certificates. You have to explicitly point certifi to a different cert store if you don't want it to use bundled certs.

Comment by SlightlyLeftPad 17 hours ago

I agree and I’m also surprised in 2026 that these revocation lists don’t update dynamically. Something like ntp for root certificates would be great.

Comment by yanslookup 19 hours ago

By the time you are connecting to spoofed WiFi networks you are already in trouble, using this vector seems like a really convoluted attack at that point.

Comment by 13 hours ago

Comment by Nickste 19 hours ago

Perhaps? But sub "spoofed" for "Free Wifi" and it doesn't seem to convoluted?

The point is that we've been able to trust SSL to protect us on open networks. We might not trust the owner of the infrastructure, but SSL meant that we could tell when our request had been tampered with. That's no longer the case.

Comment by bigfish2026 18 hours ago

Places like airports would be an absolute disaster. I’ve done so much dev work sitting in one and it would be easy enough to put a fake WiFi access point in a lounge.

Comment by 23 hours ago

Comment by tonymet 23 hours ago

we need more standardized BOM reporting. a common signal "kill -s BOM <PID>" that has the process dump it's BOM to /dev/ttys3 . the lowest-level most common / primitive interface. no APIs, exec()s needed.

75% of the problem is the detective work identifying among 1000 dependency trees running in your datacenter, and reporting the BOMs typically requires a bespoke step for each one. Every process should take a dump-BOM signal to make gathering the BOM from every cpu common , quick & instant.

Comment by Normal_gaussian 22 hours ago

Its probably better to embed clearer strings in the binary that conform to some spec. Then searching over binaries would find them.

Trying to respond to a signal is a nightmare of routing and lifecycle bugs. Never mind the fact that most dependencies won't be registered. Currently file/process signature matching is ok for major runtimes, and tends to fail on specific version detection. This would effectively formalise that.

I could see it being a successful standardisation for major runtimes and many libraries that wouldn't currently be detected - but take up would never be universal. A kind of CVE search stamp.

Comment by tonymet 20 hours ago

if it's in the elf then the kernel could handle the interrupting. that way every app wouldn't need to implement the handler. just a named BOM symbol and when the kernel sees the `kill -s BOM <PID>` it reads that BOM symbol without calling any app code.

Comment by tonymet 20 hours ago

but there needs to be a way to query the running tasks so the control plane could query running VMs without querying the FS

Comment by kg 22 hours ago

You'd still need a spec for this because of cross-language considerations, but that doesn't make it a bad idea.

i.e. if an app is written in javascript and running on mac there are potentially 4 different languages all running inside the executable that need to cooperate to handle the BOM signal and report their deps - C/ObjC, Swift, C++ and JS. Presumably you'd want to report not only the native libraries being used in the process but also things like npm packages.

Comment by tonymet 22 hours ago

Good point on that. The bom signal could be relayed. E.g. for a runtime, or multi tenant app, the parent runtime would relay the bom signal.

Presumably the runtime would have the loaded symbol table, which could be used in lieu of a BOM summary.

Comment by bogomind 17 hours ago

[flagged]

Comment by Wryivy94 1 day ago

[flagged]