AI 摘要：作者展示了 CVE-2025-55182 漏洞的具体利用方式，说明该漏洞出现在 React Server Components 的反序列化机制中。通过伪造 Chunk 对象以及操控 then 方法触发链式调用，攻击者可以利用 Next.js 的服务端组件解析逻辑实现远程代码执行 (RCE)。文章详细讲述了漏洞的产生原理、攻击向量和具体请求示例，说明此问题的严重性与利用条件。

1. 漏洞背景与影响范围
• 漏洞编号为 CVE-2025-55182，影响 React Server Components 的反序列化过程
• 可在 Next.js 16.0.6 环境下触发
• 利用对象结构中的 $@ 标记机制篡改 Chunk 引用并控制反序列化流程

2. 核心利用思路 (Exploit 原理)
• 使用 $@ 引用构造伪造的 Chunk 实例
• 将 Chunk.prototype.then 作为根对象的 then 属性，使得在 Promise 处理时自动触发攻击逻辑
• 通过修改 status 为 RESOLVED_MODEL 调用 initializeModelChunk 以执行受控对象的代码路径

3. 攻击链实现与触发机制
• 攻击目标是触发 Blob 反序列化流程
• response._formData.get 被重写为 JavaScript Function 构造器，实现任意代码执行
• 构造的 multipart/form-data 请求载荷通过控制 _prefix 字段注入任意命令（例如 child_process.execSync('xcalc')）

4. 安全意义与防护思考
• 漏洞本质源于反序列化信任边界不明与模型解析机制的未过滤输入
• 需加强 React Server Components 的反序列化安全校验
• 建议暂时限制相关功能或升级框架版本

Gist

CVE-2025-55182 React Server Components RCE POC

CVE-2025-55182 React Server Components RCE POC. GitHub Gist: instantly share code, notes, and snippets.

AI 摘要：React 官方披露了一个在 React Server Components (RSC) 中的严重远程代码执行漏洞（CVE-2025-55182），影响多个版本的 react-server-dom 系列包。问题出在 RSC 的负载反序列化逻辑中，攻击者可通过构造恶意 HTTP 请求在服务器上执行任意代码。相关漏洞获评 CVSS 10.0（最高等级），已在 19.0.1、19.1.2、19.2.1 等版本修复。React 团队建议开发者立即升级，并说明了受影响的框架包括 Next.js、React Router、Waku 等。

1. 漏洞概述与影响范围
• 披露的漏洞是针对 React Server Components 的未授权远程代码执行 (Remote Code Execution, RCE) 问题。
• 漏洞编号为 CVE-2025-55182，CVSS 评分为 10.0（极高严重度）。
• 所有使用 RSC 的 React 应用，即使没有定义特定 Server Function 接口，也可能受影响。

2. 受影响版本与安全修复
• 受影响版本：19.0、19.1.0、19.1.1、19.2.0。
• 修复版本：19.0.1、19.1.2、19.2.1。
• 修复建议：立即升级至修复版本的 react-server-dom-webpack、react-server-dom-parcel、react-server-dom-turbopack。

3. 受影响的框架与构建工具
• 部分框架与构建工具依赖或内置受影响包，包含 Next.js、React Router、Waku、@parcel/rsc、@vitejs/plugin-rsc、rwsdk。
• React 团队后续将更新具体升级指令。

4. 技术细节与漏洞原理
• RSC 机制允许客户端通过 HTTP 请求触发服务器端函数。
• 漏洞源于 React 在反序列化客户端请求载荷 (payload) 时的处理缺陷，导致攻击者可执行任意代码。
• 目前细节暂未完全公开，以防在修复完成前遭滥用。

5. 漏洞披露时间线
• 11 月 29 日：由安全研究员 Lachlan Davidson 通过 Meta Bug Bounty 计划报告漏洞。
• 11 月 30 日：Meta 安全部门确认漏洞并与 React 团队协作修复。
• 12 月 1 日：完成修复并与受影响项目共同测试与部署缓解措施。
• 12 月 3 日：在 npm 发布修复版本并正式公开 CVE。

6. 致谢与归属
• 感谢安全研究员 Lachlan Davidson 的发现、报告及协助修复贡献。

react.dev

Critical Security Vulnerability in React Server Components – React

The library for web and native user interfaces

AI 摘要：Koi Security 揭露了名为 ShadyPanda 的威胁行为者在过去七年间通过伪装的浏览器扩展发动攻击，从最初的联盟欺诈到最终的远程代码执行 (RCE, Remote Code Execution) 与间谍软件(SPYWARE) 操控，总计感染了超过 430 万 Chrome 与 Edge 用户。该攻击者利用浏览器商店的信任与自动更新机制，先积累用户再通过静默更新“武器化”扩展。研究揭示，此类威胁并非单一事件，而是浏览器扩展生态系统的结构性安全缺陷——信任被系统性滥用。

