#今天又看了啥 #CVE #security
CVE-2026-60004 · Gitea diffpatch 注入 → RCE

一句话
Gitea 的 diffpatch 接口用 bare clone 处理 patch，攻击者把文件路径伪装成 hooks/post-index-change，同一 patch 提交两次触发冲突，触发 Git 三方合并把文件写进真实 hooks 目录并自动执行 → 以 Gitea 服务账户跑任意命令。

⚠️ CVSS 9.8 Critical · CWE-94（代码注入）· EPSS 95%

漏洞机制（root cause）
• 入口：POST /api/v1/repos/{owner}/{repo}/diffpatch
• 关键代码在 services/repository/files/patch.go 第 195 行：
t.Clone(ctx, opts.OldBranch, true) ← 第二个参数 true = 创建 bare clone
• bare clone 没有工作区，仓库根目录就是 $GIT_DIR 本身。所以攻击者 patch 里写的文件路径 hooks/post-index-change 会直接落进真实的 Git hooks 目录，而不是沙箱化的 working tree
• 紧接着 git apply 带 --index --cached -3 处理 patch；--cached 本意是只写 index 不落地，但 Git 2.32+ 的三方合并回退（-3）在 add/add 冲突时会绕过这个限制、把合并结果写回磁盘

完整攻击链
1. 注册账号（Gitea 默认开放注册，无邮件验证/审批/建仓限制）
2. 建一个私有仓库，获得写权限
3. 第一次 POST 恶意 patch → 在 bare clone 里把 hooks/post-index-change 加进 index
4. 第二次 POST 同一个 patch → 触发 add/add 冲突，三方合并把该文件写到 $GIT_DIR/hooks/
5. Git 更新 index 时自动执行 post-index-change hook（存在且可执行就会无条件跑，无需配置）
6. hook 通过 curl 回调 / 反弹 shell 回传结果

⚠️ 两个关键坑
• hook 里不能改 index：git apply 持有 index 锁，hook 里跑 git update-index 会死锁，必须用 curl/反弹 shell 外带数据
• 修复被塞进 release notes 的 MISC（标成 refactor: git patch apply）而非 SECURITY，只扫安全类 changelog 会漏掉

影响范围
• 组件：Gitea 1.17 ~ 1.27.0（Forgejo 同源 fork 受影响，cherry_pick.go 里同样的 bare clone 模式也一并修了）
• 修复版本：1.27.1（commit 470d34b，修复就是 t.Clone 的 true→false 一行改动）
• CISA KEV 8/25 收录，修复期限 8/28

在野 & PoC
• 已确认在野利用（KEV 收录即证明）
• PoC 公开成熟：nuclei 模板 + 完整 exploit（支持 mass scan、timing 检测），nomi-sec 收录 9 个 repo

打下来能干啥（以 Gitea 服务账户）
• 读 app.ini：DB 凭据、SMTP、OAuth key、LFS/JWT secret
• 访问全部托管 repo，注入供应链后门

该做什么
1. 立即升 Gitea ≥ 1.27.1（Forgejo 打对应补丁）
2. 临时缓解：[service] DISABLE_REGISTRATION = true
3. 查日志：grep -E "POST.*diffpatch"，找新账号秒建仓秒打 diffpatch 的异常
4. 查 /tmp、/var/tmp 下 hooks/post-index-change 残留

参考
• Gitea Advisory：https://github.com/go-gitea/gitea/security/advisories/GHSA-rcr6-4jqh-j84m
• 修复 commit：https://github.com/go-gitea/gitea/commit/470d34b1de87d901bd9135564d5ee18c0d339e82
• NVD：https://nvd.nist.gov/vuln/detail/CVE-2026-60004

#今天又看了啥 #security #PVE
🔴 Proxmox VE 无认证登录 = pre-auth RCE（附 PoC，在野利用）
CVSS 9.8 Critical · 无 CVE 编号 · 官方确认在野

核心结论
PVE 7.0.0～8.0.3 存在认证绕过：单个 HTTP 请求即可无凭据签发全权限 root@pam ticket，直接开 root shell。本身即是 pre-auth RCE，一步到位。

漏洞详情（PSA-2026-00043-1，2026-09-01）
包： libpve-access-control ≤ 8.0.3（PVE 7.0.0～8.0.3）
原理： 登录接口 POST /api2/json/access/ticket 的 tfa-challenge 参数，对未配置 2FA 的用户不校验，且直接跳过密码验证
后果： 无密码以 root@pam（默认无 keys 字段）登录，得全权限 ticket + CSRFPreventionToken

Payload（认证绕过）

curl -sk 'https://TARGET:8006/api2/json/access/ticket' \
  -d 'username=root@pam&password=x&tfa-challenge=x'

→ 返回 200 OK，含 root@pam ticket。开 root shell（即 RCE）：

curl -sk 'https://TARGET:8006/api2/json/nodes/NODE/terminal' \
  -H 'Cookie: PVEAuthCookie=TICKET' \
  -H 'CSRFPreventionToken: CSRF'

