该挑战涉及一个基于 Debian Trixie 镜像的 Docker/Kubernetes 部署，其中运行着 PHP 8.2/Apache 环境下的原生 WordPress 7.0.0 安装。初始访问是通过已知存在漏洞的插件 wp2shell 获得的，该插件提供了 www-data 权限的 shell。主要目标是提权，该环境已针对典型的容器逃逸和 SUID 技巧进行了有意加固，指向最近的 sudo CVE。侦察发现 Dockerfile 锁定了特定版本，特别是运行时镜像中存在的 gcc 和 libc6-dev，表明存在本地编译以进行提权的可能性。sudo 的存在进一步将焦点锁定在 sudo 本地提权漏洞上。docker-compose.yml 暴露了默认的 WordPress 数据库凭据。docker/entrypoint.sh 脚本至关重要，因为它在首次启动时生成随机的 WordPress 管理员凭据，并将其导出到容器环境中，Apache/PHP 工作进程等子进程可访问这些凭据。主题目录 brunnerne-docs 被有意设置为 root 所有但世界可读，这可能是针对 root 执行钩子的一个误导项。初始访问利用了 wp2shell-poc，这是一个针对 WordPress 7.0.0 的公开利用链，涉及 CVE-2026-63030（未认证盲 SQL 注入）和 CVE-2026-60137（在恢复管理员凭据后通过插件上传实现远程代码执行）。这获得了以 www-data 身份运行的反向 shell。以 www-data 身份进行的枚举显示这是一个加固环境，没有异常的 SUID 二进制文件、能力或世界可写的 root 所有文件。识别出 sudo 版本为 1.9.15p5，这是关键信息。在 /proc/*/environ 中搜索凭据发现了 WordPress 管理员凭据，但这些并非 sudo 的系统凭据。尝试使用这些凭据或默认密码执行 sudo 均失败。提权是通过利用 CVE-2025-32463 实现的，该漏洞影响 sudo 1.9.14 至 1.9.17 版本。此漏洞允许任何本地用户利用 --chroot/-R 选项，从自提供的 chroot 中加载攻击者控制的 NSS 共享库，从而在没有 sudoers 条目或密码的情况下以 root 身份执行任意代码。该利用涉及编译一个恶意的 NSS 模块以生成 root shell，搭建一个包含自定义 nsswitch.conf（指向该模块）的虚假 chroot 目录，然后通过执行 'sudo -R woot woot' 触发它。这成功获得了 root shell，从而能够访问 flag。根本原因是 WordPress 核心未认证 SQL 注入导致初始访问时的远程代码执行，以及 sudo 1.9.15p5 漏洞（CVE-2025-32463）导致的提权。修复方案是将 sudo 升级到 >= 1.9.17p1 版本。关键经验教训包括尽早检查特权二进制文件的版本，并识别如 gcc/libc6-dev 存在等提示，以判断是否可在目标上进行本地编译。