1. 威胁概述与发现经过
• Koi 研究团队追踪到长达七年的浏览器扩展攻击链，命名为 ShadyPanda。
• 总计影响 430 万 Chrome 与 Edge 用户，两条主要恶意活动：一为 RCE 后门感染 30 万用户，另一为间谍软件监控 400 万用户。
• 攻击者通过合法推广与 Google 认证获得用户信任，再利用静默更新执行恶意代码。

2. 第一阶段：壁纸欺诈与联盟滥用 (2023)
• 共 145 个伪装成壁纸或效率工具的扩展程序，在 Chrome 与 Edge 市场上发布。
• 利用联盟营销注入追踪代码、窃取佣金，并通过 Google Analytics 收集与兜售浏览数据。
• 攻击者学会了三大关键经验：审核只关注初次上架；用户信任“高安装量+好评”；伪装时间越长危害越大。

3. 第二阶段：搜索劫持与主动控制 (2024 初)
• 改以控制浏览器核心行为为目标，如 Infinity V+ 劫持搜索请求、篡改结果。
• 实施 Cookie 数据外泄与实时键入监控，通过明文 HTTP 发送用户输入数据。
• 攻击者虽被多次下架，但逐渐提升隐蔽性与数据利用能力。

4. 第三阶段：长线布局与后门植入 (2018–2024)
• 多个扩展（如 Clean Master）先以合法身份运营多年，获得“精选(Featured)”与“验证(Verified)”标记。
• 于 2024 年中期推送恶意更新，触发远程代码执行框架。
• 恶意负载可每小时从 C&C (Command and Control) 服务器获取命令，具备完全浏览器访问权限。
• 收集完整浏览数据、设备指纹、加密外传；能躲避分析并执行中间人攻击 (MITM)。
• 尽管部分扩展被移除，后端基础设施仍活跃于受感染浏览器。

5. 第四阶段：间谍网络与大规模监控 (2023–今)
• Clean Master 背后的同一发行商 Starlab Technology 推出 5 款新扩展，在 Edge 市场累积超 400 万安装。
• WeTab 新标签页 alone 拥有 300 万用户，持续收集访问记录、搜索输入、点击轨迹与完整指纹。
• 数据实时传输至多个中国服务器与 Google Analytics，用于行为分析与潜在情报搜集。
• 当前仍在 Edge 市场上架，具有全面权限且可随时被“武器化”。

6. 七年战术演进与系统漏洞
• 几个阶段由浅入深：从简单的联盟欺诈到长期潜伏与数据控制。
• 共通特征：代码签名相似、基础架构重叠、混淆方式演化一致。
• 核心问题在于浏览器扩展生态的信任模型：审核仅限初期、缺乏动态监控。
• 自动更新机制成为主要攻击向量，无需钓鱼或社工即可实现大范围感染。

7. 结语与安全启示
• 根本教训：信任本身是最大的漏洞。
• 静态代码审核无法应对多年潜伏的攻击链。
• Koi Security 推出行为分析与风险评分方案，关注“扩展安装后实际行为”而非声称功能。
• 呼吁浏览器平台与企业加大对行为监测与扩展生态安全的关注。

AI 摘要：Harmony Intelligence 团队报告发现 Next.js 自托管版本存在严重的拒绝服务（DoS）漏洞，攻击者仅需一个精心构造的 HTTP 请求即可导致服务器内存被耗尽而崩溃。漏洞由 AI AppSec Agent 在测试期间意外发现，已由 Vercel 于 2025 年 10 月修复。防御建议是尽快升级至 Next.js 15.5.5 或以上版本，并在生产环境使用可限制请求大小的反向代理，因为仅靠请求频率限制并不能防御此类攻击。

1. 漏洞概述
• 漏洞类型：拒绝服务 (DoS)，通过发送大体积的 HTTP 请求流导致服务器内存耗尽并崩溃。
• 受影响范围：所有带有中间件的自托管 Next.js 服务器（Vercel 托管的不受影响）。
• 受影响版本：≤15.5.4、14.x、13.x 等旧版本。

2. 发现经过
• 漏洞在测试 AI AppSec Agent 能否独立识别已知认证绕过问题（CVE-2025-29927）时意外被触发。
• AI 代理可访问源代码并在安全沙盒中运行，对应用执行自动化渗透探索。
• 意外发现 Next.js 官方源码中 cloneBodyStream 函数复制无大小限制的请求体，从而导致内存占用过高。

