Every staging site runs inside its own rootless Docker container with network egress filtered at the host. A malicious plugin cannot reach your production database, your payment gateway, or any other tenant on our platform. We verify this with continuous penetration tests.
If a plugin inside staging tries to exec(), file_get_contents("/etc/passwd"), or phone home to evil.ru — the syscall is blocked, the packet is dropped, and the event appears in your activity log within 400 ms.
The container can make exactly 63 syscalls. Everything else (ptrace, module_load, kexec, etc.) returns EPERM.
Only /var/www/html, /tmp, and the MySQL datadir are writable. Everything else is mounted read-only.
Default-deny. We allow api.wordpress.org, downloads.wordpress.org, and a handful of known-good plugin update servers. Everything else blocked.
An anonymized walk-through of a real supply-chain compromise a customer caught in staging. Plugin was CVE-2024-3721 · ultimate-member 2.8.3.
usermeta row.wp_capabilities = {"administrator": true} against unauthorized uid.DROP iptables rule L3-egress-tor.Worst case it burns down a container we were going to delete in 7 days.