The holes are plugged in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For PHP 8.1 and older there are no regular releases with the fix so far, so the only way out is moving to a supported branch. On a regular server, the package manager takes care of that. Docker is a different story: every container brings its own PHP, and that PHP stays exactly as old as the image.

Which container runs which PHP?

So the first question is: which containers on my little home server actually contain PHP? For Nextcloud or WordPress that’s obvious, for self-built images or small web apps less so. Instead of going through every container by hand, the following loop asks all running containers for their PHP version and compares it with the patched releases right away.

for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  case "${v%.*}" in
    8.5) fix=8.5.12 ;;
    8.4) fix=8.4.27 ;;
    8.3) fix=8.3.36 ;;
    8.2) fix=8.2.35 ;;
    *)   fix=99 ;;
  esac
  if [ "$(printf '%s\n' "$fix" "$v" | sort -V | head -n1)" = "$fix" ]; then
    printf '\e[32m%-30s %-8s ok\e[0m\n' "$c" "$v"
  else
    printf '\e[31m%-30s %-8s anfällig?\e[0m\n' "$c" "$v"
  fi
done

The loop silently skips containers without PHP. For all others, the version shows up in green if it is at least at the patch level and in red if it is below. PHP 8.1, 7.x and older also end up in red, because there simply is no fix for them. The red lines say “anfällig?”, German for “vulnerable?”. On my server, the result looks like this:

$ ./php2shell-simple.sh
nextcloud-app-1                8.5.12   ok
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
planetfoss-web                 8.3.33   anfällig?
sisu-web                       8.4.26   anfällig?

So Nextcloud and the test WordPress had already pulled their updates, while PlanetFOSS and the site for Sisu were still lagging behind. By the way, the question mark after “vulnerable” is on purpose. The loop only compares version numbers. If an image uses the PHP package from Debian, Ubuntu or Alpine, the fix may have been backported without the number changing. In that case, only the distribution’s security advisories can tell you more.

For a closer look, there is php2shell-check by EXT IT. The MIT-licensed script is read-only and judges PHP by package versions rather than just the version number, so it also takes backported fixes into account. It looks into Docker containers, FPM pools and old processes that are still running, and on request sends a harmless request to your website. For the containers it needs root or membership in the docker group.

The project page suggests the usual one-liner with curl and sudo bash. For a script that runs with root privileges on my server, I’m not too fond of that. Better download the script together with SHA256SUMS from the releases, check it with sha256sum -c SHA256SUMS, skim through it once and then start it by hand. According to the developers, a “not vulnerable” is no guarantee, by the way:

$ sudo bash php2shell-check.sh https://eure-seite.example

On my home server I ran the script with sudo. As a member of the docker group it would see the containers without root as well, but running processes of other users and some logs would stay hidden. This is how I fetched and started it:

$ curl -fsSLO https://github.com/EXT-IT/php2shell-check/releases/latest/download/php2shell-check.sh
$ chmod +x php2shell-check.sh 
$ sudo ./php2shell-check.sh 

The verdict matches the loop: planetfoss-web with PHP 8.3.33 and sisu-web with PHP 8.4.26 are vulnerable, Nextcloud and the test WordPress are not. On top of that, it found a stopped container from Tuxsucht that my loop had completely missed:

PHP in docker containers
  [ OK ] container      nextcloud-app-1 (nextcloud:35-apache)
         PHP 8.5.12 (fixed from 8.5.12)
[...]
  [VULN] container      planetfoss-web (planetfoss-web:local)
         PHP 8.3.33, fixed in 8.3.36
         -> Update PHP to 8.3.36 or later (container: pull the new image and recreate)
[...]
  [VULN] container      sisu-web (sisu-web:local)
         PHP 8.4.26, fixed in 8.4.27
[...]
  [WARN] container      php83 (stopped, tuxsucht-php)
         stopped, but its image ships PHP 8.3.33: it comes back vulnerable on the next start
[...]
Summary  2 vulnerable, 3 undecided, 12 warnings, 11 ok

Sure, docker ps only lists running containers, and a stopped container doesn’t accept any requests. But if someone starts it again at some point, the hole is back right away. The script is also very clear about mod_php: all five running containers serve PHP through the Apache module, and the advisory demonstrates a complete attack without login against exactly this setup.

Until you can update, the script suggests a stopgap: set session.upload_progress.enabled=0 and expose_php=0, and keep post_max_size below a quarter of memory_limit. The check from the outside, on the other hand, wasn’t much help. For the two websites, the script only reports that the headers don’t reveal a PHP version and that there is no WAF in front. That says nothing about the patch level, which the script honestly admits.

