Security issue thread - PHP and eMudhra cert compromise

[p44]

@jdaviescoates Another “workaround” could be to install VPN app and mark as required to access to all installed application. What do you think? Could be a temporary workaround to avoid to stop every app?

[jdaviescoates]

@p44 I don't have the knowledge to know tbh. But it sounds a bit like what more qualified @fbartels described in that other thread.

[girish]

yes, limiting access via the VPN feature is a way to fix the issue.

To update: the base images are ready, our CI is at work pushing new packages.

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