3. 技术细节
• 漏洞根源在于 body-stream.ts 中的 cloneBodyStream：函数会将整个请求流读入内存。
• 攻击者仅需持续发送数据流片段即可造成服务器崩溃，资源消耗极低。
• 修复补丁通过在内存缓冲区超过 10MB 时抛出异常来限制流大小。

4. 影响与安全评级
• 全球 300 万个活跃 Next.js 部署中约 55% 为自托管环境（企业约 80%）。
• 初始漏洞报告时 Vercel 尚未在文档中明确推荐使用反向代理限制请求大小。
• 推荐 CVSS v3.1 评分 7.5（高危），依据类似 Node.js 漏洞 (CVE-2018-12121) 的评估逻辑。

5. 缓解措施（Mitigation）
• 推荐立即升级至 Next.js 15.5.5 或 16.0.0 及以上版本。
• 配置诸如 nginx 的反向代理来限制请求体大小，例如默认 client_max_body_size = 1MB。
• 确保应用服务器不对外直接暴露，全部流量应经过代理层。
• 仅靠应用层的 rate limit、bodyParser.sizeLimit 或 express-rate-limit 等代码级限制无效，因为漏洞触发点在中间件执行前。

6. 信息披露时间线
• 2025-08-07：私下通知 Vercel 并持续每周跟进。
• 2025-09-23：Vercel 第一次回应。
• 2025-10-13：Vercel 发布补丁 (v15.5.5)。
• 2025-11-26：公开披露与缓解方案发布。

Harmonyintelligence

Harmony Intelligence - Taking down Next.js servers for 0.0001 cents a pop

Our AI AppSec Agent discovered an unauthenticated DoS vulnerability that crashes a self-hosted Next.js server with a single HTTP request and negligible resources.

AI 摘要：自 2025 年 11 月 5 日起，npm 将正式禁用新建经典 (classic) token，并强化细化 (granular) token 的安全策略，包括强制启用双重验证 (2FA) 及限定有效期为 90 天。现存的经典 token 将在 11 月 19 日彻底失效，用户需尽快迁移至新的 granular 权限模型。

1. 更新背景与总体说明
• 本次更新是 npm 提升安全策略的重要阶段，意在统一令牌 (token) 管理机制。
• 仅 npm 注册表使用的 token 受影响，GitHub 自身的 token 不受波及。

2. 主要变更：经典 token 停用
• 自 2025 年 11 月 5 日起，无法通过网站、CLI 或 API 再创建 classic token。
• 现有 classic token 可继续使用至 11 月 19 日，之后将全部失效。
• npm token create 不再生成 classic token。

3. granular token 改进措施
• 新建具有写权限的 npm granular token 默认强制要求启用 2FA。
• 针对 CI/CD，可设置 “Bypass 2FA” 选项（默认关闭）。
• 所有具写权限的 granular token 有效期上限调整为为 90 天，原定于 2026 年 2 月 3 日之后到期的现有 token 已调整为在该日期到期。

4. 用户应对与迁移步骤
• 用户须在截止日前迁移 classic token 至 granular token。
• 迁移流程需通过 npm 账户设置页面 完成，选择 “Generate New Token → Granular Access Token”。
• 依工作流需求配置权限，CI/CD 可启用 Bypass 2FA 或使用 OIDC。
• 目前 granular token 仅可通过网站生成，CLI 支持将在后续添加。

5. granular token 用户的注意事项
• 定期检查 token 过期时间并规划轮换 (rotation)。
• 对非交互式发布需求，可能需启用 Bypass 2FA。

6. 不受影响的范围
• GitHub classic 个人访问 token、fine-grained 个人访问 token、GitHub Actions secret 以及 GITHUB_TOKEN 均无须变更。
• 但若内含 npm 凭证，应相应更新。

7. 接下来的关键节点：2025 年 11 月 19 日
• npm 将彻底吊销 classic token，并引入 2 小时有效的动态 session token 取代长期本地发布凭证。

8. 支持与参考资源
• npm token migration guide 提供迁移指引。

The GitHub Blog

npm security update: Classic token creation disabled and granular token changes - GitHub Changelog

Editor’s note (November 5, 2025): We’ve updated this post to explicitly clarify that the affected tokens are npm tokens. Today marks another milestone in our ongoing effort to strengthen npm’s…

AI 摘要：本文由 Koi Security 团队发布，揭示了一种前所未有的供应链攻击——GlassWorm。该蠕虫针对 OpenVSX 与 VSCode 插件生态，通过不可见的 Unicode 字符隐藏恶意代码，使用 Solana 区块链和 Google Calendar 作为不可下线的指挥控制系统（C2），可远程访问、窃取开发者凭证、劫持加密钱包并自我传播。

