toml-node 5.0.0 仍可通过引号路径污染 Object.prototype,附 PoC
toml-node 5.0.0 中,用 toml.parse() 解析一份四行 TOML 文档即可把属性写入 Object.prototype,该属性对进程内所有对象可见。
为什么值得看:文章给出可运行的 TOML 文档与脚本,说明 5.0.0 仍可经 Date 原型链污染 Object.prototype。
toml-node 5.0.0 中,用 toml.parse() 解析一份四行 TOML 文档即可把属性写入 Object.prototype,该属性对进程内所有对象可见。
为什么值得看:文章给出可运行的 TOML 文档与脚本,说明 5.0.0 仍可经 Date 原型链污染 Object.prototype。
GitHub 安全公告 GHSA-83vg-56qc-22m7 指出 GitPython 的 create_submodule 在拒绝 .git 路径之前就已把子模块克隆进仓库的 .git 目录。
为什么值得看:公告给出了可复现的 PoC 与逐行调用栈,说明校验发生在克隆落盘之后,可据此判断自身调用路径是否受影响。
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 的应用可据此自查。
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 有符号整数下溢未定义行为。
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 安全公告 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 撤销令牌会静默失效,便于自查撤销逻辑。
安全公司 FoxIO 披露 HTTP/3 的 QPACK 头压缩存在一类缺陷,未登录的远程攻击者用单个连接、少量压缩头部即可让服务器内存膨胀数千倍并耗尽内存,FoxIO 同时公开了可运行的 PoC。
为什么值得看:FoxIO 公开了可运行的 PoC,并给出各 HTTP/3 实现是否已修复的对照表,运维可据此判断自己使用的栈是否暴露。
GitHub 安全公告披露,@vitest/mocker 针对 GHSA-82fw-gwwq-j7x9 的路径穿越修复在 Windows 上可被反斜杠绕过:修复代码用 node:path/posix 拼接攻击者可控的 URL pathname 与 Vite root。
为什么值得看:作者用可运行脚本对比正斜杠与反斜杠两种遍历,说明已修复的路径穿越在 Windows 上仍可绕过。
@vitest/mocker 的 interceptorPlugin 在 Vite 开发服务器 WebSocket 上接受未认证的 mock 注册,并把 mock 的 url 未转义地插入生成的模块源码,能访问开发服务器端口的非浏览器 WebSocket 客户端可让服务器以任意 JavaScript 替换项目模块,并在开发者浏览器中执行。
研究者披露 Pillow 的 PIL.EpsImagePlugin.Ghostscript() 在构造 Ghostscript 命令行时直接把用户可控的文件名放在 -f 位置,未校验以 - 或 @ 开头的文件名,构成 CWE-88 参数注入。
为什么值得看:研究者公开了 Pillow 调用 Ghostscript 时的参数注入 PoC,并验证可链式执行命令,默认 -dSAFER 配置下同样成立。
Pillow 的 P;2L 和 P;4L 原始解码器在特定宽高下会读取超出传入缓冲区末尾 1 至 3 字节,原因是 ImagingRawDecode 按位深计算行字节数,而 unpackP2L/unpackP4L 按 2 或 4 个位平面各自按字节补齐,两者对一行数据占用字节数的理解不一致。
Pillow 的 ImagingScaleAffine()(src/libImaging/Geometry.c:866)在 calloc 失败时对调用方拥有的输出图像调用 ImagingDelete(),随后 Python 对象析构时再次释放,形成 use-after-free 与双重释放。
GitHub 安全公告 GHSA-j4m9-6w36-pw47 指出,Pillow 在 stroke_width 非零时创建 FreeType stroker,若 FT_Load_Glyph 对某个字形失败,清理路径会对未初始化或已释放的 glyph 指针调用 FT_Done_Glyph,形成无效释放或双重释放。
为什么值得看:公告给出可运行的 fontTools 脚本,复现 Pillow 在描边绘制时对未初始化指针调用 FT_Done_Glyph 的路径。
Pillow 的 Image.merge() 只校验 bands[1:] 的模式与尺寸,当 band 0 是单波段 I 或 F 图像时,其 image8 平面为 NULL,ImagingMerge 在 src/libImaging/Bands.c:302、:311、:321 解引用该空指针导致进程崩溃。
为什么值得看:公告给出可运行的 PoC 与崩溃栈,说明 Image.merge 只校验 band 0 之外的分带,便于确认 Pillow 部署是否受影响。
Pillow 的 MicImagePlugin 在读取内嵌 TIFF 含 3 个及以上 IFD 的 MIC 文件时,访问 im.n_frames 会陷入无限循环、占满单核 CPU 且不抛异常。该问题仅影响安装了可选 olefile 包的环境,源于 7.2.0 引入的回归,Image.open、load、is_animated 等调用不受影响。
GitHub 安全公告指出 Pillow 的 GifImageFile._seek() 在 src/PIL/GifImagePlugin.py 中用 bytes 拼接累积 GIF 注释,使 Image.open() 耗时随注释数据量呈二次方增长,默认设置下 2 MB 文件约 5 秒、4 MB 约 35 秒、8 MB 约 3 分钟,而同样大小的普通 GIF 不到 1 秒。
为什么值得看:公告给出触发条件与实测耗时数据,并附上把 bytes 拼接改为列表 join 的补丁,便于使用 Pillow 的服务评估上传接口风险。
Pillow 的 PngImageFile._seek() 在处理首个 fcTL 请求 OP_BACKGROUND 时,会先按 IHDR 声明尺寸调用 Image.core.fill 分配并清零整块画布,之后 Image.open() 的 _decompression_bomb_check 才执行。
为什么值得看:材料给出可运行的复现脚本与两份补丁,说明 APNG 在炸弹检查前按声明尺寸分配内存的路径。
Pillow 在把 TIFF 保存到 io.BytesIO 等无 fileno() 的目标时,src/libImaging/TiffDecode.c 的 _tiffWriteProc 按 state->size + size 而非写入位置扩容,导致堆缓冲区溢出,同时把未初始化的堆字节写入输出文件。
为什么值得看:报告给出可运行的复现脚本与补丁,说明默认设置下把上传图片另存为 TIFF 到内存对象即可触发越界写。
Pillow 的 libtiff 编码器 PyImaging_LibTiffEncoderNew(src/encode.c)在把源 TIFF 中未识别的标签转发给 TIFFSetField 时,按 Python 值而非 libtiff 字段定义决定传参形式,导致构造的 TIFF 标签被当作字节数或指针读取。
为什么值得看:材料给出可运行的复现脚本与逐分支分析,展示了普通 open 后 save 即可触发内存泄露或崩溃的路径。
ApostropheCMS 的公共 REST API 在处理匿名请求时,会先执行 query string 中所有可 launder 的查询构造器,再强制套用 publicApiProjection,而 search 与 sort 这两个构造器作用于底层文档、不受投影限制。
为什么值得看:公告给出可复现的 curl 请求与实测结果,说明 search 与 sort 两个查询构造器如何绕过字段白名单。
ApostropheCMS 的页面 REST 接口 GET /api/v1/@apostrophecms/page/:id 未应用 viewRole 类型级限制和 viewPermission 字段级脱敏,而 getAll 接口对两者均正确执行。编辑级用户只要知道文档 _id,即可读取仅限管理员访问的页面全文及受 viewPermission 保护的字段。
GitHub 安全公告 GHSA-rq7h-c2jc-7f22 指出,Vite 开发服务器在非 Windows 机器上,当项目导入文件的根相对路径与宿主机绝对路径相同时,可把 server.fs.allow 之外的文件内容返回给浏览器,例如 /etc/hosts。
为什么值得看:公告给出了可复现的 curl 步骤,说明非 Windows 环境下 Vite 开发服务器如何把宿主机文件返回给浏览器。
Vite 开发服务器在将未经修改的浏览器请求 URL 传入 server.transformIndexHtml 时存在跨源脚本执行问题,攻击者可构造含 `//` 的路径让生成的模块 src 指向外部域名,从而在 Vite 页面中执行任意 JavaScript。
GHSA-gfr2-rv44-r23c 指出 markdown-it 15.0.2 在默认配置下处理未闭合的链接引用定义标签或标题时呈 O(n²) 复杂度,属 CWE-407 算法复杂度拒绝服务,该问题由 14.0.0 的 PR #1004 引入。
为什么值得看:公告给出可运行的 PoC 与各版本耗时对比,能帮助用 markdown-it 渲染用户内容的服务判断是否需要限制请求体大小。
Pillow 在 ImagingJpegDecode 中未校验 libjpeg 返回的 output_width 与缓冲区尺寸,当 libjpeg-turbo 3.x 解码 SOF3 无损 JPEG 时缩放参数被忽略,导致堆缓冲区溢出。
为什么值得看:披露给出完整 Docker 复现与 ASan 报告,说明 thumbnail 默认路径如何触发堆溢出,便于自查与修复验证。
Pillow 的 PDF 解析存在无界递归问题,是 CVE-2026-42310 修复不完整的后续。
Pillow 的 TIFF 编码器在保存保留元数据的 TIFF 时存在堆越界读取:一个 1×1、16 位灰度、PackBits 压缩且含 tag 320(ColorMap)768 个 SHORT 值的 TIFF 可正常打开加载。
Pillow 的 EPS 处理中,`load(scale=N)` 会把文件声明的尺寸乘以 scale 后直接交给 Ghostscript 渲染,却只对未缩放的原始尺寸做解压炸弹检查。
Pillow 的 GifImageFile._seek() 在触发 DecompressionBombError 前就把放大后的尺寸写入 self._size,异常后不回滚,导致约 60 字节的 GIF 可让应用分配数 GB 内存直至 OOM。
Pillow 的 PPM/PGM 解析器接受宽度为 0 的图像,将其传给 ImageMorph.MorphOp.apply() 时,_imagingmorph.c 中的原生形态学代码会写入 outrow[width - 1](即 outrow[-1]),导致进程崩溃。
A2A Java SDK 的 Android 同步 POST 路径在 GHSA-9rhm 修复后仍会跟随跨域重定向,把 X-API-Key、API-Key、X-Auth-Token、X-Authentication 四个非标准认证头转发到另一个 authority。
Cachet v3 的事件创建表单存在存储型 XSS 漏洞,事件 Name 与 Message 字段未正确过滤 HTML 事件处理属性,受影响端点 /dashboard/incidents/。