OpenSSF 恶意包库更新:收录 Amazon Inspector 上报的 RubyGems 恶意包 zzhelloworld_socktest
OpenSSF 恶意包库新增 Amazon Inspector 上报的 RubyGems 恶意包 zzhelloworld_socktest,涉及 0.1.5 与 0.1.9 两个版本。
OpenSSF 恶意包库新增 Amazon Inspector 上报的 RubyGems 恶意包 zzhelloworld_socktest,涉及 0.1.5 与 0.1.9 两个版本。
Google Chrome 在 Safe Browsing 的 Enhanced Protection 中新增由 Gemini 驱动的诈骗检测,可识别欺骗性网站,并在用户从 ClickFix 攻击中复制可疑命令时发出警告。
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 中三个额外文件的具体路径与哈希,可用于排查本地是否装过该版本并定位残留。
GMO Internet 旗下 Onamae.com 确认 Onamae Desktop Cloud 遭第三方未授权访问,部分客户服务器环境被植入恶意程序,受影响服务器最多达 26,739 台。
为什么值得看:事件披露了入侵确认、服务器关停与恢复时间未定等处置细节,可了解云服务商在客户环境被植入恶意程序后的应对方式。
OpenSSF 恶意包库更新 MAL-2026-15604,为 npm 包 @worrisome/reutil 补录别名 GHSA-4f5p-mp5p-863f。
OpenSSF 恶意包库新增两条来自 GHSA 的 npm 恶意包记录,分别为 GHSA-fxf3-w84v-3v6g(@worrisome/aaaa)和 GHSA-4f5p-mp5p-863f(@worrisome/reutil),均归类为 CWE-506 嵌入式恶意代码,影响范围自 0 起的所有版本。
卡巴斯基将针对韩国机构的攻击行动命名为 FlashHole,并归因于 Lazarus Group;该行动自 2025 年 7 月开始,通过钓鱼页面和特制 GitHub 页面投递恶意载荷。
为什么值得看:卡巴斯基复盘 Lazarus 的 FlashHole 行动,其用 ML-KEM 后量子加密保护载荷下发这一手法在恶意软件投递中较为少见。
OpenSSF 恶意包库为 PyPI 包 journey-test-helloshell 0.2.0 分配编号 MAL-2026-18124,并将其标记为恶意活动 2026-10-journey-test-helloshell 的一部分。
OpenSSF 恶意包库新增记录:PyPI 包 journey-test-helloshell 0.2.0 在安装时启动反弹 Shell,攻击者可借此在受害者机器上执行任意命令。该包通过覆盖 setup.py 中的 install 命令在安装阶段执行恶意代码,被归类为定向攻击,IOC 包含 IP 137.131.233.62。
CISA 警告攻击者正在积极利用 Plex Media Server 的四个漏洞,合称 Plex2Shell,串联利用后可获取所有者 admin token 并以提升权限执行代码,联邦机构须在 10 月 23 日前完成修补或缓解。
为什么值得看:CISA 将 Plex2Shell 四个漏洞列入在野利用并给出联邦修复期限,同时把 Siemens 与 SiteGuard 的漏洞一并加入 KEV。
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 前缀校验,可读取进程有权限访问的任意文件。
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 字节。
GitHub 安全公告 GHSA-rq7h-c2jc-7f22 指出,Vite 开发服务器在非 Windows 机器上,当项目导入文件的根相对路径与宿主机绝对路径相同时,可把 server.fs.allow 之外的文件内容返回给浏览器,例如 /etc/hosts。
为什么值得看:公告给出了可复现的 curl 步骤,说明非 Windows 环境下 Vite 开发服务器如何把宿主机文件返回给浏览器。
Vite 开发服务器在将未经修改的浏览器请求 URL 传入 server.transformIndexHtml 时存在跨源脚本执行问题,攻击者可构造含 `//` 的路径让生成的模块 src 指向外部域名,从而在 Vite 页面中执行任意 JavaScript。
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 所修复漏洞的对应补丁。