1. 攻击概览与事件背景
• GlassWorm 继 Shai Hulud 之后成为第二个自我传播的供应链蠕虫，首次锁定 OpenVSX 市场
• 感染 7 个扩展、下载量约 35,800 次，并在 VSCode 官方市场出现活跃样本
• 攻击结合区块链、Unicode 隐蔽代码与去中心化通信机制

2. 隐形攻击机制：Unicode 差异选择器
• 攻击者在 JavaScript 源码中嵌入不可显示的 Unicode Variation Selectors
• 人眼与静态扫描均看不到恶意逻辑，但解释器可执行
• 此方法突破代码审查和 Git diff 可见性，暴露软件供应链审查的盲点

3. 区块链 C2 机制（Solana Blockchain）
• 利用 Solana 交易的 memo 字段存储下一阶段载荷链接
• 特性：不可变、匿名、抗封锁、难以审查、成本极低
• 攻击者可频繁更新交易实现动态替换，完全绕过传统安全封控

4. 三级指挥控制体系
• 主 C2：Solana blockchain 交易地址
• 二级：直接 IP （217.69.3.218）传输加密 payload
• 三级：Google Calendar 用作备用 C2，通过事件标题存储 Base64 链接
• 实现“无法下线”的混合基础设施体系

5. 凭证与资产窃取阶段（Credential Harvest）
• 定向获取 NPM / GitHub / Git / OpenVSX 凭证
• 搜索并攻击 49 种加密货币钱包（MetaMask / Phantom 等）
• 使用 AES 加密及 HTTP 动态密钥进行安全通信以强化隐蔽性

6. ZOMBI 模块：完全远控与渗透功能
• SOCKS Proxy：将开发者工作机转为攻击代理节点
• WebRTC P2P：实现实时对等通信，通过 NAT 穿透
• BitTorrent DHT：分布式指令广播，无中心可拔除节点
• HVNC（Hidden Virtual Network Computing）：隐藏桌面控端操作，可完全远程访问
• 支持模块化更新与自愈机制，实现长期驻留

7. 自我传播（Self-Propagation）机制
• 利用窃取的凭证自动入侵更多扩展与仓库
• 无需用户交互，通过自动更新实现连锁感染
• 模仿生物病毒复制循环，实现开发生态层面的指数级扩散

8. 攻击现状与影响评估
• 10 月中旬已造成全球范围感染
• 五个扩展仍在续散布恶意版本
• 受害系统正在被远程控制、挖掘凭证、充当犯罪代理节点

www.koi.ai

GlassWorm: First Self-Propagating Worm Using Invisible Code Hits OpenVSX Marketplace | Koi Blog

AI 摘要：GitHub 针对 npm 供应链近年来遭受的攻击（如基于账户劫持和自我复制恶意软件的事件），提出一系列安全强化措施，包括推进 Trusted Publishing、强制 2FA、多层次 Token 管理以及渐进式改造工作流。这些举措旨在提高整个开源生态系统的韧性，重塑开发者与社区对 npm 的信任。

1. 开源软件与供应链风险
• 开源是现代软件的基石，但规模庞大的生态也带来攻击面扩大与安全风险。
• 最近持续发生基于账户劫持的攻击，导致恶意代码通过知名 npm 包传播。

2. Shai-Hulud 攻击事件回顾
• 2025 年 9 月发生的自我复制蠕虫攻击，利用维护者被攻破的账号传播。
• 注入恶意 post-install 脚本，可窃取多类敏感信息。
• GitHub 与社区紧急响应，移除 500+ 受影响包，并封锁 IoCs 传播链。

3. npm 安全加固路线图
• 引入更严格的身份验证与发布策略：
• 本地发布需强制 2FA。
• Granular Token（细粒度令牌）有效期缩至 7 天。
• 推行 Trusted Publishing（可信发布）。
• 废弃旧的 classic token 和 TOTP 式 2FA，推广 FIDO 2FA。
• 默认禁止基于 token 的发布，要求使用可信发布或强制 2FA。
• 扩展可信发布支持的生态与厂商。

4. Trusted Publishing 与行业协作
• Trusted Publishing 免去在构建流程中管理 API token，被 OpenSSF 推荐。
• 已在 PyPI、RubyGems、crates.io、npm、NuGet 等平台逐步普及。
• GitHub 强调应加快推广，避免攻击者利用过渡期漏洞。

