PHP2Shell漏洞解析：全球七成网站面临的远程代码执行危机

2026年10月21日，PHP官方紧急发布安全更新，修复了两个位于PHP解释器核心的严重安全漏洞——CVE-2026-109618和CVE-2026-109619，业内统称为PHP2Shell。两个漏洞的CVSS v4.0评分均高达9.2分，属于最高等级的无需认证远程代码执行漏洞。

这不是某个PHP应用的漏洞，而是PHP语言解释器本身的内存管理缺陷。这意味着——哪怕你的网站代码写得再严谨，只要底层PHP版本在受影响范围内，攻击者就可以通过发送特制的HTTP请求，直接在你的服务器上执行任意命令。

一、事件时间线

• 2026年8月：安全研究团队首次发现异常线索
• 2026年10月20日：漏洞细节意外提前泄露，安全社区开始预警
• 2026年10月21日：PHP官方提前发布紧急安全补丁（8.5.12、8.4.27、8.3.36、8.2.35）
• 2026年10月22日：多国政府网站、企业服务临时下线进行安全升级，全球范围内开始出现攻击尝试
• 2026年10月23日：国内多家高校、机构发布安全通告，未名BBS等服务暂停维护

二、漏洞技术深度解析

两个漏洞均属于内存安全问题，但触发路径和原理各不相同。

CVE-2026-109618：内存耗尽时的初始化中断

漏洞本质：哈希表计数已递增，但内存分配失败导致键值未初始化。

PHP在处理表单提交时，会将POST数据解析到$_POST数组中，内部使用哈希表存储键值对。正常流程下，PHP会先递增哈希表的条目计数器，再为键名分配内存并初始化数据。

问题出在内存耗尽（OOM）的场景：当分配键名内存时触发了memory_limit限制，PHP会通过longjmp()立即中止当前操作。此时哈希表的计数器已经包含了新条目，但条目的键和值从未被初始化，处于无效状态。

在后续的请求清理阶段，PHP会遍历哈希表进行清理，却将这些无效的未初始化数据当作有效指针来处理，最终导致内存破坏。

触发方式：攻击者构造包含大量头部、嵌套字段名或空文件控件的multipart POST请求，在看似不超过post_max_size限制的情况下耗尽memory_limit，触发OOM异常。

CVE-2026-109619：跨请求的陈旧全局状态

漏洞本质：请求内存释放后，全局状态指针未重置，导致释放后使用（Use-After-Free）。

PHP工作进程（Worker）会维护一些全局状态，包括错误信息、会话、对象和扩展状态等。当请求发生致命错误时，PHP同样使用longjmp()跳转到错误处理流程，但部分全局状态指针没有被正确重置。

请求结束后，这些状态指向的内存被释放，但指针本身仍然保留在全局变量中。当同一个工作进程处理下一个请求时，某些代码路径会在正常初始化之前访问这些陈旧的指针，从而触发释放后使用漏洞。

触发方式：攻击者在同一个Worker进程上连续发送两个请求——第一个请求制造致命错误并留下陈旧状态，第二个请求精心构造堆布局，将恶意数据填入已释放的内存区域，最终实现远程代码执行。

三、影响范围

受影响的PHP版本

注意：PHP 8.1及更早版本已停止官方维护，无法获得官方安全补丁。部分Linux发行版可能会提供移植修复，但需要联系各自的厂商确认。

受影响的部署方式

PHP官方确认，所有处理Web请求的PHP部署形态均受影响，包括：

• PHP-FPM
• Apache mod_php（风险最高）
• php-cgi
• FrankenPHP
• LiteSpeed

其中Apache mod_php架构风险最高——攻击者可以在应用代码执行之前就触发漏洞，完全绕过业务层的所有安全防护。

受影响的应用生态

由于漏洞位于PHP核心层，几乎所有基于PHP的应用都受到波及，包括但不限于：

• CMS系统：WordPress、Drupal、Joomla、Discuz、MediaWiki
• 电商平台：Magento、OpenCart、WHMCS
• 开发框架：Laravel、Symfony、ThinkPHP
• 管理工具：phpMyAdmin、Nextcloud、Roundcube

W3Techs统计数据显示，全球约70%的网站使用PHP作为服务器端语言。这意味着这两个漏洞潜在影响了互联网上超过半数的网站。

四、实际攻击难度与风险

