「这没法避免」——唯一一个这类事故频发的语言的使用者们如是说

"No way to prevent this" say users of only language where this regularly happens — xeiaso.net · 23 小时前 · 🔒 安全

这是一篇模仿美国讽刺媒体标题体裁的短文，借虚构的安全漏洞编号 CVE-2026-92392 讽刺 C 语言生态对内存安全问题的态度。文章描述了漏洞披露后运维人员的混乱场面：该漏洞源于 curl 项目 HTTP/2 上传重试路径中的一个释放后使用缺陷——清理逻辑把残留的上传数据包装成新请求时，保留了一个指向已释放的 Curl_easy 句柄的指针，作者调侃「释放在此处显然只是一个建议」；在特定条件下，恶意服务器可借此实现远程代码执行。文章把矛头指向根本原因：受影响组件由 C 语言编写，并戏称其为「世界上唯一一个这类漏洞定期发生的编程语言」。文中虚构了一位程序员的表态，称这是一场悲剧，「但有时候事情就是这样，谁也没办法阻止」，并引用数据称过去五十年间全球约九成的内存安全漏洞出自这门语言，使用它的项目出现安全漏洞的概率是其他项目的二十倍。结尾处，作者形容这门「每季度都会准时出一两次此类漏洞、持续八年」的语言的使用者们，把自己和自己的处境称作「无可奈何」。整篇文章的讽刺结构来自现实：美国 Onion 新闻网那句著名的「唯一一个这种事反复发生的国家的人们表示这无法避免」被原样移植到编程语言身上，用来嘲弄社区面对同类型漏洞反复出现时的宿命论调，也暗指 Rust 等内存安全语言普及多年后，关键基础设施仍在用 C 重写漏洞的脚步。

核心信息

虚构漏洞 CVE-2026-92392 的技术细节有真实原型：curl 的 HTTP/2 上传重试逻辑中，清理代码将 leftover 上传数据转为新请求，却保留了指向已释放的 Curl_easy 句柄的悬空指针，特定条件下恶意服务器可触发远程代码执行。这类释放后使用缺陷正是 C/C++ 项目最高发的漏洞类别。
文中最尖锐的论据是两组数字：过去五十年全球约 90% 的内存安全漏洞出自 C 语言，使用 C 编写的项目出现安全漏洞的概率约为其他语言项目的 20 倍。作者借此反驳「只要程序员足够小心就没问题」的流行说法。
文章的讽刺手法是套用美国讽刺新闻的经典句式，把「唯一一个此类悲剧反复发生的国家」替换为「唯一一个此类漏洞反复发生的语言」，并描述这门语言的使用者自称「无可奈何」、声称「真的没有任何办法防止内存安全漏洞」，以此凸显这种宿命论的荒谬。
时间维度的描写强化了讽刺效果：文中称此类漏洞在这门语言生态中「过去八年间每季度定期发生一到两次」，暗示这不是偶发事故而是结构性、可预测的系统性问题，与「无法预防」的官方说辞形成直接矛盾。

💡 为什么值得读: 用一段短小精悍的讽刺精准点破行业积弊：当同类型漏洞以固定节奏反复出现时，「无法避免」本身就是最站不住脚的借口。

✍️ 小编看法: 这篇嘲讽文的价值在于它戳破了一个公共话语里的惯性：每当关键基础组件爆出内存安全漏洞，讨论总会停留在具体补丁和版本升级上，而回避更根本的问题——我们为什么还在用同一种方式制造同类漏洞。curl 这样的组件藏在几乎所有设备里，一个释放后使用就可能变成全球性的远程代码执行，影响面远超普通应用漏洞，但修复模式八年来几乎没有变化。被忽略的代价其实是时间账：每一次应急响应、每一次全网打补丁的人力成本，累加起来很可能远超逐步用内存安全语言重写热点路径的投入。NSA、CISA 等机构近年都在推动内存安全语言优先的政策，谷歌和微软也各自公布过自家漏洞数据里内存问题占比七成左右的统计，说明这不是社区偏见而是工程共识。当然也要公平地说，重写不等于安全，Rust 项目同样出过 CVE，重写过程中的逻辑错误、生态迁移风险都是真实的；而且 curl 这样的项目维护者稀缺，强行要求重写并不现实。对读者的实际启示是：评估依赖组件时，把实现语言和内存安全策略纳入风险模型；作为开发者，新写的底层组件优先考虑内存安全语言，至少让漏洞的「可再生率」下降。下一步值得观察的是美国政府资助的用 Rust 重写关键 C 组件的进展，如果 curl、sudo 这类项目真的完成核心路径替换，这篇讽刺文的保质期也就到了。

🏷️ curl, CVE, use-after-free, C