Security issue thread - PHP and eMudhra cert compromise

[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

[sebastienserre]

is a package for Dolibarr will be edited soon ?
package 1.15.1 runs PHP 8.4.24
Thanks

[girish]

OK, so we are 2/3rds into our package updates. over 150 packages have been updated out of the over 200 packages we maintain.

[girish]

@sebastienserre yup, there will be an update soon.

[girish]

@andreasdueren said:

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

early xmas with all these issues hitting at the same time ️

[sebastienserre]

girish Thank you.
Waiting for it.