跳到正文
只看一手#Python
  1. GitHub 安全公告库 (GHSA)60

    GraphQL-core 修复 OverlappingFieldsCanBeMerged 校验规则二次复杂度 DoS

    GraphQL-core 发布通告，指出默认启用的 OverlappingFieldsCanBeMerged 校验规则可被小体积查询触发二次复杂度，364 KB 文档在 3.2.8 上校验耗时 319 秒，且无需认证。

    为什么值得看：通告给出了触发条件、实测耗时与修复版本，并说明常规深度限制和 WAF 为何挡不住这类校验期 DoS。

  2. GitHub 安全公告库 (GHSA)58

    GraphQL-core 修复注释 token 绕过 max_tokens 限制导致的拒绝服务漏洞

    GraphQL-core 发布通告，指出解析器的 max_tokens 限制未统计注释 token，用注释填充的文档可绕过该限制并持续占用内存，38 MB 载荷在 max_tokens=5 下额外占用约 92 MB 常驻内存。

    为什么值得看：通告说明了 max_tokens 未统计注释 token 的计数缺口，并给出升级后注释计入上限的行为变化。

  3. GitHub 安全公告库 (GHSA)58

    OpenTelemetry Python opentelemetry-api 修复 tracestate 解析 CPU 耗尽问题

    GitHub 安全公告 GHSA-xcq7-p3pf-p88h 指出，opentelemetry-api 的 TraceState.from_header 用正则拆分 W3C tracestate 头且未先做长度限制。

    为什么值得看：通告给出受影响版本区间与 1.45.1 修复版本，并说明默认传播配置下即可触发，便于确认部署风险。

  4. GitHub 安全公告库 (GHSA)75

    PyJWT 2.13.0 及之前版本经 oct JWK 空 HMAC 密钥可伪造 HS256 令牌，2.14.0 修复

    PyJWT 的 HMACAlgorithm.from_jwk 接受 k 为空字符串的 oct JWK 并返回零长度密钥，使经 PyJWK、PyJWKSet 或 PyJWKClient 校验的 HS256/384/512 令牌可被攻击者用空密钥伪造，默认配置下仅触发 InsecureKeyLengthWarning 而不报错。

    为什么值得看：披露 PyJWT 空 HMAC 密钥校验缺口的同时给出可运行的伪造令牌复现流程，便于自查 JWKS 配置。

  5. GitHub 安全公告库 (GHSA)58

    Pillow BMP RLE 解码器存在内存放大 DoS，公开 PoC 与复现数据

    GitHub 安全公告披露 Pillow 的 BmpRleDecoder 在 delta escape 与 absolute mode 分支中无界增长，约 1 KB 的构造 BMP 文件即可让进程分配数 GB 内存。

    为什么值得看：披露给出可复现脚本与实测内存占用，说明约 1 KB 的 BMP 文件即可触发数 GB 级内存放大。

  6. GitHub 安全公告库 (GHSA)75

    Pillow 多帧加载器模式切换后复用旧原生存储，MPO 路径可致越界写与命令执行

    Pillow 12.3.0 的多帧加载器在帧间切换 mode 时会复用上一帧的原生 ImagingCore 存储，导致越界写与进程崩溃；作者在 PSD、MPO/JPEG、DCX、MIC 四个入口验证了该问题。

    为什么值得看：披露者给出可复现的 MPO 上传路径与 10/10 成功标记，说明多帧模式切换导致的越界写可落到命令执行。

  7. GitHub 安全公告库 (GHSA)58

    Pillow 修复 Windows 构建 WMF/EMF 渲染堆越界读漏洞 GHSA-9v9v-9qvf-h2hj

    GitHub 安全公告披露 Pillow 在 Windows 构建上存在堆越界读问题 GHSA-9v9v-9qvf-h2hj，EMF/WMF 图像尺寸未经范围检查即传入原生 drawwmf 处理程序，分配按截断为 16 位的头字段计算，拷贝却使用完整 32 位尺寸。

    为什么值得看：公告给出可运行的 EMF 构造脚本，并指出 Windows 构建下 16 位截断导致堆越界读的具体代码位置。

  8. GitHub 安全公告库 (GHSA)75

    Pillow JPEG 编码器堆缓冲区溢出：ICC 填满缓冲区后写 COM 注释越界

    Pillow 的 JPEG 编码器 ImagingJpegEncode() 在 src/libImaging/JpegEncode.c:330 写 COM 注释前不检查剩余空间，当 65498 字节 ICC profile 恰好填满 65536 字节缓冲区时，注释和整个压缩图像被写到堆缓冲区之外，进程以 SIGSEGV 或 glibc 堆错误终止。

    为什么值得看：披露给出可运行的复现脚本与补丁，说明默认保存路径下 ICC 恰好填满缓冲区即触发越界写。

  9. GitHub 安全公告库 (GHSA)65

    Django REST framework JSONParser 按攻击者指定 codec 解压请求体，公开 PoC 可绕过 DATA_UPLOAD_MAX_MEMORY_SIZE

    GitHub 安全公告 GHSA-3547-9m27-7rxg 披露 Django REST framework 的 JSONParser 会用客户端在 Content-Type charset 参数中指定的编码解码请求体，攻击者填入 bz2_codec 等字节变换编码即可绕过 Django 的 DATA_UPLOAD_MAX_MEMORY_SIZE 限制。

    为什么值得看：公告给出可运行的复现脚本与四组对照，说明默认解析器下小请求体如何放大内存占用。

  11. GitHub 安全公告库 (GHSA)58

    Django REST framework 的 TokenProxy.delete() 静默失效，撤销令牌不生效

    Django REST framework 的 TokenProxy.delete() 调用不抛异常并返回成功，但实际未删除数据库行，令牌仍可继续认证。原因是 TokenProxy 将 pk 覆写为 user_id，删除语句用用户 id 去匹配 40 位 key 列，返回 (0, {'authtoken.TokenProxy': 0})。

    为什么值得看：材料给出可运行的复现脚本与对照实验，说明通过 TokenProxy 撤销令牌会静默失效，便于自查撤销逻辑。

  1. BleepingComputer88

    LiteLLM 发布流水线被入侵，PyPI 与 Docker 镜像被植入窃密恶意代码

    LiteLLM 项目的发布流水线于 10 月 21 日被入侵，攻击者向 PyPI 和 Docker 仓库推送了 1.107.0 版本，其中包含窃取凭据并加载远程代码执行工具的编译恶意代码。

    为什么值得看：复盘列出了被投毒的 PyPI wheel 与 Docker 镜像标签及存活时间窗，可据此排查自己是否装过受影响版本。

  2. GitHub 安全公告库 (GHSA)68

    Pillow 的 Ghostscript 调用存在参数注入，公开 PoC 可链式实现 RCE

    研究者披露 Pillow 的 PIL.EpsImagePlugin.Ghostscript() 在构造 Ghostscript 命令行时直接把用户可控的文件名放在 -f 位置，未校验以 - 或 @ 开头的文件名，构成 CWE-88 参数注入。

    为什么值得看：研究者公开了 Pillow 调用 Ghostscript 时的参数注入 PoC，并验证可链式执行命令，默认 -dSAFER 配置下同样成立。

  3. GitHub 安全公告库 (GHSA)58

    Pillow 描边渲染字体时存在无效释放问题，附 PoC 复现脚本

    GitHub 安全公告 GHSA-j4m9-6w36-pw47 指出，Pillow 在 stroke_width 非零时创建 FreeType stroker，若 FT_Load_Glyph 对某个字形失败，清理路径会对未初始化或已释放的 glyph 指针调用 FT_Done_Glyph，形成无效释放或双重释放。

    为什么值得看：公告给出可运行的 fontTools 脚本，复现 Pillow 在描边绘制时对未初始化指针调用 FT_Done_Glyph 的路径。

  4. GitHub 安全公告库 (GHSA)58

    Pillow 的 Image.merge 因未校验 band 0 存在空指针解引用，公开 PoC 可致进程崩溃

    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 部署是否受影响。

  5. GitHub 安全公告库 (GHSA)60

    Pillow 修复 GIF 注释二次方拼接导致的 Image.open() DoS 问题

    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 的服务评估上传接口风险。

  6. GitHub 安全公告库 (GHSA)62

    Pillow 的 XbmImagePlugin 存在 ReDoS，512 字节文件可让 Image.open() 卡住数分钟

    GitHub 安全公告库披露 Pillow 的 XbmImagePlugin 存在 ReDoS：构造的 512 字节文件会让 Image.open() 在单核上消耗约 375 秒 CPU 后才抛出 UnidentifiedImageError。

    为什么值得看：公告给出了触发条件、耗时实测与正则修复补丁，使用 Pillow 处理用户上传图片的服务可据此判断暴露面。

  7. GitHub 安全公告库 (GHSA)60

    Pillow APNG 在解压炸弹检查前按 IHDR 尺寸分配内存，附复现脚本与补丁

    Pillow 的 PngImageFile._seek() 在处理首个 fcTL 请求 OP_BACKGROUND 时，会先按 IHDR 声明尺寸调用 Image.core.fill 分配并清零整块画布，之后 Image.open() 的 _decompression_bomb_check 才执行。

    为什么值得看：材料给出可运行的复现脚本与两份补丁，说明 APNG 在炸弹检查前按声明尺寸分配内存的路径。

  8. GitHub 安全公告库 (GHSA)70

    Pillow 保存 TIFF 到 BytesIO 时 _tiffWriteProc 存在堆溢出，附复现脚本与补丁

    Pillow 在把 TIFF 保存到 io.BytesIO 等无 fileno() 的目标时，src/libImaging/TiffDecode.c 的 _tiffWriteProc 按 state->size + size 而非写入位置扩容，导致堆缓冲区溢出，同时把未初始化的堆字节写入输出文件。

    为什么值得看：报告给出可运行的复现脚本与补丁，说明默认设置下把上传图片另存为 TIFF 到内存对象即可触发越界写。

  9. GitHub 安全公告库 (GHSA)60

    Pillow 的 libtiff 编码器经构造 TIFF 标签泄露进程内存或触发 SIGSEGV

    Pillow 的 libtiff 编码器 PyImaging_LibTiffEncoderNew（src/encode.c）在把源 TIFF 中未识别的标签转发给 TIFFSetField 时，按 Python 值而非 libtiff 字段定义决定传参形式，导致构造的 TIFF 标签被当作字节数或指针读取。

    为什么值得看：材料给出可运行的复现脚本与逐分支分析，展示了普通 open 后 save 即可触发内存泄露或崩溃的路径。