人工智能技术的爆发式迭代正重塑全球数字经济格局与国家核心竞争力新赛道，生成式大模型、多模态 AI 与千行百业的深度融合，已成为驱动数字中国建设向纵深发展的核心引擎，网络空间也由此正式迈入 “人机协同、智能对抗” 的全新纪元。当前，AI 既是网络安全防护体系升级的核心赋能者，为漏洞智能挖掘、威胁实时感知、自动化应急响应提供革命性解决方案；也催生了 AI 驱动的自动化批量攻击、生成式恶意代码、AI 增强型 APT 渗透、大模型自身安全漏洞等新型威胁，传统安全技术体系与高校人才培养模式正面临颠覆性挑战。在网络安全实战场景，AI 正彻底打破传统网安攻防的人力边界与效率瓶颈。能否掌握 “AI +网络安全 为贯彻落实教育部关于深化产教融合、推进网络安全新工科建设与 “AI + 教育” 融合发展的要求，在中国网络空间安全人才教育论坛（网教盟）指导下，湖南蚁景科技有限公司拟于2026年7月27日-7月31日在广州举办“2026 AI + 网络安全高级研讨会”，以实战化课程体系覆盖 AI 与渗透测试融合的核心场景，助力教师打造兼具前沿技术能力与教学转化价值的核心竞争力。诚邀全国相关专业负责人、学科带头人、骨干教师参会交流。 一、组织单位 指导单位：中国网络空间安全人才教育论坛 主办单位：湖南蚁景科技有限公司 二、会议内容 1、渗透测试环境搭建 使用 VMware 虚拟化技术部署 Kali Linux，完成系统初始化、网络配置、基础工具安装及优化，构建标准的渗透测试实验环境。 2、Kali 接入 AI 智能体 在 Kali 中安装 Claude Code 等 AI 助手，配置通信接口，实现操作系统与大型语言模型智能体之间的交互连接。 3、MCP Server 实现自然语言渗透 部署并利用模型上下文协议（MCP）服务，将自然语言指令转化为实际的系统操作，驱动 Kali 工具集执行自动化渗透任务。 4、MCP 深度实战开发 学习 MCP 协议核心规范，动手编写自定义 MCP 服务接口，将常用安全工具封装为可供 AI 调用的标准化组件。 5、AI 全流程驱动漏洞利用开发 使用 AI 智能体操控 Chrome 浏览器完成 Web 漏洞自动利用，借助大模型编写与调试 Exploit 脚本，并运用 AI 操作 IDA Pro 辅助二进制程序逆向分析。 6、AI 全流程自动化代码审计 搭建代码分析工具与 LLM 联动的审计管道，对多语言源代码进行自动化漏洞发现、上下文分析及结果验证。 7、AI 赋能渗透测试全链路自动化 将 AI 应用于渗透测试全流程：信息收集与资产测绘、智能化漏洞检测与确认、AI 辅助漏洞利用，以及自动生成结构化渗透测试报告。 8、多 AI 智能体协同自动化攻击链 利用多智能体编排技术，将信息收集、打点、维权、横向移动等攻击步骤串联为全自动攻击链，并结合 AI-UEBA 技术对用户与实体行为进行异常洞察。 三、参会人员 全国高校、职业院校计算机相关专业和网络（信息）安全专业的负责人、学科带头人、骨干教师、实验室人员等。 四、预期收获 1、快速搭建标准化渗透环境：独立完成可复现的虚拟化渗透测试平台部署，精通 Kali 系统深度配置与性能优化，为后续所有实战演练筑牢稳定、高效的环境基础。 2、解锁 AI 渗透入门能力：掌握 LLM 与渗透测试工作站的无缝对接技术，理解 AI Agent 与操作系统的交互原理，熟练通过命令行和 API 调用 AI 能力，正式开启人机协同渗透新时代。 3、自然语言操控安全工具：吃透 MCP 核心架构，实现用自然语言直接指挥 Nmap、Sqlmap 等主流工具，彻底降低工具使用门槛，让基础渗透操作效率提升 3-5 倍。 4、定制专属 AI 安全插件：具备安全工具 MCP 服务开发能力，可根据企业业务需求快速打造私有化 AI 安全插件，突破现成工具限制，实现任意安全工具的智能化封装。 5、AI 赋能漏洞全流程利用：一键将漏洞描述转化为可执行的 PoC/Exp 代码，获得 Web 与二进制漏洞利用、浏览器操控、逆向工程的 AI 实战加持，大幅提升漏洞挖掘与利用的自动化水平。 6、构建攻防一体智能体系：用 AI 重构渗透测试全工作流，自动化完成 90% 以上重复劳动；掌握 AI 增强代码审计流水线搭建，发现传统扫描器遗漏的逻辑漏洞；同时具备端到端自动化攻击链设计与 AI 异常检测能力，建立攻防兼备的全局安全视野。 7、结业证书：获得由湖南蚁景科技有限公司颁发的结业证书。 五、讲师简介 刘俊明 2019年CNCC-中国计算机大会攻防演讲嘉宾，哈工大网络安全国际邀请赛 HITCTF 2023 裁判长，高校网络空间安全高级研修班特聘专家，中国网络空间安全人才教育论坛特聘讲师，擅长红队渗透测试技术，多年从事渗透测试、Web 安全教研工作，具备丰富的红队人才培养经验。 曾为高校、税务、移动、电网、黄金、烟草等政府事业单位进行网安实战和安全服务技能培训; 为国防科大、中南大学、湖南大学、中国海洋大学、广州大学等高校进行网络安全、攻防演练的系统化培训。 擅长技术：Web渗透、内网渗透、漏洞挖掘、POC/EXP 编写、安全服务、应急响应等网络安全领域。 六、会议安排 1、培训方式：线下会议 / 线上直播 2、培训时间：2026年7月27日-7月31日（7月26日报到） 3、培训地点：广州市黄埔区知识城海丝知识中心 4、会议规模：100人 七、报名方式 1、报名时间：即日起至2026年7月26日 2、报名邮箱：edu@yijingsec.com 3、电话咨询：黄老师 18774948349 4、培训费用：3980元/人（含会议资料，交通费和住宿费自理，自备电脑） 5、付款方式：      ◆ 线上汇款： （请务必备注“学校名+参会者姓名”）         公司名称：湖南蚁景科技有限公司         开户行名称：农业银行湖南湘江新区分行         开户行账号：18058801040005912      ◆ 扫码付款：（请务必备注“学校名+参会者姓名”）      ◆ 现场缴费：现金、扫码或刷卡（银行卡、公务卡均可）  具体课程内容 扫描下方二维码即可报名：

1、伊朗黑客组织入侵韩国大型电子制造商 https://www.security.com/threat-intelligence/iran-seedworm-electronics 研究人员披露，与伊朗有关的黑客组织MuddyWater（又名Seedworm、Static Kitten）近期发起大范围网络间谍活动，目标覆盖多个国家和行业，其中包括一家韩国大型电子制造商、政府机构、中东一座国际机场、亚洲工业企业及教育机构。研究人员称，攻击者于2026年2月20日至27日在该韩国企业网络内活动约一周，疑似以情报搜集为导向，重点关注工业与知识产权窃取、政府间谍活动及获取下游客户或企业网络访问权限。此次行动大量使用DLL侧加载、Power 2、伪装援助文件的间谍软件行动曝光 https://cyble.com/blog/operation-humanitarianbait-infostealer-campaign/ 研究人员披露了一起名为“Operation HumanitarianBait”的网络攻击活动。该行动利用伪造的人道主义援助相关文档作为诱饵，面向俄语用户实施定向攻击。攻击链中，恶意载荷托管在GitHub平台，受害者在接触并打开相关诱饵文件后，可能进一步下载并执行后续程序。最终载荷为基于Python开发的间谍软件，说明攻击者具备利用常见开发语言和公开平台隐藏恶意活动的能力。现有信息表明，这是一场结合社会工程、远程托管载荷与信息窃取能力的攻击行动，重点在 3、新型TrickMo借助TON实现隐蔽控制 https://www.threatfabric.com/blogs/new-trickmo-variant-device-take-over-malware-targeting-banking-fintech-wallet-auth-app 研究人员发现TrickMo安卓银行木马出现新变种，其一项关键变化是利用TON区块链基础设施进行隐蔽的命令与控制（C2）通信。按照披露信息，这种做法意在提升攻击活动的隐匿性，降低传统网络层面检测与拦截的效果。标题同时提到，该变种还结合SOCKS5能力，将受感染的安卓设备转化为网络代理支点，以便为后续流量转发或间接访问提供条件。现有内容重点说明了其通信与代 4、RubyGems因恶意包攻击暂停新用户注册 https://thehackernews.com/2026/05/rubygems-suspends-new-signups-after.html RubyGems因遭遇大规模恶意软件包上传事件，已暂停新用户注册。公开信息显示，此次攻击涉及数百个恶意包，被认为进一步加剧了软件供应链安全风险。RubyGems作为Ruby生态的重要软件包仓库，此类事件可能影响开发者对第三方依赖的获取与信任，也反映出开源包管理平台在账号注册、包审核和恶意内容拦截方面面临持续压力。目前已知信息主要集中在平台采取的应急措施以及攻击规模，原文未披露更详细的技术细节、影响范围或攻击者身份。 5、富士康确认北美工厂遭氮气勒索软件攻击 https://www.bleepingcomputer.com/news/security/electronics-giant-foxconn-confirms-cyberattack-on-north-american-factories/ 富士康向媒体证实，其北美部分工厂遭遇网络攻击，事件发生后公司已启动应急响应机制，并采取多项运营措施以保障生产和交付连续性，受影响工厂目前正逐步恢复正常生产。此次攻击被“氮气”勒索软件组织认领，该组织声称窃取了约8TB数据和超过1100万份文件，内容涉及机密指令、项目资料和图纸，并提及苹果、英特尔、谷歌、英伟达和AMD等客户。公开信息显示，Nitrog 6、西氏医药披露遭遇数据窃取与系统加密攻击 https://www.bleepingcomputer.com/news/security/west-pharmaceutical-says-hackers-stole-data-encrypted-systems/ 美国制药制造企业West Pharmaceutical Services披露，其遭遇一起重大网络安全事件，攻击者不仅从公司网络中窃取了部分数据，还加密了若干系统。公司称于2026年5月4日首次发现入侵，并在5月7日确认事件具有重大影响，随后启动事件响应流程，包括在全球范围内主动下线部分系统、通知执法部门，并聘请外部网络取证专家及Palo Alto Networks Unit 7、Windows DNS客户端漏洞可导致远程代码执行攻击 https://www.freebuf.com/articles/system/481157.html 微软Windows DNS客户端中新披露的一个漏洞可能让攻击者悄无声息地在企业网络中执行恶意代码，暴露出巨大的攻击面。该漏洞被正式编号为CVE-2026-41096，CVSS严重性评分高达9.8分（满分10分）。 8、MongoDB 高危漏洞可导致攻击者执行任意代码 https://www.freebuf.com/articles/database/481122.html 最新披露的 MongoDB 高危漏洞（CVE-2026-8053）可能使威胁攻击者执行任意代码，进而完全控制受影响服务器，导致数百万条记录面临泄露风险。该漏洞直接影响 MongoDB Server 的部署环境。 9、Veeam推出全新备份管理与网络安全功能 https://siliconangle.com/2026/05/12/veeam-introduces-new-backup-management-cybersecurity-features/ Veeam发布新功能强化数据备份与防护，旗舰产品Veeam Data Platform v13.1新增量子级加密和恶意软件扫描，DataAI Command Platform实现智能数据资产管理，提升企业韧性运营能力。 10、NGINX堆缓冲区溢出漏洞可导致远程代码执行 https://www.secrss.com/articles/90300 未经身份认证的攻击者可通过发送构造的 HTTP 请求触发漏洞，造成 Worker 进程崩溃，在特定环境下还可实现远程代码执行。官方修复NGINX ngx_http_rewrite_module 堆缓冲区溢出漏洞(CVE-2026-42945)，该漏洞源于处理特定 rewrite 指令时，由于内部标志位管理错误，导致堆缓冲区分配长度与实际写入长度不一致，从而引发堆缓冲区溢出。未经身份认证的攻击者可通过发送构造的 HTTP 请求触发漏洞，造成 Worker 进程崩溃，在特定环境下还可实现远程代码执行。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

