ProFTPD这个跑了二十多年的老牌FTP服务器，因为一个日志函数的引号判断逻辑，被敲上了8.1分的CVSS评分。攻击者不需要复杂工具，只需要一个精心构造的用户名，就能让数据库执行任意命令——从绕过登录到远程控制服务器，全看管理员怎么配的。
漏洞核心：一个函数的"聪明"反成破绽
问题出在is_escaped_text()函数。这个函数的设计意图是识别"已经转义过的安全文本"，避免重复处理。但它的判断规则太简单了：只要字符串以单引号开头和结尾，中间没有引号，就认定是安全的。
攻击者利用这个逻辑漏洞，构造'恶意代码'格式的用户名。系统一看"哦，有引号包围，肯定是转义过的"，直接放行，跳过了正常的清洗流程。结果这段"用户名"被原样送进数据库查询，变成可执行的SQL指令。
这个变量通常通过%U占位符插入日志。管理员用SQLNamedQuery指令配置日志存储时，很少会想到一个用户名能击穿整个安全模型。
攻击面有多大：看配置，但通常不小
ProFTPD的mod_sql模块本身是个常见配置。它让管理员能用数据库管用户，不用给每个FTP账号建本地Linux账户——这对托管几千个网站的服务商来说是刚需。
现代Linux发行版和主机管理面板（比如cPanel、Plesk这类）经常预装ProFTPD。ZeroPath Research指出，这种架构在共享主机环境里特别普遍。一个服务器挂几千个网站，数据库后端是标准操作。
但漏洞的实际危害取决于具体配置：
· 如果只开了日志、没开数据库认证，攻击者能篡改日志、注入假记录，或者通过SQL查询探测数据库结构
· 如果用了数据库认证，攻击者可以绕过密码验证直接登录，甚至提权到管理员
· 如果数据库用户权限给得宽，配合特定条件能执行系统命令，实现远程代码执行
最麻烦的是"配置漂移"——很多服务器最初只开日志，后来功能越加越多，权限越放越宽，但安全检查没跟上。
为什么现在才被发现：遗留代码的信任假设
ProFTPD的代码库可以追溯到1990年代末。is_escaped_text()这种"看起来合理"的防御逻辑，在当时可能确实挡住了一些简单攻击。但它犯了一个经典错误：用格式特征推断安全性，而不是真正验证内容。
单引号包围不等于转义。真正的转义需要处理引号内部的特殊字符，或者使用参数化查询把数据和指令分开。这个函数把"长得像转义的"当成"确实是转义的"，属于典型的逻辑型漏洞——代码能跑，测试能过，但攻击者换个角度就看穿了。
更深层的问题是FTP协议本身的尴尬地位。它太老了，老到很多人觉得"反正没人用了"，安全投入跟着下滑。但现实是，批量主机管理、嵌入式设备、企业内部文件传输，FTP/FTPS/SFTP的装机量依然巨大。攻击者从来不嫌弃旧目标，反而喜欢这种"没人管的老系统"。
修复建议：ZeroPath Research的紧急呼吁
安全团队和系统管理员需要立即行动。具体措施原文没展开，但从漏洞机理可以反推优先级：
第一，检查mod_sql是否启用，以及SQLNamedQuery里有没有用到%U这类用户输入变量。有的话，这段配置就是攻击入口。
第二，审视数据库账号权限。即使漏洞被利用，最小权限原则也能把损失关在数据库层，不至于直接拿到系统shell。
第三，关注ProFTPD官方补丁。CVE-2026-42167的修复大概率会修改is_escaped_text()的判断逻辑，或者干脆弃用这个函数，改用更严格的输入处理。
短期来看，这个漏洞会推动一波主机商的安全审计。长期来看，它再次证明：老代码的"合理假设"在新攻击面下往往是定时炸弹。FTP不会消失，但它需要的安全维护投入，和它的"过气"名声完全不成正比。
最后说句扎心的：这个漏洞的利用门槛低到令人发指——不需要0day挖掘能力，不需要复杂漏洞链，只需要懂SQL语法和引号匹配。在漏洞赏金平台上，这种"构造特定字符串就能RCE"的漏洞，通常归类为"新手友好型"。二十多年的老牌服务器被新手友好的方式击穿，这本身比技术细节更值得行业反思。
热门跟贴