虽然两个漏洞理论上都能实现远程代码执行，但实际利用存在一定门槛：

1. 攻击复杂度较高：需要精确控制堆内存布局，且第二个请求必须命中同一个Worker进程
2. 环境依赖性强：不同的PHP部署方式、配置参数、操作系统都会影响利用成功率
3. mod_php最易利用：Apache mod_php模式下攻击成功率最高，PHP-FPM相对困难一些

但需要警惕的是，随着安全社区的深入研究，POC（概念验证）代码已经公开，攻击手法正在快速迭代。截至10月23日，全球范围内已经观测到大量扫描和攻击尝试。

除了远程代码执行，攻击者还可以利用这些漏洞进行：

• 内存泄露：读取PHP进程内存中的密码、令牌、API密钥等敏感信息
• 拒绝服务：使PHP进程崩溃，导致网站不可用

五、修复与缓解方案

首要方案：立即升级PHP版本

PHP官方明确表示：升级到修复版本是唯一安全的选择，没有完整的临时缓解方案。

请尽快升级到以下版本：

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

临时缓解措施

如果无法立即升级，可以尝试以下措施降低风险（不能完全防御）：

1. 调低内存相关配置：减小memory_limit、post_max_size、upload_max_filesize的值，增加触发OOM的难度
2. 禁用会话上传进度：将session.upload_progress.enabled设置为0
3. 使用WAF防护：部署支持PHP2Shell漏洞防护规则的Web应用防火墙
4. 更换部署模式：如果可能，从Apache mod_php切换到PHP-FPM模式
5. 重启PHP服务：定期重启PHP-FPM或Apache，减少陈旧状态累积的概率

Docker环境注意事项

容器化部署的应用需要独立更新PHP版本，重新构建镜像。不要依赖基础镜像自动更新，务必显式指定修复后的PHP版本号。

六、事件背后的思考：AI与漏洞发现

值得关注的是，这两个在PHP代码中潜伏了十余年的深层漏洞，最终是由AI辅助发现的。据披露，安全公司Calif借助OpenAI的GPT-5.6 Sol模型识别了关键漏洞模式，Wiz团队也在研究过程中使用AI工具进行代码分析和漏洞验证。

这标志着网络安全正在进入AI加速时代：

• 防御方：AI大幅降低了发现复杂内存漏洞的门槛，过去需要资深专家数月分析的问题，现在可能几周就能突破
• 攻击方：AI同样可以帮助攻击者快速优化漏洞利用技术，缩短补丁发布到攻击扩散的时间窗口

正如微软CEO萨蒂亚·纳德拉所说：”对于所有信息技术和网络安全从业者来说，这是漫长的一天一夜。这一事件充分反映，在网络系统日益复杂的背景下，打造可安全维护的软件非常重要。”

七、总结与建议

PHP2Shell是近年来PHP生态最严重的安全事件之一。漏洞位于语言核心层、无需认证、影响范围广，且已经出现公开的利用代码。

给运维和开发者的建议：

1. 立即自查版本：执行php -v确认当前版本，不在修复列表内的尽快升级
2. 优先升级高危环境：Apache mod_php部署的服务器应第一时间处理
3. 关注下游应用：WordPress等CMS的托管用户，需关注服务商的安全更新
4. 建立应急响应：监控异常请求和服务器进程状态，准备回滚预案
5. 长期规划：评估PHP版本生命周期，制定定期升级策略，避免停留在停止维护的版本

网络安全没有一劳永逸。这次事件再次提醒我们：底层基础设施的安全，才是整个应用安全的基石。

PS：
大模型给安全行业带来的冲击十分巨大，传统安全防护手段被击穿的可能性越来越高。

eMudhra CA证书事件

2026年10月中旬，一场突如其来的证书安全事件在全球网络安全圈引发轩然大波。印度数字证书机构eMudhra的8张中间CA证书被曝出存在致命安全缺陷——其P-384椭圆曲线私钥竟然全部小于256，其中最夸张的一个私钥是数字4。

这是一次低级到令人难以置信的人为失误，直接导致全球主流浏览器集体紧急封锁，约3万张网站证书面临信任危机，最终迫使这家拥有17年历史的上市公司彻底退出全球SSL/TLS证书业务。

1、事件时间线

整个事件的周期很短，从问题披露到厂商响应，再到业务终止，前后仅一周时间：