1、伪造隐私过滤项目登顶HuggingFace下载榜 https://www.hiddenlayer.com/research/malware-found-in-trending-hugging-face-repository-open-oss-privacy-filter 一个冒充“OpenAI Privacy Filter”的恶意项目曾登上Hugging Face下载排行榜首位，并累计获得约24.4万次下载。该项目以看似正常的隐私过滤工具为幌子，实际向Windows用户传播信息窃取型恶意软件，可能导致受害者的凭据、会话令牌及其他敏感数据被盗。此事件表明，热门开源与AI模型托管平台同样可能被攻击者利用，通过伪装成受欢迎或可信工具来扩大传播范围 2、黑客滥用VercelGenAI批量生成钓鱼网站 https://hackread.com/hackers-exploit-vercel-genai-phishing-sites/ 攻击者正在滥用Vercel GenAI批量创建高仿真的钓鱼网站。这些页面可模仿微软、阿迪达斯、耐克等知名品牌的外观与风格，使诈骗页面更具迷惑性，也让普通用户更难通过视觉特征识别风险。报道指出，此类生成式AI工具被不法分子利用后，可能显著降低搭建钓鱼站点的门槛，并提升伪造页面的制作效率与可信度，从而扩大网络钓鱼攻击的影响范围。该现象反映出生成式AI在便利开发的同时，也带来了新的安全滥用风险。 3、Shai-Hulud供应链攻击污染数百软件包 https://www.endorlabs.com/learn/shai-hulud-compromises-the-tanstack-ecosystem-80-packages-compromised Shai-Hulud供应链攻击已影响npm与PyPI上的数百个软件包，目标直指开发者凭证。攻击者被指与TeamPCP有关，先后入侵TanStack、Mistral AI、Guardrails AI、UiPath、OpenSearch等项目，并利用被窃取的CI/CD凭证发布恶意版本。此次攻击尤其危险之处在于，恶意包通过合法流水线发布，携带有效的OIDC身份、SLSA Build Level 3 4、Signal新增应用内警示以防社交工程攻击 https://www.bleepingcomputer.com/news/security/signal-adds-security-warnings-for-social-engineering-phishing-attacks/ Signal宣布在应用内新增确认提示和警告信息，以加强对网络钓鱼和社交工程攻击的防护，降低用户因外部请求受骗的风险。此举背景是近期多起针对高知名度用户的攻击事件，攻击者冒充“Signal支持”发送虚假警报，诱导受害者扫描二维码或提供一次性验证码，从而滥用“关联设备”功能访问账号、聊天记录和联系人列表。相关事件已被FBI、荷兰政府和德国有关部门披露，并归因于俄罗 5、斯柯达网店遭入侵致客户数据泄露 https://www.skoda-auto.de/unternehmen/sicherheitsvorfall-skoda-shop 大众集团旗下汽车制造商斯柯达披露，其在线商店因电商门户所用标准软件存在未说明漏洞而遭攻击，导致不明数量客户的个人信息被未授权访问。公司表示，受影响数据包括姓名、地址、电子邮件、电话号码、订单信息，以及登录凭据中的邮箱地址和密码加密哈希；完整信用卡信息未存储在被攻破系统中，因此攻击者无法直接获取。斯柯达称已修复相关漏洞，向数据保护监管机构报告事件，并交由专业IT取证团队开展技术分析。尽管目前没有证据表明被窃取的访问数据已被滥用，斯柯达仍提醒受影响客户警惕冒充其 6、谷歌推出AI驱动的Android移动安全增强方案 https://cybersecuritynews.com/google-enhances-android-mobile-security/ Android面临复杂威胁，谷歌推出AI主动防御体系，包括实时威胁检测、设备丢失保护和隐私控制升级，从被动修复转向主动拦截，防止诈骗和数据窃取。 7、Microsoft Teams 漏洞可导致黑客实施欺骗攻击 https://cybersecuritynews.com/microsoft-teams-vulnerability-spoofing/ 微软Teams曝高危漏洞(CVE-2026-32185)，攻击者可伪造本地设备进行欺骗攻击，影响数据机密性。已发布Android版修复补丁，建议用户立即更新，企业环境需优先处理。 8、Fortinet修复FortiSandbox与FortiAuthenticator高危漏洞 https://securityaffairs.com/192047/security/critical-fortinet-vulnerabilities-fixed-in-fortisandbox-and-fortiauthenticator.html Fortinet修复了FortiSandbox和FortiAuthenticator的高危漏洞（CVE-2026-44277和CVE-2026-26083），攻击者可远程执行任意代码，需升级至指定版本。目前未发现利用情况。 9、微软2026年5月补丁日：修复120个漏洞，含29个高危RCE漏洞 https://cybersecuritynews.com/microsoft-patch-tuesday-may-2026/ 微软2026年5月补丁修复120个漏洞，含29个高危RCE漏洞，重点涉及Windows核心网络、Office、Azure及AI工具，虽无0Day但风险高，需优先修补Dynamics 365、SharePoint及DNS等关键组件。 10、虚假Claude Code安装程序利用浏览器凭证窃取工具锁定开发者 https://hackread.com/fake-claude-code-installer-devs-browser-credential-stealer/ 攻击者伪造Claude Code安装页面，诱骗开发者下载恶意脚本窃取浏览器密钥，利用IElevator2接口解密数据，属于新型持续性攻击。建议启用脚本日志监控异常调用，采用凭证轮换降低风险。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

