@girish thank you, and thanks for confirming the fix ships in Cloudron 10. Adding one data point for anyone who finds this while still on 9.x: we hit the same crash again on 2026-07-06, on 9.2.0 (a build from before commit 33f3ca3), so it recurs exactly as expected until the v10 upgrade: tasks: setCompleted - 4900: {"result":null,"error":{"message":"Cannot read properties of null (reading 'sort')","reason":"External Error"},"percent":100} Same app (Langfuse), same place: the task died at app 31 of 73, so the roughly 40 apps after it were left on the previous snapshot again. The du precondition logged the vanished directories first, this time a delete_tmp_tmp_merge_* variant alongside the usual tmp_merge_* ones, and then readTree threw during the upload. Until we are on 10 we have excluded the ClickHouse apps from the automatic schedule so a single mid-merge app cannot abort the whole run, and we re-run on the rare miss, which clears it. Glad to confirm the fix here once we upgrade, we have a reliable reproducer under merge load.

@layuso we've discussed many of these in other threads. Today the APi is there, the 3rd party dashboards have been made and you can build your own. We also have Cloudron hosted partners who made their own management systems for their needs. What would you like to make first?

Hey James, Sorry been a bit busy here - but per your comment I can def share some insights. I went into the main cloudron dashboard, and navigated to Users > LDAP to configure my internal AD config (Dashed out some sensitive info for security) [image: 1782476078381-48d9bf82-9176-460d-8cd3-bbc4cc5f647a-image.jpeg] After the data began syncing properly, I manually went into my container and adjusted the authentication protocol to utilize OpenID instead of MySQL auth by adding the highlighted entity - [image: 1782476394053-13d291db-2501-4a5e-9fe6-c9c6c0f36d6f-image.jpeg] All seems to be working out, outside of the one tidbit I mentioned previously. But it's manageable for now and my users are having no issues logging in and accessing resources using their AD credentials

Right, the check is simply hardcoded to check for a: entry in the SPF. To check all the possibilities would be quite complicated, since we will have to implement the full SPF spec just for diagnostics. (What you see on the dashboard is just a diagnostic. The mail server Haraka has a fuller SPF implementation).

Has anyone experienced admin dashboard slowness? Front end is fine, but clicking on management has the browser wait for 5-10secs. Logs show: Jun 11 18:59:03 172.69.67.20 - - [11/Jun/2026:23:59:03 +0000] "POST /studio/edit-link HTTP/1.1" 302 390 "https://l.toldyouso.com/studio/edit-link/121242148" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36" Jun 11 18:59:04 [Thu Jun 11 23:59:04.258485 2026] [access_compat:error] [pid 72] [client 162.159.106.71:59436] AH01797: client denied by server configuration: /app/data/public/.env Jun 11 18:59:04 162.159.106.71 - - [11/Jun/2026:23:59:04 +0000] "HEAD /.env HTTP/1.1" 403 - "-" "-" Jun 11 18:59:04 [Thu Jun 11 23:59:04.412636 2026] [access_compat:error] [pid 74] [client 172.68.27.182:56976] AH01797: client denied by server configuration: /app/data/public/database/database.sqlite Jun 11 18:59:04 172.68.27.182 - - [11/Jun/2026:23:59:04 +0000] "HEAD /database/database.sqlite HTTP/1.1" 403 - "-" "-" Jun 11 18:59:10 - - - [11/Jun/2026:23:59:10 +0000] "GET / HTTP/1.1" 200 33462 "-" "Mozilla (CloudronHealth)" Jun 11 18:59:15 172.69.67.20 - - [11/Jun/2026:23:59:03 +0000] "GET /studio/links HTTP/1.1" 200 34944 "https://l.toldyouso.com/studio/edit-link/121242148" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36" Jun 11 18:59:15 172.69.67.20 - - [11/Jun/2026:23:59:15 +0000] "GET /@rob HTTP/1.1" 200 76669 "https://l.toldyouso.com/studio/links" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36" Jun 11 18:59:16 172.69.67.20 - - [11/Jun/2026:23:59:15 +0000] "GET /@rob HTTP/1.1" 200 76669 "https://l.toldyouso.com/studio/links" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36" Jun 11 18:59:16 - - - [11/Jun/2026:23:59:16 +0000] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.4.58 (Ubuntu) OpenSSL/3.0.13 (internal dummy connection)"

