BrunnerCTF : WordPressed to Root Writeup

Overview The box ships a mostly-stock WordPress 7.0.0 install on PHP 8.2 / Apache, running on a Debian Trixie base image, packaged as a Docker/Kubernetes challenge deployment. Initial access comes through a deliberately vulnerable plugin ( wp2shell ) that hands over a www-data shell. Privilege escalation is the real puzzle: the box is hardened against the usual container-escape and SUID tricks, and the intended path is a real, recent CVE in sudo itself. Recon The challenge source was distributed as a zip ( boot2root_wordpressed-to-root.zip ) containing the Docker build context: . ├── docker │ ├── entrypoint.sh │ ├── install.php │ └── seed.php ├── docker-compose.yml ├── Dockerfile └── theme └── brunnerne-docs ├── footer.php ├── functions.php ├── header.php ├── index.php └── style.css Dockerfile pins the interesting versions: FROM wordpress:7.0.0-php8.2-apache@sha256:0b6e5bf0ed2518696a34ba3812370743b0ad3e2676882967ff5c712e51425c03 AS wordpress-source FROM debian:trixie-20240408-slim@sha256:70955dce615f114142818e95339f6ae9b461cf424d79d59ca2b04ec725d4dbc8 ... apache2 ca-certificates curl gcc libc6-dev libapache2-mod-php8.2 \ php8.2 php8.2-curl php8.2-gd php8.2-mbstring php8.2-mysql php8.2-xml php8.2-zip sudo Two details stand out immediately: gcc and libc6-dev are installed in the runtime image, not just a build stage. That is a strong hint that compiling a local privilege-escalation PoC on-box is part of the intended path. sudo is installed, which combined with the previous point points straight at a sudo local-root bug rather than a container escape. docker-compose.yml also leaks the DB credentials up front (default WordPress dev creds - not the actual privesc path, but useful context): MARIADB_DATABASE : wordpress MARIADB_USER : wordpress MARIADB_PASSWORD : wordpress MARIADB_ROOT_PASSWORD : rootpassword docker/entrypoint.sh is the key file for understanding the box's behavior at runtime. On first boot it generates a random WordPress admin account and exports the cred