Submitted 6 hours ago by GottaHaveFaith@fedia.io to selfhosted@lemmy.world
Ive checked all my self hosted services and was happy to find out the only one was written in PHP, addy, formerly anonaddy.
You can use the awesome self hosted GitHub repo or this one already filtered for PHP
That list isn’t completely accurate. My project, for instance, is not on the PHP list despite it being written in PHP because the platform is Docker. The selfh.st filter as described by eshol might be the better way to go.
The list is just for a quick check, I actually went through all the repos of my services
None of my stuff is publicly accessible so yay for not having to take anything offline.
My Nextcloud is the only public facing service on the list. Is it sufficient to just disable public access via Nginx Proxy Manager and continue to permit local access for Nextcloud, or do I need to just shut down Nextcloud until it gets updated?
Public access is what is in immediate danger. Private services are safe from bots, but at risk from attacker on your network - a compromised IoT device or package on server could move laterally to vulnerable PHP services
Nextcloud is updated, go ahead and update yours.
The good thing about it is that all PHP applications run through a single service (unless you use containers for each of them individually, I guess), so it’s really easy to take them all down at the same time, and update them all at once.
Isn’t zabbix missing ? Just from the top of my mind
eshol@lemmy.world 6 hours ago
I also maintain a language filter over at selfh.st/apps that can be used to identify PHP-heavy platforms:
selfh.st/apps/?language=PHP
RaoulDook@lemmy.world 5 hours ago
Very helpful!
ikidd@lemmy.dbzer0.com 2 hours ago
One I know about that’s not on your list and is very likely to be an exposed service is Mailcow. Looks like the PHP filter isn’t triggering for it, but it’s definitely PHP based.
eshol@lemmy.world 54 minutes ago
The directory pulls the prominent language from each project’s repo, which is JavaScript for Mailcow.
I should update the dataset to grab any languages above a certain % threshold (25%?) to prevent instances like this where something might fall through the cracks.