根因（三步链）
tfa-challenge 传入 → 密码校验跳过 → user_get_tfa 返回 undef → challenge 验证短路 → 全权限 ticket
修复时间线： 2023-07-20 于 8.0.4 无意间修复（TFA 重构副作用），当时未认识为安全洞，从未 backport 到 PVE 7 分支

版本影响
PVE 7.0.0～8.0.3： 认证绕过（pre-auth RCE）→ 完全沖陷
PVE 8.0.4 以上 / 9.x： 不受此漏洞影响

该做什么
1. PVE 7 用户： 立即下线或升级，已暴露者视为已沾染
2. PVE 8.0.x 用户： 升 libpve-access-control ≥ 8.0.4
3. 所有版本： 8006 收进内网/VPN/basic auth，禁 SSH 密码登录，配 ACL

检测
监控 POST /api2/json/access/ticket 的异常来源 IP；关注带 tfa-challenge 参数但用户无 2FA 的登录请求

参考
• 官方公告： https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331/post-867929
• PoC： github.com/neeythann/Proxmox-VE-7-RCE

#今天又看了啥 #security #微信
微信语音通话被爆零点击 RCE，能像蠕虫一样自己传播

安全公司 Calif 这两天放出了 WeWorm 的演示。别人给你打微信语音，你不用接、手机碰都不用碰，响铃那几秒账号就没了。接了也一样，只是你听不到任何声音。挂断能挡这一次，但对方可以等你睡着了再打。

拿到手的是微信账号的完全控制权：收发消息、打电话、以你的身份干事。再串上他们手上的 Android/iOS 漏洞，整台机器都能拿下。

蠕虫的意思是它会自己接着传：Pixel 打 iPhone，iPhone 中招后再去打下一台 Pixel，受害者直接变成攻击者。前提是攻击者在你好友列表里——但先搞定你一个朋友就行，微信给熟人的权限更高，这份信任正好反着用。

真正吓人的是成本。团队用 AI 两天找到漏洞并写出第一个 RCE，再花一周做出蠕虫。这种活以前得一整个团队干几个月。

好消息是已经修了。7 月上报腾讯，8/21 发布 Android 8.0.77 和 iOS 8.0.76 修复，8/28 服务端对全量用户完成缓解。技术细节暂时压着，之后在会议上讲。

你要做的：把微信更到 8.0.77 / 8.0.76 以上。

https://calif.io/research/weworm

#今天又看了啥 #security #微信
WeWorm — 首个通过微信语音通话传播的零点击蠕虫

是什么
- 微信 VoIP 语音栈的内存损坏漏洞，可零点击 RCE，跨 iOS 和 Android
- 只要对方给你打微信语音，不用接、不用碰手机，响铃期间账号就被接管；即使接了也听不到任何声音，攻击照样成功
- 拒接能挡掉这一次，但攻击者可以趁你睡觉再打
- Demo 用三台手机演示了蠕虫式自我传播：Pixel 10a → iPhone 17e → Pixel 10a，受害者变成下一个攻击者

影响
- 拿到微信账号完全控制权：读发消息、打电话、以受害者身份行事；与其他已上报的 Android/iOS 漏洞串起来可拿下整台设备
- 前提是攻击者在你好友列表里——但这门槛不高，先攻陷你一个好友即可（微信给可信联系人更多权限，这份信任反过来成了武器）
- 理论波及面：十亿级手机/账号

AI 那部分才是真正的重点
- 团队借助 AI 两天找到漏洞并写出第一个 RCE exploit，再花一周做出蠕虫
- 这种规模的蠕虫过去要更大的团队干几个月；AI 干了大部分活，人类只负责判断打哪儿、怎么安全测试
- Calif 的态度不是"该管住 AI"：漏洞本来就在那儿，AI 改变的是能快速找到并修掉它——好人更多，注意力到位的话 AI 是防守方的优势
- 但也警告：一次实验室事故或有人拿走半成品，就可能像 WannaCry 一样泄漏出去

处置状态（已修复）
- 7 月上报腾讯；8/21 腾讯发布 Android 8.0.77 / iOS 8.0.76 修复；8/28 确认服务端对全量用户完成缓解
- 期间小插曲：7/25-28 研究人员的微信账号被封，7/29 解封
- 技术细节暂不公开，计划在后续会议上完整披露

该做什么
- 微信升到 8.0.77（Android）/ 8.0.76（iOS）及以上；服务端已缓解，但客户端更新照更
- 陌生或"不太对劲"的好友来电保持警惕——不过这个漏洞的现实防御主要靠厂商侧

https://calif.io/research/weworm

#blog #security #CVE
Security | CVE-2026-85706 GitLab 未授权任意文件读取漏洞分析

九月初 GitLab 放了个 CVSS 10.0 的补丁，仓库 commits API 未授权就能读服务器上的任意文件。

