The challenge involved a Docker/Kubernetes deployment with a stock WordPress 7.0.0 install on PHP 8.2 / Apache, running on a Debian Trixie base image. Initial access was gained through a known vulnerable plugin, wp2shell, which provided a www-data shell. The primary objective was privilege escalation, intentionally hardened against typical container escapes and SUID tricks, pointing towards a recent sudo CVE.Reconnaissance revealed a Dockerfile pinning specific versions, notably gcc and libc6-dev present in the runtime image, indicating on-box compilation for privilege escalation. The presence of sudo further narrowed the focus to a sudo local-root bug. The docker-compose.yml exposed default WordPress database credentials.The docker/entrypoint.sh script was crucial, as it generated random WordPress admin credentials on first boot and exported them into the container's environment, accessible by child processes like Apache/PHP workers. The theme directory, brunnerne-docs, was intentionally root-owned but world-readable, a potential red herring for root-executed hooks.Initial access utilized the wp2shell-poc, a public exploit chain for WordPress 7.0.0, involving CVE-2026-63030 (unauthenticated blind SQL injection) and CVE-2026-60137 (RCE via plugin upload after admin credential recovery). This granted a reverse shell as www-data.Enumeration as www-data showed a hardened environment with no unusual SUID binaries, capabilities, or world-writable root-owned files. The sudo version 1.9.15p5 was identified as a critical piece of information.Credential hunting in /proc/*/environ revealed the WordPress admin credentials, but these were not system credentials for sudo. Attempts to use them or default passwords with sudo failed.Privilege escalation was achieved using CVE-2025-32463, affecting sudo 1.9.14 through 1.9.17. This vulnerability allowed any local user to leverage the --chroot/-R option to load an attacker-controlled NSS shared library from a self-supplied chroot, executing arbitrary code as root without a sudoers entry or password.The exploit involved compiling a malicious NSS module that dropped a root shell, staging a fake chroot directory with a custom nsswitch.conf pointing to this module, and then triggering it with 'sudo -R woot woot'. This successfully granted a root shell, allowing access to the flag.The root cause was the WordPress core unauthenticated SQL injection leading to RCE for initial access, and the sudo 1.9.15p5 vulnerability (CVE-2025-32463) for privilege escalation. The fix involves upgrading sudo to version >= 1.9.17p1. Key lessons included checking privileged binary versions early and recognizing hints like gcc/libc6-dev presence for on-target compilation.