Indeed, we use that angular version 1.5.8 and can look into updating that. Generally though I am not sure how one would exploit this in the Cloudron use-case. So I don't think it makes much difference. The only user-content which is dynamic in that sense would be the footer, but if the admin sets a malicious footer, I guess the situation is already an issue.
@nj Cloudro relies on Ubuntu LTS versions and security updates are enabled automatically (independent from Cloudron releases). So once the ubuntu securty team updates the kernels, all Cloudrons will get is as well. Since this is a kernel issue, you will likely see some "reboot required" notification in your Cloudron dashboard afterwards.
@girish I would say pick and choose what is applicable obviously you would know best it's also worth noting there are CIS benchmarks specifically for Docker Containers which might be a better fit. You could combine the two for better hardening.
The backdoor was removed before it was compiled into a binary for admins to download so there is no issue for anyone running PHP. However this does prove to be an issues in regards to PHP's safety - They have moved to GitHub (@girish mentions in his reply) and will be better closely monitoring pushes and merges into the code base.
PHP's Own Nikita Popov: "The changes were on the development branch for PHP 8.1, which is due to release at the end of the year" which means the code has not been distributed. It's a big deal but not as big as everyone is making it out to be.
@imc67 I've published a new package which sets the getremoteaddrconf now correctly.
Since we only have one reverse proxy, the second setting was not needed in my tests. So this is untouched by default.
This appears to be someone/bot trying out common usernames in one of your apps. Unfortunately this is not too uncommon, but also not an a real issue if you have strong passwords. The requests will be rate-limited as well to prevent proper brute-force attacks.
The internal IP is associated to an app, it may or may not change when an app is restarted. However the ldap logs might indicate there are multiple apps configured to use LDAP. The port is actually dynamic per request, so that is the reason why it does not show in docker ps/inspect
@girish I think all these % numbers are a bit misleading and opinionated - but as you rightly detail it's a case of looking at the appropriateness of each item and reasonability.
It's impossible to know or remember everything but still a nice too for a quick review to see if there's any easy wins, and I suppose the scoring mechanism could be handy marketing for some once a certain level is considered reasonably hardened.
I think there's a genuine case in the future where if we introduce per-app admins, then app admin can access terminal of one app to see traffic (and sniff ldap/db creds) of another app. I think it's an excellent suggestion to remove it!