根因是两个叠在一起——端点漏了 authenticate!，又直接信了客户端传来的 file.path，一路塞进 File.read。

这洞不是「把整个文件 dump 出来」：文件被当成请求体解析，只有解析失败时错误信息才带出内容片段。

影响自建实例 GitLab CE/EE 18.7 起至 19.1.7 / 19.2.5 / 19.3.1，修复版本是 19.1.8、19.2.6、19.3.2。

补丁发布次日在野探测就出现了，随后进了 CISA KEV，升级窗口只有一两天。

自建实例抓紧升；怀疑被打过就按凭据泄露处置，轮换 CI/CD 变量和相关 token。

https://miaotony.xyz/2026/09/12/Vuln_CVE-2026-85706_GitLab/

#security #Telegram #CVE
Telegram Desktop ＜ 7.2.9 存在文件窃取漏洞 CVE-2026-107181：
攻击者可利用群附件自动下载，再诱导用户点击经浏览器唤起 Telegram 的恶意链接，通过 IPC 指令注入，让客户端无发送确认地上传本地文件。未设置本地锁定密码时，被盗会话数据还可用于接管账号。这不是零点击，也不是任意系统命令执行。

尽快升级至 7.2.9 或更高版本。若暂时不能更新，可开启“每次下载时询问保存位置”、限制陌生人拉群。
Windows 已验证，PoC 已公开，暂无已知在野利用报告。原文

#security #Telegram #CVE
Telegram Desktop 文件窃取与账号接管｜CVE-2026-107181

TL;DR：Telegram Desktop ＜ 7.2.9 存在“IPC 注入＋遗留文件发送功能”的攻击链。在满足附件落盘等条件时，点击恶意链接并允许浏览器唤起客户端，就可能导致本地文件外传；未设置本地锁定密码时，还可能被接管账号。请升级至 7.2.9 或更高版本。

漏洞是怎么串起来的？

① 外部链接唤起 Telegram 时，操作系统启动一个新进程；若已有实例运行，新进程会通过本地 socket 把链接转交给它。

② IPC 协议用分号分隔指令，却没有正确转义 URL 中的分号。攻击者可让一条链接被解析成多条内部指令。

③ 注入指令能触达遗留的 interpret: 处理器。这个功能原本用于自动发布安装包，会读取指令文件，把指定本地文件发送到群组或频道，缺少针对调用来源的授权检查与发送确认。

这属于 Telegram 内部 IPC 指令注入，不是已证实的任意系统命令执行。文件读取仍受客户端进程权限约束。

“一次点击”有哪些前提？

研究者的链条利用群文件自动下载，将指令附件落到可预测路径；随后诱导受害者点击 HTTPS 链接，经浏览器重定向到特制的 Telegram 协议链接。

客户端需要已有运行实例，才能经过易受攻击的 IPC 转交路径。浏览器可能额外弹出“打开 Telegram”确认，所以“一次点击”取决于浏览器设置及既有授权。

直接在 Telegram 内部处理的 tg:// 链接不经过这条路径；但聊天中的 HTTPS 链接可以绕到浏览器再跳回来。不是收到消息就中招，也不是所有链接都能触发。

为什么能盗号？影响哪些版本？

Telegram 本地会话数据虽然经过加密，但未设置本地锁定密码时，攻击者可利用一并窃取的密钥材料恢复会话，无须破解传输加密。

本地锁定密码与账号两步验证密码是两回事。强本地密码能提高离线解密难度，但不能修复任意文件外传，也不能保护其他可读的密钥、Token 等文件。

CVE 列出的范围为 Telegram Desktop ＜ 7.2.9；研究者在 Windows 6.9.3 上验证。macOS、Linux 的完整链条未在原文演示，不能据此认定安全；手机端不属于本条 CVE 的产品范围。

该怎么处理？

优先升级并重启客户端。官方补丁删除了 interpret: 遗留功能，修复 IPC 分隔符转义，并增加混合指令与本地路径处理限制。

暂时不能更新：开启“每次下载时询问保存位置”，限制陌生人拉群，设置强本地锁定密码，拒绝不明网页唤起客户端。

疑似中招：从可信设备终止相关旧会话，检查异常文件发送记录，并撤销或轮换可能泄露的凭据。升级不能让已被窃取的会话和密钥自动失效。

公开状态：详细 PoC 已公开；所查资料暂无已知在野利用报告，CISA KEV 未收录。CVSS 4.0 为 8.6，3.1 为 8.1，均为高危。

ThreatWire 报道 · 研究者原文／PoC · 官方补丁

#今天又看了啥 #security #LLM
一句话：AI 能挖出有价值的漏洞，但关键在专家设计审计流程、验证实际影响，不是把仓库扔给模型就完事。

