DockPanel Security Hardening — Methodology & Results

What I Did

Instead of a generic code review, I studied how real attackers actually break into hosting panels — then checked DockPanel against those exact patterns.

Research

Studied real-world exploits from CyberPanel (22,000 servers ransomwared), VestaCP (mass credential theft), CloudPanel (hardcoded encryption keys), HestiaCP (users accessing other users' data), Webmin (backdoor in password reset), and CWP (RCE from the login page). Also studied Rust, Docker, nginx, PostgreSQL, and React-specific attack techniques.

What Was Found and Fixed

55 vulnerabilities across 79 files, plus 7 more caught by mandatory self-audit.

The big ones:

- Every system command (341 calls) was inheriting the full environment — an attacker who sets LD_PRELOAD gets code execution in every docker/git/nginx/systemctl call. Fixed with env_clear() on all commands.
- Database backup was building shell commands by pasting user input into bash -c strings. Rewrote to use safe piped processes.
- Backups followed symlinks — a user creates ln -s /etc/shadow ./shadow, downloads a backup, and reads any file on the server. Fixed.
- "Revoke All Sessions" did nothing — it saved a timestamp, but the auth system never checked it. Fixed.
- Every credential was stored in plaintext — database passwords, SMTP, API keys, OAuth secrets, 2FA secrets, DKIM keys. If the database leaked, everything leaked. Now encrypted with AES-256-GCM.
- Deploy log streaming had no ownership check — any user could watch any other user's deployments. Fixed.
- Docker compose volumes weren't resolving symlinks — a symlink could bypass the path restriction. Fixed with canonicalize().
- Self-audit caught 6 code paths where encrypted credentials would be sent as garbage to the agent instead of being decrypted first. Fixed before they caused runtime failures.

The Method

This is called threat-informed security testing — studying real attacks on similar systems, then auditing your own code against those specific patterns.

Combined with a mandatory self-audit loop: fix → test → re-audit → repeat until zero findings. Single-pass reviews miss things. The self-audit rounds caught.

7 additional issues the first pass missed.

Result:

88/88 end-to-end tests passing. ~180 total vulnerabilities fixed across all audit sessions. Zero remaining items.

############################################################################################################################

The research phase is what made the difference between the two audits.

Without research (Audit 1, post-incident): I reviewed the code against general patterns I already knew— such as injection, traversal, and missing auth. Found 117 issues. But I missed things like env_clear() on 341 commands, plaintext credentials, tar symlink attacks, the revoke_all_sessions no-op, and nginx header inheritance loss. Those are things I wouldn't think to check unless I knew attackers specifically exploit them.

With research (Audit 2): I studied what actually got CyberPanel ransomwared, what got VestaCP mass-compromised, how CloudPanel's hardcoded keys were exploited. Then I checked DockPanel against those exact patterns. Found 55 more issues, including the ones the first audit missed.

The reason it works: an AI reviewing its own code has the same blind spots it had when writing it. But an AI that first reads about how HestiaCP's backup restore was exploited via symlinks will then think to check if DockPanel's backup restore has the same issue. It does —, and it did.

The key is making the research specific to your stack. Not "OWASP top 10" generic stuff, but "what CVEs exist for hosting panels that use Docker + systemd + nginx + PostgreSQL." That's what produces actionable checklists instead of vague advice.

If you're using an AI for security, always do research first, audit second.