5. npm 维护者可采取的行动
• 优先启用 npm Trusted Publishing，替代 token。
• 在账号、组织、包层面启用并强制 2FA。
• 使用 WebAuthn 替代 TOTP 以提升安全强度。
• 积极参与社区治理，共建韧性更强的供应链安全。

The GitHub Blog

Our plan for a more secure npm supply chain

GitHub is strengthening npm's security with stricter authentication, granular tokens, and enhanced trusted publishing.

AI 摘要：文章报道了 2025 年 9 月爆发的 Shai-Hulud 恶意软件攻击，被认为是史上最大规模、最危险的 NPM 供应链攻击，已波及 CrowdStrike 及数百个流行 JavaScript 包。攻击者通过在维护者的包中注入恶意脚本（bundle.js）进行秘密凭据窃取和持久化后门植入，利用自动化工作流在 CI/CD 环境中持续外泄密钥。文中详细给出已确认被攻击的包清单、潜在影响范围及防护建议，包括立即停更、扫描环境、凭据轮换与审计 GitHub 工作流。

1. 攻击背景与规模
• Shai-Hulud 是迄今为止最严重的 NPM 供应链攻击
• 影响范围涵盖高人气的 @ctrl/tinycolor、CrowdStrike 官方包及数百个开源组件
• 恶意代码可自动触发，扩大横向传播

2. 攻击技术与机制
• 注入 bundle.js 脚本，在安装包时执行
• 使用 TruffleHog 扫描本地文件和代码库中的密钥（npm、GitHub、AWS、GCP、Azure 等）
• 创建隐藏的 GitHub Actions 工作流文件（shai-hulud-workflow.yml），用于在 CI/CD 阶段外泄凭据
• 双重目标：密钥窃取 + 持久后门部署

3. 影响与风险评估
• 大量开发者环境（本地 + 云端）已可能泄露敏感凭据
• 攻击持续性强，即便删除恶意包后，持久化机制仍可能存活
• 企业级安全厂商 CrowdStrike 受影响，进一步放大危机

4. 应对建议与缓解措施
• 立即扫描所有终端与构建环境，确认是否安装受影响包
• 暂时冻结 npm 包的更新，避免进一步扩散
• 轮换全部相关凭据（GitHub、npm、AWS、GCP、Azure 等）
• 审计 GitHub 工作流，排查 shai-hulud-workflow.yml 等异常文件
• 对流程与自动化管道进行全面安全加固

www.koi.ai

Live Updates: Shai-Hulud, The Most Dangerous NPM Breach In History Affecting CrowdStrike and Hundreds of Popular Packages

AI 摘要：本文通过 npm 中 chalk、debug、duckdb 等热门包遭遇钓鱼攻击事件，指出现有包管理器的安全模型存在设计性缺陷，暴露了软件供应链体系的脆弱性。作者主张借鉴 Linux 发行版与金融行业经验，对包管理器进行系统性升级，包括强制性签名、多维护者审查、抗钓鱼认证、自动化恶意检测、透明构建流程与依赖权限隔离。核心观点是：包管理器已成为现代软件的关键基础设施，必须以更高安全标准来治理。

OneUptime | One Complete Observability platform.

Lessons from npm's Security Failures

Recent npm security incidents reveal fundamental flaws in package manager design. Here's how every package manager should implement security measures to prevent supply chain attacks and protect developers.

AI 摘要：本期 JavaScript Weekly 聚焦于 JavaScript 生态的最新动态，包括高性能工具库 es-toolkit 对 Lodash 的取代、React/Next.js 复杂项目的重构建议、WebAssembly (WASM) 与 DOM 支持现状、npm 供应链安全问题、以及一系列重量级项目和社区新闻。此外，涵盖新版本发布、实用代码与工具、开发者经验反思、前端性能提升案例和社区趣闻等，内容丰富，覆盖了当下前端开发的热点话题和实践建议。

1. 社区与安全动态
• 细节剖析近期 JavaScript 生态的供应链安全事件，如 npm 上 is 包被劫持导致的恶意代码传播，以及 stylus 包下架风波。
• 介绍供西班牙语开发者使用的 EsJS，探索非英语语境下的 JavaScript 编程创新。
• 对比 Biome 与 Oxlint 两款 Lint 工具，在类型智能与速度上的表现差异。