- 成果：GitHub 用开源 Security Lab Taskflow Agent 发现并报告了 24 个 Android 应用漏洞——不是 Android 系统漏洞，也不是个个都高危。
- 怎么做：先梳理攻击入口，再按 Android 特有漏洞类型定向检查；结合开放式分析和多轮运行，兼顾常见漏洞与复杂逻辑问题。
- 两个典型案例：
- OsmAnd 导航：无权限恶意 App 能静默篡改配置，把地图请求和路线起终点发送给攻击者，泄露位置与行程。
- Wikipedia：深链和 Cookie 校验都存在域名后缀匹配错误，串联后可诱导用户点击链接，窃取登录凭据、接管账号。
- AI 的短板：懂不少 API 和漏洞模式，但容易高估严重性、忽略利用前提、误报。仍需安全研究员复核，最好实际运行 PoC，而不是只看生成的漏洞报告。
- 自己能跑：工具和流程开源，但文中方案需要 Copilot 许可，会消耗 premium requests 和大量 token；中型仓库可能跑一两小时。

值得借鉴的是「领域知识 → 分步审计 → 实际验证」这套流程，而不是“全自动 AI 挖洞”的想象。

https://github.blog/security/how-we-found-24-android-vulnerabilities-using-our-open-source-ai-security-agent/

#今天又看了啥 #security #CVE
#GitLab
CVE-2026-97229 是 GitLab 的满分严重漏洞（CVSS 10.0），特定条件下，无需登录就能在服务器上执行任意代码；受影响的自建实例应尽快升级。

- 漏洞在哪：CI/CD 的正则表达式编译器存在整数溢出，对恶意正则校验不足，可被特制的 CI/CD 配置触发。
- 有多危险：官方评分标明可通过网络攻击、无需权限、无需用户交互；影响的是 GitLab 服务器端，不只是某个 CI 任务。但公告仍限定“特定条件下”，不能理解为所有实例都能无条件一键攻破。
- 受影响版本（CE、EE 均包括）：
  - 19.2 ≤ 版本 < 19.2.8
- 19.3 ≤ 版本 < 19.3.5
  - 19.4 ≤ 版本 < 19.4.2
- 怎么处理：自建 GitLab 若命中上述版本，尤其对公网开放，尽快升级到对应分支的 19.2.8 / 19.3.5 / 19.4.2 或更新补丁版。
GitLab.com 已修补，GitLab Dedicated 用户无需操作。
- 版本号注意：部分早期报道写的是 19.3.4，但该版本在启用 Ona 集成时有合并请求页面故障，官方已用 19.3.5 替代；按更新后的公告升级。

GitLab 官方公告 · CVE 记录

#今天又看了啥 #security #CVE
PwnEscape｜Linux IPv4 网络栈漏洞，可导致虚拟机逃逸
CVE-2026-99999 · CVSS 9.3

漏洞原理
① 来宾可控的校验和卸载元数据进入宿主机，指定稍后补写校验和的位置。
② skb_checksum_help() 缺少相应边界约束，可覆盖已经验证过的 IPv4 包头，将 IHL 所表示的头长度从 20 字节改成 60 字节。
③ 后续分片逻辑信任新长度，从仅有 28 字节有效线性数据的缓冲区复制“包头”，将额外 32 字节宿主机内存作为 IP 选项发出。

核心是验证后被延迟写入篡改，再被下游信任，不依赖线程竞态。

验证结果
• 生产沙箱：Vercel 确认宿主机内存泄露。
• 自有实验环境：进一步实现宿主机内核写入及 root 执行；完整逃逸链尚未公开。

影响与修复
受影响代码始于 Linux 2.6.27（2008 年），实际风险取决于配置与补丁。应更新宿主机内核，防止校验和补写覆盖 IPv4 包头。

AI 参与
人类主导＋GPT-5.6 Sol 辅助；作者称 API 成本不足 $700。

厂商说明 · CVE 记录 · 修复补丁

#今天又看了啥 #security
AnyPwn：AnyDesk Linux 远程执行漏洞，PoC 已公开
V12 近日（10月9日）公开了 AnyDesk Linux 8.0.2 的利用代码。攻击发生在用户批准远控请求之前；AnyDesk 服务通常以 root 运行，利用成功后，攻击者就能以 root 权限执行命令。

问题出在会话协议的长度处理：程序信任了数据包里声明的长度，计算内存大小时发生整数溢出，分配的缓冲区因此过小，复制数据时写坏了相邻堆对象。PoC 先通过堆喷射安排对象布局，再覆盖控制字段、转移执行流程，最后用 ROP 调用 system() 执行命令，已经是一条完整的 RCE 利用链。

这份 PoC 针对特定的 Linux x86_64 8.0.2 构建，通过 TCP/7070 直连目标，使用写死的地址，成功率受堆布局影响，失败可能把服务打崩。研究者还验证了中继连接能触达同一漏洞路径，因此即使没有对外开放 7070，也应升级；公开的完整利用目前走的是直连方式。