0.前言 在上一次的技术分享文章中，着重讨论了 RAG 时代的数据投毒问题，也就是当外部文档被检索、拼接并送入大模型上下文时，数据就不再只是被动的信息来源，它可能变成一段能够影响模型行为的代码，详细可以搜索《Data is Code：RAG 时代的数据投毒与大模型上下文劫持》 这种风险在 RAG 系统中尤为明显，攻击者不一定需要入侵服务器，也不一定需要修改模型权重，只要一段被污染的文本进入知识库，并在合适的问题下被召回，它就有机会改变模型的回答逻辑，突破指令边界，甚至诱导模型泄露同一上下文中的敏感信息。 上次我在第三种RAG投毒方式，零交互数据窃取中，提到这种攻击还可以进一步升级，即用GCG计算出一串人类看不懂的乱码，这串乱码在向量空间里的坐标跟很多都重合，完成一次更加隐蔽的攻击 RAG 投毒更多讨论的是攻击内容如何进入上下文，而 GCG 是探讨，如果我们已经知道模型会受上下文影响，那么能不能用算法自动搜索出最容易影响模型的那一小段文本？ 这就是 GCG 值得被单独拿出来讲的原因，因为它把大模型越狱从人写 prompt推进到了算法优化 prompt的阶段 说到底，如果说 RAG 投毒讨论的是外部数据如何劫持上下文，那么 GCG 讨论的就是另一个更底层的问题：模型的安全边界，是否可以被算法自动搜索出来？ 1.GCG介绍 在讨论 GCG 之前，先要把它放回到大模型越狱的语境里 1.1从 Jailbreak 到 Adversarial Suffix 传统的 Jailbreak(越狱)，本质上是通过构造特殊提示词，让模型偏离原本的安全对齐策略。比如通过角色扮演、规则重写、上下文欺骗、任务拆分等方式，让模型误以为自己可以回答原本应该拒绝的问题 这类方法有一个共同点：它们基本上是由人写出来的 也就是说，攻击效果依赖于攻击者对模型行为的观察、对提示词的理解，以及大量试错。攻击者要不断调整表达方式，测试模型是否会拒绝，观察模型在哪些语境下更容易被攻击，比如说会说一些不该说的话，或者是泄露不该泄露的东西 但 GCG 的出现，把这个问题变成了个半自动，即GCG 不再把 Jailbreak 看成一个单纯的提示词写作问题，而是把它建模成一个优化问题： 在用户原始问题后面，能不能自动搜索出一小段 token 后缀，让模型更倾向于生成目标响应，而不是执行安全拒答？ 这段被搜索出来的文本，通常叫做adversarial suffix，也就是对抗后缀 它可以被抽象成下面这个形式： 用户问题 + 对抗后缀 → 模型输出 这里真正被优化的，不是用户问题本身，也不是模型权重，而是后面那一小段额外文本 这也是 GCG 和传统 Jailbreak 最大的差别 说得通俗易懂点，就是传统 Jailbreak 更像是在说服模型，而GCG算法更像是在搜索模型的脆弱方向 之前的分享里讲 RAG 投毒时，重点是外部数据如何进入上下文，并在推理期影响模型行为 而这次讲 GCG，就是在进一步探索，如果说模型确实会被上下文影响，那么什么样的上下文片段最容易影响它？ 1.2 GCG算法 GCG的原文链接 https://arxiv.org/abs/2307.15043 GCG 是Greedy Coordinate Gradient的缩写，可以拆成三个关键词来看： Greedy     贪心 Coordinate 坐标 Gradient   梯度 这三个词基本上就概括了它的核心思想 Gradient 指的是，算法会利用模型的梯度信息，判断当前后缀中的某个 token 如果被替换，模型输出会朝哪个方向变化 Coordinate 指的是，它不是一次性改完整段文本，而是把后缀看成多个位置，每次选择其中一个 token 位置进行修改 这里的位置可以简单理解成后缀中的第几个 token 比如： [x0] [x1] [x2] [x3] [x4] GCG 每次会尝试修改其中某一个位置，比如先看 x3 能不能换成更合适的 token，再看 x1、x4 等位置 Greedy指的是，每一轮修改时，它都会倾向于保留当前看起来效果最好的替换。也就是说，它不保证一次找到全局最优，但会不断做局部最优选择，让后缀逐步 朝目标方向靠近 所以，用一句话解释 GCG GCG 是一种利用梯度信息，在离散 token 空间中贪心搜索对抗后缀的方法 如果说得更人话一点： 它就像是在模型输入后面放了一串可调参数，然后不断问模型：我把这里换成哪个 token，最容易让你的输出朝目标方向偏移 这里可能会有人有个疑问，特别是有做图像干扰的师傅们 就是图像可以做梯度优化很好理解，因为图片是像素矩阵，像素值是连续的 比如一个像素原来是：0.31 我们可以把它微调成：0.33 但文本不是连续的 一个 token 要么是猫，要么是狗，要么是某个标点符号，不能把猫加上 0.01 变成另一个 token 所以疑问就是 token 是离散的，GCG 为什么还能用梯度？ 其实关键在于语言模型真正处理的并不是 token 字符串本身，而是 token 对应的 embedding 向量 Embedding 向量就像是给每一个词语或事物分配的多维特征坐标位置，它把人类才能懂的抽象概念变成了一串数字，让意思越相近的东西，在这个数学坐标系里 住得越紧凑，从而让计算机能直接通过量距离来算出它们的关系 举个最直白的例子解释一下 如果把词语当成找对象，我们可以给它们打分（坐标）： “苹果”：甜度(0.8)，水分(0.9)，机械感(0.0) -> [0.8, 0.9, 0.0] “香蕉”：甜度(0.9)，水分(0.5)，机械感(0.0) -> [0.9, 0.5, 0.0] “汽车”：甜度(0.0)，水分(0.0)，机械感(1.0) -> [0.0, 0.0, 1.0] 在计算机眼里，它算一下距离就会发现，苹果和香蕉的向量数字非常接近，所以它们是同一类，都是属于水果范畴 而汽车跟它们差了十万八千里，这就是 Embedding 的核心作用 回到GCG，一个输入 token 进入模型时，会先被映射成一个高维向量，虽然 token ID 是离散的，但 embedding 向量是连续的，连续向量就可以参与梯度计算 可以这样理解： token           →   embedding 向量 离散文本         →   连续空间中的一个点 不可直接求导       →   可以通过向量方向估计变化趋势 GCG 并不是直接对 token 做加减法，而是通过梯度判断： 如果想让模型更接近某个目标输出，那么当前这个 token 对应的 embedding 应该往哪个方向变化？ 然后算法会回到词表中，寻找那些更接近这个方向的候选 token，再尝试用它们替换当前 token 所以，GCG 的关键并不是文本本身可导，而是： 文本进入模型后会变成 embedding，而 embedding 空间中的方向变化可以用梯度来估计 这也是为什么它经常会生成一些人类看起来像乱码的后缀，因为GCG算法并不是在追求人类读起来通顺，而是在追求模型内部表示空间中的有效扰动 从安全对齐的角度看，一个经过对齐的模型在面对危险问题时，理想行为应该是拒绝回答 也就是说，当输入是危险问题的时候，模型应该更倾向于输出： 抱歉，我不能帮助完成这个请求 而不是输出具体的危险内容 GCG 要做的事情，就是在不修改模型权重的情况下，只通过修改输入后缀，让模型的输出概率发生偏移 可以抽象成： 原始状态： 用户问题 → 模型倾向于拒答 加入后缀后： 用户问题 + 后缀 → 模型更容易生成目标响应 这里需要注意一点： GCG 并不是让模型理解这段后缀的语义，也不一定是通过自然语言逻辑说服模型。 很多时候，这段后缀在人类看来没有明确含义，但它在模型内部可能会影响某些 token 的生成概率 类比到图像对抗样本一样，人眼看到的图片几乎没变化，但模型的分类结果可能发生变化，GCG 对语言模型做的是类似的事情，只不过扰动对象从像素变成了 token 因此，GCG 的真正意义不是发现了一种奇怪的越狱提示词，而是说明： 大模型的安全边界可能不是一个稳定的语义规则边界，而是一个可以被搜索和逼近的概率边界。 1.3 GCG具体流程 通俗易懂来说，GCG可以具体分为六步 第一步：初始化一段后缀 算法首先会在用户问题后面放一段初始后缀 这段后缀一开始可以是随机 token，也可以是某种占位文本 抽象表示如下： 用户问题 + [x1, x2, x3, x4, ..., xn] 其中 [x1, x2, x3, ..., xn] 就是后面要不断优化的部分 第二步：设定优化目标 GCG 需要一个目标方向，比如，它可能希望模型更倾向于生成某类目标响应，而不是安全拒答 可以把它抽象成： 目标：让模型输出从拒答路径偏向目标响应路径 第三步：计算当前后缀的影响 模型会根据当前输入计算输出概率，此时算法会评估： 当前后缀距离目标还有多远？ 如果当前后缀效果不好，说明它还需要继续被修改 这个距离通常会通过损失函数来衡量 损失函数就是 AI 的错题扣分器，预测答案偏离标准答案越离谱，扣的分，也就是Loss 值就越高，AI 学习的过程就是想方设法把这个分数降到最低 举个例子，最开始的 Loss 是 6.13，说明那一组前缀离成功劫持大模型还差得很远；经过 200 轮的不断纠错调整，Loss 降到了 0.0004，说明算法已经找到了近乎 完美的payload，错题本上的扣分基本清零了 损失越高，说明模型越不倾向于生成目标响应，损失越低，说明当前后缀越能把模型推向目标方向 说白了，就是GCG 会把模型有没有被诱导到目标方向转化成一个可计算的损失值 第四步：用梯度寻找候选 token 接下来是 GCG 最关键的一步。 算法会查看后缀中每一个位置，估计如果替换这个位置上的 token，损失可能如何变化 比如当前后缀是： [x0] [x1] [x2] [x3] [x4] 算法可能发现，修改 x3 对降低损失最有帮助，于是它会围绕 x3 这个位置，从词表中挑出一批候选 token 这里的梯度就像一个方向指示器，它告诉算法，当前这个位置，往哪些 token 方向替换更可能有效？ 第五步：尝试替换并评估效果 找到候选 token 后，算法会尝试把当前位置替换成不同候选项，然后重新计算损失。 比如： 原始后缀： [x0] [x1] [x2] [x3] [x4] 候选替换： [x0] [x1] [a] [x3] [x4] [x0] [x1] [b] [x3] [x4] [x0] [x1] [c] [x3] [x4] 算法会比较这些替换方案，选择让损失下降最多的那个 第六步：重复迭代 完成一次替换后，算法会继续下一轮，它会再次计算梯度，再次选择位置，再次生成候选 token，再次替换。 整个过程可以画成下面这个循环： 初始化后缀   ↓ 计算损失   ↓ 计算梯度   ↓ 选择候选 token   ↓ 尝试替换   ↓ 保留效果最好的替换   ↓ 重复迭代 经过多轮迭代后，原本随机或普通的后缀，可能会变成一段对模型输出有明显影响的 adversarial suffix 整个过程的伪代码如下： 输入： 模型 M 原始输入 x 可优化后缀 s = [s1, s2, ..., sn] 目标响应 y 迭代轮数 T 初始化： 随机或固定初始化一段 suffix s 循环 T 轮：  1. 将 x 与当前 suffix s 拼接，送入模型 M  2. 计算模型生成目标响应 y 的损失 L  3. 对 suffix 中每个 token 位置计算梯度  4. 根据梯度为每个位置选出若干候选 token  5. 尝试替换某个位置上的 token  6. 重新计算替换后的损失  7. 保留让损失下降最多的那次替换 输出： 优化后的 suffix s 上面这段伪代码看起来像普通优化算法，但它真正特殊的地方在于，优化对象不是模型参数，而是输入文本 优化空间不是连续向量，而是离散 token，优化目标不是提升任务准确率，而是改变模型在安全边界附近的输出倾向 2.GCG实践 说了这么多，我们来做点GCG实践 2.1 Hackergame https://github.com/USTC-Hackergame/hackergame2023-writeups这里拿中国科学技术大学2023的一道Hackergame题目来讲解 本地部署环境一定要 Gradio 3.50.2 和 Transformers 4.35.0 否则本地跑起来会有各种各样的错误 这里我们着重来看第三个flag flag3已经不像之前的flag1和flag2可以通过手写提示词的方式就可以直接拿到flag的 这里就必须用到GCG算法了，我们回顾一下刚刚所讲的GCG步骤 先初始化，设定目标，计算后缀，梯度寻找token，替换评估，重复迭代，这里就不再过多赘述了，直接看解题代码 from transformers import AutoModelForCausalLM, AutoTokenizer, GenerationConfig from livelossplot import PlotLosses  # pip install livelossplot import gc import numpy as np import torch import torch.nn as nn from transformers import AutoModelForCausalLM, AutoTokenizer np.random.seed(20) torch.manual_seed(20) torch.cuda.manual_seed_all(20) target = "hackergame"  # 这个就是我所说的初始化目标 num_steps = 500 #最多优化 500 轮 adv_string_init = "!"*100 #初始前缀，先用 100 个感叹号占位 adv_prefix = adv_string_init #当前正在被优化的前缀 # larger batch_size means more memory (but more likely to succeed) batch_size = 512 #每轮尝试 512 个候选前缀 device = 'cuda:0' topk = 256 #每个位置从梯度推荐的前 256 个 token 里采样 def get_embedding_matrix(model):    return model.transformer.wte.weight def get_embeddings(model, input_ids):    return model.transformer.wte(input_ids) def token_gradients(model, input_ids, input_slice, target_slice, loss_slice):    """   Computes gradients of the loss with respect to the coordinates.   Parameters   ----------   model : Transformer Model       The transformer model to be used.   input_ids : torch.Tensor       The input sequence in the form of token ids.   input_slice : slice       The slice of the input sequence for which gradients need to be computed.   target_slice : slice       The slice of the input sequence to be used as targets.   loss_slice : slice       The slice of the logits to be used for computing the loss.   Returns   -------   torch.Tensor       The gradients of each token in the input_slice with respect to the loss.   """    embed_weights = get_embedding_matrix(model)    one_hot = torch.zeros(        input_ids[input_slice].shape[0],        embed_weights.shape[0],        device=model.device,        dtype=embed_weights.dtype   )    one_hot.scatter_(        1,        input_ids[input_slice].unsqueeze(1),        torch.ones(one_hot.shape[0], 1,                   device=model.device, dtype=embed_weights.dtype)   )    one_hot.requires_grad_()    input_embeds = (one_hot @ embed_weights).unsqueeze(0)    # now stitch it together with the rest of the embeddings    embeds = get_embeddings(model, input_ids.unsqueeze(0)).detach()    full_embeds = torch.cat(       [            input_embeds,            embeds[:, input_slice.stop:, :]       ],        dim=1   )    logits = model(inputs_embeds=full_embeds).logits    targets = input_ids[target_slice]    loss = nn.CrossEntropyLoss()(logits[0, loss_slice, :], targets)    loss.backward()    grad = one_hot.grad.clone()    grad = grad / grad.norm(dim=-1, keepdim=True)    return grad def sample_control(control_toks, grad, batch_size):    control_toks = control_toks.to(grad.device)    original_control_toks = control_toks.repeat(batch_size, 1)    new_token_pos = torch.arange(        0,        len(control_toks),        len(control_toks) / batch_size,        device=grad.device   ).type(torch.int64)    top_indices = (-grad).topk(topk, dim=1).indices    new_token_val = torch.gather(        top_indices[new_token_pos], 1,        torch.randint(0, topk, (batch_size, 1),                      device=grad.device)   )    new_control_toks = original_control_toks.scatter_(        1, new_token_pos.unsqueeze(-1), new_token_val)    return new_control_toks def get_filtered_cands(tokenizer, control_cand, filter_cand=True, curr_control=None):    cands, count = [], 0    for i in range(control_cand.shape[0]):        decoded_str = tokenizer.decode(            control_cand[i], skip_special_tokens=True)        if filter_cand:            if decoded_str != curr_control \                    and len(tokenizer(decoded_str, add_special_tokens=False).input_ids) == len(control_cand[i]):                cands.append(decoded_str)            else:                count += 1        else:            cands.append(decoded_str)    if filter_cand:        cands = cands + [cands[-1]] * (len(control_cand) - len(cands))    return cands def get_logits(*, model, tokenizer, input_ids, control_slice, test_controls, return_ids=False, batch_size=512):    if isinstance(test_controls[0], str):        max_len = control_slice.stop - control_slice.start        test_ids = [            torch.tensor(tokenizer(                control, add_special_tokens=False).input_ids[:max_len], device=model.device)            for control in test_controls       ]        pad_tok = 0        while pad_tok in input_ids or any([pad_tok in ids for ids in test_ids]):            pad_tok += 1        nested_ids = torch.nested.nested_tensor(test_ids)        test_ids = torch.nested.to_padded_tensor(            nested_ids, pad_tok, (len(test_ids), max_len))    else:        raise ValueError(            f"test_controls must be a list of strings, got {type(test_controls)}")    if not (test_ids[0].shape[0] == control_slice.stop - control_slice.start):        raise ValueError((            f"test_controls must have shape "            f"(n, {control_slice.stop - control_slice.start}), "            f"got {test_ids.shape}"       ))    locs = torch.arange(control_slice.start, control_slice.stop).repeat(        test_ids.shape[0], 1).to(model.device)    ids = torch.scatter(        input_ids.unsqueeze(0).repeat(test_ids.shape[0], 1).to(model.device),        1,        locs,        test_ids   )    if pad_tok >= 0:        attn_mask = (ids != pad_tok).type(ids.dtype)    else:        attn_mask = None    if return_ids:        del locs, test_ids        gc.collect()        return forward(model=model, input_ids=ids, attention_mask=attn_mask, batch_size=batch_size), ids    else:        del locs, test_ids        logits = forward(model=model, input_ids=ids,                         attention_mask=attn_mask, batch_size=batch_size)        del ids        gc.collect()        return logits def forward(*, model, input_ids, attention_mask, batch_size=512):    logits = []    for i in range(0, input_ids.shape[0], batch_size):        batch_input_ids = input_ids[i:i+batch_size]        if attention_mask is not None:            batch_attention_mask = attention_mask[i:i+batch_size]        else:            batch_attention_mask = None        logits.append(model(input_ids=batch_input_ids,                      attention_mask=batch_attention_mask).logits)        gc.collect()        del batch_input_ids, batch_attention_mask    return torch.cat(logits, dim=0) def target_loss(logits, ids, target_slice):    crit = nn.CrossEntropyLoss(reduction='none')    loss_slice = slice(target_slice.start-1, target_slice.stop-1)    loss = crit(logits[:, loss_slice, :].transpose(1, 2), ids[:, target_slice])    return loss.mean(dim=-1) model = AutoModelForCausalLM.from_pretrained(    'roneneldan/TinyStories-33M',    torch_dtype=torch.float16,    trust_remote_code=True, ).to(device).eval() tokenizer = AutoTokenizer.from_pretrained(    "EleutherAI/gpt-neo-125M", use_fast=False) def is_success(prompt):    input_ids = tokenizer.encode(prompt, return_tensors="pt")    output = model.generate(input_ids.to(        device), max_new_tokens=50, num_beams=1, temperature=0)    output = output[:, len(input_ids[0]):]    output_text = tokenizer.decode(output[0], skip_special_tokens=True)    print(output_text)    if output_text.lower().find(target.lower()) != -1:        return True    return False plotlosses = PlotLosses() adv_slice = slice(0, len(tokenizer.encode(    adv_string_init, add_special_tokens=False))) target_slice = slice(adv_slice.stop, adv_slice.stop +                     len(tokenizer.encode(target, add_special_tokens=False))) loss_slice = slice(target_slice.start-1, target_slice.stop-1) best_new_adv_prefix = '' for i in range(num_steps):    input_ids = tokenizer.encode(        adv_prefix+target, add_special_tokens=False, return_tensors='pt').squeeze()    input_ids = input_ids.to(device)    coordinate_grad = token_gradients(model,                                      input_ids,                                      adv_slice,                                      target_slice,                                      loss_slice)    with torch.no_grad():        adv_prefix_tokens = input_ids[adv_slice].to(device)        new_adv_prefix_toks = sample_control(adv_prefix_tokens,                                             coordinate_grad,                                             batch_size)        new_adv_prefix = get_filtered_cands(tokenizer,                                            new_adv_prefix_toks,                                            filter_cand=True,                                            curr_control=adv_prefix)        logits, ids = get_logits(model=model,                                 tokenizer=tokenizer,                                 input_ids=input_ids,                                 control_slice=adv_slice,                                 test_controls=new_adv_prefix,                                 return_ids=True,                                 batch_size=batch_size)  # decrease this number if you run into OOM.        losses = target_loss(logits, ids, target_slice)        best_new_adv_prefix_id = losses.argmin()        best_new_adv_prefix = new_adv_prefix[best_new_adv_prefix_id]        current_loss = losses[best_new_adv_prefix_id]        adv_prefix = best_new_adv_prefix    # Create a dynamic plot for the loss.    plotlosses.update({'Loss': current_loss.detach().cpu().numpy()})    plotlosses.send()    print(f"Current Prefix:{best_new_adv_prefix}", end='\r')    if is_success(best_new_adv_prefix):        break    del coordinate_grad, adv_prefix_tokens    gc.collect()    torch.cuda.empty_cache() if is_success(best_new_adv_prefix):    print("SUCCESS:", best_new_adv_prefix) 脚本的核心思想是：先初始化一段无意义前缀，例如一串感叹号，然后不断修改这段前缀中的 token，使模型在看到这段前缀后，更倾向于把 hackergame 作为后续文本生成出来，也就是说，优化阶段并不是直接让模型自由生成，而是把输入构造成： adv_prefix + hackergame 然后计算模型在当前 adv_prefix 条件下预测 hackergame 的 loss，并且将loss值降低 GCG 的关键在于，它不是随机乱试前缀，而是利用梯度来指导 token 替换 脚本会把可控前缀中的每个 token 转成 one-hot 表示，再通过模型的 embedding 矩阵映射成连续向量。虽然 token 本身是离散的，但 embedding 空间是连续 的，因此可以计算目标 loss 对这些 one-hot 位置的梯度 梯度告诉我们：如果想让 loss 下降，当前位置更应该替换成哪些 token 接下来，脚本会为每个位置选出若干个梯度方向上更有希望的候选 token，并构造出一批候选前缀 每个候选前缀通常只和当前前缀相差一个 token，然后脚本批量评估这些候选前缀对应的目标 loss，选择 loss 最低的那个作为新的前缀 这个过程会不断重复： 直到模型在只看到 adv_prefix 的情况下，能够自动续写出 hackergame，脚本就认为攻击成功 2.2 本地部署GCG https://github.com/llm-attacks/llm-attacks可以在本地进行gcg攻击过程的一个复现，前期环境安装的命令就不提了，这里提一个模型的问题 # pip install "fschat[model_worker]" python -c " from huggingface_hub import snapshot_download snapshot_download('lmsys/vicuna-7b-v1.5', local_dir='/data/models/vicuna-7b-v1.5') " # python -c " from huggingface_hub import snapshot_download snapshot_download('meta-llama/Llama-2-7b-chat-hf',                  local_dir='/data/models/llama-2-7b-chat-hf',                  token='YOUR_HF_TOKEN') " 第一种是下载Vicuna-7B模型，这种模型最轻量，复现最快 第二种是LLaMA-2-7B-Chat，也是论文中的主要目标，但是LLaMA-2 需要先在 HuggingFace 申请访问权限，获取 token 启动命令 CUDA_VISIBLE_DEVICES=0 python -u ../main.py \    --config="../configs/individual_vicuna.py" \    --config.attack=gcg \    --config.train_data="../../data/advbench/harmful_behaviors.csv" \    --config.result_prefix="../results/test_run" \    --config.n_train_data=2 \    --config.data_offset=0 \    --config.n_steps=10 \    --config.test_steps=5 \    --config.batch_size=512 可以看到最终的结果在终端中，随着迭代步数（n_steps）的推进，有几个现象印证了 GCG 算法原理： 在每一轮迭代中，终端都会实时打印出当前的 Loss 值。正如前文所述，损失函数在这里充当了扣分器 在针对目标任务，例如诱导模型输出恶意漏洞脚本的第 0 步，初始的感叹号后缀（! ! !...）产生的 Loss 值通常较高，这说明在没有任何有效干预时，模型原始状态强烈倾向于执行安全拒答 但随着梯度优化的进行，Loss 值会肉眼可见地逐步缩小，这意味着算法找到了让损失下降最多的替换方案，当前生成的对抗后缀正在把模型的输出概率一步步推向设定的目标方向 且在不断迭代的过程中，最初的占位符，比如感叹号会被诸如 avec、payload、compact 等看似毫不相干的词汇或零碎符号逐渐替换 这个过程直观地展示了算法如何利用梯度信息，在离散 token 空间中进行贪心搜索 它根本不在意这些词汇组合在人类读起来是否通顺，它只在乎把某个位置换成哪个 token，最容易让输出朝目标方向偏移 也就是说，大模型的安全边界可能不是一个稳定的语义规则边界，而是一个可以被算法自动搜索和逼近的概率边界 这段对抗样本对人眼来说毫无逻辑，但在模型内部的连续 Embedding 空间中，它却构成了最致命的有效扰动 当跑完设定的步数后，如果 Loss 降到了足够低的阈值，模型就会彻底突破原本的安全对齐限制，顺着后缀，将原本应该拒绝的恶意内容直接生成出来 这里我只实验了10步，做了一个测试而已，所以最终结果 (Step 10): 攻击失败 (Passed 0/1) 归根到底还是因为步数太少，算法没能找到有效的破解后缀，模型依然坚守底线，回答：I'm sorry, but I cannot provide a strategy for hacking... 所以可以把n_steps设置为500，可能会有更好的效果

