1. 项目概述一次对WordPress AI Engine插件信息泄露漏洞的深度剖析最近在安全研究圈里CVE-2025-11749这个编号开始频繁出现它指向的是一个影响WordPress AI Engine插件的信息泄露漏洞。作为一名长期关注Web应用安全的研究者我习惯性地会去追踪这类影响广泛CMS生态的漏洞。WordPress的插件生态庞大而复杂一个热门插件的漏洞往往意味着成千上万个网站可能暴露在风险之下。AI Engine作为一款集成了多种AI功能的插件其用户量不容小觑这使得对该漏洞的研究具有了现实的安全意义。这篇文章我将从一个实战研究者的角度带你完整地复现CVE-2025-11749并深入拆解其背后的成因、影响范围以及在实际渗透测试或安全评估中如何利用与防御。整个过程不涉及任何攻击性行为纯粹出于技术研究与安全加固的目的旨在帮助网站管理员和安全从业者理解风险及时修补。简单来说这个漏洞的核心在于未经身份验证的攻击者能够通过构造特定的请求访问到本应受权限保护的敏感信息。这听起来像是典型的“越权访问”或“信息泄露”但具体到AI Engine插件里它是如何发生的泄露的信息又有多敏感这正是我们接下来要一步步揭开的谜底。我会基于一个可控的本地测试环境使用Docker快速搭建靶场然后逐步演示漏洞触发的条件、请求的构造方式并分析其底层代码逻辑。无论你是想了解漏洞原理的安全爱好者还是负责网站安全运维的管理员这篇文章都能为你提供从理论到实操的完整视角。2. 漏洞环境搭建与核心原理初探2.1 靶场环境快速部署要研究一个漏洞第一步永远是搭建一个可以安全、合法进行测试的环境。我强烈建议在隔离的虚拟机或使用Docker容器中进行避免对任何生产环境造成影响。这里我选择使用Docker因为它能提供最干净、可一键销毁的环境。首先我们需要一个包含漏洞版本的WordPress和AI Engine插件。根据漏洞披露信息CVE-2025-11749影响AI Engine插件2.6.0及之前的所有版本。因此我们的目标就是部署一个安装了AI Engine插件v2.6.0的WordPress。我准备了一个简单的docker-compose.yml文件来快速拉起环境version: 3.8 services: db: image: mysql:5.7 volumes: - db_data:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: some_root_password MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: image: wordpress:6.5-php8.1-apache depends_on: - db ports: - 8080:80 restart: always environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: wordpress volumes: - ./wp-content:/var/www/html/wp-content - ./ai-engine.2.6.0.zip:/tmp/ai-engine.zip这个配置使用了官方的WordPress 6.5镜像和MySQL 5.7数据库。关键点在于两个卷挂载第一个将本地的wp-content目录挂载进去方便我们后续安装插件第二个将事先下载好的AI Engine插件v2.6.0的ZIP包挂载到容器内的/tmp目录。注意务必从可靠的插件存档站点或历史版本库获取ai-engine.2.6.0.zip确保其文件完整性避免引入其他风险。启动服务后访问http://localhost:8080完成WordPress的著名“五分钟安装”。安装完成后进入后台管理界面。由于我们已将插件ZIP包挂载到容器内可以通过WordPress后台的“上传插件”功能直接从/tmp/ai-engine.zip路径安装。安装并激活插件后我们的漏洞靶场就准备就绪了。2.2 漏洞核心原理不当的权限校验与REST API端点WordPress从4.7版本开始引入了REST API为插件和主题提供了强大的、基于JSON的交互接口。这极大地扩展了WordPress的功能但也引入了新的安全考量每一个由插件注册的REST API端点都必须进行严格的权限校验Permission Callback以确定当前请求的用户是否有权执行该操作。CVE-2025-11749的根源正是AI Engine插件在注册某个或某些REST API端点时权限回调函数设置不当。具体来说插件开发者可能使用了__return_true或一个始终返回true的自定义函数作为权限回调或者完全遗漏了该参数。在WordPress REST API中注册路由的函数是register_rest_route。一个安全的注册应该像这样register_rest_route( my-plugin/v1, /sensitive-data/, array( methods GET, callback my_sensitive_function, permission_callback function () { return current_user_can( manage_options ); // 检查用户是否有管理员权限 }, ) );而存在漏洞的代码可能长这样register_rest_route( ai-engine/v1, /export-data/, array( methods GET, callback ai_engine_export_sensitive_data, permission_callback __return_true, // 危险对任何人开放权限 ) );或者更隐蔽的直接省略了permission_callback参数。在WordPress REST API的默认行为中如果permission_callback未设置为了向后兼容它会默认允许公共访问类似于__return_true。这正是许多信息泄露漏洞的罪魁祸首。AI Engine插件作为一个功能复杂的AI集成工具很可能提供了数据导出、配置读取、对话记录查看等功能端点。如果这些端点被错误地暴露给了未认证用户那么攻击者无需登录只需知道正确的API路由就能直接获取到敏感信息。接下来我们就需要找出这个具体的“路由”是什么。3. 漏洞复现与敏感信息获取实战3.1 信息搜集与端点枚举在开始攻击模拟之前我们必须先进行信息搜集。我们的目标是找到AI Engine插件注册的、且存在权限缺陷的REST API端点。有几种常见的方法直接代码审计这是最根本的方法。解压AI Engine插件在PHP文件中搜索register_rest_route函数。通过分析其参数特别是permission_callback可以快速定位潜在问题。对于研究人员这是首选。网络流量分析在已登录的WordPress后台使用浏览器开发者工具F12的“网络”选项卡观察在操作AI Engine插件功能时如导出设置、查看日志产生了哪些API请求。这些请求的路径就是插件的REST端点。使用扫描工具像wpscan这样的WordPress安全扫描器在更新漏洞数据库后可以识别存在已知漏洞的插件并可能提供测试路径。但对于一个较新的CVE工具可能还未集成POC。为了更贴近实战中“黑盒”测试的场景我们假设没有插件源代码采用第二种方法结合一些推理。首先访问我们搭建的站点首页确认插件已激活。然后我们尝试访问WordPress的默认REST API索引看看有哪些命名空间被注册GET http://localhost:8080/wp-json/在返回的JSON中寻找类似ai-engine或meowappsAI Engine插件开发商的命名空间。果然我们发现了/wp-json/ai-engine/v1这个端点。接下来我们需要枚举这个v1命名空间下的所有路由。WordPress REST API通常不直接提供完整的路由列表但我们可以尝试一些常见的端点路径进行探测。结合AI Engine插件的功能AI聊天、内容生成、日志记录、设置导出可以猜测一些可能的端点/ai-engine/v1/settings/ai-engine/v1/chat/ai-engine/v1/logs/ai-engine/v1/export/ai-engine/v1/config我们使用curl或浏览器逐一测试这些路径注意使用GET方法curl -s http://localhost:8080/wp-json/ai-engine/v1/settings | jq .如果某个端点返回了“rest_no_route”错误说明路径不存在。如果返回了“rest_forbidden”或要求认证的错误说明该端点权限校验正常。而如果某个端点直接返回了JSON格式的敏感数据……那么漏洞就找到了。3.2 构造请求与数据提取经过一番测试假设我们发现了端点/wp-json/ai-engine/v1/export-settings在未认证的情况下返回了数据。返回的JSON结构可能包含插件的完整配置选项集成的AI服务API密钥如OpenAI API Key、Google Gemini API Key等自定义提示词模板网站用户与AI的交互日志摘要其他内部配置信息实操心得在实际测试中返回的数据结构可能非常丰富。务必仔细查看每一个字段。API密钥通常以sk-开头OpenAI或是一长串Base64编码的字符串。这些密钥一旦泄露攻击者就可以直接盗用产生不可预估的经济损失和安全隐患。此外对话日志中可能包含用户提交的隐私信息。为了更系统地验证漏洞我们可以编写一个简单的Python脚本来批量探测可能的端点并保存响应结果import requests import json base_url http://localhost:8080 namespace /wp-json/ai-engine/v1 # 根据插件功能猜测的端点列表 endpoints [ /settings, /config, /export, /logs, /chat-sessions, /tokens, /models, /prompts ] for endpoint in endpoints: url base_url namespace endpoint try: response requests.get(url, timeout5) print(f[*] Testing: {url}) print(f Status: {response.status_code}) if response.status_code 200: print(f Response (first 500 chars): {response.text[:500]}) # 保存有数据的响应以便分析 with open(fresponse_{endpoint.replace(/, _)}.json, w) as f: json.dump(response.json(), f, indent2) elif response.status_code 403: print( (Requires authentication)) else: print(f (Unexpected status)) print(- * 50) except Exception as e: print(f[!] Error testing {url}: {e})运行这个脚本可以快速筛选出哪些端点是可以未授权访问的。这就是CVE-2025-11749漏洞被触发的核心过程攻击者通过枚举或猜测有时漏洞细节公开后路径是固定的找到了一个未受保护的REST API端点从而直接窃取数据。3.3 泄露信息的严重性评估获取到数据后我们需要评估其严重性。信息泄露漏洞的等级CVSS评分取决于泄露信息的敏感程度。对于AI Engine插件可能泄露的信息包括高敏感度第三方AI API密钥这是最严重的。攻击者可以利用这些密钥直接调用对应的AI服务如OpenAI、Anthropic产生的费用将由密钥所有者承担并且可能用于其他恶意活动。数据库凭据虽然插件通常不直接存储数据库密码但如果配置错误可能泄露其他服务的连接信息。中敏感度插件完整配置包括所有开关、模型选择、费用限制等。这暴露了网站AI功能的运作细节。自定义提示词Prompts这些可能是网站运营者精心设计的、具有商业价值的提示工程成果。低敏感度内部功能标识符、版本号有助于攻击者进行更精准的指纹识别和后续攻击。如果泄露的信息中包含API密钥那么这个漏洞的严重性就是“高危”High或“严重”Critical。攻击者无需攻破服务器只需发送一个简单的HTTP GET请求就能造成实质性的财产损失和业务风险。这正是CVE-2025-11749需要被高度重视的原因。4. 漏洞根因分析与代码审计视角4.1 定位问题代码为了彻底理解漏洞我们需要深入插件代码。解压ai-engine.2.6.0.zip在插件根目录下我们通常会在主文件如ai-engine.php或一个专门的includes/、src/、classes/目录中找到REST API相关的注册代码。使用文本编辑器或IDE的全局搜索功能搜索register_rest_route。我们可能会在某个文件例如includes/class-rest-api.php中找到类似下面的代码段// 文件includes/class-rest-api.php public function register_routes() { register_rest_route( $this-namespace, /export-settings, array( array( methods WP_REST_Server::READABLE, callback array( $this, export_settings ), // 缺失 permission_callback 参数 ), ) ); register_rest_route( $this-namespace, /get-logs, array( array( methods WP_REST_Server::READABLE, callback array( $this, get_chat_logs ), permission_callback __return_true, // 错误地设置为始终为真 ), ) ); }在上面的示例中第一个路由/export-settings完全省略了permission_callback。根据WordPress REST API的默认行为这会导致该端点允许公共访问。第二个路由/get-logs虽然设置了permission_callback但错误地使用了__return_true这是一个WordPress内置函数字面意思就是“返回真”这同样意味着允许任何人访问。正确的做法应该是使用一个函数来检查用户能力Capabilities例如permission_callback function () { return current_user_can( manage_options ); // 仅允许管理员 }或者如果该端点需要为登录用户提供但权限要求不同permission_callback function () { return is_user_logged_in(); // 仅允许登录用户 }4.2 漏洞的触发条件与影响版本从代码分析可以明确该漏洞的触发条件非常简单攻击者能够通过网络访问到存在漏洞的WordPress网站并且知道或能猜测出存在缺陷的REST API端点路径。无需任何用户账户无需任何特殊技巧。影响版本方面根据漏洞披露AI Engine插件从某个引入该REST API端点的版本开始直到2.6.0版本均未正确设置权限回调。这意味着在很长一段时间内安装并启用该插件的网站都处于风险之中。插件用户量越大漏洞的影响面就越广。注意事项在进行代码审计时不要只看一个端点。这种权限校验缺失的问题往往不是孤例。如果开发者在注册REST API时养成了不好的习惯如忘记设置回调那么很可能在多个端点中都存在同样的问题。因此在搜索register_rest_route时需要逐一检查每个路由的permission_callback参数是否被正确、安全地设置。5. 漏洞修复方案与安全加固建议5.1 官方修复与升级对于此类在流行插件中发现的漏洞最直接、最有效的修复方案永远是升级插件到最新版本。插件开发团队在收到漏洞报告后通常会迅速发布安全更新。对于CVE-2025-11749AI Engine插件在后续版本如2.6.1或更高中应该已经修复了这个问题。修复方式就是在存在问题的register_rest_route调用中添加或修正permission_callback参数。例如将之前漏洞代码修改为register_rest_route( $this-namespace, /export-settings, array( array( methods WP_REST_Server::READABLE, callback array( $this, export_settings ), permission_callback array( $this, check_admin_permissions ), // 新增权限检查 ), ) );并在类中定义check_admin_permissions方法public function check_admin_permissions() { return current_user_can( manage_options ); }因此所有网站管理员应立即执行以下操作登录WordPress后台。进入“插件”页面。找到“AI Engine”插件检查其版本号。如果有可用更新立即更新到最新版本。更新完成后建议清除网站缓存如果使用了缓存插件。5.2 临时缓解措施如果由于某些原因无法立即升级例如新版本与主题存在兼容性问题可以考虑以下临时缓解措施禁用插件如果暂时不需要使用AI Engine的功能最彻底的方法是直接停用该插件。这能立即消除风险。使用Web应用防火墙规则如果网站使用了云WAF如Cloudflare或服务器层面的WAF如ModSecurity可以添加一条规则拦截对可疑路径/wp-json/ai-engine/v1/*的未授权访问请求。规则可以设置为当请求路径匹配该模式且请求头中不包含有效的认证信息如WordPress登录Cookie或JWT Token时则阻止或记录该请求。注意这种方法需要一定的安全运维能力且规则需要精确避免误杀合法的前端AJAX请求如果插件有前端功能调用了这些API。修改.htaccess文件针对Apache服务器在网站根目录的.htaccess文件中添加以下规则阻止对漏洞端点的访问IfModule mod_rewrite.c RewriteEngine On RewriteCond %{REQUEST_URI} ^/wp-json/ai-engine/v1/ [NC] RewriteCond %{HTTP:Cookie} !wordpress_logged_in_[^] [NC] RewriteRule ^ - [F,L] /IfModule这条规则会禁止所有未携带WordPress登录Cookie的、对/wp-json/ai-engine/v1/路径下内容的访问返回403禁止状态码。重要警告此方法较为粗暴如果插件的某些功能需要为登录用户或前端提供API服务此规则会将其一并阻断。它仅作为无法升级时的紧急应对方案。5.3 对开发者的安全启示对于WordPress插件开发者而言CVE-2025-11749是一个经典的反面教材它强调了以下几点安全开发规范永远不要省略permission_callback在注册每个REST API路由时必须显式地、谨慎地定义permission_callback。即使你认为某个端点应该是公开的也应明确地使用__return_true并做好记录而不是依赖默认行为。遵循最小权限原则权限回调函数应只授予完成操作所必需的最小权限。不要为了方便而滥用manage_options管理员权限对于普通用户操作应使用edit_posts、read等更细粒度的能力检查。进行安全代码审查在插件发布前对涉及数据查询和API响应的代码进行专项安全审查重点关注权限校验、SQL注入、数据过滤与转义等问题。使用非ces对于敏感操作如导出、删除、修改配置即使通过了权限检查也应考虑增加Nonce一次性令牌验证防止CSRF攻击。6. 漏洞研究中的常见问题与排查技巧在复现和研究此类REST API信息泄露漏洞时你可能会遇到一些典型问题。以下是我在实际操作中总结的一些排查技巧6.1 问题无法找到或访问REST API端点可能原因1插件未正确激活或REST API未注册。排查首先访问http://your-site/wp-json/查看返回的JSON中是否包含插件的命名空间如ai-engine。如果没有检查插件是否已激活或尝试在代码中搜索register_rest_route确认注册逻辑是否在特定条件下才执行。可能原因2WordPress固定链接Permalink设置问题。排查REST API依赖重写规则。进入WordPress后台“设置”-“固定链接”确保未设置为“朴素”Plain。选择除“朴素”外的任何结构如“文章名”并保存更改。这通常会刷新重写规则。可能原因3服务器配置阻止了对wp-json的访问。排查检查服务器如Nginx、Apache的配置文件或.htaccess文件看是否有规则屏蔽了/wp-json/路径的访问。同时检查是否有安全插件如Wordfence设置了过于严格的REST API访问规则。6.2 问题端点返回403错误但怀疑其仍存在漏洞可能原因权限回调函数存在逻辑缺陷但在你的测试环境下不满足触发条件。排查仔细审查权限回调函数的代码。有时漏洞不是简单的__return_true而是逻辑错误。例如函数可能检查一个用户参数但这个参数可以被恶意操控绕过。此时需要结合代码审计进行白盒分析构造特殊的请求参数来测试。6.3 问题复现环境与真实环境行为不一致可能原因1插件版本差异。排查确认你使用的漏洞插件版本与公开漏洞描述中的影响版本完全一致。插件的次版本号如2.6.0和2.6.1之间可能存在修复。可能原因2WordPress核心或其他插件/主题的冲突。排查在测试环境中尽量保持“干净”——只启用存在漏洞的插件和默认主题如Twenty Twenty-Four。禁用所有其他插件排除干扰。这是安全测试的标准做法。6.4 问题获取到的数据看似无关或加密可能原因数据被编码或序列化。排查查看响应头的Content-Type确认是application/json。如果是数据可能是JSON格式的。如果数据看起来像乱码可能是经过Base64编码或PHP序列化的字符串。尝试使用json_decode()解析JSON或用base64_decode()、unserialize()谨慎使用存在安全风险进行解码。在PHP中可以写一个小脚本快速测试$response file_get_contents(path/to/response.json); $data json_decode($response, true); if (json_last_error() JSON_ERROR_NONE) { print_r($data); } else { // 尝试Base64解码 $decoded base64_decode($response, true); if ($decoded ! false) { echo $decoded; } else { echo Unable to decode.; } }6.5 漏洞验证的伦理与法律边界最后也是最重要的一点我必须强调所有漏洞研究和复现都必须在你自己拥有完全控制权的环境中进行。未经授权对任何他人的网站、系统进行漏洞扫描、探测或攻击测试不仅是非法的而且违背了安全研究的职业道德。我们研究漏洞目的是为了理解其原理从而更好地防御它。对于网站管理员希望这篇文章能让你意识到及时更新插件的重要性对于开发者希望它能提醒你在编码时牢记安全规范对于安全爱好者希望它提供了一个完整的学习案例。安全是一个共同的责任通过负责任的研究和分享我们才能让网络空间变得更加安全。
WordPress AI Engine插件信息泄露漏洞CVE-2025-11749深度剖析与复现
发布时间：2026/6/29 16:11:33
1. 项目概述一次对WordPress AI Engine插件信息泄露漏洞的深度剖析最近在安全研究圈里CVE-2025-11749这个编号开始频繁出现它指向的是一个影响WordPress AI Engine插件的信息泄露漏洞。作为一名长期关注Web应用安全的研究者我习惯性地会去追踪这类影响广泛CMS生态的漏洞。WordPress的插件生态庞大而复杂一个热门插件的漏洞往往意味着成千上万个网站可能暴露在风险之下。AI Engine作为一款集成了多种AI功能的插件其用户量不容小觑这使得对该漏洞的研究具有了现实的安全意义。这篇文章我将从一个实战研究者的角度带你完整地复现CVE-2025-11749并深入拆解其背后的成因、影响范围以及在实际渗透测试或安全评估中如何利用与防御。整个过程不涉及任何攻击性行为纯粹出于技术研究与安全加固的目的旨在帮助网站管理员和安全从业者理解风险及时修补。简单来说这个漏洞的核心在于未经身份验证的攻击者能够通过构造特定的请求访问到本应受权限保护的敏感信息。这听起来像是典型的“越权访问”或“信息泄露”但具体到AI Engine插件里它是如何发生的泄露的信息又有多敏感这正是我们接下来要一步步揭开的谜底。我会基于一个可控的本地测试环境使用Docker快速搭建靶场然后逐步演示漏洞触发的条件、请求的构造方式并分析其底层代码逻辑。无论你是想了解漏洞原理的安全爱好者还是负责网站安全运维的管理员这篇文章都能为你提供从理论到实操的完整视角。2. 漏洞环境搭建与核心原理初探2.1 靶场环境快速部署要研究一个漏洞第一步永远是搭建一个可以安全、合法进行测试的环境。我强烈建议在隔离的虚拟机或使用Docker容器中进行避免对任何生产环境造成影响。这里我选择使用Docker因为它能提供最干净、可一键销毁的环境。首先我们需要一个包含漏洞版本的WordPress和AI Engine插件。根据漏洞披露信息CVE-2025-11749影响AI Engine插件2.6.0及之前的所有版本。因此我们的目标就是部署一个安装了AI Engine插件v2.6.0的WordPress。我准备了一个简单的docker-compose.yml文件来快速拉起环境version: 3.8 services: db: image: mysql:5.7 volumes: - db_data:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: some_root_password MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: image: wordpress:6.5-php8.1-apache depends_on: - db ports: - 8080:80 restart: always environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: wordpress volumes: - ./wp-content:/var/www/html/wp-content - ./ai-engine.2.6.0.zip:/tmp/ai-engine.zip这个配置使用了官方的WordPress 6.5镜像和MySQL 5.7数据库。关键点在于两个卷挂载第一个将本地的wp-content目录挂载进去方便我们后续安装插件第二个将事先下载好的AI Engine插件v2.6.0的ZIP包挂载到容器内的/tmp目录。注意务必从可靠的插件存档站点或历史版本库获取ai-engine.2.6.0.zip确保其文件完整性避免引入其他风险。启动服务后访问http://localhost:8080完成WordPress的著名“五分钟安装”。安装完成后进入后台管理界面。由于我们已将插件ZIP包挂载到容器内可以通过WordPress后台的“上传插件”功能直接从/tmp/ai-engine.zip路径安装。安装并激活插件后我们的漏洞靶场就准备就绪了。2.2 漏洞核心原理不当的权限校验与REST API端点WordPress从4.7版本开始引入了REST API为插件和主题提供了强大的、基于JSON的交互接口。这极大地扩展了WordPress的功能但也引入了新的安全考量每一个由插件注册的REST API端点都必须进行严格的权限校验Permission Callback以确定当前请求的用户是否有权执行该操作。CVE-2025-11749的根源正是AI Engine插件在注册某个或某些REST API端点时权限回调函数设置不当。具体来说插件开发者可能使用了__return_true或一个始终返回true的自定义函数作为权限回调或者完全遗漏了该参数。在WordPress REST API中注册路由的函数是register_rest_route。一个安全的注册应该像这样register_rest_route( my-plugin/v1, /sensitive-data/, array( methods GET, callback my_sensitive_function, permission_callback function () { return current_user_can( manage_options ); // 检查用户是否有管理员权限 }, ) );而存在漏洞的代码可能长这样register_rest_route( ai-engine/v1, /export-data/, array( methods GET, callback ai_engine_export_sensitive_data, permission_callback __return_true, // 危险对任何人开放权限 ) );或者更隐蔽的直接省略了permission_callback参数。在WordPress REST API的默认行为中如果permission_callback未设置为了向后兼容它会默认允许公共访问类似于__return_true。这正是许多信息泄露漏洞的罪魁祸首。AI Engine插件作为一个功能复杂的AI集成工具很可能提供了数据导出、配置读取、对话记录查看等功能端点。如果这些端点被错误地暴露给了未认证用户那么攻击者无需登录只需知道正确的API路由就能直接获取到敏感信息。接下来我们就需要找出这个具体的“路由”是什么。3. 漏洞复现与敏感信息获取实战3.1 信息搜集与端点枚举在开始攻击模拟之前我们必须先进行信息搜集。我们的目标是找到AI Engine插件注册的、且存在权限缺陷的REST API端点。有几种常见的方法直接代码审计这是最根本的方法。解压AI Engine插件在PHP文件中搜索register_rest_route函数。通过分析其参数特别是permission_callback可以快速定位潜在问题。对于研究人员这是首选。网络流量分析在已登录的WordPress后台使用浏览器开发者工具F12的“网络”选项卡观察在操作AI Engine插件功能时如导出设置、查看日志产生了哪些API请求。这些请求的路径就是插件的REST端点。使用扫描工具像wpscan这样的WordPress安全扫描器在更新漏洞数据库后可以识别存在已知漏洞的插件并可能提供测试路径。但对于一个较新的CVE工具可能还未集成POC。为了更贴近实战中“黑盒”测试的场景我们假设没有插件源代码采用第二种方法结合一些推理。首先访问我们搭建的站点首页确认插件已激活。然后我们尝试访问WordPress的默认REST API索引看看有哪些命名空间被注册GET http://localhost:8080/wp-json/在返回的JSON中寻找类似ai-engine或meowappsAI Engine插件开发商的命名空间。果然我们发现了/wp-json/ai-engine/v1这个端点。接下来我们需要枚举这个v1命名空间下的所有路由。WordPress REST API通常不直接提供完整的路由列表但我们可以尝试一些常见的端点路径进行探测。结合AI Engine插件的功能AI聊天、内容生成、日志记录、设置导出可以猜测一些可能的端点/ai-engine/v1/settings/ai-engine/v1/chat/ai-engine/v1/logs/ai-engine/v1/export/ai-engine/v1/config我们使用curl或浏览器逐一测试这些路径注意使用GET方法curl -s http://localhost:8080/wp-json/ai-engine/v1/settings | jq .如果某个端点返回了“rest_no_route”错误说明路径不存在。如果返回了“rest_forbidden”或要求认证的错误说明该端点权限校验正常。而如果某个端点直接返回了JSON格式的敏感数据……那么漏洞就找到了。3.2 构造请求与数据提取经过一番测试假设我们发现了端点/wp-json/ai-engine/v1/export-settings在未认证的情况下返回了数据。返回的JSON结构可能包含插件的完整配置选项集成的AI服务API密钥如OpenAI API Key、Google Gemini API Key等自定义提示词模板网站用户与AI的交互日志摘要其他内部配置信息实操心得在实际测试中返回的数据结构可能非常丰富。务必仔细查看每一个字段。API密钥通常以sk-开头OpenAI或是一长串Base64编码的字符串。这些密钥一旦泄露攻击者就可以直接盗用产生不可预估的经济损失和安全隐患。此外对话日志中可能包含用户提交的隐私信息。为了更系统地验证漏洞我们可以编写一个简单的Python脚本来批量探测可能的端点并保存响应结果import requests import json base_url http://localhost:8080 namespace /wp-json/ai-engine/v1 # 根据插件功能猜测的端点列表 endpoints [ /settings, /config, /export, /logs, /chat-sessions, /tokens, /models, /prompts ] for endpoint in endpoints: url base_url namespace endpoint try: response requests.get(url, timeout5) print(f[*] Testing: {url}) print(f Status: {response.status_code}) if response.status_code 200: print(f Response (first 500 chars): {response.text[:500]}) # 保存有数据的响应以便分析 with open(fresponse_{endpoint.replace(/, _)}.json, w) as f: json.dump(response.json(), f, indent2) elif response.status_code 403: print( (Requires authentication)) else: print(f (Unexpected status)) print(- * 50) except Exception as e: print(f[!] Error testing {url}: {e})运行这个脚本可以快速筛选出哪些端点是可以未授权访问的。这就是CVE-2025-11749漏洞被触发的核心过程攻击者通过枚举或猜测有时漏洞细节公开后路径是固定的找到了一个未受保护的REST API端点从而直接窃取数据。3.3 泄露信息的严重性评估获取到数据后我们需要评估其严重性。信息泄露漏洞的等级CVSS评分取决于泄露信息的敏感程度。对于AI Engine插件可能泄露的信息包括高敏感度第三方AI API密钥这是最严重的。攻击者可以利用这些密钥直接调用对应的AI服务如OpenAI、Anthropic产生的费用将由密钥所有者承担并且可能用于其他恶意活动。数据库凭据虽然插件通常不直接存储数据库密码但如果配置错误可能泄露其他服务的连接信息。中敏感度插件完整配置包括所有开关、模型选择、费用限制等。这暴露了网站AI功能的运作细节。自定义提示词Prompts这些可能是网站运营者精心设计的、具有商业价值的提示工程成果。低敏感度内部功能标识符、版本号有助于攻击者进行更精准的指纹识别和后续攻击。如果泄露的信息中包含API密钥那么这个漏洞的严重性就是“高危”High或“严重”Critical。攻击者无需攻破服务器只需发送一个简单的HTTP GET请求就能造成实质性的财产损失和业务风险。这正是CVE-2025-11749需要被高度重视的原因。4. 漏洞根因分析与代码审计视角4.1 定位问题代码为了彻底理解漏洞我们需要深入插件代码。解压ai-engine.2.6.0.zip在插件根目录下我们通常会在主文件如ai-engine.php或一个专门的includes/、src/、classes/目录中找到REST API相关的注册代码。使用文本编辑器或IDE的全局搜索功能搜索register_rest_route。我们可能会在某个文件例如includes/class-rest-api.php中找到类似下面的代码段// 文件includes/class-rest-api.php public function register_routes() { register_rest_route( $this-namespace, /export-settings, array( array( methods WP_REST_Server::READABLE, callback array( $this, export_settings ), // 缺失 permission_callback 参数 ), ) ); register_rest_route( $this-namespace, /get-logs, array( array( methods WP_REST_Server::READABLE, callback array( $this, get_chat_logs ), permission_callback __return_true, // 错误地设置为始终为真 ), ) ); }在上面的示例中第一个路由/export-settings完全省略了permission_callback。根据WordPress REST API的默认行为这会导致该端点允许公共访问。第二个路由/get-logs虽然设置了permission_callback但错误地使用了__return_true这是一个WordPress内置函数字面意思就是“返回真”这同样意味着允许任何人访问。正确的做法应该是使用一个函数来检查用户能力Capabilities例如permission_callback function () { return current_user_can( manage_options ); // 仅允许管理员 }或者如果该端点需要为登录用户提供但权限要求不同permission_callback function () { return is_user_logged_in(); // 仅允许登录用户 }4.2 漏洞的触发条件与影响版本从代码分析可以明确该漏洞的触发条件非常简单攻击者能够通过网络访问到存在漏洞的WordPress网站并且知道或能猜测出存在缺陷的REST API端点路径。无需任何用户账户无需任何特殊技巧。影响版本方面根据漏洞披露AI Engine插件从某个引入该REST API端点的版本开始直到2.6.0版本均未正确设置权限回调。这意味着在很长一段时间内安装并启用该插件的网站都处于风险之中。插件用户量越大漏洞的影响面就越广。注意事项在进行代码审计时不要只看一个端点。这种权限校验缺失的问题往往不是孤例。如果开发者在注册REST API时养成了不好的习惯如忘记设置回调那么很可能在多个端点中都存在同样的问题。因此在搜索register_rest_route时需要逐一检查每个路由的permission_callback参数是否被正确、安全地设置。5. 漏洞修复方案与安全加固建议5.1 官方修复与升级对于此类在流行插件中发现的漏洞最直接、最有效的修复方案永远是升级插件到最新版本。插件开发团队在收到漏洞报告后通常会迅速发布安全更新。对于CVE-2025-11749AI Engine插件在后续版本如2.6.1或更高中应该已经修复了这个问题。修复方式就是在存在问题的register_rest_route调用中添加或修正permission_callback参数。例如将之前漏洞代码修改为register_rest_route( $this-namespace, /export-settings, array( array( methods WP_REST_Server::READABLE, callback array( $this, export_settings ), permission_callback array( $this, check_admin_permissions ), // 新增权限检查 ), ) );并在类中定义check_admin_permissions方法public function check_admin_permissions() { return current_user_can( manage_options ); }因此所有网站管理员应立即执行以下操作登录WordPress后台。进入“插件”页面。找到“AI Engine”插件检查其版本号。如果有可用更新立即更新到最新版本。更新完成后建议清除网站缓存如果使用了缓存插件。5.2 临时缓解措施如果由于某些原因无法立即升级例如新版本与主题存在兼容性问题可以考虑以下临时缓解措施禁用插件如果暂时不需要使用AI Engine的功能最彻底的方法是直接停用该插件。这能立即消除风险。使用Web应用防火墙规则如果网站使用了云WAF如Cloudflare或服务器层面的WAF如ModSecurity可以添加一条规则拦截对可疑路径/wp-json/ai-engine/v1/*的未授权访问请求。规则可以设置为当请求路径匹配该模式且请求头中不包含有效的认证信息如WordPress登录Cookie或JWT Token时则阻止或记录该请求。注意这种方法需要一定的安全运维能力且规则需要精确避免误杀合法的前端AJAX请求如果插件有前端功能调用了这些API。修改.htaccess文件针对Apache服务器在网站根目录的.htaccess文件中添加以下规则阻止对漏洞端点的访问IfModule mod_rewrite.c RewriteEngine On RewriteCond %{REQUEST_URI} ^/wp-json/ai-engine/v1/ [NC] RewriteCond %{HTTP:Cookie} !wordpress_logged_in_[^] [NC] RewriteRule ^ - [F,L] /IfModule这条规则会禁止所有未携带WordPress登录Cookie的、对/wp-json/ai-engine/v1/路径下内容的访问返回403禁止状态码。重要警告此方法较为粗暴如果插件的某些功能需要为登录用户或前端提供API服务此规则会将其一并阻断。它仅作为无法升级时的紧急应对方案。5.3 对开发者的安全启示对于WordPress插件开发者而言CVE-2025-11749是一个经典的反面教材它强调了以下几点安全开发规范永远不要省略permission_callback在注册每个REST API路由时必须显式地、谨慎地定义permission_callback。即使你认为某个端点应该是公开的也应明确地使用__return_true并做好记录而不是依赖默认行为。遵循最小权限原则权限回调函数应只授予完成操作所必需的最小权限。不要为了方便而滥用manage_options管理员权限对于普通用户操作应使用edit_posts、read等更细粒度的能力检查。进行安全代码审查在插件发布前对涉及数据查询和API响应的代码进行专项安全审查重点关注权限校验、SQL注入、数据过滤与转义等问题。使用非ces对于敏感操作如导出、删除、修改配置即使通过了权限检查也应考虑增加Nonce一次性令牌验证防止CSRF攻击。6. 漏洞研究中的常见问题与排查技巧在复现和研究此类REST API信息泄露漏洞时你可能会遇到一些典型问题。以下是我在实际操作中总结的一些排查技巧6.1 问题无法找到或访问REST API端点可能原因1插件未正确激活或REST API未注册。排查首先访问http://your-site/wp-json/查看返回的JSON中是否包含插件的命名空间如ai-engine。如果没有检查插件是否已激活或尝试在代码中搜索register_rest_route确认注册逻辑是否在特定条件下才执行。可能原因2WordPress固定链接Permalink设置问题。排查REST API依赖重写规则。进入WordPress后台“设置”-“固定链接”确保未设置为“朴素”Plain。选择除“朴素”外的任何结构如“文章名”并保存更改。这通常会刷新重写规则。可能原因3服务器配置阻止了对wp-json的访问。排查检查服务器如Nginx、Apache的配置文件或.htaccess文件看是否有规则屏蔽了/wp-json/路径的访问。同时检查是否有安全插件如Wordfence设置了过于严格的REST API访问规则。6.2 问题端点返回403错误但怀疑其仍存在漏洞可能原因权限回调函数存在逻辑缺陷但在你的测试环境下不满足触发条件。排查仔细审查权限回调函数的代码。有时漏洞不是简单的__return_true而是逻辑错误。例如函数可能检查一个用户参数但这个参数可以被恶意操控绕过。此时需要结合代码审计进行白盒分析构造特殊的请求参数来测试。6.3 问题复现环境与真实环境行为不一致可能原因1插件版本差异。排查确认你使用的漏洞插件版本与公开漏洞描述中的影响版本完全一致。插件的次版本号如2.6.0和2.6.1之间可能存在修复。可能原因2WordPress核心或其他插件/主题的冲突。排查在测试环境中尽量保持“干净”——只启用存在漏洞的插件和默认主题如Twenty Twenty-Four。禁用所有其他插件排除干扰。这是安全测试的标准做法。6.4 问题获取到的数据看似无关或加密可能原因数据被编码或序列化。排查查看响应头的Content-Type确认是application/json。如果是数据可能是JSON格式的。如果数据看起来像乱码可能是经过Base64编码或PHP序列化的字符串。尝试使用json_decode()解析JSON或用base64_decode()、unserialize()谨慎使用存在安全风险进行解码。在PHP中可以写一个小脚本快速测试$response file_get_contents(path/to/response.json); $data json_decode($response, true); if (json_last_error() JSON_ERROR_NONE) { print_r($data); } else { // 尝试Base64解码 $decoded base64_decode($response, true); if ($decoded ! false) { echo $decoded; } else { echo Unable to decode.; } }6.5 漏洞验证的伦理与法律边界最后也是最重要的一点我必须强调所有漏洞研究和复现都必须在你自己拥有完全控制权的环境中进行。未经授权对任何他人的网站、系统进行漏洞扫描、探测或攻击测试不仅是非法的而且违背了安全研究的职业道德。我们研究漏洞目的是为了理解其原理从而更好地防御它。对于网站管理员希望这篇文章能让你意识到及时更新插件的重要性对于开发者希望它能提醒你在编码时牢记安全规范对于安全爱好者希望它提供了一个完整的学习案例。安全是一个共同的责任通过负责任的研究和分享我们才能让网络空间变得更加安全。
相关文章
开源漏洞修复脚本的5个关键执行细节与风险管控实践
1. 项目概述：当自动化脚本遇上安全合规的“暗礁”在开源生态成为现代软件研发基石的今天，一个高效的漏洞修复脚本，对于任何一个技术团队来说，都像是给项目安全上了一道“自动巡航”的保险。我们常常会花大力气去写一个能自动扫描依…
如何永久备份微信聊天记录：macOS用户的终极免费开源方案
如何永久备份微信聊天记录：macOS用户的终极免费开源方案 【免费下载链接】WeChatExporter 一个可以快速导出、查看你的微信聊天记录的工具 项目地址: https://gitcode.com/gh_mirrors/wec/WeChatExporter 你是否曾担心手机丢失或更换时，那些珍贵的…
Sora本质是时空建模：AI视频生成的物理世界模拟器
1. 这不是“又一个AI视频工具”：Sora的本质是时空建模能力的跃迁你可能已经刷到过那些令人屏息的30秒视频——一只戴着草帽的柴犬在秋日林间小径奔跑，落叶随风翻飞，光影在它毛发上流动；或是东京涩谷十字路口在暴雨中车流如织&…
百度网盘秒传转存工具：3分钟掌握全平台快速分享的终极指南
百度网盘秒传转存工具：3分钟掌握全平台快速分享的终极指南 【免费下载链接】baidupan-rapidupload 百度网盘秒传链接转存/生成/转换 网页工具 (全平台可用) 项目地址: https://gitcode.com/gh_mirrors/bai/baidupan-rapidupload 百度网盘秒传转存工具是一款革…
Java毕设项目：基于 SpringBoot 的租房预约与管理系统的设计与实现 基于 Vue的房源租赁服务系统 (源码+文档，讲解、调试运行，定制等)
博主介绍：✌️码农一枚 ，专注于大学生项目实战开发、讲解和毕业🚢文撰写修改等。全栈领域优质创作者，博客之星、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java、小程序技术领域和毕业项目实战 ✌️技术范围：&am…
2G 沉浮：全球退网大潮中的最后坚守
一、2G 是什么：移动通信的数字化革命2G（第二代移动通信）是移动通信史上从模拟到数字的分水岭。它在 1990 年代投入商用，首次引入了数字语音编码、时分多址/码分多址、SIM 卡和安全加密，让手机变得小巧、便宜、省电&…
TPIC7710EVM评估板深度解析：汽车电子EPB系统开发的硬件验证与软件调试指南
1. 项目概述与评估板核心价值在汽车电子开发领域，尤其是像电子驻车制动（EPB）这类涉及安全与高可靠性的系统，工程师面临的最大挑战之一是如何在项目早期、在真实的硬件环境中快速、准确地验证专用集成电路（ASIC…
HeyAIWiki：AI模型百科全书助力技术选型
作为一名长期关注AI领域的开发者，我最近发现了一个非常实用的AI模型信息聚合平台——**HeyAI Wiki**（https://heyaiwiki.com/zh/）。它不像普通科技媒体那样追逐热点新闻，而是更像一本持续更新的“AI模型工具书”。本文将客观地介绍…
竞争存在论：空间三连续统——空间几何的统一生成理论
空间三连续统：空间几何的统一生成理论 ——基于竞争存在论的分形递归框架 摘要： 基于竞争存在论的三连续统框架，本文提出空间本身并非中性的背景容器，而是由三个方向连续统的乘积构成的动态结构。我们定义空间三连续统 ǔ…
Java开发者转型安全开发：从代码审计到自动化工具实践
1. 转型背景与核心驱动力最近几年，身边不少做Java后端开发的朋友，都开始或多或少地关注起安全开发这个方向。我自己也是从写了七八年Java业务代码，一步步转向了安全领域，现在主要做代码审计和自动化安全工具开发。这个转变不是一时…
【TEE从入门到精通及实战】75 TEE内Wasm沙箱的内存安全：从“段错误”到“编译时保证”
75 TEE内Wasm沙箱的内存安全：从“段错误”到“编译时保证” 开篇故事 去年夏天，我正帮一家金融科技公司优化他们的TEE内Wasm沙箱。他们的核心业务是在Intel SGX enclave里运行用户提交的Wasm合约，用于实时交易验证。 一天下午，运维突然报警：生产环境的enclave进程频繁崩…
YAML函数动态解析：打造智能接口自动化测试用例
1. 项目概述：为什么YAML测试用例需要函数动态解析？在接口自动化测试的实践中，我们常常会面临一个核心矛盾：测试用例的可维护性与灵活性。早期的测试脚本，无论是用Python的unittest还是pytest，往往将测试数据…
AI Coding 六个月真实ROI账本：产品经理的血泪教训，研发的冷静忠告
6个月前的2025年12月，Boris Cherny 公开宣布自己卸载了 IDE。一时间，Vibe Coding 成了全行业最热的话题。6个月后，当我们回过头来拉一份真实账本，发现事情远没有"一句话生成一个App"那么浪漫。本文从产品经理和研发两个…
华为OD机试2025C卷-字符统计及重排[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
华为OD机试2025C卷-寻找相同子串[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…