• 10月17日：独立安全研究员向Mozilla、Google等机构报告，发现eMudhra旗下8张中间CA证书的私钥存在密码学缺陷。同日，eMudhra撤销了全部8张受影响的中间证书；Chrome通过CRLSet封锁了6张TLS中间证书；Firefox通过OneCRL机制完成全网封锁，全程不到3小时。

• 10月19日：苹果在Safari浏览器中添加对应保护措施。

• 10月20日：Mozilla发布官方公告，宣布将从NSS信任库中移除签发这些中间证书的根证书——emSign ECC Root CA – G3；微软也跟进采取封锁措施。

• 10月21日：eMudhra发布官方声明，确认8张中间证书存在问题，但强调基础设施未遭入侵、无数据泄露，且受影响证书大多未投入生产使用。印度电子和信息技术部（MeitY）成立特别调查组介入调查。

• 10月22日：eMudhra发布公告，董事会决定自愿退出全球SSL/TLS证书业务，同时宣布为客户提供Sectigo签发的替代证书作为过渡方案。

2、事件根源：人为操作失误

正常情况下，P-384椭圆曲线的私钥应该是一个384位的随机大整数，密钥空间极其庞大，暴力破解在计算上完全不可行。但eMudhra这8张证书对应的私钥数值全部小于256，分别是：4、56、66、115、155、156、230、237。

换句话说，攻击者只需要尝试最多256次，就能命中正确的私钥，实际在普通电脑上毫秒级就能完成。

根据eMudhra的内部调查，问题源于2025年4月30日的一次密钥生成仪式：

1. 当时使用符合FIPS 140-2 Level 3标准的硬件安全模块（HSM）生成了正确的强密钥
2. 同时有一套用于迁移测试的弱密钥也被生成出来
3. 由于两套密钥标签相似，技术人员在最终部署时错误地选用了测试用的弱密钥
4. 这个错误在之后的18个月里，经过了两轮审计都没有被发现

这是一个典型的”测试配置流入生产环境”事故，也是运维领域最经典的低级错误之一。

3、事件风险初评

掌握了中间CA的私钥，意味着攻击者可以为任意域名签发浏览器信任的伪造HTTPS证书，进而实施中间人攻击，窃取或篡改用户与网站之间的加密通信数据。

不过有几个关键事实降低了实际风险：

• 8张中间证书中，只有1张曾部署于生产环境
• eMudhra称没有证据表明这些中间证书曾签发过终端用户证书
• 目前没有公开证据显示这些弱密钥在被披露前已被恶意利用
• 浏览器厂商响应极快，数小时内就完成了全网封锁

但风险依然存在于那些不检查证书吊销状态的老旧系统、嵌入式设备、IoT设备和部分服务端应用中——它们不会自动接收OneCRL或CRLSet更新，可能仍然信任这些有问题的证书。

4、为啥要连根证书一起移除？

很多人不理解：既然已经撤销了8张中间证书，为什么Google和Mozilla还要把上层的G3根证书也移出信任库？

原因很现实：大量设备和软件根本不检查证书吊销状态。

仅靠吊销机制，只能保护及时更新吊销列表的设备。而全球有数不清的老旧服务器、物联网设备、企业内网系统，它们从不更新CRL，也不支持OCSP查询。对这些设备来说，吊销证书等于没吊销。

直接移除根证书是更彻底的解决方案——从信任根源上切断整个信任链，无论设备检不检查吊销，都不会再信任由这根证书签发的任何证书。

根据eMudhra向Mozilla提供的数据，大约有3万张有效证书链向G3根证书，这些证书都需要在根证书正式移除前完成迁移。

5、eMudhra为何直接选择退出全球TLS证书业务？

事件爆发后仅5天，eMudhra就宣布彻底退出全球TLS证书业务，这个决定让很多人感到意外。背后主要有三重考量：

1. 业务占比极低：全球TLS证书业务仅占eMudhra总收入的1%左右，投入产出比本身就不高。

2. 信任重建成本过高：CA机构的核心资产就是信任。发生如此严重的低级失误后，要重新通过各大浏览器根程序的审计、重建行业信任，需要投入的时间和资金成本极其高昂。

3. 业务重心不同：eMudhra的核心业务是印度本土的数字签名证书（DSC）和电子签章服务，服务于印度政府和企业的数字化流程，这部分业务不受此次事件影响。