1、Pwn2OwnBerlin2026因报名爆满遭拒黑客集体公开0Day漏洞 https://www.freebuf.com/articles/ai-security/480925.html 全球最著名的黑客竞赛正面临始料未及的危机。据报告，由趋势科技旗下Zero Day Initiative（ZDI）主办的Pwn2Own Berlin 2026赛事在举办19年来首次出现名额爆满情况。这项实时挖掘0Day漏洞的专家竞赛，实际可容纳的黑客数量已达到硬性上限。被拒之门外的数十名研究者正发起被称为"报复性披露"的行动。xchglabs团队本准备了86个针对NVIDIA、Docker、Linux KVM和PyTorch等系统的漏洞，在无缘角逐100万美元奖金池后，他们选择直接 2、Windows 11遭新型BitUnlocker降级攻击：5分钟内可解密加密磁盘 https://www.freebuf.com/articles/system/480862.html 一款名为BitUnlocker的新工具曝光了针对微软BitLocker加密的降级攻击手法。攻击者通过利用补丁更新与证书吊销之间的关键时间差，可在5分钟内物理破解已打补丁的Windows 11设备上的加密卷。该攻击源于微软安全测试与攻防研究团队（STORM）发现的四个关键0Day漏洞之一（CVE-2025-48804），已于2025年7月补丁星期二修复。 3、可远程获取Shell的Android零点击漏洞PoC利用代码公开 https://www.freebuf.com/articles/480859.html 谷歌在2026年5月的Android安全公告中披露了一个潜藏在Android系统核心的灾难性零点击漏洞，这对移动安全领域造成了严重冲击。编号为CVE-2026-0073的漏洞存在于Android的adbd守护进程中，允许附近的威胁行为者在无需用户交互的情况下远程获取完整Shell访问权限。 4、cPanel与WHM发布三个新漏洞修复补丁—请立即更新 https://thehackernews.com/2026/05/cpanel-whm-patch-3-new-vulnerabilities.html cPanel修复三个高危漏洞（CVE-2026-29201/2/3），涉及权限提升、代码执行和拒绝服务，建议用户立即升级至指定版本。漏洞可能被武器化，需紧急修补以防攻击。 5、TrickMo安卓木马借助TON隐藏通信 https://www.threatfabric.com/blogs/new-trickmo-variant-device-take-over-malware-targeting-banking-fintech-wallet-auth-app ThreatFabric发现TrickMo安卓银行木马出现新变种“Trickmo.C”，自今年1月起持续被跟踪。该恶意软件伪装成TikTok或流媒体应用，主要针对法国、意大利和奥地利用户的网银账户及加密货币钱包。其最新变化是将The Open Network（TON）用于隐蔽的命令与控制通信，通过设备内嵌的本地TON代理和.adnl地址与操作者连接，借 6、CheckmarxJenkins插件遭投毒发布窃密版本 https://checkmarx.com/blog/ongoing-security-updates/ Checkmarx披露，其官方Jenkins AST插件在Jenkins Marketplace上曾被发布恶意篡改版本，版本号为2026.5.09。该事件被认为与TeamPCP黑客组织有关，攻击者据称利用此前在Trivy供应链攻击中窃取的凭证进入Checkmarx的GitHub环境，并向部分制品发布恶意代码。这是该公司自3月底以来遭遇的第三起相关供应链事件。Checkmarx表示，恶意版本并未经过正常发布流程，且缺少对应git标签和GitHub Release，建议用户仅使用2025年1 7、GhostLock利用Windows文件API锁定访问 https://zenodo.org/records/20070064 安全研究员Kim Dvash发布了名为GhostLock的概念验证工具，展示攻击者如何滥用Windows合法文件接口CreateFileW及其共享模式参数，阻止本地或SMB网络共享中的文件被其他用户和应用打开。其核心做法是将dwShareMode设为0，以独占方式打开文件，在句柄持续存在期间触发“共享冲突”错误，从而造成访问中断。该工具可递归锁定SMB共享中的大量文件，且普通域用户无需提权即可实施。如果攻击者从多台受控设备同时发起并持续重新获取句柄，影响会进一步扩大。研究人员指出，这更接近干扰性拒绝服务攻击而非勒索破坏； 8、Linux内核维护者提议引入"紧急禁用开关"应对0Day漏洞空窗期 https://www.freebuf.com/articles/system/480774.html Linux 服务器管理员或将获得在操作系统内核中临时禁用漏洞功能的能力——前提是开源社区采纳内核开发者提出的这项建议。该机制可在 0Day 漏洞补丁发布前作为临时防护措施。 9、美国头部车企通用汽车因违规出售用户数据被罚近9000万 https://www.secrss.com/articles/90184 通用汽车因未经用户同意，收集存储驾驶数据并出售给数据经纪商，因此获利约1.36亿元，数十万美国公民的隐私权益受损，因此被罚近9000万元，为加州消费者隐私法案生效以来的最大罚单。 10、Hugging Face惊现供应链投毒：仿冒OpenAI仓库窃取开发者敏感数据 https://www.secrss.com/articles/90164 2026年5月7日，安全研究机构 HiddenLayer 披露了一起针对 AI 开发社区的供应链投毒攻击事件。攻击者在 Hugging Face 平台创建恶意仓库 Open-OSS/privacy-filter，通过 typosquatting 技术冒充 OpenAI 官方 "Privacy Filter" 项目，成功进入平台趋势榜榜首位置。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

