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 的服务评估上传接口风险。
GitHub 安全公告库披露 Pillow 的 Image.quantize(palette=...) 在调色板为空时会返回 512 字节未初始化的 C 栈内存作为像素值，一个 80 字节的空 PLTE PNG 即可触发，泄露内容包含栈、堆、libc、libpython 与 _imaging 模块地址及栈保护 canary。
GitHub 安全公告库披露 Pillow 的 XbmImagePlugin 存在 ReDoS：构造的 512 字节文件会让 Image.open() 在单核上消耗约 375 秒 CPU 后才抛出 UnidentifiedImageError。
为什么值得看：公告给出了触发条件、耗时实测与正则修复补丁，使用 Pillow 处理用户上传图片的服务可据此判断暴露面。
Pillow 的 PdfParser.get_value() 递归深度保护失效：max_nesting 默认 -1 且每次递归递减，永远不等于 0，嵌套几千层的 PDF 对象即可触发未捕获的 RecursionError。
Pillow 在把多帧图像以 save_all=True 保存为多页 PDF 时，耗时随帧数呈二次方增长，原因是 src/PIL/PdfParser.py 的 PdfParser.next_object_id() 每次调用都重建并扫描已占用的对象 id 集合。
GitHub 安全公告库发布 GHSA-gg2r-wvfm-q9rx，指出 Pillow 的 MSP RLE 解码器把游程数据写入无上限的 io.BytesIO，单次游程可扩张约 85 倍，问题位于 src/PIL/MspImagePlugin.py:144-146。
Pillow 的 PngImageFile._seek() 在处理首个 fcTL 请求 OP_BACKGROUND 时，会先按 IHDR 声明尺寸调用 Image.core.fill 分配并清零整块画布，之后 Image.open() 的 _decompression_bomb_check 才执行。
为什么值得看：材料给出可运行的复现脚本与两份补丁，说明 APNG 在炸弹检查前按声明尺寸分配内存的路径。
Pillow 的 PdfParser.rewrite_pages() 在追加保存 PDF 时沿页面树 /Parent 链向上遍历且不记录已访问节点，333 字节的自引用 PDF 即可让 im.save(fp, "PDF", append=True) 永久挂起并占满一个 CPU 核心。
GitHub 安全公告披露 Pillow 在将图像编码为内存中的 TIFF 时存在堆 use-after-free：libtiff 在编码阶段拒绝某个 tag 导致 TIFFWriteScanline 失败后，编码器释放了输出缓冲区却未关闭 TIFF 句柄，随后清理阶段 TIFFClose 刷新数据写回已释放内存。
为什么值得看：公告给出可运行的 Python 复现脚本与 ASan 调用栈，便于维护者确认内存释放路径并判断自身服务是否受影响。
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 即可触发内存泄露或崩溃的路径。
virtualenv 发布通告，指出 app-data seeder 与 pip 生成的 POSIX 控制台启动器会把环境目标路径当作 shell 语法解析，攻击者需影响传给 virtualenv 的环境路径且用户随后运行生成的启动器，命令才会以用户权限执行，Windows 可执行启动器不受影响。
virtualenv 的 safe_delete() 在删除失败恢复权限时用 lstat() 读取符号链接自身权限位，却用会跟随链接的 chmod() 应用，导致只读目录内符号链接指向的目标文件权限被改为 0777。该错误处理逻辑自 21.7.5 引入，需删除失败且调用用户拥有目标文件并可修改其权限，root 不会进入该路径。PR #3427 已避免在删除失败时修改 POSIX 权限。
virtualenv 内置创建器在创建环境前调用 ensure_dir() 处理 bin、lib 等目录，因 exists() 会跟随符号链接，攻击者预先在目标目录放置指向外部的目录链接后，创建过程会经该链接把 python、pip、activate 等文件写到请求目录之外。
OpenSSF 恶意包库新增收录 PyPI 上的 acoustichub、acousticpack、asrdock、asrloom 等恶意包，均仅涉及 0.1.0 版本，归属活动 2026-10-voice-synthesis-profiles。
OpenSSF 恶意包库更新了 npm 包 snavbox 的恶意包记录 MAL-2025-49362，受影响版本在原有 1.0.0、1.0.2、1.0.3 基础上补入 1.0.1。该记录关联 GHSA-ppfj-vpcr-qwqg，归类为 CWE-506 内嵌恶意代码，GHSA 条目以 SEMVER 范围从 0 引入覆盖 1.0.0 至 1.0.3。
OpenSSF 恶意包库新增一条来自 GHSA 的恶意包记录，涉及 npm 生态的 snavbox 包 1.0.0–1.0.3 版本，对应 GHSA-ppfj-vpcr-qwqg，归类为 CWE-506 嵌入式恶意代码。通告称安装或运行该包的机器应视为完全失陷，需在另一台机器上立即轮换全部密钥，仅卸载包无法保证清除恶意软件。
OpenSSF 恶意包库更新 MAL-2026-2144，将 PyPI 上的 litellm 1.107.0 标记为恶意，该版本于 2026-10-21 11:39 至 11:40 UTC 上传，含上游源码中没有的凭据窃取程序与远程代码执行后门，注入发生在构建或上传阶段。
OpenSSF 恶意包库新增记录，指出 2026-10-21 上传至 PyPI 的 litellm 1.107.0 含上游源码中不存在的凭据窃取程序与远程代码执行后门，系在构建或上传环节注入。
为什么值得看：记录披露了投毒 wheel 中三个额外文件的具体路径与哈希，可用于排查本地是否装过该版本并定位残留。
OpenSSF 恶意包库新增两条来自 GHSA 的 npm 恶意包记录，分别为 GHSA-fxf3-w84v-3v6g（@worrisome/aaaa）和 GHSA-4f5p-mp5p-863f（@worrisome/reutil），均归类为 CWE-506 嵌入式恶意代码，影响范围自 0 起的所有版本。
pypdf 修复了标准 xref 表在文件于表内结束时触发无限循环的问题，攻击者可构造不完整 PDF 导致该循环。该问题已在 pypdf==6.20.0 中修复，无法升级者可参考 PR #4170 的改动作为规避方案。漏洞经安全渠道与公开 issue #4169 报告。
pypdf 修复了移除树节点（如大纲项）时可能陷入无限循环的问题，攻击者可构造恶意 PDF 触发该缺陷。修复版本为 pypdf 6.20.1，无法升级的用户可参考 PR #4188 中的改动作为规避方案。
pypdf 修复了 PdfWriter.find_outline_item 中的无限循环问题，攻击者可构造恶意 PDF 触发该循环。该问题已在 pypdf 6.20.1 中修复，无法升级的用户可参考 PR #4188 中的改动作为规避方案。
ApostropheCMS 的 @apostrophecms/import-export 3.7.0 中，gzip 解压仍无单条目、解压总字节和条目数量配额，归档解析也先于文档类型授权。
ApostropheCMS 的 @apostrophecms/import-export 3.7.0 中，overrideDuplicates() 续接逻辑仍接受客户端提供的替换选择，未将其绑定到服务端维护的重复分析，替换与写入辅助函数在更新前也未建立统一的资源身份与授权上下文。
ApostropheCMS 的 @apostrophecms/import-export 3.7.0 中，canImportOrExport() 的导入校验只检查类型的导入配置与查看权限，写入辅助函数直接调用 document-manager 的 insert/update，缺少正常发布权限检查与 beforePublish 过渡。
sanitize-html 2.18.0 在默认配置下重新净化被丢弃 iframe 的原始文本时进行无界递归调用，几千字节的未闭合 iframe 标签即可触发 RangeError: Maximum call stack size exceeded。
ApostropheCMS 的颜色字段因 TinyColor.isValid 未在字符串末尾锚定匹配，仅校验字符串是否以合法 rgb()/hsl() 颜色开头，拥有编辑权限的认证用户可在合法颜色前缀后存入任意 HTML，渲染时触发存储型 XSS。该问题与 GHSA-97v6-998m-fp4g 同源，修复校验（要求整串为合法颜色或仅存储 TinyColor 归一化输出）可同时关闭两者。
ApostropheCMS 的公共 REST API 在处理匿名请求时，会先执行 query string 中所有可 launder 的查询构造器，再强制套用 publicApiProjection，而 search 与 sort 这两个构造器作用于底层文档、不受投影限制。
为什么值得看：公告给出可复现的 curl 请求与实测结果，说明 search 与 sort 两个查询构造器如何绕过字段白名单。
GitHub 安全公告指出，ApostropheCMS 的 @apostrophecms/import-export 中 POST /api/v1/@apostrophecms/import-export/clean-export 接口缺少认证与授权检查。
ApostropheCMS 存在存储型 XSS：当项目为 widget 定义带 CSS property 但无 selector 的自由格式 string 样式字段时，编辑器可控值会被拼成内联 CSS 声明，并在未做 HTML 属性转义的情况下写入 widget 包装器的 style 属性。
ApostropheCMS 的页面 REST 接口 GET /api/v1/@apostrophecms/page/:id 未应用 viewRole 类型级限制和 viewPermission 字段级脱敏，而 getAll 接口对两者均正确执行。编辑级用户只要知道文档 _id，即可读取仅限管理员访问的页面全文及受 viewPermission 保护的字段。
ApostropheCMS 的 POST /api/v1/@apostrophecms/doc/slugTaken 接口存在信息泄露问题，任意已登录用户（editor 角色即可）可通过返回的布尔值枚举私有页面、草稿与归档内容的 slug。该接口未校验读取权限，也未按 visibility、viewRole 或发布状态过滤，攻击者可借此摸清 CMS 全部内容结构。
djust v1.1.4 的 MCP 工具 find_handlers_for_template 在 template_path 为已存在的绝对路径时直接 open() 读取，未做 realpath 前缀校验，可读取进程有权限访问的任意文件。
Storybook 发布安全通告，指出运行受影响版本的 Storybook 开发服务器时，恶意网站可能对开发者项目造成未授权文件修改，在附加条件下被修改的文件可能以开发者权限被本地运行时执行；官方称未发现已在野利用。
为什么值得看：通告给出四个受影响大版本的修复版本，并说明默认行为变更，开发者可据此判断升级与工作流调整。
GitHub 安全公告指出，github.com/moov-io/signedxml 的 ExclusiveCanonicalization 在 ValidateReferences() 中于任何摘要或签名校验前复制整个累积命名空间映射。
为什么值得看：通告说明了免认证 DoS 的成因与受影响版本，并给出修复思路和修复前后的内存占用对比数据。
OpenChoreo API server 的 `PUT .../workflowruns/{runName}` 接口从请求体读取归属标签做授权校验，却按 URL 路径定位实际修改对象，持有某组件 `workflowrun:update` 权限的已认证调用者可借此改写其他项目或组件的 WorkflowRun 归属标签，进而读取构建日志、Kubernetes 事件或删除该运行。
OGNL 的 stricter-invocation 阻止列表按被调用方法的声明类过滤，因 java.lang.reflect.Method 等不在列表中，表达式可用 someMethod.invoke(target, args) 作代理调用 Runtime、ProcessBuilder 等被阻止的方法，PoC 在默认上下文下成功创建文件。
Slack Morphism 在签名校验失败时会把按攻击者可控时间戳与请求体算出的正确 HMAC 写入 SlackEventWrongSignatureError.generated_hash，并经 Debug/Display 与 Axum 默认错误处理器以 error 级别记入日志。
GitHub 安全公告 GHSA-8rjx-v5ww-45pp 指出，virtualenv 的 ViaTemplateActivator.instantiate_template 逐个键替换激活模板中的占位符，若已替换并加引号的值包含后续占位符名称，后续替换会改写引号内的名称，导致路径剩余部分在用户激活环境时作为代码执行。