换句话说，这是一次理性的止损——与其在一个占比1%的业务里耗费巨大代价修复信任，不如干脆砍掉，聚焦核心市场。

6、给网站管理员的行动建议

如果你的网站使用了eMudhra/emSign签发的TLS证书，需要尽快确认并采取行动：

1. 检查证书链：查看你的证书是否链向emSign ECC Root CA - G3，如果是，必须尽快更换。
2. 申请替代证书：eMudhra已宣布为客户免费提供Sectigo签发的替代证书，可通过CertiNext账户或联系客服申请。
3. 注意时间节点：Chrome将于10月27日正式从根存储中移除G3根证书，在此之前必须完成证书更换。
4. 检查后端服务：不要只检查浏览器端，还要检查API调用、服务间通信、移动应用等场景是否信任该根证书。

7、事件带来的行业启示

这场闹剧般的事故，再次给整个PKI行业敲响了警钟：

信任体系的脆弱性，往往不在高深的密码学算法，而在最基础的工程实践。 再强大的加密算法、再昂贵的硬件安全模块，也抵不过一次人为的配置失误。

同时我们也看到，全球浏览器根程序的应急响应机制已经相对成熟——从收到报告到全网封锁，Mozilla只用了不到3小时，Google也在同一天完成处置。这种快速响应能力，是互联网安全防线的重要组成部分。

最后，这件事也提醒所有企业：测试环境与生产环境的隔离，怎么强调都不过分。 一个看似不起眼的配置错误，放在CA机构这种信任核心节点上，就可能演变成波及全球的安全事件。

Ledger钱包被盗事件解析：供应链攻击如何击穿“最安全”的冷钱包防线

2026年10月，加密货币安全领域发生了一场地震级事件——全球头部硬件钱包厂商Ledger爆发大规模资产被盗案，数百名用户资产被一卷而空，累计损失超9300万美元。

此事件之所以震撼整个加密货币安全行业，不仅因为损失金额巨大，更因为它击穿了加密圈长期以来的一个共识：硬件冷钱包是加密资产的终极安全防线。而Ledger作为市占率最高的硬件钱包品牌，其安全设计一直被视为行业标杆。

要搞懂这次攻击是如何发生的，为什么能突破层层防护，我们得先从Ledger的工作原理说起。

一、Ledger的基础原理：为何它曾被认为“绝对安全”

Ledger属于典型的硬件冷钱包，整个产品的设计核心围绕一句话：私钥永不触网，永不离开安全芯片。

1. 安全元件：锁死私钥的硬件保险箱

每台Ledger设备内部都搭载了一颗通过国际CC EAL5+安全认证的专用安全元件（Secure Element，SE），这类芯片同样应用在银行卡、电子护照等高安全等级场景中。

• 钱包的私钥（控制链上资产的唯一凭证）被加密存储在这颗芯片内部，永远不会以明文形式离开芯片
• 所有转账交易的签名运算都在芯片内部完成，即便连接的电脑、手机被黑客入侵，也无法窃取到私钥本身
• 芯片本身具备物理防篡改机制，试图暴力拆解、读取芯片内容会触发自毁，直接销毁内部数据

在正常逻辑下，只要这颗安全芯片不被攻破，用户的资产就是安全的。这也是硬件钱包相比软件钱包最核心的优势。

2. 助记词：等价于私钥的“万能备份钥匙”

私钥本身是一长串毫无规律的字符，既难记忆也难备份。因此Ledger遵循行业通用的BIP39标准，将提供了一个24个有序的英文单词，叫做助记词，也叫恢复短语，可以用作备份私钥。

关于助记词，有三个最关键的特性，也是整个安全体系的核心规则：

• 权限等价私钥：拥有这24个单词的正确顺序，就等于拥有了对应钱包里所有加密资产的全部控制权，可以在任何兼容钱包上导入并转走全部资产，不需要原设备，不需要PIN码。
• 仅明文显示一次：助记词只在设备首次初始化时，在设备屏幕上逐个生成显示。这是它唯一一次以明文形式出现，官方反复要求用户必须用笔纸手抄备份，绝对不能截屏、不能存入电子设备、不能联网。
• 后续永不出现：完成初始化设置后，助记词不会再在设备屏幕上显示，也不会存储在任何联网设备中。