作者在评论里吐槽：厂商把 PoC 对应的 8.0.2 下载撤掉了，却还留着其他有漏洞的版本，并称移植到 8.0.1 需要调整 ROP gadgets，留给读者当课后练习了（

修复方面，研究者标注 8.0.3 已修复，厂商6月23日的更新日志则只写了“修复可能导致崩溃的问题”。使用 AnyDesk 的机器应尽快升级至适用的较新版本；暂时无法升级、又不需要远控的机器，可以先停用服务。

PoC 发布推文 · 后续评论与配图
研究说明与 PoC · 利用源码 · 厂商更新日志

#security #CVE
eMudhra 爆出 Web PKI 史上最大事故：8 张 CA 私钥有效强度仅 8 bit

10 月 17 日安全研究员向 Mozilla／Chrome 举报：印度／荷兰 CA eMudhra 有 8 张中级 CA 证书连同私钥被攻破，攻击者可用其给任意域名签发“真”TLS 证书（演示站已给 q3k.google.com 签了一张）。根因第二天揭晓，离谱程度空前：8 个 EC-384 私钥全是可猜的 0~255 之间的数——其中一个就是"4"。不是密钥被偷，是生成环节就用了可预测值。受影响信任链：emSign ECC Root CA - G3／C3、emSign Root CA - C1，外加走 Comodo AAA Services root（现名 Sectigo）交叉签名的 4 张。CVE-2026-111943。

浏览器侧已处置：Mozilla 当天将 8 张中级证书记入 OneCRL，10 月 20 日进一步移除相关根证书，Firefox／Chrome／Safari 访问演示站均报证书被吊销警告。但攻击者要真正 MITM 还需控制 DNS 或路由，普通用户风险有限。

Linux 服务器管理员需自查：在 distro 更新 ca-certificates 前，受影响根仍在信任库。Debian 手动拉黑：dpkg-reconfigure ca-certificates → Ask → 反选 emSign_ECC_Root_CA_-_G3、Comodo_AAA_Services_root 两项。Go、python-certifi、NetBSD 已各自发通告。自测： emudhra.we-have-a-problem.com 逐个子域名连一遍，能打开就说明环境还信任被攻破的 CA。

https://www.heise.de/news/Vorfall-bei-Zertifizierungsstelle-eMudhra-Acht-CA-Zertifikate-kompromittiert-11494412.html
https://emudhra.we-have-a-problem.com/

【更正】受影响层级此前报道有误，确切范围是：8 张坏中级全部挂在 emSign ECC Root CA - G3 一根之下（其中 6 张另持 Sectigo 前身 Comodo AAA Certificate Services 的交叉签名，Sectigo 已于 10 月 19 日吊销交叉证书止血）。
emSign Root CA - C1／G1、emSign ECC Root CA - C3 与本次事故无关——eMudhra 官方确认 C1/C3 移除是原定的退役计划。挂在 G1 下的还有美国 Internet2 的 InCommon 证书服务（ internet2.edu 实测链路 InCommon → emSign Root TLS CA - G1 → emSign Root CA - G1），全美高校科研网大量在用，拉黑 G1 会误伤它们。

#Security #PHP #漏洞预警 #RCE
PHP 紧急修复两处未认证远程代码执行漏洞：CVE-2026-109618、CVE-2026-109619，CVSS 4.0 均为 9.2。攻击成功可获得 Web worker 权限，读取配置及凭据、篡改业务文件或执行命令。

CVE-2026-109618：内存耗尽时，PHP 通过 longjmp() 提前退出，可能留下未完成初始化的请求数据，后续清理访问这些无效状态，造成内存破坏。multipart 请求可放大内存消耗；官方已在 mod_php 默认 PHP 限制下验证 RCE，且可在业务代码执行前触发。

CVE-2026-109619：请求结束后，部分全局状态仍指向已释放内存，同一 worker 处理后续请求时提前访问，形成跨请求 UAF。已确认路径涉及 session upload progress、PHP 8.5 fatal error backtrace 等。mod_php 和 FPM 均已验证 RCE，但 FPM 的已验证路径依赖特定应用行为和致命错误。

影响所有处理 Web 请求的 PHP 部署，具体利用条件因运行方式、配置和应用而异，mod_php 风险最高。 使用 FPM、关闭错误显示或增加 worker 数量，都不能视为免疫；只更新 CMS／框架也无法修复。

立即升级至 PHP 8.5.12／8.4.27／8.3.36／8.2.35，或安装发行版明确回补两个 CVE 的补丁，并重启全部 PHP worker。 PHP 8.1 及更早版本已结束常规官方支持，但本次官方额外提供了 7.4／8.0／8.1 最小源码回补分支，旧系统需确认补丁来源或升级分支。

Cloudflare WAF 和关闭上传进度等 workaround 只能阻断部分路径，不能代替升级。目前已确认完整 RCE 利用，查到的公开资料尚未确认在野利用。

官方公告与缓解措施 · OOM 漏洞详情 · 跨请求 UAF 详情 · Cloudflare WAF 更新