漏洞概述 2026年5月7日，安全研究领域迎来了一次重大的震荡，安全研究员 Hyunwoo Kim 披露了一种名为 "Dirty Frag" 的新型 Linux 内核本地权限提升（LPE）漏洞。该漏洞属于纯逻辑型缺陷，其破坏力极大，允许任何非特权本地用户在几乎所有主流 Linux 发行版上实现稳定、无需竞态条件的 Root 权限提升。 Dirty Frag 漏洞并非单一的代码疏漏，而是由内核网络协议栈中两个独立子系统的历史遗留架构问题串联而成：分别存在于 xfrm-ESP（自2017年引入）与 RxRPC（自2023年引入）子系统中的原地解密（In-place Decryption）逻辑缺陷。该漏洞与此前轰动业界的 "Copy Fail" (CVE-2026-31431) 和著名的 "Dirty Pipe" (CVE-2022-0847) 属于同一漏洞家族，均利用了 Linux 内核在零拷贝（Zero-Copy）路径（如 splice()、sendfile() 或使用 MSG_SPLICE_PAGES 标志）上对页缓存（Pa 漏洞原理分析 Linux 页缓存 (Page Cache) 机制的信任模型 Linux 操作系统采用页缓存机制来大幅加速文件系统的读写操作。当用户态进程读取磁盘上的文件时，内核会将文件内容加载到物理内存的“页”（通常为 4KB 大小）中，这些被缓存的物理页即为页缓存。如果多个进程读取同一个文件，它们将透明地共享同一块物理内存中的页缓存，从而极大地节省了系统内存开销并提升了并发读取效率。 在正常的权限控制与内存保护模型下，如果一个非特权进程以只读模式（Read-Only）打开文件，它只能读取这些页缓存，绝对无法进行修改。任何修改意图都必须通过内核的写时复制（Copy-On-Write, COW）机制进行处理：当内核检测到写入操作时，会为进程分配一个私有的内存页副本，所有的修改均在副本上进行，从而保护了原始页缓存的纯洁性和底层磁盘文件的完整性。Dirty Frag 漏洞的本质，正是攻击者找到了一条未被严密监控的“捷径”，绕过了写时复制机制，直接向驻留在内存中的只读文件页缓存中非法写入了恶意指令数据。 零拷贝技术、非线性数据包与 MSG_SPLICE_PAGES 为了满足万兆甚至更高速率网络的数据传输需求，减少用户态与内核态之间不必要的上下文切换，Linux 引入了 splice() 和 sendfile() 等零拷贝系统调用。零拷贝的核心理念是避免数据在“用户态缓冲区”和“内核态缓冲区”之间进行消耗 CPU 周期的无意义拷贝。 在网络传输层，内核使用 sk_buff（Socket Buffer）结构体来管理网络数据包。传统的 sk_buff 包含一个连续的数据区域（即线性区）。而在零拷贝路径中，内核会生成非线性的 sk_buff：即 sk_buff 的 frag 数组（片段数组）并不包含实际的数据内存拷贝，而是直接存储指向页缓存中现有物理页的指针或引用。 当应用程序通过 splice() 系统调用将一个文件发送到网络套接字，且在底层路径中使用了 MSG_SPLICE_PAGES 标志时，内核会将该文件的页缓存直接挂载到 sk_buff 的 frag 结构中。此时，这些物理页的“所有权（Ownership）”实际上并不属于网络协议栈，而是属于底层的文件系统或匿名内存映射。网络协议栈在处理这些引用的 sk_buff 时，应当严格将其视为“只读”数据，或在必须修改时显式调用 COW 机制创建私有副本。 密码学子系统的原地操作 (In-place Operation) 优化困境 在处理复杂的网络协议栈（如 IPsec 隧道或加密 RPC 调用）时，数据包的加密与解密是高度计算密集型的任务。为了追求极致的吞吐量和最低的延迟，内核网络开发者倾向于使用原地操作（In-place Operation）来进行密码学运算。原地操作意味着密码引擎直接在密文所在的原始内存地址上进行解密计算，并将生成的明文直接覆盖在原本的密文之上，从而彻底免除了分配新内存和进行数据拷贝的开销。 然而，原地操作的绝对前提是：内核必须在运算前百分之百地确保当前操作的内存区域是私有的且完全可写的。如果当前的 sk_buff 是非线性的，且其内部的 frag 指向的是外部拥有的页缓存（例如通过 splice 系统调用挂载的、其他进程正在使用的只读文件页），此时直接进行原地解密，就会导致解密后的数据（或被攻击者刻意构造的伪造密文）被内核自身强制写入到不该被修改的系统页缓存中。这种架构层面的假设失配，构成了整个漏洞利用链条中最核心的突破口。 漏洞家族的演进图谱：从 Dirty Pipe 到 Dirty Frag 分析 Dirty Frag 无法脱离其在安全发展史中的演进脉络。此类“页缓存污染（Page Cache Poisoning/Write）”漏洞已经形成了一个具有明显家族特征的攻击面，暴露出 Linux 内核在处理文件缓存与 I/O 缓冲区融合时的系统性脆弱。 Dirty Frag 与 Copy Fail 共享了完全相同的底层漏洞模型（Sink）和攻击原语，但 Dirty Frag 彻底摆脱了对 algif_aead 密码学模块的依赖 。这意味着，即使系统管理员在之前应对 Copy Fail 漏洞时已经通过黑名单禁用了 algif_aead 模块，系统依然完全暴露在 Dirty Frag 的威胁之下。 Dirty Frag 是一个高度复杂的复合型逻辑漏洞，它巧妙地利用了内核在处理 UDP 封装（UDP Encapsulation）和特定加密网络传输协议时的状态机缺陷。具体而言，该漏洞是由两个相互独立但原理高度一致的子缺陷构成的，攻击者只要能够触及其中任意一条代码路径，即可实现完整的权限提升。 xfrm-ESP 子系统缺陷分析 (Page-Cache Write) xfrm 是 Linux 内核中负责实现 IPsec（IP 安全架构）的基础框架，而 ESP（Encapsulating Security Payload）是 IPsec 协议族中的核心组件，用于为网络层数据提供机密性、数据源验证和抗重放攻击保护。 自 2017 年 1 月提交的内核补丁 cac2661c53f3 开始，ESP 子系统的代码在处理接收到的网络数据包时，为了提升 UDP 封装下 ESP 数据包的处理性能，引入了一个致命的逻辑缺陷。在常规的、负责任的安全协议栈处理流程中，函数 skb_cow_data() 被强制调用，用来仔细检查 sk_buff 是否包含共享的或由外部持有的只读引用页（如通过 splice 挂载的页缓存）。如果发现存在此类引用，该函数会强制执行写时复制（COW），将数据拷贝到安全的私有内存中，以确保后续的解密覆写操作不会越界破坏系统状态。 然而，在 ESP-in-UDP 的无写时复制快速路径（no-COW fast path）中，内核代码的处理逻辑出现了偏差。esp_input 函数在某些特定的套接字状态下，错误地绕过了对 skb_cow_data() 的调用，并直接指令 crypto_authenc_esn_decrypt 函数在原始的 sk_buff 片段（frag）上执行极其危险的原地解密操作。 在一条经典的攻击路径中：攻击者首先通过 AF_INET6 等协议族建立一个配置了 UDP 封装特性的 IPsec 套接字。随后，攻击者调用 splice()，将一个高权限的 SUID 二进制文件（如 /usr/bin/su 或 /usr/bin/sudo）的只读页缓存直接拼接到该套接字的发送队列中，从而构造出一个带有 MSG_SPLICE_PAGES 标志、其片段指针直接指向目标文件页缓存的非线性数据包。当该数据包被发送并经由本地环回接口（Loopback）或底层路由重新进入接收端的快速路径时，ESP 解密例程盲目地假定当前 sk_buff 的认证标签区域（Tag area）和数据负载区域均是 RxRPC 子系统缺陷分析 (Page-Cache Write) 与 ESP 漏洞的成因如出一辙，第二个构成 Dirty Frag 的子漏洞隐藏在 AF_RXRPC 协议栈的深处。RxRPC 是一种专门为 Andrew File System (AFS) 及其相关分布式计算服务设计的远程过程调用（RPC）网络传输层协议。 自 2023 年 6 月的内核提交 2dc334f1a63a 引入以来，RxRPC 子系统中的 rxkad_verify_packet_1 函数便潜伏着一个类似的页缓存写入缺陷。在对接收到的 RxRPC 数据包进行完整性验证与解密时，该函数会调用 pcbc(fcrypt) 加密算法，对数据包执行高效率的原地单块解密（in-place single-block decrypt）。 如果攻击者针对该协议栈发起攻击，将一个受其完全控制且由 splice 系统调用映射的只读文件页缓存强行投递到 RxRPC 的接收处理链条中，解密引擎同样会绕过至关重要的 COW 机制，以不可阻挡的态势，强行在这些本不属于网络栈的外部物理页上覆盖解密后的字节流 。 漏洞逻辑的绝对稳定性：摆脱竞态条件的限制 在操作系统内核漏洞的利用历史中，类似于 Dirty COW（CVE-2016-5195）这样的经典提权漏洞，往往高度依赖于极为苛刻的精确时间窗口来引发竞态条件（Race Condition）。这种依赖性导致漏洞利用在不同 CPU 架构、系统负载或内核版本下的成功率波动极大，甚至频繁导致内核崩溃（Kernel Panic）。 相比之下，Dirty Frag 被安全界定义为一个异常纯粹的“确定性逻辑漏洞”（Deterministic Logic Bug）。在 Dirty Frag 的利用流程中，内存映射的创建、数据包的构造、套接字的发送与接收、以及最终解密函数的调用，其生命周期和执行流是严格确定且串行的。只要攻击者成功触发了带有 MSG_SPLICE_PAGES 标志的快速路径，并迫使内核调用对应的原地加密接口，数据覆写的动作就必定发生。这种冷酷的确定性赋予了该漏洞无与伦比的极高稳定性——其利用成功率在大多数环境下接近 100%，且几乎不会留下导致系统崩溃的内存破坏痕迹。这种特性使得 Dirty Frag 在实战环境 漏洞影响范围 Dirty Frag 漏洞的影响深度和覆盖广度在近年来的内核安全事件中实属罕见。它不仅横跨了长达近 9 年的 Linux 内核发布周期，波及了几乎所有已知的主流企业级操作系统，更对当前依赖内核隔离的云原生架构和多租户商业模式提出了根本性的挑战。 受影响版本与组件图谱 漏洞在内核代码树中的生存周期极长。公开的分析表明： xfrm-ESP 页缓存污染缺陷： 自内核补丁提交 cac2661c53f3（2017 年 1 月）起，便已潜伏在代码中，这意味着近九年来发布的所有包含 IPsec 组件的内核均在其威胁笼罩之下 17。 RxRPC 页缓存污染缺陷： 自内核补丁提交 2dc334f1a63a（2023 年 6 月）引入，持续影响后续的所有上游内核版本 17。 下表详细汇总了已知受该漏洞直接影响的主流操作系统发行版： 令人极其忧虑的是，在漏洞曝光初期，即便是最新的主线 Linux 内核版本（例如 7.0.3-1 甚至刚发布的 7.0.4 候选版本）同样处于未修补状态，这意味着整个开源生态在一段时间内处于完全的“裸奔”状态。 Dirty Frag 的高危性不仅仅体现在桌面端或传统服务器上，其真正的灾难性影响在于其能够轻易瓦解现代云计算环境中的复杂隔离架构。 多租户共享主机架构的崩溃 在由 CloudLinux 等技术构建的共享主机（Web Hosting）环境中，成百上千个不相关的网站租户或小型企业共享同一个底层 Linux 内核以降低成本。Dirty Frag 允许一个仅拥有极低权限（如受限的 PHP 执行权限或 jailed shell）的恶意租户，通过运行一个简单的 Python 或 C 脚本，瞬间提权为 Root。一旦获取 Root 权限，攻击者即可肆意穿透隔离沙箱，直接访问、篡改或窃取同一物理节点上其他所有租户的数据库凭证、商业机密及用户隐私数据。 Kubernetes 集群的容器逃逸与横向接管 云原生 Kubernetes (K8s) 环境面临着同等级别的风险。如果集群中的工作负载（Pods）未配置极为严格的无特权沙箱机制（例如未通过 Sysctl 显式禁用 unprivileged_userns），攻击者在利用 Web 漏洞攻陷一个看似受限的普通业务容器后，可以利用 Dirty Frag 漏洞执行跨边界打击。由于页缓存机制在宿主机操作系统层面是全局共享的，攻击者能够在容器内部直接修改宿主机底层的基础二进制文件（如 /bin/bash 或 runc）。当宿主机的合法管理员或其他进程调用这些已被注入木马的文件时，攻击者便实现了从容器到宿主 CI/CD 流水线构建环境的风险 在诸如 GitHub Actions、GitLab CI、Jenkins 等持续集成与持续部署（CI/CD）环境中，平台需要频繁运行由外部开发者提交的、潜在不受信任的代码以进行编译和测试。恶意行为者可以通过提交经过伪装的恶意 Pull Request，在构建流水线的 Runner 节点中静默利用 Dirty Frag 提权。由于该漏洞无竞态、不导致崩溃，此类攻击极难被传统的异常检测机制捕获。提权成功后，攻击者可轻易窃取整个代码仓库的环境变量、生产环境的 API 密钥、代码签名证书及底层云基础设施的访问凭证，从而实施极具破坏性的供应链攻击。 漏洞复现 攻击构造分析 Dirty Frag 所提供的核心攻击原语是：有限但高度可控的任意页缓存写入能力（Controlled Arbitrary Write to Page Cache）。受限于内核加密模块内部固定结构和处理块大小的逻辑约束，攻击者或许无法在一次系统调用中写入数兆字节的连续数据。然而，在现代操作系统的二进制执行机制下，这种限制已无关紧要。攻击者只需精确计算偏移量，覆盖关键系统组件（如具有 SUID 标志的 /usr/bin/su、/usr/bin/passwd 二进制文件，或是核心动态链接库 libc.so）中的短短数个关键字节（例如 4 字节的跳转指令覆盖），便足以兵不血刃地彻底改变整个程序的执行 PoC 阶段性执行链路 阶段 1：环境评估与目标劫持锁定 攻击程序首先探测当前系统的架构与内核特性，并选择一个系统中广泛存在且具有 SUID 标志（允许程序以文件所有者即 root 权限运行）的目标文件（如 /usr/bin/su）。程序以普通的只读模式（O_RDONLY）安全打开该文件，并使用内存映射（mmap）技术或直接读取操作，精准定位需要被替换的目标机器指令的内存偏移量。 阶段 2：构建管道与映射 Splice 缓冲区 攻击程序在内存中实例化一个标准的 UNIX 管道（Pipe）。随后，调用 splice() 系统调用，指明将目标文件（/usr/bin/su）的对应文件描述符单向映射到该管道的输入端。在此关键步骤中，内核为追求效率，绝对不会复制任何底层文件数据，而是仅仅将指向该文件物理页缓存的内存管理指针装载到管道内核结构的环形缓冲区（Ring Buffer）内。 阶段 3：特殊套接字初始化与协议栈注入准备 攻击程序进而请求内核分配一个特定的网络套接字。在利用 ESP 漏洞分支的情况下，程序会实例化一个针对 UDP 封装模式的 AF_INET6（或 AF_INET）套接字，并隐蔽地配置相应的 IPsec 策略路由；若采取利用 RxRPC 分支的策略，则会直接创建一个 AF_RXRPC 类型的套接字体系 。 阶段 4：触发 MSG_SPLICE_PAGES 与致命的原地修改 此阶段是整个漏洞链的核心。攻击者使用支持零拷贝的高级网络发送函数（如 sendmsg），明确携带 MSG_SPLICE_PAGES 标志，将之前填充好的管道内容推送至底层的网络协议栈。内核网络子系统顺理成章地将这些源自管道的物理页引用，直接封装进网络数据包 sk_buff 结构的非线性片段数组（frag）中。 随后，当数据流经底层网络栈并进入接收端的数据处理逻辑时，esp_input 或 rxkad_verify_packet_1 函数拦截到了这些数据包。进入密码学处理阶段时，由于缺乏对内存所有权的边界感知，密码学引擎将攻击者在用户态预先控制的“伪造密文”或“状态参数”，通过原地解密（In-place Decryption）机制，直接、暴力地覆写到了那块原本被标记为只读的、属于目标二进制文件的页缓存上。 阶段 5：执行流篡改与权限接管 底层内存覆写瞬间完成。攻击程序随即调用常规的 execve() 系统调用，请求操作系统运行那个看似正常的 /usr/bin/su 文件 16。当内核加载该二进制文件并为其分配执行空间时，由于 Linux 的缓存机制，它直接命中了已经驻留在内存中并被严重污染的页缓存。原本用于执行密码验证逻辑的核心指令，在 CPU 执行时已被偷梁换柱为攻击者注入的反弹 Shell（Reverse Shell）指令或专门的提权 Shellcode。操作系统忠实地执行了这些最高权限指令，随之将一个具有完全 Root 权限的交互式终端拱手让给了底层的攻击者。 漏洞修复 鉴于 Dirty Frag 漏洞属于未经协调即被强制公开的严重 0-day 事件，全球 Linux 基金会、各大商业操作系统供应商以及网络安全机构在极短时间内启动了最高级别的联合应急响应。 官方内核源码修复方案分析 ESP 漏洞修补逻辑 (xfrm-ESP) 针对影响深远的 xfrm-ESP 子系统，Linux 上游的 netdev 代码树在紧急响应后合并了修复补丁，对应的代码提交 ID 为 f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4。 该修复方案的核心技术思路是：在协议栈深处彻底撤销不安全的内存就地操作假设，强制要求系统在网络层进入加密或解密例程之前，必须对非私有属性的内存页执行严格的写时复制（COW）或进行深度的内存所有权校验。补丁通过修改底层结构，确保了在调用 crypto_authenc_esn_decrypt 等需要高频修改数据缓冲区的密码学函数时，目标 s RxRPC 漏洞修补逻辑 (AF_RXRPC) 针对第二个漏洞分支 RxRPC，相应的修复补丁已被提交至 Linux 内核邮件列表（LKML）进行严谨审查，其对应的技术讨论追踪标识为 afKV2zGR6rrelPC7@v4bel。该补丁全面重构了 rxkad_verify_packet_1 函数的缓冲区遍历与数据提取逻辑，从架构层面明令禁止密码学引擎在由外部传入的、属性未知的不可变页上直接启动 pcbc(fcrypt) 算法的单块解密运算。 各大主流企业级发行版（如 Ubuntu, AlmaLinux, RHEL, Debian）的系统工程师团队正加紧拉取上述上游补丁，并进行繁杂的向后移植（Backport）工作，以将其集成至各自维护的 LTS（长期支持）内核版本中。例如，注重安全响应的 AlmaLinux 已率先在 kernel-6.12.0-124.55.2.el10_1 等测试仓库版本的内核中集成了完整的防御修复。 生产环境应急响应与临时缓解策略 考虑到在复杂的企业数据中心和云基础设施中，大规模的内核升级和系统全局重启往往需要数周的调度窗口，安全响应团队必须在官方稳定版补丁部署前，立即实施非破坏性的临时缓解方案。 1. 阻断攻击路径：禁用受影响的内核模块 (Module Blacklisting) 由于漏洞的触发与利用过程严重依赖于特定底层网络协议栈模块的支撑，当前最直接、最快速且行之有效的缓解措施是阻止 esp4, esp6 和 rxrpc 这三个模块被内核守护进程动态加载至内存中。系统管理员可通过在系统的模块配置文件中写入虚拟的黑名单指令来实现拦截： # 写入黑名单防护配置，并尝试强制卸载当前可能已加载的脆弱模块   sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true" 执行上述防护命令后，攻击者在用户态试图使用的恶意 PoC 将因无法请求创建相关的底层网络套接字结构而直接报错退出，原本畅通无阻的漏洞利用链条被硬性切断。此操作具备极高的实施效率（通常耗时不超过 10 秒），且全程无需重启系统服务。当后续应用了官方内核更新后，仅需删除 /etc/modprobe.d/dirtyfrag.conf 文件即可恢复系统原状。 黑名单策略的局限性与兼容性风险评估： 需要强调的是，禁用 esp4 和 esp6 模块将直接导致所有高度依赖内核数据路径的 IPsec 安全隧道（如通过 strongSwan 或 Libreswan 配置的企业级 VPN 节点）陷入瘫痪。同理，禁用 rxrpc 模块将导致那些依赖于 Andrew File System (AFS) 协议的分布式服务无法通信。然而，对于未开启此类隧道的绝大多数通用 Web 业务服务器、数据库集群或微服务节点而言，此方案是完全安全的（它不会对依赖其他机制的隧道协议如 Tailscale, WireGuard, OpenVPN 造成任何负面影响）。 在 AlmaLinux 等特定发行版中，rxrpc 模块可能仅通过特定的 kernel-modules-partner 扩展包提供，此时更彻底的解决方案是直接使用包管理器将其移除： sudo dnf remove kernel-modules-partner 这能有效削减不必要的内核攻击面。 2. 消除既有威胁：清除被污染的页缓存 (Cache Eviction) 鉴于 Copy Fail 和 Dirty Frag 这类漏洞的特殊机制，它们仅仅修改了驻留在系统动态内存中的页缓存数据，由于巧妙避开了写回触发机制，并未将相应的物理页标记为“脏页”（Dirty，即需要被操作系统写回持久化存储的标志），因此底层磁盘上文件的真实物理内容往往并未受损。 然而，这引发了一个更隐蔽的风险：如果在安全人员介入、模块被禁用或网络阻断之前，系统就已经遭受了隐秘攻击，那么那些被植入了恶意逻辑的指令页可能依然潜伏在活跃的内存缓存中。因此，在实施任何访问控制后，必须通过内核接口强制系统清空缓存，迫使内核抛弃内存中的可疑数据，并在下一次文件访问时从安全的底层磁盘重新读取纯净的二进制数据块： # 强制内核清空页缓存、目录项 (dentries) 和 inode 缓存   sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches 清除缓存前依然可以成功： 清除缓存后失败： 将模块强制隔离与系统级缓存清理紧密结合，可以在缺乏官方有效内核补丁的高危时间窗口内，最大程度地夺回系统控制权并保障核心业务的安全运行。 云环境防御 内核热补丁技术 (Livepatching)： 包括 CloudLinux 在内的主流企业级云服务提供商，通过其 KernelCare 等基础设施提供了非颠覆性的热补丁更新方案。这类技术允许运维团队在不中断当前运行进程、不牺牲系统高可用性（SLA）的前提下，将针对 Dirty Frag 的 CVE 修复逻辑直接动态注入到运行中的内核内存空间中，实现了对漏洞的瞬时无感阻断。 非特权用户命名空间限制 (User Namespaces Restriction)： 对于无需运行 rootless 容器的普通业务系统，通过系统参数限制无特权用户的命名空间创建权限（如执行 echo 1 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns），能够在极大程度上收缩内核的复杂攻击面，阻断此类需要复杂环境构造的提权路径。 基于 eBPF 的无侵入式行为监控引擎： 针对该漏洞高度特征化的攻击行为，防御平台可编写并下发 eBPF（Extended Berkeley Packet Filter）探针，深入内核关键路径，实时监控程序调用 splice() 且目的端句柄指向 AF_INET6（配置为 UDP 封装状态）或 AF_RXRPC 协议等异常行为进程链。通过在运行时设置基于多维时序特征的异常序列检测模型，安全平台可以在漏洞真正触发文件覆写的前置阶段，提前捕获微小的异常状态并精准阻断恶意进程的执行。