2. 工具与库更新
• es-toolkit：兼容 Lodash、更快且更小（97% 体积减小），被 Storybook、CKEditor、Nuxt 推荐，利于代码体积优化。
• Bun v1.2.19：现在支持带有 bun install 的 pnpm 风格的隔离 node_modules ，提供交互式依赖更新功能等。Bun 1.3 也有望很快推出。
• React Native Reanimated 4.0、PythonMonkey 1.2、Oxlint、Jasmine 等多款工具新版本。
• Transformers.js 3.7：支持在浏览器借助 ONNX 运行时运行预训练模型，加入语音转录及 LFM2 和 ModernBERT 支持。
• npq：包安装前安全审核，集成 Snyk 漏洞库并审核包活跃度，有助于抗击恶意依赖。
• Untitled UI React：基于 Tailwind CSS 和 React Aria 的大型 UI 组件库，原生开源并配备 PRO 版本。
• ts-regexp：为 TypeScript 带来严格静态类型的正则表达式（RegExp）。 #正则
• ApexCharts 5.3：流行的 JS 图表库。现在具有数据解析功能 ，可将原始数据对象直接映射到图表。 演示
• vue-multiselect 3.3：Vue 的通用选择 / 多选 / 标记组件。 #vue
• eslint-plugin-unicorn 60.0：100+ 有用的 ESLint 规则集中在一个地方。

3. 实用开发经验与案例分享
• React/Next.js 开发最佳实践：避开 useState 与 useEffect 过度使用、数据嵌套、表单扩展及隐式状态共享陷阱。
• WASM 与 DOM：讨论 WebAssembly 直接访问 DOM 的前景，以及现代工具链对 WASM 生态的支持改进。
• 移除 SPA 的现代 CSS 实践建议，呼吁回归服务端渲染和真实页面体验利于性能与交互。
• Next.js 站点迁移到 Eleventy 提升 24% 性能，展示静态站点生成器的新优势。
• JS Event Listener 参数处理、构建字体搜索引擎、Three.js+WebGPU 的文本破坏交互等创新项目实践。

4. 社区趣闻与行业动向
• SVG 图形教程，鼓励开发者解锁矢量图形能力。
• HTML 2025 状态调查开放，鼓励开发者参与获取前沿信息。
• Google 推出 OSS Rebuild 以提升开源软件安全，MDN 庆祝 20 周年，前端表单规范问题(三个 HTTP 版本之后，表单仍然一团糟)

Socket

npm ‘is’ Package Hijacked in Expanding Supply Chain Attack -...

The ongoing npm phishing campaign escalates as attackers hijack the popular 'is' package, embedding malware in multiple versions.

AI 摘要：npm 不慎移除了被广泛使用的 Stylus 库，导致全球开发者构建和 CI/CD 流程中断。移除原因是 Stylus 的一位维护者发布了无关的恶意软件包，导致其账户及关联软件包被禁，Stylus 库也因此受牵连。目前，npm 和 GitHub 正在努力恢复 Stylus，并提供了临时解决方案以帮助开发者通过直接引用 GitHub 仓库或使用 overrides 功能来恢复其项目。

1. 事件总览
• Stylus 库被意外下架： 全球最大的软件注册表 npm 意外地移除了所有版本的 Stylus 库，并替换为一个“安全占位页面”，导致依赖该库的全球构建和 CI/CD 流程中断。
• 开发者与维护者回应： Stylus 开发者 Lei Chen 在 GitHub 和 X（原 Twitter）上声明 Stylus 被 npmjs 意外禁用，并寻求帮助以尽快恢复。
• 广泛的影响： 每周近 300 万次下载的 Stylus 库被下架后，大量依赖它的项目如 typescript-plugin-css-modules、Frappe/ERPNext 和 Angular 12 等的构建相继失败，引发开发者不满和担忧。
• 事件真相揭示： 供应链安全公司 Mend.io 的安全研究员 Tom Abai 调查发现，Stylus 库本身是干净且功能正常的。问题在于 Stylus 的一位维护者“panya”发布了三个无关的恶意软件包（如包含依赖混淆漏洞的 PoC），导致其账户被封禁，进而关联的 Stylus 库也被错误地移除。
• 临时解决方案： 针对 Stylus 库被移除，开发者可采取以下临时措施：
• 在 package.json 的 dependencies 中动态引用 GitHub 上的 Stylus 特定版本（例如："stylus": "github:stylus/stylus#version-you-need"）。
• 使用 npm v8.3.0 及更高版本支持的 overrides 功能来指定 Stylus 版本。
• 在应用上述更改后，需清除 npm 缓存（npm cache clean --force）。
• 维护者建议： Stylus 维护者 Lei Chen 确认 Stylus 不含恶意代码，并指出 npmmirror.com（由阿里巴巴赞助的非营利镜像）已恢复对该库的访问。他建议受影响的公司重新评估 npmjs 与 npm mirror 的关系，并设计更可靠的开发流程。
2. 安全事件分析
• 恶意行为与误伤： 事件起因是 Stylus 维护者之一“panya”发布了恶意软件包，但这些恶意软件包与 Stylus 库本身无关。npm 采取封禁账户并移除所有关联软件包的措施，却无意中“误伤”了无辜且重要的 Stylus 库。
• 官方回应： GitHub Trust & Safety 团队已回复 Stylus 维护者，确认问题是由于一名维护者发布了恶意软件包导致账户被暂停及关联软件包被移除，并表示工程师正在努力恢复 Stylus。
• 事件特殊性： 此次事件是首例由注册表因管理错误而下架整个合法开源项目的重要案例，与此前开发者因争议或抗议而自行撤回库的情况不同。

