Nuxt 修复 routeRules 未解码请求路径导致 appMiddleware 被绕过的问题
Nuxt 通告指出,routeRules 的键与原始请求路径比较时未解码百分号编码,而路由解析会解码参数,因此对动态或通配路由发起的编码路径请求可跳过 appMiddleware 等规则,无需认证与用户交互。
为什么值得看:通告说明了动态与通配路由下 appMiddleware 被百分号编码绕过的条件,并给出修复版本与页面级中间件的规避方案。
厂商与组件
GitHub 安全公告库收录的开源组件漏洞、GitHub 自身安全问题与 PoC 仓库动态。
68 条精选近 30 天 68 条共收录 228 条
Nuxt 通告指出,routeRules 的键与原始请求路径比较时未解码百分号编码,而路由解析会解码参数,因此对动态或通配路由发起的编码路径请求可跳过 appMiddleware 等规则,无需认证与用户交互。
为什么值得看:通告说明了动态与通配路由下 appMiddleware 被百分号编码绕过的条件,并给出修复版本与页面级中间件的规避方案。
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。
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 的应用可据此自查。
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 的修复。
GitHub 安全公告指出,Next.js 用于图像优化的上游库存在内存相关漏洞,当 Next.js 运行在基于 glibc 的 Linux 上时可能导致 RCE。规避方案是确保 Next.js 使用的 sharp 版本大于或等于 0.35.5,全新安装会自动获得修复版本,升级 Next.js 到已修复版本也能让包管理器自动提供修复后的 sharp。
为什么值得看:通告说明 Next.js 图像优化依赖的上游库存在内存问题,并给出 sharp 版本与升级两条规避路径。
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 成功标记,说明多帧模式切换导致的越界写可落到命令执行。
GitHub 安全公告披露 Pillow 在 Windows 构建上存在堆越界读问题 GHSA-9v9v-9qvf-h2hj,EMF/WMF 图像尺寸未经范围检查即传入原生 drawwmf 处理程序,分配按截断为 16 位的头字段计算,拷贝却使用完整 32 位尺寸。
为什么值得看:公告给出可运行的 EMF 构造脚本,并指出 Windows 构建下 16 位截断导致堆越界读的具体代码位置。
Pillow 的 JPEG 编码器 ImagingJpegEncode() 在 src/libImaging/JpegEncode.c:330 写 COM 注释前不检查剩余空间,当 65498 字节 ICC profile 恰好填满 65536 字节缓冲区时,注释和整个压缩图像被写到堆缓冲区之外,进程以 SIGSEGV 或 glibc 堆错误终止。
为什么值得看:披露给出可运行的复现脚本与补丁,说明默认保存路径下 ICC 恰好填满缓冲区即触发越界写。
GitHub 安全公告指出,启用 cacheComponents: true 时,若一个 use cache 函数调用另一个读取 root param 的 use cache 函数,且内层调用命中已有缓存条目,外层函数的缓存键会遗漏该 root param,导致同一份响应被复用于所有 root param 值。
为什么值得看:通告说明启用 Cache Components 后嵌套 use cache 函数的缓存键会漏掉 root param,导致跨值内容串用,且无规避方案。
GitHub 安全公告 GHSA-3547-9m27-7rxg 披露 Django REST framework 的 JSONParser 会用客户端在 Content-Type charset 参数中指定的编码解码请求体,攻击者填入 bz2_codec 等字节变换编码即可绕过 Django 的 DATA_UPLOAD_MAX_MEMORY_SIZE 限制。
为什么值得看:公告给出可运行的复现脚本与四组对照,说明默认解析器下小请求体如何放大内存占用。
Django REST framework 的 content negotiation 对每个 Accept token 重复解析且不限制 token 数量与总大小。
为什么值得看:作者给出完整可运行 PoC 与实测耗时,说明默认 gunicorn 双 worker 部署下两个连接即可让服务停摆。
Django REST framework 的 TokenProxy.delete() 调用不抛异常并返回成功,但实际未删除数据库行,令牌仍可继续认证。原因是 TokenProxy 将 pk 覆写为 user_id,删除语句用用户 id 去匹配 40 位 key 列,返回 (0, {'authtoken.TokenProxy': 0})。
为什么值得看:材料给出可运行的复现脚本与对照实验,说明通过 TokenProxy 撤销令牌会静默失效,便于自查撤销逻辑。