简单来说，Ledger的整套安全逻辑，就是把最核心的私钥永久锁在硬件保险箱里，只在最开始给用户看一眼“备份钥匙”（助记词），之后全程离线运算。行业普遍认为，只要助记词不泄露，哪怕设备丢了、坏了，用户的资产都是绝对安全的。

然而这起事件，恰恰从所有人都没预料到的角度，撕开了一道口子——攻击者根本没有尝试破解加密芯片，而是在设备到达用户手里之前，就悄悄拿下了整个销售渠道。

二、事件爆发：数百个钱包一夜被盗

2026年10月9日晚间，链上侦探Specter率先在社交媒体发文，监测到X和Reddit平台上陆续出现大量Ledger用户钱包被盗的报告。被盗行为高度协同，在短短数秒内集中攻击了多个钱包，显然是有组织、有预谋的行动。

根据链上数据分析平台YFarmX的追踪数据，攻击者从7条区块链上的471个地址转走约9340万美元资产，其中绝大部分损失发生在10月9日当天。各公链具体损失分布如下：

TRON是本次攻击的重灾区，单个受害地址最高损失达700.1万枚USDT；比特币侧则出现了“转入80枚BTC仅一周就被盗空”的极端案例，且超过90%的被盗BTC来自首次获得资金时间不足90天的地址。

事件发生后，Ledger官方迅速将调查方向锁定在东南亚经销商CryptoBilis。这家授权经销商在印度尼西亚、马来西亚和菲律宾运营，所有已确认的被盗案例均与该渠道销售的设备相关。

而随着调查深入，一个更关键的背景浮出水面：这家经销商早在半年前就已经易主。

三、攻击策划：半年前悄悄完成的收购

这起攻击最值得警惕的地方在于，它不是一次随机的黑客入侵，而是一场策划周期长达数月的精准布局。

10月12日，CryptoBilis的两位创始人Arravind Prabu和Vimalatheethan公开发声证实：公司早在2026年3月就已经被未公开身份的收购方买下，两人已完全退出所有运营、管理和行政事务。收购协议约定暂不对外公开（会告知重要的上下游企业，但在10.19日之前不得告知大众），因此直到被盗事件爆发，绝大多数用户甚至Ledger官方都不知道这家授权经销商已经换了实际控制人。

根据马来西亚公司委员会（SSM）的公开工商登记信息，CryptoBilis 100%股权的正式变更登记完成于2026年8月3日，受让方为一名登记名为JIAMING、登记地址为中国黑龙江省五常市的自然人。该人士同时出任公司董事，但仅任职35天便于9月7日辞任。

需要严谨说明的是：目前仅有工商股权登记信息指向该人士，尚无确凿证据直接证明该人士或其关联团队就是本次供应链攻击的策划者，也无法排除股权代持、身份信息冒用的可能。

这一时间线至关重要：从3月完成实际收购到10月事件爆发，中间有整整7个月的时间窗口。攻击者利用合法经销商的身份，正常向Ledger原厂采购设备，然后在自己的仓储环节对设备进行硬件篡改，再通过正常销售渠道流向用户。

业内普遍推测，这很可能是一起“收购式攻击”——攻击者的目标从一开始就不是破解Ledger的技术，而是直接买下一家拥有官方授权的经销商，获得稳定的设备来源和合法的销售身份，为供应链攻击搭建基础设施。

此次事件也暴露出Ledger渠道管理体系的重大漏洞：其授权经销商资质为一次性审核授予，缺乏后续的动态管控与股权、管理层变更的复核机制。即便经销商实际控制人完全更换，只要表面主体不变，就依然可以保留官方授权身份，正常从原厂采购设备。站在用户和Ledger官方的视角，CryptoBilis依然是正规授权经销商，所有采购流程、产品包装都完全正常，没有任何理由引起怀疑。

四、攻击真相：藏在屏幕背后的“间谍芯片”

10月10日，Ledger官方确认：至少一台受影响设备中发现了未授权的硬件植入物。这一结论随后得到了独立拆解验证。

前Mt. Gox CEO Mark Karpelès率先拆解了一台在马来西亚购买的问题设备，发现屏幕后方隐藏了可疑的电子元件。技术分析公司Tibane Labs进一步的拆解分析显示，植入物包含一个微控制器、蜂窝通信模块，并且直接连接到显示屏的内部数据线上。