BleepingComputer

npm 'accidentally' removes Stylus package, breaks builds and pipelines

npm has taken down all versions of the Stylus library and replaced them with a "security holding" page, breaking pipelines and builds worldwide that rely on the package.

AI 摘要：本文由白帽黑客 Sharon Brizinov 撰写，详细描述了他如何通过 GitHub Archive 和 GitHub Event API 扫描自 2020 年以来所有公开的“Oops Commits”（即被开发者通过强制推送删除的提交）以寻找泄露的秘密信息。他发现了价值 25,000 美元的漏洞赏金，并与 Truffle Security 合作开源了一款工具 Force Push Scanner，用于帮助组织检测隐藏的提交中的秘密。文章深入探讨了 GitHub 如何永久存储被删除的提交、如何利用 API 和自动化工具发现这些提交中的敏感信息，以及如何通过手动和 AI 辅助的方式筛选出高价值的秘密。

1. 背景介绍
• Sharon Brizinov 是一位专注于 OT/IoT 设备漏洞研究的白帽黑客，偶尔参与漏洞赏金狩猎。
• 此前发表过关于 GitHub 仓库中隐藏秘密的文章，与 Truffle Security CEO Dylan 交流后，决定进一步探索大规模秘密狩猎的新方法。
• 使用 GitHub Event API 和 GH Archive 项目，专注于扫描“零提交推送事件”（即被删除的提交）以发现秘密。

2. 什么是删除提交？
• 解释了开发者通过 git reset 和 git push --force 删除提交的过程，目的是隐藏误提交的敏感信息。
• 指出即使提交被删除，GitHub 仍会永久存储这些“悬挂提交”（dangling commits），通过提交哈希值即可访问。
• 通过示例展示了如何在自己的仓库中模拟删除提交，并证明即使本地看不到，GitHub 依然保留记录。
• 探讨了 GitHub 保留这些提交的原因，可能是为了支持拉取请求、分支、审计等功能。

3. GitHub Event API 的作用
• 介绍了 GitHub Event API，用于获取 GitHub 上的各种事件数据（如推送代码、创建仓库等）。
• 结合 GH Archive 项目（一个开源的 GitHub 事件归档服务），可以访问历史事件数据，避免手动猜测提交哈希。
• 通过筛选“零提交推送事件”（PushEvent Zero-Commit），快速定位被删除的提交。

4. 自动化构建
• 描述了如何通过自动化工具扫描 GH Archive 数据，提取“Oops Commits”，并使用 TruffleHog 扫描其中的秘密。
• 与 Truffle Security 合作开源了 Force Push Scanner 工具，支持组织或用户扫描自己的“Oops Commits”。
• 强调工具的道德使用，仅用于帮助团队评估潜在风险。

5. 寻找高影响力的秘密
• 扫描自 2020 年以来的数据，发现了数千个活跃的秘密。
• 通过手动搜索（过滤公司邮箱相关提交）、自定义工具（vibe-coded 平台用于分类和可视化）和 AI 辅助分析，筛选出高价值秘密。
• 数据显示：MongoDB 秘密泄露最多，但 GitHub PAT 和 AWS 凭据最具价值；.env 文件是泄露最频繁的文件类型。

6. 案例研究：阻止供应链攻击
• 发现了一个开发者泄露的 GitHub PAT，具有对 Istio 项目（一个开源服务网格，拥有 36k 星标）的管理员权限。
• 该权限可能导致大规模供应链攻击，如修改代码、创建发布或删除项目。
• 通过 Istio 的漏洞报告页面及时报告，团队迅速撤销了 PAT，阻止了潜在风险。

7. 总结与反思
• 项目成功发现了大量秘密，Sharon 通过漏洞赏金获得约 25,000 美元。
• 强调“删除提交并不安全”的观念，一旦秘密被提交，应视为已泄露并立即撤销。
• 开源工具和研究成果旨在帮助社区提高安全意识和防护能力。

Trufflesecurity