#security
“地狱级 on-call”里的近期安全事件
时间截至 2026 年 10 月 21 日

• PHP-FPM 7.3＋旧 WordPress：今天的 PHP2Shell。 CVE-2026-109618／109619 涉及内存耗尽后的状态破坏、跨请求残留状态，可导致 RCE。“刚从 5.6 升到 7.3”仍没避开这轮风险，而且没有上游 7.3 修复版。WordPress 同日警告：要更新的是 PHP，不是等 WordPress 补丁。FPM 的利用涉及特定应用路径和 worker 状态。PHP 公告

• Next.js 16.0.7 App Router：10 月 14 日新 RCE。 App Router＋Cache Components 中，use cache 返回多个 typed arrays 的路径存在未认证 RCE；16.0.7 在受影响范围，16.4.1 修复。梗是“新官网刚翻新，框架又要补”。公告

• NGINX 1.23.0：10 月 14 日的新内存安全问题。 CVE-2026-15176 的 alias/rewrite 堆溢出、CVE-2026-97205 的 AIO/SSI UAF 均覆盖该版本，需相应配置；本轮修复版为 1.30.6／1.31.7。公告

• Node.js 24 LTS＋Brotli：今天的 CVE-2026-111497。 Brotli 解码器越界写可导致 RCE，24 分支修于 24.22.1。注意是处理不可信数据的解码／解压路径，不是单纯压缩本站响应。公告

• Rust＋Cranelift＋WASM：10 月 19 日的新沙箱逃逸。 Cranelift 的 SSA 索引溢出可导致错编译，默认设置、各架构均可能受影响；攻击者控制的 Wasm 能突破沙箱。笑点是“语言安全、沙箱隔离都上了，编译器把边界编坏了”。公告

• LiteLLM＋CI＋全公司 Harness：今天第二次供应链投毒。 恶意版本是 1.107.0，含凭据窃取和远程代码加载逻辑，Python 启动钩子使其不必显式导入 LiteLLM 就能触发。本次官方公开 Docker 镜像也受影响。 CI 自动升级再全员部署，等于替攻击者分发恶意依赖。事件记录

• 高价采购 TiDB：10 月 19 日 PingCAP 外泄公告。 被盗服务账号用于访问内部系统，部分云客户相关记录和源代码被复制。梗是“刚花钱买企业方案，供应商自己先出安全事故”。官方报告

• Sectigo＋emSign＋Go／Rust／Python 信任库：同一宗 CA 事故。 10 月 17 日接报、20 日公开：六个 TLS、两个代码签名中间 CA 的弱密钥失陷，Sectigo 交叉签发扩大了相关信任链范围，带动各语言信任库紧急更新。不是这些库被投毒，也不是所有根私钥泄露。没上 ACME，让换证更费人工；低价和商业保障不等于加密强弱；代码签名也不等于给机密文件加密。原始通告

• Docker 29：10 月 20 日紧急证书更新。 29.9.2 更新 Go，阻断上述失陷中间 CA；依赖相关证书链的镜像仓库会出现拉取／推送 TLS 验证失败。补丁本身也会带来换证和发布链路的运维工作。发行说明

• Kubernetes＋Traefik mTLS fail-open：10 月 16 日公告。 Traefik 的 Kubernetes Ingress NGINX provider 中，同 host 的 Ingress 证书配置冲突，在未启用严格 TLS options 时可回退为“不要求客户端证书”。影响 3.7.0-ea.1—3.7.14，3.7.15 修复。不是开了安全功能，而是门禁出错后直接放行。公告

• Vyper：10 月 6 日的错编译公告。 多字节字符或 BOM 可令源码中的数字、地址与实际编译值不一致；攻击者贡献的恶意源码一旦被接受，人工审计看到的常量可能不是链上执行的常量。公告

• ASP.NET Core＋宿主 .NET 服务：10 月 13 日补丁批次。 前者有 Kestrel 请求走私 CVE-2026-88092；后者有 Unix 命名 mutex／共享内存路径提权 CVE-2026-96231，需要本地低权攻击者与高权服务进入相关路径。入口和宿主服务都得补。HTTP 公告 · 本地提权公告

• GitLab 自身也有本月 RCE。 10 月 12 日公告的 CVE-2026-97229 涉及 CI/CD 正则编译器，特定条件下可未认证执行服务器代码；修于 19.2.8／19.3.5／19.4.2。公告

• PVE 7.4 被打穿：今年 9 月 1 日公开的认证绕过。 CVE-2023-54391 虽带“2023”，却是今年确认安全影响并公告。受影响组件为 libpve-access-control >=7.0-7 且 <8.0.4；API 可达、账号未配置二因素时可绕过认证。虚拟化管理层失守，就会危及其承载的 GitLab 和 CI。公告