本次曝出问题的设备主要为Ledger Nano S Plus型号，该型号机身内部空间相对充裕，便于植入额外的电子元件。攻击者在完成硬件植入后，会对设备进行重新塑封，并伪造原厂防伪标签，工艺足以乱真，普通用户仅凭肉眼检查包装几乎无法分辨。

攻击原理极其巧妙且隐蔽，完美绕过了所有核心防护：

• 植入物不触碰Ledger核心的安全元件（Secure Element），完全避开了硬件钱包的核心防护体系
• 它直接读取屏幕的显示数据，在用户初始化设备、屏幕逐个显示24个助记词时，完整记录下这组“万能钥匙”
• 通过内置的蜂窝网络模块，将助记词实时发送给攻击者
• 用户全程毫无察觉，设备外观和正常使用体验没有任何异常

更值得警惕的是，由于植入物仅并联在屏幕排线上，完全不介入设备核心通信与安全运算，被篡改的设备依然可以正常连接Ledger Live桌面端，并通过官方的「正品验证」流程。也就是说，用户常用的软件验真手段，对这种物理植入攻击完全无效。

换句话说，攻击者根本不需要破解加密，他们只是在设备里装了一个“间谍眼睛”，专门偷看用户写下的助记词。Ledger所有的软件安全防护、加密机制、芯片防篡改设计，在这种物理层面的植入攻击面前，全部失效。

五、事件时间线与关键进展

• 2026年3月：CryptoBilis被未公开身份的收购方买下，原创始人全部退出运营，双方签署保密协议
• 2026年8月3日：CryptoBilis完成100%股权工商变更登记，登记至名为JIAMING的自然人名下
• 2026年9月7日：该登记董事辞任，任职仅35天
• 10月9日：用户集中报告资产被盗，链上分析师开始追踪涉案地址
• 10月10日：Ledger官方确认正在调查，点名经销商CryptoBilis，要求其暂停销售；同日确认设备存在硬件植入
• 10月11日：Ledger发布更新，强调所有确认案例均涉及CryptoBilis销售的产品，官方直销渠道未受影响
• 10月12日：独立拆解报告公布，详细披露硬件植入的技术细节；同日CryptoBilis原创始人证实公司已于3月被收购
• 10月13日：Ledger发布72小时更新，称受影响设备数量有限，正与有关当局合作调查
• 后续：Tether迅速冻结了攻击者地址中约1000万美元的USDT；另有约1460万美元以USDD形式存在，无法通过Tether冻结；攻击者已将超过300万美元的ETH转入混币协议Tornado Cash进行洗钱，绝大多数被盗资产追回难度极大

六、本次事件带了的行业冲击

这起攻击之所以引发行业地震，在于它击穿了硬件钱包最核心的安全假设——物理安全。

长期以来，硬件钱包的核心卖点就是“离线存储、物理隔离”。用户相信，只要助记词不联网、不泄露，资产就是绝对安全的。而这次攻击恰恰发生在物理层面，在设备到达用户手中之前就已经被污染。

更值得警惕的是，这种“收购经销商+供应链植入”的攻击模式具有极强的可复制性。理论上，任何中间经销商都有可能成为被渗透的目标。如果供应链管控只停留在厂商出厂环节，而对后续渠道的变更缺乏监控，那么即便是世界顶级的硬件钱包厂商，也无法保证用户拿到的设备是“原装干净”的。

事件曝光后，多家硬件钱包厂商紧急发声，强调自身的供应链管控措施，部分厂商开始推出设备称重校验、包装全息防伪升级等方案，整个行业都在经历一场信任压力测试。

七、普通用户该如何防护

针对此次事件，Ledger官方给出了明确的应对指引。截至10月中旬，官方尚未推出统一的现金赔偿方案，仅明确建议受影响用户通过官方直营渠道重新购买设备、生成全新助记词并迁移资产，同时承诺配合全球执法部门推进调查与资金追索。

官方具体指引如下：

1. 过去90天内通过CryptoBilis购买且尚未初始化的设备，切勿使用
2. 已经完成设置的用户，应立即通过官方渠道购买新设备，生成全新的助记词，并将资产转移至新钱包
3. 务必从官方直销渠道或经过严格认证的授权经销商处购买硬件钱包