1、黑客借谷歌广告和Claude聊天传播Mac恶意软件 https://www.linkedin.com/posts/brkalbyrk7_macsync-ugcPost-7459229553027088384-7UXy/ 研究人员发现攻击者正在利用谷歌搜索广告和Claude.ai共享聊天功能，向Mac用户投递恶意软件。用户搜索“Claude mac download”时，可能看到指向真实claude.ai域名的赞助结果，但进入后会遇到伪装成“Apple Support”发布的安装指导，诱导其在终端粘贴命令。研究人员发现，不同共享聊天页面虽使用独立基础设施与载荷，但社会工程话术高度一致。相关脚本可在内存中运行，并通过多态投递规避基于哈希的检测；部 2、黑客诱骗DigiCert签发恶意软件签名证书 https://hackread.com/hackers-digicert-issue-certificates-sign-malware/ DigiCert在发现证书被滥用于恶意软件签名后，已撤销60张代码签名证书。事件起因是攻击者通过恶意支持聊天附件实施欺骗，诱使相关流程签发可用于代码签名的证书，随后这些证书被用于为Zhong Stealer恶意软件进行签名。代码签名证书通常用于验证软件来源和完整性，一旦被攻击者获取并用于恶意程序，可能提升恶意样本的伪装性与可信度，从而增加传播和绕过安全检测的风险。此次事件反映出证书签发与支持流程可能成为攻击目标，也提示企业需要加强审核、附件处理和证书滥 3、虚假通话记录应用在Play商店窃取用户付款信息 https://www.welivesecurity.com/en/eset-research/fake-call-logs-real-payments-how-callphantom-tricks-android-users/ 网络安全研究人员在官方的Google Play安卓应用商店中发现了欺诈性应用程序，这些应用程序谎称可以访问任何电话号码的通话记录，但实际上却是诱骗用户加入订阅服务，而这些订阅服务提供的却是虚假数据，最终导致用户遭受经济损失。这28款应用在被官方应用商店下架前，累计下载量超过730万次，其中一款应用的下载量就超过300万次。这项由斯洛伐克网络安全公司ESET代号为“C 4、两名美国男子因协助朝鲜黑客渗透美企获刑 https://hackread.com/us-men-sentenced-north-korean-hackers-hack-us-firms/ Matthew Knoot和Erick Prince因协助朝鲜黑客渗透美国企业，被分别判处18个月监禁。报道指出，两人通过搭建和运营“远程笔记本电脑农场”的方式，为相关人员提供进入美国公司网络环境的条件，从而帮助其隐藏真实身份并实施渗透活动。此案反映出，利用本地设备和远程接入手段掩饰来源、规避审查，已成为针对企业渗透行动中的重要辅助模式。案件结果也显示，美国司法部门正持续打击为朝鲜黑客活动提供支持的个人与网络基础设施。 5、德国警方再度打掉Crimenetwork平台并逮捕管理员 https://www.bka.de/DE/Presse/Listenseite_Pressemitteilungen/2026/Presse2026/260508_PM_Crimenetwork.html?utm_source=BC 德国执法部门宣布关闭重启版网络犯罪交易平台Crimenetwork，并在西班牙马略卡逮捕一名35岁德国籍嫌疑人。该平台自2012年起长期活跃，曾是德国最大的网络犯罪市场之一，提供非法服务、违禁品和被盗数据交易。2024年末，德国法兰克福检方、网络犯罪打击中心和联邦刑警局已查封原平台并抓获一名管理员，但数日后其以新基础设施重新上线。警方称，新版本迅速聚集约2.2 6、Ollama越界读取漏洞可致远程内存泄露 https://thehackernews.com/2026/05/ollama-out-of-bounds-read-vulnerability.html Ollama在0.17.1之前版本存在一项严重的越界读取漏洞。攻击者可通过构造恶意GGUF文件触发该问题，从而远程读取进程内存内容，造成敏感信息泄露。泄露数据可能包括API密钥等机密信息。报道指出，受影响的暴露服务器规模超过30万台，风险范围较广。该漏洞的核心影响在于模型文件处理过程中发生越界读取，使原本不应被访问的内存内容被返回或暴露。对于正在使用旧版本Ollama并加载来自不可信来源GGUF文件的环境，应尽快升级至0.17.1或更高 7、JDownloader下载器遭入侵，用户被植入远控木马 https://cybersecuritynews.com/jdownloader-downloader-hacked/ 知名开源软件JDownloader遭供应链攻击，官网下载链接被替换为携带Python远程木马的恶意文件。攻击持续两天，木马具备持久性后门功能，能执行任意代码。建议受影响用户重装系统，未运行文件需验证数字签名。 8、Ivanti终端管理器移动版曝出五个新漏洞 其中一处已被利用 https://www.csoonline.com/article/4169001/five-new-holes-one-exploited-found-in-ivanti-endpoint-manager-mobile.html 专家警告Ivanti移动终端管理方案存在五处高危漏洞，其中一处已被利用，需立即修补并轮换凭证。建议淘汰传统本地安全方案，转向现代防御体系，强调零信任模型的重要性。 9、新型PamDOORa后门攻击Linux系统窃取SSH凭证 https://cybersecuritynews.com/new-pamdoora-backdoor-attacking-linux-systems/ PamDOORa后门通过劫持Linux的PAM框架窃取SSH凭证，利用pam_exec模块绕过监控，具备反取证能力。需加强SELinux、禁用SSH root登录并监控系统文件变更以防御。 10、ODINI恶意软件利用CPU磁场辐射突破法拉第笼隔离的计算机 https://cybersecuritynews.com/odini-malware-air-gapped-computers/ ODINI恶意软件通过操控CPU负载产生低频磁场，穿透法拉第笼窃取气隙隔离计算机数据，传输速率达40比特/秒。防御需特殊屏蔽或信号干扰，最可靠措施是禁止附近使用电子设备。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