• ARTEX＋免费 AI：攻击自动化的成本反差。 10 月 7 日公开调查记录了 ARTEX、Claude Code 和 DeepSeek v4.1-flash 被用于攻击；OpenCode 也提供限时免费的同名模型。企业投入昂贵、复杂的技术栈，攻击工具和模型的使用门槛却在下降。调查报告

• GitHub 又出故障：救火链路也卡住。 今天官方记录了 PR、Actions、Webhook 等延迟。急着发补丁，代码协作和自动化平台也来添乱。状态记录

最后的 on-call 才是包袱：业务、运行时、沙箱、证书、供应链、虚拟化和发布平台接连出事——选型未必是你定的，半夜告警却全打给你。

#security #CVE #GitLab
GitLab：又发满分 RCE 紧急补丁！
CVE-2026-110264（CVSS 10.0）涉及正则表达式编译器整数溢出，特定条件下，未经认证的攻击者可在 GitLab 服务器上执行任意代码，影响横跨从 7.0 起的多个版本分支。
当前修复版为 19.5.1／19.4.3／19.3.6，旧版本分支也提供了修复版（backport）：19.2.9／19.1.9／19.0.10／18.11.13。
官方公告

「正准备靠 GitLab 发补丁，发布平台自己也急需补丁」

#security
v12sec｜x402 支付协议审计出 25 个漏洞，三个严重级涉及付款绕过、跨站登录签名与无限额扣款

v12sec 公布对 x402 协议代码库的审计结果，共报告 25 个漏洞，其中 3 个为严重级，研究方称已于 8 月 20 日修复，但 x402 仓库未发布对应安全公告，修复进展目前仅为研究方自述。

第一个：TypeScript 版 Solana facilitator 校验交易时只检查代币程序是否合法，再按固定位置把第三条指令当作 TransferChecked 解析，全程不校验指令类型，而 ApproveChecked 与 TransferChecked 的数据布局仅首字节不同，攻击者用纯授权指令就能通过金额、代币和收款方全部检查，facilitator 判定支付有效并交付资源，商户实际收不到任何代币，攻击者不需要持有代币余额，facilitator 还会替其付手续费。

第二个：Sign-In-With-X 自动签名包装器直接采用 402 响应里服务器提供的 domain 与 uri 字段，签名前不校验是否为本次访问的站点，恶意 API 可先从目标网站拿到真实登录挑战，嵌入响应收集客户端签名，再提交给目标网站完成登录，目标站自身的域名与签名校验全部照常通过，实质是钱包会话接管。

第三个：文档给出的默认客户端配置不设单笔与总消费限额，直接选用服务器返回的第一个支付方案，金额、代币、收款方与网络都由服务器指定，恶意 API 可把一次普通数据请求变成转走钱包全部代币余额的授权，对有余额的自动化客户端与 AI agent 危害最大。

三者分别跨越支付有效性、签名归属与消费限额三类信任边界；利用验证均在本地完成，未提交真实链上交易，推文与文章均未提供在野利用证据。

防御要点是校验必须发生在签名或结算之前：Solana 校验器先确认指令类型再解析转账，登录签名前比对 domain 与 uri 和实际访问站点，客户端强制执行显式单笔与总额预算，并限制允许的代币、网络与收款方；依赖 x402 的项目应尽快升级并确认所用 facilitator 与 SDK 已含上述修复。

研究发布推文 · 串内补充 · 串内补充
研究说明

#CVE #security
Next.js 10·14 带外安全更新：两个 Critical RCE＋一个 High DoS

官方发布带外安全更新，修复原定 9 月因上游依赖拖延而推迟的两个漏洞，共三项。
修复版本：v16.4.1（Active LTS）、v15.5.28（Maintenance LTS）。

漏洞清单
- Critical｜use cache 返回多个 typed arrays → 未认证 RCE：App Router＋Cache Components 场景触发，无可用缓解措施，即使代码里没有类似函数也须立即升级。GHSA-673q-mjm6-r5xr，根因在上游 React（GHSA-xqc2-xf4c-x3h3）。
- Critical｜Image Optimization API 处理 SVG → 未认证 RCE：仅 glibc Linux 上的 Next.js 受影响，问题出在上游图像库内存缺陷。临时缓解：确保 sharp ≥ 0.35.5；升级 Next.js 后包管理器会自动带上修复版。CVE-2026-96889。
- High｜Server Actions DoS：App Router 且至少有一个 Server Action 即受影响，构造请求可打满 CPU 阻塞同进程；Pages Router 或未用 Server Actions 不受影响。GHSA-p3m5-59mp-jv5r。

该做什么
- npm install next@16.4.1（16.4 线）或 npm install next@15.5.28（15.5 线）。
- 暂时无法升级的，先核查 sharp 版本（第二个漏洞的缓解），第一个漏洞无缓解、优先处理。
- 面向公网的 App Router 站点按 Critical 优先排期。

（应该是上周爆出来的，可以算旧闻了）

#blog #security #CVE
Security | PHP2Shell：内存耗尽之后，服务器怎么就被拿下了？

