Security issue thread - PHP and eMudhra cert compromise

[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

[humpty]

Invoice Ninja v5.13.50 is out, but I'm not sure if it has the php fixes. In any case, please update the package!

https://github.com/invoiceninja/invoiceninja/releases/tag/v5.13.50

[Tphane]

@girish
Hi
About this Gitlab flaw does it impact security concerns about Cloudron instances ?
Is it better to wait before doing app updates in our Cloudron instances ?
Cloudron uses Gitlab for its developpment and for pushing new updates ?

[nebulon]

The new gitlab package with the fix is already out now. So please update that

[sebastienserre]

any news about the Dolibarr package ?