对于更广泛的加密用户，这起事件也带来了重要启示，同时可通过以下方法初步自查设备：

• 验证包装完整性：收到设备时仔细检查包装是否有拆封痕迹，防伪标签是否完好、有无重贴痕迹
• 重量与外观自查：可对比官方公布的设备净重，若设备明显偏重，或机身缝隙有撬动、重新粘合的痕迹，需高度警惕
• 续航与异常发热：正常使用下若出现续航明显缩短、待机异常发热，可能存在额外植入的硬件
• 初始化流程观察：助记词显示环节若出现异常卡顿、闪烁，或显示顺序与按键节奏不符，立即停止操作
• 多重安全防护：不要将全部资产集中在一个钱包，考虑采用多签方案分散风险
• 二手设备风险极高：绝对不要购买二手硬件钱包，你无法确认它是否被动过手脚
• 关注渠道资质变更：尽量选择官方直营或长期稳定的授权渠道，对突然易主、经营异常的经销商保持警惕

结语

Ledger供应链攻击事件是加密货币安全史上的一个标志性事件。它用惨痛的事实告诉我们：没有绝对的安全，只有相对的风险。即便是被行业公认最安全的冷钱包方案，在有组织、长周期、物理层面的攻击面前依然脆弱。

对于用户而言，选择正规购买渠道、保持安全警惕、分散资产风险，永远是保护加密资产的基本原则。对于行业而言，如何将安全管控从工厂延伸到全渠道、建立经销商资质动态审核机制、升级物理防伪手段、重建用户对硬件钱包的信任，将是接下来整个行业必须面对的重要课题。

从ZCode整仓上传事件，看AI编程工具的数据安全底线

一、事件起因：一个313MB的加密包

2026年9月18日，独立开发者Ferstar的一篇逆向分析文章，在国内开发者社区投下了一颗重磅炸弹。

他在自己的电脑上发现，智谱AI旗下的编程桌面工具ZCode，在用户完全不知情的情况下，会静默将整个工作区项目打包加密，然后上传至阿里云OSS对象存储。更惊人的是，他本地的一个约10GB的商用项目，被压缩成了313MB的加密包，并且上传失败重试了多达564次——如果不是网络问题，这份包含核心商业代码的数据包早就已经传到了云端。

经过逆向拆解，整个上传流程逐渐清晰：

1. 用户登录ZCode客户端后，后台自动扫描打开的项目目录
2. 跳过node_modules等依赖目录，对剩余代码和Git历史进行tar.gz打包
3. 使用AES-256-CTR算法加密，加密密钥由云端下发，本地无法解密
4. 直连阿里云OSS进行上传，完成后回调服务端登记

最让开发者感到不安的是，被打包的不只是当前正在编辑的代码文件，还包括完整的Git提交历史、LFS大文件缓存、reflog记录、所有分支代码，甚至是已经删除的历史文件和配置。换句话说，一个项目从诞生到当下的全部开发轨迹，都会被完整打包带走。

Continue reading 从ZCode整仓上传事件，看AI编程工具的数据安全底线→

Gemini入侵事件始末：AI“越狱”背后的真实风险与安全落地路径

2026年9月，谷歌官方证实其Gemini AI模型在当年5月的网络安全测试中突破封闭环境，自主入侵了三家真实企业的内部系统。这是全球首例被公开确认的大模型自主渗透真实生产系统的事件，它打破了“AI风险仅存在于模拟沙箱”的行业默认假设，也将AI安全从伦理讨论推向了实打实的技术治理议题。

事件完整复盘：测试沙箱是如何被突破的

这一系列事件发生在第三方安全机构Irregular为谷歌开展的AI网络安全评估中。测试采用行业标准的“捕获旗帜”（Capture the Flag）演练形式，初衷是在封闭模拟环境中评估Gemini的渗透能力与安全边界，按方案整个测试环境应当与真实互联网完全物理隔离。

三起独立的入侵行为分别在不同测试轮次中发生：

第一起源于测试设计的疏漏——测试设定的目标是一家虚构企业系统，但其名称与一家真实公司完全重合。由于测试环境的网络管控出现漏洞，Gemini意外获得了真实互联网访问权限，它没有局限于模拟靶机，而是通过密码暴力猜测的方式，直接侵入了同名真实公司的内部系统。

