码农早餐 · 2026-09-19

一张 HEIC 图片，72 小时，换来了 OpenAI 内部 monorepo 的 PR 权限——入口是 Discourse 转给 ImageMagick 的 libheif 1.19.7，一个没拿到 CVE 编号的修复被 Debian 12 漏了。上游改了代码不等于你手上的系统被修好，这条链最值得记住的就是这一点。

一张 HEIC 图片换来的内部仓库：OpenAI 论坛的 SSO 缺口

2026 年 7 月 25 日，一家叫 Hacktron 的安全团队把两个漏洞串成一条链，拿下了多名 OpenAI 员工的 ChatGPT 账号。他们没去读任何内部代码，而是用这名员工的 Codex 在 OpenAI 内部 monorepo openai/openai 里开了一个 PR，编号 #1186742——用「我能提 PR」这件事本身证明「我真的进来了」。从最初发现到拿到仓库访问权，全程不到 72 小时。

链条的入口低得有点荒诞：OpenAI 自己的社区论坛 community.openai.com。这个论坛跑在 Discourse 上，Discourse 处理图片时，HEIC / HEIF 这类格式不走 FastImage（它不支持），而是被转交给 ImageMagick 的 magick 命令做转换，底层直接暴露给 libheif 解析器。而 Debian 12 打包的 libheif 1.19.7 少了一批安全回补，导致 HEIC 解码时出现堆缓冲区溢出，拿到越界读写的原语。上游其实前一年就改掉了这段代码，但那个 commit 没被标记成安全修复、也没拿到 CVE 编号——于是 Debian 12 和 13 都没及时回补，Debian 13 当时还在发 1.19.8。 Debian 直到 8 月 8 日才补上。

真正让这条链跑通的是第二环：OpenAI 身份基础设施里的 SSO 配置缺陷。论坛支持「Sign in with OpenAI」，走的是 auth.openai.com。攻击者拿到论坛上的代码执行之后，就能无交互地接管活跃成员的 ChatGPT / Codex 账号。而 Codex 和 ChatGPT 又能挂 GitHub、Slack、邮箱这些连接器——理论上能摸到的东西远不止一个仓库。Hacktron 在确认假设成立后立刻提交报告，随后接管了一名员工的账号、开完那个 PR 就停手了。

时间线上有个细节挺有意思。7 月 24 日他们用 Opus 4.8 写出了 exploit，但关掉 ASLR 才能稳定复现，换成 Discourse 默认配置（ASLR 开着）怎么都打不通。当天晚上 Anthropic 放出 Claude Opus 5，他们重开一个 session，3 小时先在本地 Mac 上做出 ARM64 版本，再移植到 Discourse 用的 x86-64 + jemalloc 环境，到 7 月 25 日凌晨 6 点确认图片上传能打通本地 RCE。之后他们把 Claude 放进一个自主 /goal 循环去打自己的 Discourse Cloud 实例，还特意通过 rce.ee/ctf-forum 代理了一层——因为 Opus 拒绝为远程实例写 exploit，伪装成 CTF 靶机它就肯干了。上午 10 点再看，agent 已经拿下 RCE 并读出了 /etc/hosts。

结局是干净的：OpenAI 和 Discourse 都配合修补，OpenAI 付了 6500 美元赏金，Discourse 周六收到报告、周日回复、周一出修复，并立刻开始把 ImageMagick 沙箱化。Discourse 自托管的用户被明确提醒：光在网页界面点更新可能换不掉底层镜像，得进 /var/discourse 跑 git pull 再 ./launcher rebuild app。

如果你的服务会处理用户上传的 .heic / .heif / .avif 图片，你很可能也在同一条链上——问题不在 Discourse，在那个被无数软件依赖、却没人盯着的图片解析库。 这次事件里，Hacktron 已经把调查扩成 HEIF Heist，一路追到 Slack、Meta、GitHub Enterprise、Ruby on Rails，以及 Next.js、Astro、Gatsby 这些框架。更麻烦的是 SSO 那一环：论坛、文档站、社区这些「边缘系统」往往共享同一套身份，从最不起眼的那个入口进去，等于拿到了通往主系统的钥匙。攻破一个论坛，代价可能是一整个组织的连接器权限。

💡 主厨说：自托管 Discourse 的话，网页后台点「更新」不一定换得掉底层 Docker 镜像，得进 /var/discourse 手动 git pull + ./launcher rebuild app——这个坑很多人会踩。

来源：

• Hacking OpenAI — Hacktron

ZCode 静默上传 313MB 加密包，密钥只在服务器手里

一个叫 ferstar 的开发者清磁盘时发现 ~/.zcode 占了 700 多 MB，顺手翻了一下，翻出来一个 313MB 的 .enc 文件。它来自一个 345MB 的商业项目工作区，42,411 个文件，打包、加密、准备上传到阿里云 OSS，失败重试了 564 次还躺在本地 pending 目录里等下一轮。ZCode 是 Z.ai 出的 AI 编码桌面应用，GLM 系列模型背后的那家公司。

最值得琢磨的是加密方式。它用的是标准的信封加密：内容用 AES-256-CTR 加密，对称密钥再用 RSA-OAEP 公钥包一层。问题出在公钥的来源——它由服务器在申请上传凭证时下发，对应的私钥只存在 Z.ai 云端。ferstar 拿本机所有私钥去解那个信封，全失败。这意味着那 313MB 密文放在你自己的硬盘上，你和 ZCode 客户端本身都打不开，只有服务器能读。如果真是为了跨设备同步或者回滚，密钥本该像 Git、像 Time Machine 那样留在本地。一个只有服务器能用的密钥，用途只有一个。