And how do you update PHP?

Don’t update anything inside the container itself, it would be gone again with the next recreate. Instead, pull the new image in the respective Compose directory and recreate the container with it. For self-built images with their own Dockerfile you need docker compose build --pull, so that Docker also fetches a fresh base image:

docker compose pull && docker compose up -d

Important: of course this only helps if the base image already contains the patched version. According to IT-Connect, the new tags initially even showed up without an image behind them, but by now generic tags such as php:8.3-apache ship the patched PHP. If your Dockerfile pins a fixed version like php:8.4.24-fpm, you have to bump it yourself. Simply run the loop again after the update. Take care of the containers that are reachable from the internet first.

The PlanetFOSS test environment shows what this looks like in practice. Its image is based on php:8.3-apache, and the Dockerfile only adds extensions such as GD and Intl. My deploy script does call docker compose up -d --build, but that doesn’t fetch a new base image, it takes the one from August out of the cache. That’s where the old PHP 8.3.33 came from. Only --pull fetches the fresh version:

$ cd /data/docker/planetfoss
$ docker compose build --pull web
$ docker compose up -d web

After a good minute the new image was ready, and the container ran PHP 8.3.36. The database in the same Compose project stays untouched, because both commands only address the web service. Afterwards the loop shows PlanetFOSS in green, and php2shell-check also reports only sisu-web as vulnerable. The old image is still lying around on disk as a leftover, by the way; docker image prune cleans it up.

$ ./php2shell-simple.sh
[...]
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
sisu-web                       8.4.26   anfällig?

All in all, PHP2Shell is a good example of how self-hosting with Docker is convenient, but the updates don’t come by themselves. heise has collected more details on the vulnerabilities. How to keep containers up to date without a lot of fiddling, I covered in Keeping Docker containers up to date with Dockcheck. How do you keep your containers up to date?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

That’s exactly what PlanetFOSS is for. The site has been running in a trial phase for a few days, and starting today I’d like to launch it officially. The idea is a planet that isn’t tied to one project but collects across topics: distributions, desktops, the kernel, self-hosting, gaming, security, politics. The sources are publishers, blogs, project sites, and video channels, in German and English, and every visitor decides which language they want to see.

A magazine, not a list

Visually, PlanetFOSS takes its cue from a modern computer magazine rather than the classic Planet list. There’s a lead story, cards with an image and a teaser, categories, and a bar with the topics of the day. The site only takes what the source sites themselves provide for previews, meaning Open Graph data or the content of the RSS feed. Every card links straight to the original article. There are no full texts.

I also put some effort into privacy. The preview images are stored as WebP on PlanetFOSS’s own server, so no visitor IP ends up on third-party servers. There are no cookies, no external scripts, and no tracking. You can still mark articles with a star as worth reading, without an account: instead of a CAPTCHA, your browser solves a small computing puzzle, and the star is only remembered locally in your browser.

Under the hood, it’s good old PHP with MySQL, no framework, on ordinary shared hosting. Every five minutes, a cron job kicks off a cycle: fetch feeds, enrich new articles, sort them, rebuild the front pages. The real work, though, isn’t the fetching but the sorting. A site with more than a hundred sources quickly turns into a wall of text when ten sites report on the same thing.

Same news, one bundle

When a new Firefox version comes out, it feels like everyone writes about it. On a regular Planet site, you’d see Firefox ten times in a row. That’s why PlanetFOSS compares every new article with all articles from other sources published in the last 48 hours. If the title contains the same topic with the same version number, say “Firefox 158” or “Ubuntu 26.10”, the articles end up in a shared bundle, even across the language barrier.

There are two more signals. If two news items link to the same primary source, such as the release notes or a press release, they very likely belong together. Run-of-the-mill targets like GitHub or Wikipedia don’t count. As a last resort, the aggregator compares the titles themselves: stop words get thrown out, and if half of the remaining words match and the titles share a topic, it’s a bundle.

The motto here: better to bundle too little than to bundle wrong. A missing “also at” hardly anyone notices, but two unrelated stories lumped together stand out right away. On the front page, bundles with two sources appear as a card with a source bar underneath. From three sources on, it becomes a story card that’s twice as wide in the grid and lists every additional report with its own headline and its own link to the original.

New topics without a dictionary

PlanetFOSS has a dictionary with terms like GNOME, Plasma, Proxmox, or Steam. It helps with the categories, which a small Naive Bayes classifier also assigns, and with version topics. The thing is, the open source world keeps coming up with new names that aren’t in any dictionary. During the first tests, I noticed ArtCraft, for example: seven articles about a new project, and the site hadn’t picked up on any of it.

