Astro 修复 JSX/MDX 渲染中 script/style 内容未转义导致的反射与存储 XSS
Astro 发布安全通告,指出 JSX 与 MDX 渲染管线对 script、style 元素的动态字符串子节点未做转义,攻击者可控值可提前闭合元素并注入任意 HTML 与 JavaScript,造成反射或存储 XSS。
为什么值得看:通告说明了 Astro 的 JSX/MDX 渲染在动态字符串子节点上未转义,并给出 7.3.2 修复版本与规避写法。
Astro 发布安全通告,指出 JSX 与 MDX 渲染管线对 script、style 元素的动态字符串子节点未做转义,攻击者可控值可提前闭合元素并注入任意 HTML 与 JavaScript,造成反射或存储 XSS。
为什么值得看:通告说明了 Astro 的 JSX/MDX 渲染在动态字符串子节点上未转义,并给出 7.3.2 修复版本与规避写法。
Storybook 发布安全通告,指出 dev server 会把 WebSocket 认证 token 暴露给任何能加载其 HTML 页面的客户端,同一局域网内的主机可通过 IP 访问并取得该 token,进而向 story 文件注入代码或创建新文件,在特定条件下可在开发者机器上执行代码。
GitHub 安全公告披露 toml-node 的 toml.parse() 在处理十六进制、八进制、二进制和十进制整数字面量时,未先限制数字串长度就直接调用 BigInt(),导致超线性耗时。
为什么值得看:公告给出了可复现的 PoC 与实测耗时表,说明单个超长整数字面量即可阻塞 Node.js 事件循环。
GitHub 安全公告指出 npm 包 toml(BinaryMuse/toml-node)的 toml.parse() 在处理超长点分键、表头或内联表键时存在 O(n²) 复杂度问题,v5.0.0 仍受影响且尚未修复。
toml-node 的 toml.parse() 存在二次复杂度(O(n²))DoS:lib/compiler.js 的 addTableArray() 每遇到一个 [[name]] 头都会全量重扫两个记账 Set 且不清理无关条目。
toml-node 5.0.0 中,用 toml.parse() 解析一份四行 TOML 文档即可把属性写入 Object.prototype,该属性对进程内所有对象可见。
为什么值得看:文章给出可运行的 TOML 文档与脚本,说明 5.0.0 仍可经 Date 原型链污染 Object.prototype。
fastify 发布通告,指出 headers schema 在编译前只把属性键位置的头部名转小写,propertyNames 子 schema 中 enum 与 const 里的头部名未被归一化,导致以标准大小写书写的头部名拒绝列表无法匹配小写请求头,被禁止的头部仍可到达处理函数。
为什么值得看:通告说明这是 CVE-2026-84428 修复不完整留下的缺口,并给出 5.12.6 升级与两种规避写法。
GitHub 安全公告 GHSA-83vg-56qc-22m7 指出 GitPython 的 create_submodule 在拒绝 .git 路径之前就已把子模块克隆进仓库的 .git 目录。
为什么值得看:公告给出了可复现的 PoC 与逐行调用栈,说明校验发生在克隆落盘之后,可据此判断自身调用路径是否受影响。
GitHub 安全公告库发布 Next.js 通告,指出使用 App Router 与 Cache Component 的应用若存在返回多个 typed array 的 use cache 函数,可导致远程代码执行。通告称此类受影响应用没有已知规避方案,即使应用不含类似函数也建议立即升级。
为什么值得看:通告说明使用 App Router 与 Cache Component 且 use cache 函数返回多个 typed array 的应用存在 RCE 风险,且无规避方案。
Electron 修复了 macOS 离屏渲染模式下主进程未充分校验 GPU 进程帧数据的问题,被攻陷的 GPU 进程可致主进程在生成 paint 事件图像时越界读取内存,造成内存泄露或应用崩溃。
pypdf 存在内存占用过大问题:攻击者可构造包含大量小操作的 PDF 内容流,在解析时消耗大量内存。该问题已在 pypdf 6.21.0 中修复,暂无法升级的用户可参考 PR #4218 中的改动作为规避方案。
pypdf 存在解析数组和字典时内存占用过大的问题,攻击者可构造含大量元素的 PDF 触发。该问题已在 pypdf 6.21.0 中修复,无法升级者可参考 PR #4218 的改动作为规避方案。
pypdf 在读取文档表单字段时存在资源消耗问题,攻击者可构造 PDF 导致大量内存占用或长时间运行。该问题已在 pypdf==6.21.0 中修复,无法升级的用户可参考 PR #4219 中的改动作为规避方案。
Nuxt 通告指出,routeRules 的键与原始请求路径比较时未解码百分号编码,而路由解析会解码参数,因此对动态或通配路由发起的编码路径请求可跳过 appMiddleware 等规则,无需认证与用户交互。
为什么值得看:通告说明了动态与通配路由下 appMiddleware 被百分号编码绕过的条件,并给出修复版本与页面级中间件的规避方案。
Nuxt 披露 GHSA-934w-87qh-qr26(CVE-2026-53722)修复不完整:在 pages 禁用(pages 为 false、无 pages/ 目录)的应用中,将不受控输入绑定到 :to 时,以 ASCII C0 控制字符(如 %01)前缀的 javascript: URL 会被当作内部路由绕过协议检查,点击后在本域执行脚本。
Nuxt 的 server islands 在渲染 useHeadSafe 输入时未做净化,影响 nuxt >=3.13.0(引入 server islands head 支持的版本),Nuxt 2 不受影响。
Nuxt 发布通告,指出在默认 router.options.sensitive: false 下页面路由不区分大小写,而服务器端路由规则由 Nitro 匹配器按大小写敏感解析,导致 /Admin 这类大小写变体路径跳过 redirect、headers、proxy、ssr: false 等规则。
为什么值得看:通告说明大小写变体路径会跳过 redirect、headers 等服务器端路由规则,并给出 Nuxt 3 无修复的处置建议。
GraphQL-core 发布通告,指出默认启用的 OverlappingFieldsCanBeMerged 校验规则可被小体积查询触发二次复杂度,364 KB 文档在 3.2.8 上校验耗时 319 秒,且无需认证。
为什么值得看:通告给出了触发条件、实测耗时与修复版本,并说明常规深度限制和 WAF 为何挡不住这类校验期 DoS。
GraphQL-core 发布通告,指出解析器的 max_tokens 限制未统计注释 token,用注释填充的文档可绕过该限制并持续占用内存,38 MB 载荷在 max_tokens=5 下额外占用约 92 MB 常驻内存。
为什么值得看:通告说明了 max_tokens 未统计注释 token 的计数缺口,并给出升级后注释计入上限的行为变化。
GitHub 安全公告披露 @graphql-tools/utils 的 mergeIncrementalResult 存在原型污染,攻击者可用数组形式的 path 段绕过 __proto__ 等键名检查,向 Object.prototype 写入任意属性。
为什么值得看:报告给出可运行复现与 npm 各版本实测差异,说明非原始类型 path 段如何绕过键名检查写入 Object.prototype。
Astro 的 View Transitions CSS 生成器未将字符串动画属性限制在生成的声明内,攻击者可控数据进入 duration 等属性时可注入 CSS。
GitHub 安全公告 GHSA-xcq7-p3pf-p88h 指出,opentelemetry-api 的 TraceState.from_header 用正则拆分 W3C tracestate 头且未先做长度限制。
为什么值得看:通告给出受影响版本区间与 1.45.1 修复版本,并说明默认传播配置下即可触发,便于确认部署风险。
GitHub 安全公告指出 nbconvert <= 7.17.1 在导出为 markdown、latex、rst、asciidoc 时存在任意文件写入漏洞,ExtractOutputPreprocessor 在 extractoutput.py:116-119 将攻击者可控的 path 直接拼接到 output_files_dir 且未做规范化校验。
为什么值得看:公告给出可复现的 ipynb 片段,说明恶意 cell 输出文件名如何穿越目录写入任意位置,便于验证与排查。
GitHub 安全公告 GHSA-c6gr-qvv4-5v3f 指出,DOMPurify 在 PARSER_MEDIA_TYPE 设为 application/xhtml+xml 时。
为什么值得看:材料给出可运行的 PoC 脚本与复现步骤,说明 XHTML 解析模式下 SMIL 属性名大小写差异如何让过滤失效。
DOMPurify 3.4.16 针对 GHSA-p98j-92pf-mc4p 的修复不完整:_handleHookDetachedNode() 只检查 hook 自身节点是否失去父节点,当 IN_PLACE hook 删除当前节点的父节点或尚未访问的兄弟节点时,该子树不会被遍历或中和,事件处理器保留。
为什么值得看:材料给出可运行的 jsdom 与浏览器复现,说明 3.4.16 的修复只覆盖 hook 删除自身节点的情况,使用 IN_PLACE 的应用可据此自查。
DOMPurify 在同时启用 SAFE_FOR_TEMPLATES 与 RETURN_DOM、RETURN_DOM_FRAGMENT 或 IN_PLACE 时,附加 shadow root 文本内容中的 {{...}}、${...} 等模板表达式可绕过净化存活。
Jupyter Server 2.0.0 至 2.5.0 在启用 GatewayClient.url 后,Gateway WebSocket 处理器只校验用户已认证,不调用 Authorizer 判断其是否有权执行内核,被拒绝 execute 权限的已认证用户仍可打开内核通道向上游内核发送消息。
PyJWT 的 HMACAlgorithm.from_jwk 接受 k 为空字符串的 oct JWK 并返回零长度密钥,使经 PyJWK、PyJWKSet 或 PyJWKClient 校验的 HS256/384/512 令牌可被攻击者用空密钥伪造,默认配置下仅触发 InsecureKeyLengthWarning 而不报错。
为什么值得看:披露 PyJWT 空 HMAC 密钥校验缺口的同时给出可运行的伪造令牌复现流程,便于自查 JWKS 配置。
GitHub 安全公告 GHSA-jj87-hc4r-jwfw 指出,npm 包 stream-json 的 FlexAssembler 在规则 filter 为字符串或 RegExp 时,每次容器开始都会对完整 keyStack 执行 join,嵌套深度 D 的文档产生 O(D^2) CPU 开销,约 96 KB(深度 16000)的输入可阻塞事件循环超过 1 秒。
为什么值得看:通告说明 stream-json 的 FlexAssembler 在字符串或 RegExp 过滤规则下存在平方级 CPU 消耗,并给出 maxDepth 默认 1024 的修复。
Librsvg 解析含嵌套 XInclude 的 SVG 文档时,若实体声明与已有实体重名,会触发释放后使用错误:递归 XInclude 解析的另一文档声明同名实体,经 entity_insert() 替换首个条目并调用 xmlFreeNode(),外层 xmlCtxtParseEntity() 仍继续使用已释放的 144 字节 xmlEntity。
GitHub 安全公告指出,Next.js 用于图像优化的上游库存在内存相关漏洞,当 Next.js 运行在基于 glibc 的 Linux 上时可能导致 RCE。规避方案是确保 Next.js 使用的 sharp 版本大于或等于 0.35.5,全新安装会自动获得修复版本,升级 Next.js 到已修复版本也能让包管理器自动提供修复后的 sharp。
为什么值得看:通告说明 Next.js 图像优化依赖的上游库存在内存问题,并给出 sharp 版本与升级两条规避路径。
Sentry-JavaScript SDK 的 tunnelRoute 选项会让 SDK 对隧道路径下的所有请求跳过中间件,而 rewrite 只处理隧道路径本身带 o 和 p 参数的请求,落在两者差距内的请求会进入应用且不经过中间件。
Pillow 的 Image._decompression_bomb_check 只在 Image.open() 时对首帧执行,MpoImageFile.seek() 与 DcxImageFile.seek() 重新解析帧后未再检查,构造首帧极小、后续帧超大尺寸的 MPO 或 DCX 文件即可绕过限制并耗尽内存。
GitHub 安全公告 GHSA-g842-9rc4-69pw 指出,Pillow 的 SpiderImagePlugin 中 seek() 绕过了解压炸弹检查:用 1x1 的 frame0 打开文件后调用 im.seek(1),尺寸被设为 (100,100) 却不触发 DecompressionBombWarning 或 DecompressionBombError。
GitHub 安全公告披露 Pillow 的 BmpRleDecoder 在 delta escape 与 absolute mode 分支中无界增长,约 1 KB 的构造 BMP 文件即可让进程分配数 GB 内存。
为什么值得看:披露给出可复现脚本与实测内存占用,说明约 1 KB 的 BMP 文件即可触发数 GB 级内存放大。
Pillow 12.3.0 的多帧加载器在帧间切换 mode 时会复用上一帧的原生 ImagingCore 存储,导致越界写与进程崩溃;作者在 PSD、MPO/JPEG、DCX、MIC 四个入口验证了该问题。
为什么值得看:披露者给出可复现的 MPO 上传路径与 10/10 成功标记,说明多帧模式切换导致的越界写可落到命令执行。
Pillow 的 PDF 追加路径(Image.save(..., format="PDF", append=True))在处理畸形 /Pages 树时会重复展开同一子引用,造成确定性资源耗尽。
Pillow 12.3.0 的 src/_imaging.c 中 xsize += dx 仅校验正向溢出,当 PILfont 字形步进 dx 取 -32768 并重复 65,537 次时触发 C 有符号整数下溢未定义行为。
Pillow 的 TarIO.__init__ 未校验 tar 头 size 字段是否为正,构造 size 为负值的头部会让 seek 回退到自身,形成永不返回的无限循环,进程占用 98%–100% CPU。
GitHub 安全公告指出,Pillow 的 Exif.load() 在剥离 EXIF 数据开头的 Exif\x00\x00 标记时,每轮都会复制剩余数据,而 PNG 的 eXIf 块没有像 tEXt、zTXt、iTXt 那样受 MAX_TEXT_CHUNK 和 MAX_TEXT_MEMORY 限制,因此填充重复标记的 eXIf 块会让解析耗时随块大小平方增长。