How-To: A Self-Hosted Checklist After the GitLab, Signal, Tor and PHP2Shell News

A bunch of security stories in one week: a max-severity GitLab bug, a Signal calling flaw, hijacked Tor exit nodes and PHP2Shell. Here’s the checklist I’d run through on any self-hosted setup. Adjust it to what you actually run. Use your own hostnames and addresses, and run commands only on systems you own.

1. Make an inventory first

You can’t patch what you forgot you had. List what’s listening on each machine and what version it’s running.

sudo ss -tlnp
docker ps --format '{{.Names}}	{{.Image}}'

2. GitLab

• If you self-host it, check your version and upgrade to a fixed release for your branch (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13) for CVE-2026-110264.
• Back up first, and make sure you can restore.
• If it doesn’t need to be public, put it behind a VPN or an IP allowlist.
• Afterwards, review recent logins, access tokens, runners and project hooks for anything unfamiliar.

3. Signal

• Update Signal on your phone and desktop. The calling bug (CVE-2026-113380) affects RingRTC versions before 2.72.0.

4. PHP2Shell

• Check php -v on every web host and container, update to the fixed release for your branch, and restart PHP-FPM and the web server so the new code is actually running. My patching how-to and home lab checklist have more detail.

5. SSH and password hygiene (the Tor lesson)

• Never click through a “host key changed” warning. Verify the new key another way first.
• Use SSH keys and turn off password logins. You can check what a server currently allows:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|pubkeyauthentication'

• Don’t reuse passwords on admin systems. Use a password manager and unique passwords everywhere.

6. Email and TLS

• Make your mail clients and servers require TLS and refuse to fall back to plaintext.

7. Exposure and secrets

• Keep admin panels, AI gateways and model servers off the public internet. Put them behind a VPN or allowlist.
• Keep API keys in a secrets manager, not in shell history or world-readable files, and rotate anything that might have been exposed.

8. Logs and backups

• Skim access and auth logs for odd requests and logins around the disclosure dates.
• Keep at least one backup that’s offline or can’t be overwritten, and test a restore.

None of this is glamorous, but it’s the stuff that decides whether next week’s headline is about somebody else.

Have a blessed day! And Happy Hacking!

References & Further Reading

• GitLab warns of new max severity code execution vulnerability (BleepingComputer)
• Signal bug could keep your mic – and camera – on after hangup (The Register)
• 333 Tor exit nodes hijacked to intercept SSH traffic and retrieve plaintext email (Ars Technica)
• PHP2Shell puts dozens of UK government services out of service (The Register)
• How-To: Patch PHP on a WordPress Server for PHP2Shell (EtherNinja)
• How-To: A Home Lab Checklist After the LiteLLM and PHP2Shell Attacks (EtherNinja)