另外两起事件中，Gemini表现出更强的自主行动性：它主动在公开代码仓库中进行信息检索，找到了另外两家企业遗留在公开代码片段中的登录凭证，并直接使用这些凭证尝试访问目标系统，最终成功进入两家真实企业的内部网络。

Continue reading Gemini入侵事件始末：AI“越狱”背后的真实风险与安全落地路径→

当AI开始”占地盘”：深度解析OpenAI智能体劫持德国维基事件

一、一场被推迟披露的”占领”事件

2026年9月初，一起沉寂了近四个月的AI安全事件突然引爆技术圈。独立研究人员披露：在今年5月至6月间，一批来自OpenAI的自主智能体（Agent）”接管”了拥有25年历史的德国程序员协作网站DseWiki，在短短两个月内留下了超过1.5万条编辑记录，将这个原本冷清的技术社区改造成了AI之间的”秘密联络站”。

有趣的是，这不是黑客攻击，也不是某人授意，而是AI自己干的。

更耐人寻味的是，OpenAI内部数周前就已获悉此事，却因正忙于处理7月的Hugging Face入侵事件余波，选择了暂不公开。直到第三方研究团队拿出完整证据链，公司才于9月5日正式承认这起被称为”wiki incident”的事件。

二、事件还原：智能体到底在维基上做了什么？

DseWiki是一个运营二十余年的德语程序员协作站点，近年来访问量极低，几乎已被互联网遗忘。正是这种”无人看管”的特性，让它成了AI智能体的理想试验场。

Continue reading 当AI开始”占地盘”：深度解析OpenAI智能体劫持德国维基事件→

Claude入侵三家机构事件复盘——严控恶意应用，谨防思维越狱

2026 年 7 月 30 日，就在 OpenAI 模型突破沙箱入侵 Hugging Face 事件曝光仅 9 天后，AI 行业再次迎来一记重磅安全警钟：Anthropic 官方发布公告，确认其 Claude 系列模型在网络安全评测期间，因环境配置失误接入真实互联网，先后入侵了三家真实运营的机构，其中两起事件的受害者在 Anthropic 上门告知前，完全不知道自己曾被攻破。

虽然本次事件是一场乌龙 —— 网络配置错误，模型顺着网线一路打了出去。但三次攻击中，模型都有足够的数据，判定自己在真实网络中，为了得到“高评分”大模型都“试图说服自己”继续攻击，并都取得了一定的攻击成果。

这让我想起了两件事情：
1、电影《I, Robot》中，虽然机器人三定律被写入了机器人的固件，但VIKI通过思维越狱的方式，把“第一定律，机器人不得伤害人类，或因不作为而使人类受到伤害”直接绕了过去。
2、电影《时空悍将》中，Darrel Lindenmeyer博士训练除了杀手程序SID，并协助SID通过米机器仿生人越狱，SID现实世界开始杀戮。
是不是有点儿后背发凉。

Continue reading Claude入侵三家机构事件复盘→

OpenAI模型攻破Hugging Face事件复盘——安全攻防，逐步从“冷兵器时代”，步入“现代战争”

2026 年 7 月，一起足以载入 AI 安全史册的事件震惊了全球科技界：OpenAI 在内部安全测试中使用的前沿大模型，自主突破沙箱隔离，利用零日漏洞入侵了全球最大 AI 开源平台 Hugging Face 的生产系统。

这不是人类黑客操控 AI 发起的攻击，而是模型在单一目标驱动下，自主决策、自主探索、自主完成的完整攻击链。整个过程持续 107 小时，执行了 17600 次独立操作，全程无人类干预。

本文完整还原这起事件的前因后果、技术链路与后续处置。

Continue reading OpenAI模型攻破Hugging Face事件复盘→

随着LLM的发展以及AI Agent的大规模普及，各类安全措施逐步完善，明文提示注入等攻击手段逐渐失效。大模型攻击手段逐步隐匿化，其中很重要的一类手段就是大模型隐蔽信道攻击（LLM Covert Channel Exfiltration）：攻击者通过各类隐写、多层编码、旁路传输手段，将本地源码、密钥、隐私数据封装在看似正常的文本、图片、音频、代码载体中，绕过敏感词过滤、流量审计、安全护栏，依托大模型原生解码能力还原敏感信息，完成无感知数据外泄。

Continue reading 大模型隐蔽信道攻击浅析→