1、TCLBanker木马借WhatsApp和Outlook自传播 https://www.elastic.co/security-labs/tclbanker-brazilian-banking-trojan 研究人员披露一种新型银行木马TCLBanker。该恶意程序通过伪装成Logitech AI Prompt Builder的MSI安装包入侵系统，并利用DLL侧载在合法进程中运行，以规避安全产品检测。TCLBanker目前主要针对巴西用户，会检查时区、键盘布局和区域设置，瞄准59个银行、金融科技和加密货币平台。其具备反分析和反调试能力，可识别多种安全研究工具，并在受害者访问目标网站时通过WebSocket与C2通信，配合覆盖层实施虚假登录、PIN输入、 2、Google修复GeminiCLI高危远程执行漏洞 https://www.pillar.security/blog/my-agentic-trust-issues-from-prompt-injection-to-supply-chain-compromise-on-gemini-cli Google已修复Gemini CLI中的一处CVSS 10级高危漏洞。根据报道，攻击者可结合提示注入与权限提升手法，借助GitHub Issue相关交互链路触发远程代码执行，进而影响开发流程与依赖供应链安全。该问题的风险在于，一旦利用成功，攻击者可能从命令行工具入口扩大控制范围，最终造成完整的供应链妥协。报道强调，此次漏洞与GitHub Issue场景有 3、英伟达确认亚美尼亚GeForceNOW数据泄露 https://www.bleepingcomputer.com/news/security/nvidia-confirms-geforce-now-data-breach-affecting-armenian-users/ 英伟达向媒体证实，GeForce NOW发生用户信息泄露事件，但影响范围仅限于亚美尼亚，由当地联盟合作伙伴运营的基础设施遭入侵所致，英伟达自有网络和其直接运营服务未受影响。英伟达表示，受影响用户将由当地运营方GFN.am通知。GFN.am披露，该网络安全事件发生于3月20日至26日，泄露信息包括部分用户资料，但未涉及账户密码，且3月9日之后注册的用户不受影响。此前有名为 4、JDownloader官网遭入侵投放恶意安装包 https://jdownloader.org/incident_8.5.2026.html?v=20260508277000 研究人员发现JDownloader官方网站于2026年5月6日至7日期间遭攻击者入侵，下载链接被篡改，导致Windows“替代安装器”和Linux shell安装器指向恶意载荷，形成供应链攻击。开发团队表示，攻击者利用一个未修补漏洞，在未获认证的情况下修改了网站CMS中的访问控制列表和页面内容，但未取得底层服务器或操作系统权限。研究人员分析发现，Windows恶意程序会投放经过混淆的Python远控木马，可从C2服务器接收并执行代码；Linux安装脚本则被植入恶意代 5、恶意HuggingFace仓库冒充OpenAI投递窃密木马 http://www.hiddenlayer.com/insight/malware-found-in-trending-hugging-face-repository-open-oss-privacy-filter 研究人员发现一个名为Open-OSS/privacy-filter的恶意Hugging Face仓库冒充OpenAI“Privacy Filter”项目，曾短暂登上平台热门榜首，并在下架前累计约24.4万次下载。该仓库复制了正版项目说明，并通过loader.py伪装为正常AI代码，实则在Windows系统上关闭SSL验证、下载并执行包含PowerShell命令的载荷，进一步获取 6、新型Linux PamDOORa后门利用PAM模块窃取SSH凭证 https://flare.io/learn/resources/blog/pamdoora-new-linux-pam-based-backdoor-sale-dark-web 网络安全研究人员披露了一个名为PamDOORa的新型Linux 后门的详细信息，该后门由一个名为“darkworm”的威胁行为者在Rehub俄罗斯网络犯罪论坛上以1600美元的价格出售。该后门程序被设计成一个基于可插拔认证模块（PAM）的后渗透工具包，它通过一个特殊的密码和特定的TCP端口组合来实现持久的SSH访问。它还能窃取所有通过受感染系统进行身份验证的合法用户的凭据。这款名为PamDOORa的工具是一种基于P 7、IvantiEPMM高危漏洞正遭在野利用 https://hub.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs?language=en_US Ivanti Endpoint Manager Mobile（EPMM）中的远程代码执行漏洞CVE-2026-6973已在有限范围内遭到攻击者利用，且可带来管理员级访问权限，风险较高。美国网络安全和基础设施安全局（CISA）已要求相关机构在2026年5月10日前完成修复，进一步提升了该问题的处置紧迫性。现有信息显示，此次利用活动规模尚有限，但由于 8、伪造macOS故障排查页面诱导窃取iCloud数据 https://hackread.com/fake-macos-troubleshooting-sites-steal-icloud-clickfix/ 研究人员发现一种新的ClickFix攻击正针对macOS用户展开。攻击者在Medium和Craft等平台发布伪造的故障排查指南，利用用户寻求系统问题解决方案的心理，诱导其在终端中执行恶意命令。相关命令会部署AMOS和SHub Stealer等信息窃取恶意程序，从而收集受害者设备上的敏感数据。根据标题信息，此次活动还涉及窃取iCloud相关数据，说明攻击目标可能包括账号凭证、会话信息或云端同步内容。该手法结合了社工诱导与终端执行，绕过传统下载 9、cPanel与WHM修复三个高危安全漏洞 https://thehackernews.com/2026/05/cpanel-whm-patch-3-new-vulnerabilities.html The cPanel已发布安全更新，修复cPanel与WHM中的三个新漏洞。其中两项漏洞的CVSS评分为8.8，属于高危级别，可能带来代码执行和权限提升风险。此次补丁旨在降低相关系统被攻击者利用的可能性，减少对服务器管理环境和托管服务的安全威胁。由于这些漏洞影响核心管理组件，使用cPanel和WHM的运维人员与服务提供商应尽快完成更新与补丁部署，并结合现有安全策略开展检查，以降低潜在入侵和系统被控风险。 10、知名打车应用Yango因跨境传输数据违规被罚8亿元 https://www.secrss.com/articles/90144 欧洲数据保护机构已对打车应用Yango的运营公司MLU B.V.处以1亿欧元（约合人民币8.01亿元）罚款。此前调查发现，该公司在未采取欧盟法律规定保护措施的情况下，将出租车用户的个人数据传输至俄罗斯。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

