The open source you don't know you're running

Most of the serious security news this month has been about open source software. Not because open source is worse, but because it is everywhere, often in places nobody has written down.

A month of open source headaches

Look at the last few weeks. Two PHP flaws, nicknamed PHP2Shell, affect every PHP version since March 2012. Details leaked, patches came out early on 21 October, and exploitation started within hours. AWS says it saw attacks before the flaws were even made public.

In the same week, attackers got into LiteLLM's release process. Version 1.107.0, published to PyPI and Docker, carried an infostealer aimed at cloud, developer and AI provider keys. It is the project's second incident this year. GitLab fixed a pre-authentication remote code execution flaw rated a full 10 out of 10, affecting versions all the way back to 7.0. And on 16 October researchers published a working root exploit for OpenBSD, built on a bug that goes back to the original BSD code.

None of these were obscure tools. They sit underneath websites, AI gateways, source control and firewalls.

The real problem: you don't know where it is

When a Windows patch comes out, most of us know exactly what to do. Patch management tools see Windows. They often don't see the PHP runtime inside a web server, the Python package inside a container, or the copy of GitLab a developer stood up two years ago.

That is the gap attackers use. A WordPress update does nothing if the server underneath is running an old PHP build. Updating a Docker image does nothing if a pinned tag still pulls the bad version.

What I'd do this weekend

1. Make a simple list

You don't need an expensive tool to start. A spreadsheet with four columns is enough: what it is, where it runs, what version, and who owns it. Start with anything facing the internet: web servers, VPNs, firewalls, Git servers, anything with a login page.

2. Check the runtime, not just the app

For web servers, run php -v and compare it with the vendor's fixed versions. For Python, check with pip show for the packages you care about. For containers, look at the actual image digest that is running, not the tag in a compose file.

3. Treat AI tooling like any other server

AI gateways such as LiteLLM hold API keys for several providers at once. That makes them a very attractive target. If you run one, pin versions, watch for release notices, and rotate keys if a bad version ever touched your systems.

4. Subscribe to the right feeds

Most projects publish security announcements by mailing list, GitHub advisories or an errata page. OpenBSD, for example, ships fixes as numbered errata you can apply with syspatch. Pick the handful of projects you rely on and subscribe. It takes ten minutes.

5. Have a plan for a poisoned update

Supply chain attacks flip the usual advice. Normally you patch fast. When a release itself is malicious, the people who patched fastest got hit first. For build systems and anything that pulls packages automatically, consider a short delay before new versions are trusted, and know how you would roll back.

Why this is worth the effort

Open source is not going away, and it shouldn't. It runs most of the internet, and the fixes for these issues came out quickly. The weak point is usually our side: not knowing what we run. An hour spent building that list now will save a long night when the next big flaw lands.

If you only do one thing, find every internet-facing server running PHP and check its version today.

Sources

← All posts