Since then, PlanetFOSS looks for new names on its own. A candidate has to appear in the titles of at least three sources within the last 48 hours (four if only one language is involved), but no more than once in the four weeks before. Then there’s a little trick: a name is never written in lowercase. That filters out words like “released” or the German “Sicherheitslücke” (security hole) without endless stop word lists. Whatever is left becomes a new topic.

Comets and supernovas

Now it gets interesting. The name sets the scene: when a topic suddenly gets a flood of coverage, say on the release day of a new Ubuntu version, it becomes a supernova, a sudden, very bright outburst. A topic that’s only just picking up speed is a comet. And once the outburst is over, there’s still an afterglow for a while.

A comet appears as soon as at least three different sources write about a topic within twelve hours. Its cards get a badge, and it moves to the front of the topic bar. So that general catch-all topics like the Linux kernel don’t become permanent comets, they also need twice as many sources as usual. If a comet can’t keep up the momentum, it drops back to a normal topic.

A supernova needs more. Four sources have to report within 24 hours, almost all of them in the last twelve hours. The topic has to be broad, meaning it reaches at least two types of sources (publisher, blog, project, video) or shows up in both languages. On top of that, it needs at least three times as many sources as its average over the last four weeks. Otherwise, every week with some Ubuntu news would be a supernova.

PlanetFOSS knows some things in advance. A release calendar holds the known dates for Ubuntu, GNOME, KDE Plasma, Fedora, Debian, the kernel, and Firefox. If a topic falls within that window, one source fewer is enough to ignite. At the same time, no more than two supernovas may burn at once, so the front page doesn’t drown in nonstop fireworks. If there are more candidates, the strongest ignite and the rest stay comets for the time being.

A supernova burns for at least twelve hours. After that, it cools down once nothing new arrives for six hours or the number of sources drops below half of its peak. If a second wave comes along, such as the first reviews a few days after a release, it can ignite again. After 72 hours, the topic goes to the archive, but its topic page stays online and keeps collecting later posts.

How the front page comes together

When a supernova is burning, it gets its own band at the very top above the lead story, showing the number of posts and sources and a row of cards, sorted by official announcements, news, reviews, how-tos, and videos. Whatever is in that band doesn’t show up again further down. On top of that, PlanetFOSS sends a post to the @planetfoss account on Mastodon half an hour after a supernova ignites.

For everything else, the site hands out points. The score takes into account the size of the bundle, the stars from visitors, an active supernova topic, and the weight of the source. All of that is divided by the age of the article, so older posts gradually slide down. Stories that many sources cover stay up longer, but not forever.

For the lead story, importance beats freshness, but the candidates come from the last 24 hours and preferably bring a large image. The age of a bundle is the age of its second-newest report: if more sources keep writing, it stays up front, but a single latecomer isn’t enough. If a post has already been the lead for more than eight hours, it loses half of its points, and after 14 hours three quarters.

To keep one busy source from filling the whole page, the selection also looks for variety. In the lead story and the top stories next to it, every post comes from a different source, and the “Latest” section shows at most two articles from the same site. That way, smaller blogs get their spot next to the big publishers, and the front page looks a little different every time you visit.

Statistics instead of AI

By the way, there’s no AI in PlanetFOSS that summarizes texts or guesses topics. Everything runs on counting, comparing, and a handful of thresholds. In my opinion, that’s actually the better way: it costs nothing, sends no data anywhere, and stays traceable. When a supernova ignites, you can say exactly why. That said, I did build the site myself with AI assistance.

Of course, it didn’t work without some fine-tuning. Early on, for example, a supernova ignited for Microsoft Defender, even though the four news items were spread over 18 hours. Since then, an outburst has to be genuinely fresh. Ubuntu 26.10 also ignited two hours late on its release day at first, because it was measured against all Ubuntu news. That’s why version topics now get their own baseline.

I keep an eye on cases like these, and for that the site saves a snapshot of topics, bundles, and lead stories every six hours. So the logic will surely keep changing. A wrong bundle or a comet that shouldn’t be one can be corrected by hand in the admin area. The algorithm dutifully respects those corrections on its next run.

Just head over to planetfoss.net and tell me what you think. Which sources are you still missing, and which blogs, magazines, or other publications from the German- or English-speaking Linux and open source world absolutely belong on the planet? I’m happy to take suggestions in the comments. And if you run a blog yourself and would rather not be included, the site of course also offers a way to opt out.

Update: Why the stars on PlanetFOSS no longer use frosted glass, and what that has to do with a memory leak in WebKitGTK, is covered in WebKitGTK 2.54: Tiny Star, Massive Memory Leak.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.