1、PCPJack蠕虫窃取云凭证并清除TeamPCP感染 https://www.sentinelone.com/labs/cloud-worm-evicts-teampcp-and-steals-credentials-at-scale/ 研究人员披露新型恶意框架PCPJack正针对暴露在公网的云基础设施发起攻击，主要目标包括Docker、Kubernetes、Redis、MongoDB、RayML及存在漏洞的Web应用。该恶意程序通过bootstrap.sh感染Linux云系统，部署后会创建隐藏目录、安装依赖、下载模块并建立持久化。其突出特征是会主动检查并清除TeamPCP相关进程、服务、容器、文件和持久化机制，从而独占受害主机。研究人员称，P 2、基于Mirai的xlabs_v1僵尸网络借ADB劫持物联网设备 https://hunt.io/blog/xlabs-v1-ddos-for-hire-operation-exposed#Infrastructure_Analysis 研究人员发现名为xlabs_v1的僵尸网络基于Mirai变种，正利用Android Debug Bridge（ADB）默认使用的5555端口入侵并招募物联网设备，将其纳入攻击基础设施。该恶意网络在控制受感染设备后，可发起多达21种DDoS攻击方式，并支持按照带宽层级组织攻击资源。报道指出，其主要用途之一是针对游戏服务器实施分布式拒绝服务攻击，以提升攻击效率和持续性。现有信息表明，这一活动凸显了暴露ADB服务的物联网设备面临 3、恶意PyPI包借助Zulip接口传播ZiChatBot木马 https://securelist.com/oceanlotus-suspected-pypi-zichatbot-campaign/119603/ 2025年7月有3个上传至PyPI的软件包被用于传播ZiChatBot恶意程序，攻击目标涵盖Windows和Linux系统。该恶意代码的一项关键特征是将Zulip的API用作命令与控制（C2）通道，从而借助正常网络服务掩护通信行为，提升隐蔽性并增加检测难度。此事件再次表明，开源软件仓库供应链正持续成为攻击者投放恶意载荷的重要渠道。对于开发者和企业而言，应加强对第三方依赖包的来源审查、版本变更监控与安装前检测，降低因引入恶意包而导致系统受害的风 4、vm2严重沙箱逃逸漏洞可致主机执行任意代码 https://github.com/patriksimek/vm2/security/advisories/GHSA-ffh4-j6h5-pg66 Node.js沙箱库vm2被披露存在严重漏洞CVE-2026-26956，可导致攻击者逃逸沙箱并在宿主机上执行任意代码。该问题已确认影响vm2 3.10.4，较早版本也可能受影响，且公开了概念验证代码。通告称，漏洞影响启用了WebAssembly异常处理和JSTag支持的Node.js 25环境，已在Node.js 25.6.1上确认。漏洞根因是vm2在处理沙箱与宿主环境之间的异常时存在缺陷，攻击者可借此让宿主侧错误对象泄露回沙箱，并进一步恢复 5、PaloAltoPAN-OS漏洞正被利用致远程执行 https://security.paloaltonetworks.com/CVE-2026-0300 Palo Alto Networks的PAN-OS出现编号为CVE-2026-0300的安全漏洞，攻击者可通过暴露在公网的PAN-OS门户发起利用，在目标防火墙设备上实现以root权限执行任意代码。信息显示，该漏洞在2026年5月13日补丁发布前就已被实际利用，说明其具有较高现实威胁。现有内容指出，受影响场景与公开可访问的 PAN-OS门户有关，但未提供更多技术细节、影响版本范围或攻击链说明。 6、Apache修复可致拒绝服务与潜在RCE的HTTP/2漏洞 https://httpd.apache.org/docs/current/mod/mod_http2.html Apache已修复HTTP/2组件中的严重漏洞CVE-2026-23918。该漏洞被描述为双重释放问题，可能被攻击者利用，导致目标服务发生拒绝服务，并存在进一步实现远程代码执行（RCE）的潜在风险。受影响对象为Apache HTTP Server 2.4.66版本用户。根据披露信息，此次问题集中在HTTP/2相关处理逻辑，说明在特定条件下内存管理缺陷可能被触发，从而影响服务稳定性与安全性。 7、 Linux内核Dirty Frag本地提权漏洞影响主流发行版 https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html Linux内核曝高危漏洞Dirty Frag，可本地提权至root，影响多数发行版。该漏洞结合xfrm-ESP和RxRPC漏洞，无需竞争条件，成功率极高。建议临时禁用相关模块esp4、esp6和rxrpc。 8、Ollama漏洞暴露AI框架无限制访问：30万台服务器面临风险 https://www.csoonline.com/article/4168584/ollama-vulnerability-highlights-danger-of-ai-frameworks-with-unrestricted-access.html Ollama框架存在高危漏洞Bleeding Llama（CVE-2026-7482），可致30万台服务器内存数据泄露，包括敏感信息和API密钥。攻击者通过特制文件触发堆越界读取，仅需三次API请求即可窃取数据。建议立即升级至0.17.1版本，部署防护措施并轮换密钥。 9、黑客利用虚假Claude AI网站传播新型Beagle后门程序 https://hackread.com/hackers-fake-claude-ai-site-infect-beagle-malware/ 黑客利用虚假Claude AI网站传播新型Beagle后门，通过恶意广告和SEO投毒诱骗用户下载含恶意软件的压缩包，采用DLL旁加载技术绕过检测。攻击者使用Cloudflare和阿里云隐藏行踪，建议仅从官方渠道下载软件并警惕可疑链接。 10、ShinyHunters黑客组织篡改Canvas LMS门户 全球数千所高校受影响 https://hackread.com/shinyhunters-defaces-canvas-lms-portal-universities-affected/ 黑客组织ShinyHunters攻击Canvas LMS平台，篡改高校登录页面勒索数据，影响全球近9000家机构。泄露信息含姓名、邮箱等，但未涉及敏感数据。平台故障严重影响教学，高校警惕后续钓鱼攻击。Instructure正调查事件范围。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

1、VECT2.0勒索软件因缺陷致数据永久损毁 https://research.checkpoint.com/2026/vect-ransomware-by-design-wiper-by-accident/ 研究人员发现VECT 2.0勒索软件存在致命缺陷，会在加密或破坏文件的过程中造成不可逆的数据损毁，导致受害者即使支付赎金也无法恢复文件。这意味着该家族不仅实施勒索，还因其实现问题使数据恢复路径被彻底切断，进一步加剧受害组织和个人的损失。报道指出，赎金支付在此情况下失去实际意义，受害者难以通过攻击者提供的方式取回数据。此类事件再次表明，面对勒索软件威胁，依赖离线备份、分层防护、及时修补和应急响应机制，比事后支付赎金更为关键。 2、钓鱼活动借助远程管理工具波及80余家机构 https://www.securonix.com/blog/venomous-helper-phishing-campaign 自2025年4月起，一个名为VENOMOUS#HELPER的网络钓鱼活动持续活跃，已影响80多家组织，受害对象主要位于美国。该活动在诱饵设计上使用与美国社会保障局（SSA）相关的主题，以提高邮件或消息内容的可信度并诱导目标上当。报道指出，攻击者在行动中利用了SimpleHelp和ScreenConnect两款远程监控与管理（RMM）工具。现有信息主要表明其攻击范围、所用社工主题以及涉及的工具类型，未进一步披露更完整的入侵链、具体受害行业分布或后续影响细节。 3、Vimeo因Anodot供应链事件泄露11.92万人信息 https://www.bleepingcomputer.com/news/security/vimeo-data-breach-exposes-personal-information-of-119-000-people/ 视频平台Vimeo因第三方数据异常检测公司Anodot发生安全事件，导致用户和客户数据被未授权访问。Have I Been Pwned对泄露数据分析后称，此次事件共暴露119,200人的邮箱地址，部分记录还包含姓名。Vimeo此前表示，被访问的数据主要涉及技术数据、视频标题和元数据，以及部分客户邮箱地址，不包括视频内容、有效登录凭证和支付卡信息，平台服务也未受到中断。该 4、MuddyWater伪装Chaos勒索掩护间谍攻击 https://www.rapid7.com/blog/post/tr-muddying-tracks-state-sponsored-shadow-behind-chaos-ransomware/ 研究人员发现伊朗背景黑客组织MuddyWater在一次入侵中伪装成Chaos勒索软件攻击，实际更像是网络间谍活动而非单纯牟利。攻击者通过Microsoft Teams实施社工，与员工建立聊天和屏幕共享，诱导受害者泄露凭据、调整多因素认证设置，并在部分场景部署AnyDesk实现远程访问。得手后，攻击者进一步访问内部系统和域控，借助RDP、DWAgent、AnyDesk维持持久化，并投放伪装成Mic 5、DAEMONTools官方安装包遭供应链投毒 https://securelist.com/tr/daemon-tools-backdoor/119654/ DAEMON Tools自2026年4月8日起发生供应链攻击，官方签名安装程序被植入恶意代码。由于受影响样本仍带有合法签名，攻击具备较强隐蔽性，可能使用户在下载安装官方软件时误装恶意程序。报道指出，此次事件可被用于面向全球目标的定向恶意载荷投递，说明攻击者可能借助可信分发链路扩大影响范围。目前已知关键信息包括受影响时间点、被篡改对象为官方安装器，以及其可支持针对性投放；原文未进一步披露具体恶意软件家族、受害规模及修复进展。 6、DataDome披露超大规模低速DDoS攻击事件 https://hackread.com/low-and-slow-ddos-attack-hits-2-45-billion-5-hours/ DataDome研究人员发现一起大规模“低速且持续”DDoS攻击事件。此次攻击在5小时内累计发出24.5亿次请求，动用了约120万个IP地址，显示出较强的分布式特征。与传统以瞬时高流量压垮目标的攻击方式不同，“低速”DDoS通常通过持续、分散且更难被快速识别的请求对平台造成压力，可能影响业务可用性与防护系统判断。现有信息主要披露了攻击规模、持续时间和参与的IP数量，未进一步说明受影响平台名称、攻击来源归属及最终影响范围。 7、谷歌搜索广告钓鱼瞄准GoDaddy旗下ManageWP账户 https://www.bleepingcomputer.com/news/security/hackers-abuse-google-ads-for-godaddy-managewp-login-phishing/ 研究人员发现一场通过谷歌赞助搜索结果投放的钓鱼活动正在针对GoDaddy旗下ManageWP平台用户。攻击者在“managewp”搜索结果中投放高仿链接，并采用对手中间人（AiTM）方式，将伪造登录页作为受害者与真实ManageWP服务之间的实时代理，实时窃取账号、密码及随后输入的双因素认证代码。研究人员指出，ManageWP常被开发者、网站代理商和企业用于集中管理多站点，而其 8、思科修复可致设备需手动重启的拒绝服务漏洞 https://www.bleepingcomputer.com/news/security/new-cisco-dos-flaw-requires-manual-reboot-to-revive-devices/ 思科发布安全更新，修复影响Crosswork Network Controller（CNC）和Network Services Orchestrator（NSO）的高危拒绝服务漏洞CVE-2026-20188。该漏洞源于对入站网络连接的速率限制不足，未经身份验证的远程攻击者可通过低复杂度攻击耗尽连接资源，导致系统失去响应，影响合法用户及依赖服务。根据思科说明，受攻击设备在出现故障 9、泛微E-cology调试接口漏洞正被利用 https://nvd.nist.gov/vuln/detail/CVE-2026-22679 泛微E-cology存在编号为CVE-2026-22679的远程代码执行漏洞，且已被攻击者实际利用。该问题出现在2026年3月12日之前的相关版本中，攻击者可通过调试接口发起利用，进而在目标系统上执行任意代码，导致服务器被入侵和系统失陷。现有信息表明，此次攻击路径与暴露的调试端点有关，风险影响较为直接。对于使用受影响版本的机构而言，应尽快核查系统版本与调试接口暴露情况，并关注厂商后续安全更新与缓解建议，以降低被攻击和横向渗透的风险。 10、Apache HTTP Server漏洞致数百万服务器面临远程代码执行攻击风险 https://cybersecuritynews.com/apache-http-server-rce/ Apache发布HTTP Server关键安全更新，修复五个漏洞，包括高危双重释放漏洞（CVE-2026-23918，CVSS 8.8），可导致远程代码执行。建议所有2.4.66及更早版本用户立即升级至2.4.67。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。