MQTT：传入的剩余长度缺少上限，允许服务器控制长时间等待

报告编号：#3488278

curl的MQTT实现接受服务器宣告的任何有效的Remaining Length，没有明确的上限（仅受限于MQTT规范的最大值268,435,455字节）。恶意服务器可以发送一个声明此最大大小的PUBLISH数据包，但只提供极少量的负载，从而导致curl无限期地等待剩余数据。

这是一个低严重性的客户端拒绝服务（挂起）问题，可以通过 --max-time 和 --max-filesize 选项来缓解。由于数据是以小块缓冲方式处理的，因此不会发生内存耗尽。

受影响的代码： lib/mqtt.c（约第737行）

1
2

1data->req.size = remlen;
2mq->npacket = remlen;

概念验证： 恶意MQTT服务器发送一个剩余长度过大的发布数据包。

尽管标记为 0xFF FF FF 7F（等于 268,435,455 字节），但系统只传输了几个字节。尽管有初始的大小声明，但实际数据量始终很小。大小指示并不总是反映传输的内容。看似巨大的声明可能只携带极少信息。

curl接受声明的剩余长度而不进行验证，并据此调整其期望；只有在通信结束或超时后它才会响应。虽然设计初衷是遵循协议，但依赖外部信号使得在边界条件下可能出现非预期行为。

随附截图显示：

• 有害服务器从远端发送了一个夸大的剩余长度。
• curl的日志显示剩余数据量：268435455 字节。

影响

• 低严重性 / 协议强化问题
• 无崩溃
• 无内存损坏
• 无过度内存分配
• 恶意服务器可能导致curl等待一个非常大的传输
• 可通过现有选项（如 --max-time 和 --max-filesize）部分缓解

建议的强化措施： 对传入的数据包应用与传出数据包已使用的相同的 MAX_MQTT_MESSAGE_SIZE 限制。

1
2
3
4
5
6

1if(remlen > MAX_MQTT_MESSAGE_SIZE) {
2  failf(data, "MQTT message too large (%zu bytes, max %d)",
3        remlen, MAX_MQTT_MESSAGE_SIZE);
4  result = CURLE_WEIRD_SERVER_REPLY;
5  goto end;
6}

附件： F5191289: 2.png F5191291: 1.png F5191292: 3.png

时间线：

• 5天前：gaurav_7777 向 curl 提交了报告。
• 5天前：bagder (curl 工作人员) 关闭了报告并将状态改为 Not Applicable。评论道：“这基本上是一种 slowloris 攻击。服务器也可以直接停止发送，而curl会坐着等待更多数据。这不是一个安全问题，这是curl按设计工作。”
• 5天前：bagder (curl 工作人员) 请求公开此报告，理由是遵循项目的透明度政策，希望所有报告都被公开。
• 5天前：gaurav_7777 同意公开此报告。
• 5天前：此报告已被公开。

报告详情：

• 报告日期：2026年1月6日 UTC 上午8:51
• 报告人：gaurav_7777
• 报告对象：curl
• 严重程度：低 (0.1 ~ 3.9)
• 公开日期：2026年1月6日 UTC 上午8:55
• 弱点：不受控制的资源消耗
• CVE ID：无
• 赏金：隐藏
• 账户详情：无