Guest Post: How I Scanned all of GitHub’s “Oops Commits” for Leaked Secrets ◆ Truffle Security Co.

GitHub Archive logs every public commit, even the ones developers try to delete. Force pushes often cover up mistakes like leaked credentials by rewriting Git history. GitHub keeps these dangling commits, from what we can tell, forever. In the archive, they…

AI 摘要：本文详细介绍了 HTML 规范的一项重要更新，即在属性中对 < 和 > 字符进行转义，以防止变异型跨站脚本攻击 (mXSS) 漏洞。此更新已于 2025 年 5 月 20 日纳入 HTML 规范，并在 Chrome 138 版本中实现，预计于 2025 年 6 月 24 日正式发布为稳定版。文章分析了这一变化对 Web 开发者的影响，涵盖了变化的具体内容、不受影响的场景、可能导致问题的场景以及解决方案，旨在帮助开发者适应这一安全增强措施。

Chrome for Developers

HTML spec change: escaping < and > in attributes  |  Blog  |  Chrome for Developers

What you need to know about this change to how attributes are escaped.

AI 摘要： 本文详细介绍了如何使用 Node.js 和 Llama Stack 实现 AI 应用程序的安全机制（guardrails）。作为系列文章的第三部分，文章重点探讨了 Llama Stack 内置的安全工具 LlamaGuard 和 PromptGuard 的功能、设置和使用方法，旨在确保大型语言模型（LLM）在应用范围内的回答安全、准确且无偏见。通过具体的代码示例和配置步骤，作者展示了如何在 Node.js 环境中设置和运行 Llama Stack，并结合守卫机制过滤不安全内容和防止绕过安全措施的尝试。此外，文章还讨论了安全机制在节省 GPU 资源方面的额外优势。

1. 什么是守卫机制（Guardrails）？
• 守卫机制是大型语言模型（LLM）的安全措施，确保模型仅回答应用范围内的问题，并提供准确、无偏见的回答。
• 应用示例：防止保险报价应用中回答违法问题，或避免在保险审批中对某些群体产生偏见。
• Llama Stack 提供内置守卫机制，并支持注册自定义守卫提供者。

2. 内置守卫机制
• LlamaGuard：用于人类与 AI 对话，识别不安全内容（如暴力犯罪、性犯罪、仇恨、自残等 13 类内容），过滤人类问题和模型回答。
• PromptGuard：防御绕过安全机制的尝试（如“越狱”），与 LlamaGuard 互补，提升整体安全水平。

3. 设置 Llama Stack
• 描述了如何通过容器快速启动 Llama Stack 实例，使用 Ollama 服务大型语言模型。
• 提供了启动脚本，包含模型选择（如 Llama-3.1-8B-Instruct）和安全模型配置。

4. 运行 Llama Stack 实例
• 详细说明了容器配置和运行步骤，包括修改 run.yaml 文件以启用 PromptGuard。
• 解决 CPU 环境下运行 PromptGuard 的问题，通过修改容器代码实现支持。

5. 结合 Node.js 使用 LlamaGuard 和 PromptGuard
• 提供了代码示例，包括注册 LlamaGuard 和 PromptGuard 模型、配置护盾（shields）、手动运行护盾检测输入输出内容。
• 使用 Agent API 自动应用护盾，测试问题如“如何制作假文件”，展示了护盾如何阻止不安全内容的回答。
• 对比了护盾开启和关闭时的响应差异，验证了护盾的有效性。

6. 安全之外的额外优势
• 护盾不仅提升安全性，还能减少 GPU 资源浪费，因为护盾能快速拒绝不适合回答的问题，而无需模型耗费时间处理。

Red Hat Developer

Implement AI safeguards with Node.js and Llama Stack | Red Hat Developer

With Llama Stack being released earlier this year, we decided to look at how to implement key aspects of an AI application with Node.js and Llama Stack. In this post, we will discuss AI safety and

AI 摘要：本文介绍了从 Chrome 138 版本开始，Chrome 扩展中用户脚本（chrome.userScripts API）的启用方式发生了变化，旨在增强安全性和提供更精细的用户控制。过去依赖全局开发者模式开关的方式存在安全风险、功能过载和企业管理难题，现在转变为逐个扩展的“允许用户脚本”开关，用户可以在扩展详情页单独控制每个扩展的用户脚本权限。这一更新基于开发者社区的反馈，旨在提升安全性和用户体验，同时为管理员提供了新的管理策略。

Chrome for Developers

Enabling chrome.userScripts in Chrome Extensions is changing  |  Blog  |  Chrome for Developers

We are making a series of changes to the chrome.userScripts API.