Update: All apps in error state after Cloudron restore After restoring Cloudron, all my apps ended up in an error state. I've been digging into the logs and wanted to share what I found in case it's relevant to my setup or helps others. The key error from the app task log: Error: ENOENT: no such file or directory, scandir '/mnt/managedbackups/<uuid>/2026-06-10-000001-121/app_<myapp>.<mydomain>_v3.12.2' So during the restore, Cloudron tries to download the app backup from /mnt/managedbackups/..., but that path doesn't exist. This then causes the task to crash with an AssertionError rather than a clean BoxError, which is probably also worth flagging as a minor bug. I suspect this is related to my specific setup: I have an external backup location that is no longer mounted (as described earlier in this thread). Cloudron appears to be pointing the restore at that unmounted path. Resolution that worked for me: Explicitly restoring each app from its most recent backup (rather than letting the automatic restore run) resolved the error state. Ideally, this should be the default behaviour during a Cloudron restore anyway, restoring from the most recent available backup, so this might be worth looking into. Happy to provide more details if useful.

@james Thanks so much! I'll do that

@dark thanks for your report. I looked into them. For transparency, here is our assessment. All the reported issues require the attacker to already have an admin token / compromised admin password. All the issues below are not reproducible as a (compromised) normal user. Also. the issues were reproduced on the demo instance, which of course has the admin username/password displayed in public. We found the report to be thorough and with clear explanation on how to reproduce the problems. From our side, we ack the bugs and have made the following fixes: Problem: Full SSRF via applinks. This is about adding an internal IPs as an applink. Our analysis: Linking to internal apps is a legitimate feature. An applink is fundamentally a bookmark and there's nothing wrong with pointing it at 192.168.1.50 or an internal app. Applinks REST response only returns label and icon not contents of a site. You can't really infiltrate EC2 metadata etc and neither can you make non GET requests. Our fix: We have added a fix now to block server internal IPs like localhost and docker internal network. Problem: SQL injection via dynamic column names. This is about being able to send arbitrary field names in the REST APIs. Our analysis: Indeed, our query builders, should only use field names which are in the db and are part of an allow list. Our fix: We have added allow list to all our model code Problem: 2FA/TOTP BYPASS via skipTotpCheck: true Our analysis: I think this is because the demo instance does not allow you to set a TOTP. It doesn't show an error currently when this happens and leads the user to believe an OTP was set. For the demo server, we can't allow users to set a TOTP because it will make it unsuable for others. Our fix: We will show an error like we show in other places. But also, the password login routes have already been removed in Cloudron 10 (which is yet to be released). That route exists as a backward compat for the CLI. Cloudron only supports OIDC device auth for the CLI from Cloudron 10. Problem: Stored XSS via branding footer Our analysis: right. This issue has been present since ages and our demo instance always has someone putting some alert() or some stupid HTML in there periodically... Our fix: We give in to the non-stop reports about this... We use dompurify now. Thanks for the report again. Very clear and solid notes. I also took the chance to update https://www.cloudron.io/security.html and https://www.cloudron.io/.well-known/security.txt

Hello @sponch It depends on your provider how he initializes the Ubuntu system. A good guide is https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_storage_devices/getting-started-with-swap_managing-storage-devices#recommended-system-swap-space_getting-started-with-swap According to the Red Hat guide, 4GB SWAP for a 32GB RAM system is the minimal recommended.

@girish that's true! thankfully never had any Cloudron security breaches, but the existence of all apps is visible to the public web, and with AI now able to find zero-day exploits so quickly, data-security risks are increasing one way to mitigate that is if the apps were limited to access only from those with access to it via their mesh vpn maybe it's already possible with asking AI to set all that up, but i'm just thinking out loud for the ordinary person that might not want to tinker with that and just have it as a an option out of the box

@seeker Community app now available https://forum.cloudron.io/topic/15473/bind-git-backed-web-apps

https://cert.europa.eu/publications/security-advisories/2026-005/ is maybe a better link

Thank you @james! And I just realised, that "Last run:" refers to the end of the creation of the backup. Now things match again

@stalecontext i've build an image on docker Hub: https://hub.docker.com/repository/docker/wazolab/copyparty Also i've opened 2 issues on your repo: https://git.cathedral.gg/Ben/copyparty-cloudron-app/issues/1 https://git.cathedral.gg/Ben/copyparty-cloudron-app/issues/2

@james I think this post worth to add on our documentation.

Hey @james , it's not what I'm looking for - I need an already issued SSL certificate to be planted into Cloudron, automatically. The command I've reverse-engineered and provided earlier works, so I stick with it for now. Hopefully, an official stable, documented API to appear soon.

@timconsidine thanks. This was on my own version. I haven't got round to trying yours yet Tim, but yours is the one people should try.

Hello @dimtar Currently, there is no Cloudron build in method for that. You can always put a firewall in front of Cloudron and only allow access via a certain IP-Addresses ranges or a VPN. See https://docs.cloudron.io/installation/home-server and https://docs.cloudron.io/installation/intranet . You can run a completely firewalled installation with valid SSL certs.

@loudlemur I didn't write the skills . But @james is a good candidate for feedback .