Security issue thread - PHP and eMudhra cert compromise

[msbt]

@girish will/can there a patch for Cloudron <10 users? I have a LAMP which requires MYSQL 8.0, that's why I haven't upgraded to 9.2.0 yet, to avoid compatibility issues with MYSQL 8.4

Edit: Might opt for a custom app, that's not a healthy way to maintain that LAMP app

Unrelated: Great response time and effort for the fixes, much appreciated!

[maxkreg]

I powered off my netcup Cloudron servers a few hours ago and I´m now browsing through the forum, gathering info.
Would this be a sensible restart procedure, once cloudron and package updates are available?

• Before booting, restrict inbound access at the provider firewall to my IP only (SSH/HTTPS, covering IPv4 and IPv6), initially blocking other outbound traffic except administrative replies - if possible
• Boot normally and stop all apps through the dashboard.
• Allow the outbound connectivity needed for updates (no idea how..), verify/update Ubuntu’s ca-certificates, and install Cloudron 10.1.6 when available as laid out in @girish´s first post
• Update and test app packages individually once available, keeping unpatched apps stopped before restoring public access.

Would this make preventing Docker from starting during boot unnecessary? Also, is restricting inbound access sufficient for temporary operation, or should apps awaiting CA/runtime fixes remain stopped because of their outbound TLS connections?

Thank you guys being as fast and commited as you are

[sebastienserre]

How to receive the PHP fix ? I don't see any updates?
Do I need to stop my PHP apps ?

[jcaruso]

@sebastienserre Individual PHP apps will need to be updated. I just noticed that WordPress has been updated but others aren't yet. It sounds like the automated systems are still testing and building updates and they'll be ready soon.

[humpty]

@sebastienserre yes, it's best to stop the PHP-based apps. You can see which apps are affected a few posts up. App updates are being rolled out. For instance, Wordpress and Freescout fixes are ready. As for the server, go to the initial post, log in to your server(s) via SSH, and run the commands to make sure the server is up to date. That's all you need to do right now.

[jdbaker]

Yinz are true heroes!

[Teiluj]

@luckow said:

@jdaviescoates as fas as i know:
2fauth
...
yourls

Is there such list for Community apps also?

Thanks @staff and @all for the prompt community actions

[sebastienserre]

@humpty I followed steps on the server, it's up-to-date.
I run Cloudron 10.1.5, is a 10.1.6 will be released orno need it's per apps based ?

[humpty]

@sebastienserre 10.1.6 is needed and on the way. Stay tuned.

[girish]

The internal priority is to get the PHP apps updated first. The PHP issue is far more severe than the certificate issue (which requires the DNS or something else to be compromised to work). In that sense, 10.1.6 will happen but after most of the PHP apps are updated.

[OneTools Project]

Is putting the concerned apps into recovery mode until the updates are there enough to "secure" them?

[jdaviescoates]

@OneTools-Project I don't know. I've stopped all of mine. But you can't update stopped apps, so you have to restarted the again to update them. I'm taking advantage of the Cloudron CLI for the first time to make this process quicker and easier. And Claude just gave me this to restart and then force start all my WordPress apps that were all stuck on a wrong 4.0.0 version number and so weren't able to update:

for a in $(cloudron list | awk '$5=="stopped" && $3=="org.wordpress.unmanaged.cloudronapp@4.0.0" {print $1}'); do cloudron start --app "$a" && cloudron update --app "$a" --appstore-id org.wordpress.unmanaged.cloudronapp@3.17.0 --force; done

[Grienauer]

Do we know when the cloudron Update is available? Thank you all for you work!

[dsp76]

@Grienauer Packages are being updated one by one. Many are already patched.

[andreasdueren]

https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html One more thing @girish @nebulon

[ei8fdb]

Thank you @girish @nebulon @james and other Cloudron staff I don't know about. I checked in earlier and saw you were in the process of reacting to the news. And I wasn't stressed, I knew it'd be fixed.

I dropped Internet traffic to my homeserver Cloudron and decided to wait patiently. My small company users went for . And now I'm seeing updates being available for the apps I run. Click...click...one by one.

We don't see all the frantic work you've all been doing, but your fast response and updating is a credit to you all. You provide a great service.

When this one is "finished", I hope you get a long beer and a longer sleep.

If only all companies responded as fast as you.

[thoresson]

Cloudron already enables automatic security updates on the host. But you can and should check this manually.

First run:

# dpkg-query -W -f 'installed: ${Version}\n' ca-certificates
installed: 20260816ubuntu0.26.04.1

Slightly off topic for this thread, but asking here as others might run into the same issue when working with the PHP CVE: What if the date was in June? What could cause the automatic security updates to fail?

[leighmhart]

Turned off my Castopod 1.15.5 (org.castopod.cloudronapp@2.13.4) for now as it is running PHP 8.3.6 - hoping a 2year jump in minor semantic versions isn't as rough as it sounds it might be...

Edit: Good news the upstream has fixed this one already https://github.com/ad-aures/castopod/releases/tag/v1.15.6 Castopod 1.15.6 - so it looks to me like a maintainer just needs to bump the php-base to match - e.g.: cloudron/php-base:8.4-20261021 and update the manifest for v1.15.6 ?

[robi]

@girish said:

@humpty all our apps are node.js based .

No worries, there's a new node 0day too!

[necrevistonnezr]

Do we have a list which Apps use PHP and should therefore be stopped, currently?

Edit, this does the trick, check in running and stopped apps if and which php is inside:

for c in $(docker ps -aq); do
  img=$(docker inspect -f '{{.Config.Image}}' $c)
  if [ "$(docker inspect -f '{{.State.Running}}' $c)" = "true" ]; then
    docker top $c -eo pid,comm 2>/dev/null | grep -qE '\s(php|php-fpm[0-9.]*|apache2|frankenphp)$' || continue
    state="running"
    v=$(docker exec $c php -r 'echo PHP_VERSION;' 2>/dev/null || echo "?")
  else
    state="stopped"
    v=$(docker run --rm --network none --entrypoint php "$img" -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  fi
  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="" ;;
  esac
  if [ -z "$fix" ]; then s="UNKNOWN/EOL"
  elif [ "$(printf '%s\n' "$v" "$fix" | sort -V | head -1)" = "$fix" ]; then s="PATCHED"
  else s="VULNERABLE"; fi
  printf '%-12s %-8s %-10s %s\n' "$s" "$state" "$v" "$img"
done

Checks all Cloudron app containers for PHP versions affected by CVE-2026-109618 / CVE-2026-109619 (CERT-EU advisory 2026-018). Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

• Running apps: only listed if a PHP web process (php-fpm, apache2/mod_php, frankenphp) is actually running; version is read via docker exec.
• Stopped apps: version is read from the image in a throwaway container without network access. The app itself is not started.

For me, it’s “just” FreshRSS and Tachyon:

VULNERABLE   stopped  8.5.10     cloudron/org.freshrss.cloudronapp:202610200521170000
VULNERABLE   stopped  8.5.10     cloudron/com.github.kimusan.tachyon.cloudronapp:202610170524260000