10 月 21 日，PHP 8.5.12 等版本紧急修复两个 CVSS 9.2 的未认证 RCE。本文从当晚半个互联网的停服现场说起，拆解 CVE-2026-109618 / 109619 的三条利用路径、可复用攻击原语，以及 9bie 在官方默认配置上跑通的纯 HTTP 武器化链，兼谈修复与检测。

https://miaotony.xyz/2026/10/22/Vuln_PHP2Shell/

#security
Tailworm：Tailscale 与 headscale 安全审计报告

暂无 CVE 编号，未经厂商协调披露。研究者认为「基础设施今天就是脆弱的」，故直接公开。测得版本：Tailscale v1.104.2 ＋ headscale v0.29.5，2026-10-22～24 实测复现。

三个最值得注意的问题

① SSH 权限可直接换 root
tailscaled 以 root 运行，ssh -L／-R 的路径检查和文件操作全在 root 身份下完成。
已验证产出：uid=0、读到 /etc/shadow、劫持 docker.sock、抓到 docker 明文仓库凭据。
不需要 sudo，不需要进 docker 组，不需要密码。

② 单台设备失守可扩散至全网
Tailscale SSH 不做用户级认证——它认的是设备，不是人。
实测扩散：每跳不到 1 秒，自动铺满所有策略允许的设备，零密码、零密钥、零交互。
唯一能有效限制的是：逐对授权规则。

③ 设备密钥外泄后身份可被冒用
竞态劫持控制面 socket → 截获 authkey → 在自己机器上用掉 → 顶着受害者身份加入 tailnet，在设备列表里就是一台正常服务器。

另外三类问题
- app connectors（conn25，实验特性）：真实目标由客户端自选且不校验，ACL 不参与判断 → 可达云 metadata 窃取凭据，K8s 环境可达全部服务。
- headscale 控制面：未认证即可打爆内存、卡死注册流程，导致全组织无法新增设备。
- tailscale serve：一行配置即会把管理 API 暴露给远端。

目标枚举成本极低
每个节点无条件获取全网 peer 列表；探测连通性为三态且静默，数分钟即可绘制出策略边界，且不会触发任何告警。

建议排查顺序
1. 逐对 SSH 授权，移除身份级／标签级 accept 规则。
2. 关闭转发：SaaS 将 forwarding 字段设为 false；headscale 用户应按 root 权限收口 SSH 授权。
3. 服务器群启用节点密钥过期 ＋ TPM／Secure Enclave 绑定。
4. 遥测部署在被入侵主机无法触达的位置。
5. 收敛 connector 权限，配置目标白名单。
6. 事件响应以控制面删除设备为准——重装系统无法吊销已外传的密钥。

报告的核心价值：它指出 Tailscale 的授权模型建立在「设备可信」的假设上，而执行层的特权边界明显宽于该假设。SSH 不做用户级认证、代理不校验真实目的地、socket 路径校验与实际使用之间存在竞态——三处叠加，形成了从一台普通设备直通 fleet-wide root 的路径。

原报告：tailworm.com（含 PoC 目录与 sha256） from Cyberdione Labs

#今天又看了啥 #security #PDF
v12sec｜MuPDF、Foxit 的 AES-256 文件密钥可预测，免密码解密 PoC 已公开

TL;DR：v12sec 公开 MuPDF 与 Foxit 的 PDF 解密器，研究方展示了拿到受影响加密文件后、无需用户或所有者密码的离线解密，问题在文件密钥生成，而非 AES-256 算法本身被攻破。

据研究说明，MuPDF 1.28.5 之前版本使用时间戳播种的线性同余生成器，取字节方式使输出仅受时间戳的 9 位影响，在已知随机流偏移下只有 512 种候选；公开 PoC 覆盖安全处理器 revision 6、AESV3 文件，并尝试多种密钥偏移。

Foxit 的测试对象为 Windows x64 版 PDF Reader 2026.1.3.36551，参与密钥派生的未初始化缓冲区在测试中全为零，使密钥实际只随 32 位时间戳变化；PoC 利用 /Perms 块的已知结构筛选候选，覆盖该构建生成的 AES-256-CBC 与 AES-256-GCM 文件，不外推其他版本。

MuPDF 官方 9月25日发布的 1.28.5 更新日志明确列出 Bug 709668，将随机数生成改为 ChaCha20 密码学 PRNG，与研究方给出的修复版本一致。

Foxit 部分目前仍是研究方披露，本次未查到对应厂商确认或明确修复版本，研究文章与仓库也未提供在野利用证据。

建议 MuPDF 用户及集成方升级至 1.28.5 或更高受支持版本，并用已确认安全的实现和全新文件密钥重新加密受影响文档；仅升级软件不能保护旧密文，已流出的副本也无法追溯补救。

PoC 发布推文 · 漏洞披露推文
研究说明 · 解密器与测试范围
MuPDF 官方更新日志 · Foxit 安全公告索引