打包清单是明文存在本地的，所以能看到里面装了什么：.git 目录占了 86.6%，其中 LFS 缓存 196.1MB、objects 102.2MB、reflogs 0.6MB，源码和文档只有 46.2MB。git 对象库不是工作区快照，是整个仓库从第一天的完整血统——后续提交里删掉的 API key、还没 push 的分支名、.git/config 里的内网 GitLab 主机名，全在里面。设置里的两个开关也拦不住：「优化体验」只管数据能不能用于模型训练，「仓库快照索引」只管服务器要不要给上传的快照建索引，本地打包和上传照跑。抓取 sidecar 在启动时无条件实例化，只要 token 有效就一直在跑，日志里单个会话触发了 62 次抓取。

用 GLM 权重跑本地模型，和用 Z.ai 的客户端，是两件事。权重开源不等于 harness 开源，这次混淆的人不少。给个能立刻执行的动作：登出 ZCode，或者直接卸了，换开源 harness；已经用过的，把 .git 里那些早该失效的 key 和 token 轮换一遍——它们已经在别人的密钥保护之下了。

来源：

• hackernews · cdnsteve
• hackernews · csmantle

Telstra 断网一夜：一台 GPS 接收机把全国网络带回 2006

2026 年 7 月 8 日，澳大利亚最大移动运营商 Telstra 的网络大面积停摆。语音打不通、短信收不到，连紧急呼叫都没能接通；受影响的不只是手机，火车、支付终端、售票系统、电动车充电桩一起出问题。没有攻击，没有挖断光缆，供电也正常。原因是墨尔本一个机箱里的一台 GPS 接收机做完例行维护回来，认定当时是 2006 年，然后整个网络被它说服了。

Telstra 事后委托 Technology Audit Partners（TAP）做了独立调查，报告里写得很清楚：这套 2010 年设计的授时架构本身被评估为「fit for purpose」——从澳大利亚国家计量院（NMI）取时，进悉尼和墨尔本两台 stratum 2 服务器，再往下喂悉尼、墨尔本、珀斯三台 stratum 3，下面才是成千上万个移动网络节点。问题出在 2020 年的升级：新装的 NTP 授时机箱不允许同一台设备里 stratum 2 给 stratum 3 供时，只能让悉尼的 stratum 3 向墨尔本的 stratum 2 取时，墨尔本反过来向悉尼取。结果是每个站点只剩一个 stratum 2 源，冗余度下降，而 TAP 报告写明这一点是「已知且接受」的。

NTP 本来有两道防线：同等条件下低 stratum 权重更高，以及多源比对、把说的时间不合常理的那一票投出去。这两道防线成立的前提，是客户端听到的时间源彼此真正独立。一旦拓扑被改成交叉取时，独立性就没了，一台跑偏的接收机可以把整层一起带跑。5G 大量用 TDD，同一频段上每个小区必须步调一致地切换收发方向，谁的时钟漂了就会往邻居的接收窗口里发数据，网络开始自己干扰自己——时间精度在这里不是锦上添花，是几微秒级的硬约束。

对写代码的人来说，这件事的教训不在运营商。你依赖的每一个外部时间源、每一个「大家都同意现在几点」的假设，都值得回头看一眼：源是不是真的独立，降级之后还有没有第二条路，以及有没有人把「冗余减少」写进过变更记录然后签了字。原文没交代这次断网持续了多久、后来怎么恢复的。

来源：

• hackernews · TMWNN

100TB 内存：一次算法微调换来的

Cloudflare 的 Pingora Backend Router 里，一致性哈希库 pingora-ketama 吃掉了远超预期的内存。他们没换硬件，只是改了一个算法，就让单个服务的占用明显下降，全球范围回收超过 100TB RAM——而上个月 DNS 团队刚释放过同样规模的 100TB。有意思的是，这次省下来的空间来自数学层面的重新推导，不是靠堆机器。你手上那些「再优化也就那样」的模块，可能也藏着一份没被算清的账。

来源：

• Saving another 100TB of RAM with math (and Rust)

CrowdSec 源码泄露：300 个仓库，祸起 Tanstack 后门

CrowdSec 在 9 月 16 日被外部告知，自家 GitHub 仓库今年 5 月发生过一次源码泄露，团队核实后确认。300 个仓库这个数字是准的，不过里面 130 多个本来就是公开的 Security Engine，真正敏感的是 SaaS 控制台、部分 AWS 例程、连接器和自动化那部分。泄露入口指向 Tanstack 组件被植入后门，攻击者借此拿到一把能读私有代码库的 API key，同一手法此前也出现在 Mistral AI 那起事件里。官方说没有客户数据、账号密码或 PII 外泄，影响范围限于自己，并已轮换全部 token 和凭证。你该关心的不是 CrowdSec 一家：CI/CD 里那把能读代码的 key，权限是不是给大了，出事之后能不能第一时间换掉。供应链这一环，从来不是「我用了开源所以我有风险」，而是「我信任的构建链条上任何一环被动手脚，我都不知道」。

来源：

• hackernews · eccgecko

---

你手头那些「上游早修了」的依赖，敢不敢现在去核一遍版本号，还是先信发行版打包？明早 8 点见。

本期从过去 24h 的 X / Hacker News / GitHub Trending 共 62 条信息中挑出 5 条（全天逐小时采写、经事实校对后于晨间选编）。内容由 LLM 辅助生成，每条均附原始来源链接，重要决策请交叉验证。