Security issue thread - PHP and eMudhra cert compromise

[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.

[p44]

Hi @girish on a single Wordpress Developer instance I was asked to update to org.wordpress.unmanaged.cloudronapp@3.17.0 and I updated.

But all other Wordpress Developer instances, even if I hit "check updates”, nothing happens...

[joseph]

@p44 can you check the version of the WP developer instances? It is in the info tab.

[p44]

@joseph

I have:

WordPress (Developer) 7.0
Package version
org.wordpress.unmanaged.cloudronapp@4.0.0

The (only) one updated shows now:

WordPress (Developer) 7.1.3
Package version
org.wordpress.unmanaged.cloudronapp@3.17.0

My question is: if there is an available update, why if I hit "check for updates” nothing happens?

Thanks a lot

[Benoit]

Thanks for your work @girish . Do you know if a fix is on the way for Moodle ?

[jdaviescoates]

@p44 said:

WordPress (Developer) 7.0
Package version
org.wordpress.unmanaged.cloudronapp@4.0.0

You're suffering from something that got me (and others) too - that 4.0.0 release was a mistake. You need to force the update the the newer version with a lower release number using the CLI:

cloudron update --app SITE_LOCATION --appstore-id org.wordpress.unmanaged.cloudronapp --force

[p44]

@jdaviescoates Thanks a lot, how I can run this without installing Cloudron CLI? Eg. directly from App command line.

I think if this problem is on scale, devs should release a fix also to address this specific issue...

Edit:

@jdaviescoates I installed Cloudron CLI and I used this string that you posted above:

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

[joseph]

@p44 yes, there is a fix in https://git.cloudron.io/platform/box/-/commit/a213f095d15c060959a904516ddb0c22d6c0f3d7 for this in 10.1.6 .

[p44]

This post is deleted!

[whitespace]

Wallabag and Castopod haven't been updated in a while.

Here is a Wallabag thread. It seems they are 1 year behind in codebase updates. (??) But there is a compatibility-frinedly fix being tested.
https://github.com/wallabag/wallabag/pull/9096

Castopod released an update a few hours ago on their official code:
https://github.com/ad-aures/castopod/releases/tag/v1.15.6