Pillow 修复 Image.quantize() 空调色板泄露栈内存问题
GitHub 安全公告库披露 Pillow 的 Image.quantize(palette=...) 在调色板为空时会返回 512 字节未初始化的 C 栈内存作为像素值,一个 80 字节的空 PLTE PNG 即可触发,泄露内容包含栈、堆、libc、libpython 与 _imaging 模块地址及栈保护 canary。
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 的 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 调用栈,便于维护者确认内存释放路径并判断自身服务是否受影响。
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 等文件写到请求目录之外。
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 归一化输出)可同时关闭两者。
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 的 POST /api/v1/@apostrophecms/doc/slugTaken 接口存在信息泄露问题,任意已登录用户(editor 角色即可)可通过返回的布尔值枚举私有页面、草稿与归档内容的 slug。该接口未校验读取权限,也未按 visibility、viewRole 或发布状态过滤,攻击者可借此摸清 CMS 全部内容结构。
djust v1.1.4 的 MCP 工具 find_handlers_for_template 在 template_path 为已存在的绝对路径时直接 open() 读取,未做 realpath 前缀校验,可读取进程有权限访问的任意文件。
Electron 修复了 hid 和 usb 权限检查可能归属错误来源的问题:从 iframe 发起检查时,session.setPermissionCheckHandler 收到的是顶层框架的 origin 和 details,而非发起请求的框架。
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 逐个键替换激活模板中的占位符,若已替换并加引号的值包含后续占位符名称,后续替换会改写引号内的名称,导致路径剩余部分在用户激活环境时作为代码执行。
GitHub 安全公告 GHSA-c947-3pg5-gm8q 指出,virtualenv 的 FishActivator 未定义 quote(),沿用 shlex.quote 的 POSIX 规则。
virtualenv 在 21.14.4 中修复了 zsh 用户执行 bash `activate` 脚本时的命令注入问题:环境名中的 `$(...)`、反引号或 `${...}` 在开启 `PROMPT_SUBST` 的 zsh 中会随每次提示符绘制被执行。
Vite 的 `?vite-wasm-instance` 查询由内部 Wasm 插件的 `load` 钩子处理,该钩子未应用 `server.fs` 检查,直接读取磁盘文件并尝试按 WebAssembly 解析,解析失败时 Node 与 Deno 的报错会带出文件前 4 字节。
pypdf 修复了多过滤器流导致内存占用过大的问题,攻击者可构造 PDF 触发大量内存消耗,需访问带有大量过滤器或经多个过滤器传递大量数据的流。该问题已在 pypdf==6.20.0 中修复,无法升级者可参考 PR #4173 的改动作为规避方案。
virtualenv 发布通告,指出 bash 的 activate 脚本只对 PS1 的两轮处理中的一轮转义环境名,名称中含 \$(...) 时会在用户每次绘制提示符时以该用户权限执行命令,21.14.7 已修复。
Ubuntu 发布 USN-8930-2,为 Ubuntu 26.10 上的 U-Boot 提供 USN-8930-1 所修复漏洞的对应补丁。
针对 PHP 的 CVE-2026-109618 与 CVE-2026-109619(php2shell,CVSS v4.0 9.2,无需认证 RCE),材料给出临时缓解措施与机制说明。
PHP 项目于 2026 年 10 月 21 日发布安全更新,修复 CVE-2026-109618(OOM 处理中的内存破坏)与 CVE-2026-109619(跨请求残留状态的 use-after-free),两者 CVSSv4 均为 9.2,可让攻击者以 Web worker 权限实现免认证 RCE。
为什么值得看:PHP 同时修复两个可导致免认证 RCE 的缺陷,通告给出了受影响版本区间、修复版本与临时缓解配置。
PHP 安全团队于 2026 年 10 月 21 日发布紧急补丁,修复两个 CVSS 评分 9.2 的 RCE 漏洞 CVE-2026-109618 和 CVE-2026-109619,影响 PHP 5、6、7、8 各版本,并已为 7.4、8.0、8.1 回移补丁。
同一件事,精选收录的是《PHP 将发布带外更新修复两个 CVSS 9.2 的 RCE 漏洞》
Ubuntu 发布 USN-8946-1,修复 Unbound 的多个漏洞,涉及 CVE-2026-80225、CVE-2026-81634、CVE-2026-85501、CVE-2026-50252、CVE-2026-40691、CVE-2026-44690、CVE-2026-32665、CVE-2026-55973 及 CVE-2023-50387、CVE-2023-50868。远程攻击者可利用这些问题导致 Unbound 资源耗尽或崩溃,造成拒绝服务,其中 CVE-2026-44690 可污染缓存。受影响版本涵盖 Ubuntu 14.04 LTS 至 26.04 LTS 的部分版本。
Ubuntu 发布 USN-8948-2,将 USN-8948-1 中针对 Ubuntu 22.04 LTS、24.04 LTS、26.04 LTS 和 26.10 的 PHP 修复扩展到 Ubuntu 14.04 LTS、16.04 LTS、18.04 LTS 和 20.04 LTS。
为什么值得看:公告把此前只覆盖新版本的安全更新扩展到 14.04 至 20.04 LTS,仍在使用旧版 PHP 的运维可据此核对补丁版本。