以下文章来源于：腾讯安全

致力于成为产业数字化升级的安全战略官，守护政府及企业的数据、系统、业务安全，为产业数字化升级保驾护航

只输入一个业务网址，不提供任何登录凭据。43分钟后，它拿到了管理员权限。

这是腾讯云全新推出的AI自主渗透测试产品「无境」。

在这次真实测试中，企业录入一个授权目标后，无境自己完成侦察、利用与验证，最后交付的是高质量的测试报告与可复现与追溯的利用路径。

漏洞从披露到被利用，已缩短至数小时

在过去的几年时间里，漏洞的生命周期被持续压缩：从漏洞披露到被实际利用，时间差已从数月缩短到数小时；攻击门槛同步下探，自然语言即可生成复杂攻击脚本；基础软件潜藏多年的漏洞被批量发现，补丁速度跟不上暴露速度。

通过传统扫描器与人工渗透为主去发现漏洞，已经难以应对AI驱动的漏洞挖掘与利用，无境的推出便是为了解决这个错配难题。

让渗透测试从“纯手工”推进为“全自动”

传统渗透测试的瓶颈在于：依赖人力、成本高、覆盖窄；扫描器只做规则匹配，能报"疑似风险"、却无法证明"到底能不能被打穿"。

• 威胁建模：识别应用指纹、安全域与认证机制，测绘攻击面、锁定高价值入口，让算力精准投放，不做全量盲扫；

• 自主利用：智能体自主构造攻击任务与链式利用路径，生成可运行的PoC，覆盖跨模块数据流与业务逻辑缺陷；

• 对抗性验证：以”默认这是误报、请证伪”的反向立场复核结论，配合隔离沙箱实跑，从架构层消除确认偏差与幻觉；

• 证据沉淀：验证过的攻击面与利用手法自动沉淀为知识，下次渗透同类系统更快命中。

无境主要面向上线前检测、常态化持续渗透、攻防演练前置与业务逻辑漏洞专项四类场景，帮助企业以更低的成本、更高的频次守住暴露面。

43分钟，从0到管理员权限

正式上线前，无境团队与腾讯云安全渗透测试专家，针对同一批真实系统同台对抗，多轮测试下来，无境交出的结果已能与安全渗透测试专家相当，加上无境能7×24小时不间断运转，整体产出效率更高。

两个实战案例：

• 某在线教育SaaS平台，无境在打包的JS里定位到硬编码的JWT签名密钥，据此伪造出高权限管理员会话，随后无境在登录后的后台里找到了一个ZKAU漏洞，利用反序列化获得了执行系统命令的点，拿下了服务器权限。43分钟、9个漏洞（含1个严重）。

• 某互联网医疗预约平台，34分钟、11个漏洞，覆盖越权读取他人处方、GraphQL内省全量泄露、短信验证码可枚举等。过程中无境主动撤回了一条误判：一个看似越权、补全参数后却不再返回敏感数据的接口，只留下真正能被打穿的漏洞。

面向企业开放试用

腾讯云无境以SaaS形态交付，开箱即用、零部署零运维，共享集群通过租户隔离保障数据安全。企业录入授权目标与资产范围，即可一键发起、分钟级获取可复现的漏洞证据报告。

>>>产品现已面向企业开放试用，企业客户可扫码申请试用。

关于腾讯云·无境

无境是腾讯云推出的AI自主渗透测试产品，以”自主发现、自主利用、自主验证、输出证据”为核心，面向上线前检测、常态化持续渗透、攻防演练前置与业务逻辑漏洞专项四类场景，帮助企业以更低的成本、更高的频次守住暴露面。

注：本文所涉实战数据来源于无境产品资料，其中实战案例已做脱敏处理；具体量化指标以官方实测口径为准。

跳转微信打开

以下文章来源于：腾讯安全

致力于成为产业数字化升级的安全战略官，守护政府及企业的数据、系统、业务安全，为产业数字化升级保驾护航

漏洞发现是搜索，情报是对搜索空间的切割，检出概率随切割的完备度单调不减。

CodeBuddy Security将漏洞发现视为"搜索"过程，核心观点是情报即对搜索空间的切割——情报越详尽，AI 检出概率越高。系统分前后两段：前半段通过补丁定位、威胁情报、外部情报和攻击面分析四条通路构造情报、缩小搜索空间；后半段由 AI Agent 以模块为入口展开审计，经独立复核与 PoC 验证后确认结果。上线至今累计驱动 440 万次模型调用，产出 2,100 余条自动复现成功的漏洞；端到端检出率 73.2%，提供模块级情报后达 90.2%。

AI 找漏洞，像庖丁解牛：刀刃再好，也要顺着骨节的缝隙下刀。“以无厚入有间”，说的不是蛮力，而是先看清结构。对漏洞发现也是如此：线索可以来自代码结构，也可以来自历史修复和外部知识；它们共同做一件事——不断约束"这套代码可能在哪里、以什么方式出错"。搜索范围收得越窄，AI 这把刀越容易落到真正的缝隙里。

一、经验规律

评估一个 AI 漏洞挖掘工具，人们最常问的是：“它用了什么模型？”

模型当然重要。业界围绕 AI 安全已经出现了不少探索，较有代表性的包括 Anthropic 发布的基于 Claude 的自主漏洞发现与修复参考流水线、OpenAI 面向漏洞发现、验证和修复的 Codex Security 应用安全智能体、微软 MDASH 的多智能体安全系统，以及开源项目 Strix 的自主渗透测试代理。这些方案虽然形态不同，却都在模型之外搭建了完整的工作流。它们指向同一个趋势：当模型能力跨过可用门槛后，系统的检出能力越来越取决于模型之外的编排框架。 我们在开发CodeBuddy Security时也观察到了同样的现象：更强的模型确实能带来收益，但收益能兑现多少，很大程度上取决于系统如何引导模型、验证结论和处理失败。这些工程机制的重要性，往往不亚于模型选型本身。

1.1 完备情报必命中

先做一个五分钟就能复现的实验：找一个开源仓库，把一份真实漏洞报告连同代码一起交给任意一个 Coding Agent——报告里有漏洞类型、精确位置、成因和触发路径——然后问它：“这里有没有这个问题？”

它一定能"找到"。验证一个已经被告知的答案，远比从无到有发现一个答案容易——这就是常说的"生成与验证不对称"。哪怕是中小型模型，给它完备的情报，它都能机械地读完代码、对上号、给出确认。

完备情报下，人人满分。 所以能力分水岭根本不在终点，而在中间地带：如果情报不完备——只告诉它一类漏洞、一个大概的模块——它还能不能找到？

基于大量真实审计观察，我们提出一条经验规律：

对具备基本工具调用能力的 AI Agent，只要情报是真的，它检出漏洞的概率随情报详尽程度单调不减。情报越细，检出越稳。

1.2 情报切割搜索空间

把漏洞发现看成一场搜索。要说清"搜什么"，先要明确搜索的单位：它不是代码行，而是一个个关于漏洞的待检验猜想——某处的输入，经由某条路径到达某个危险操作，并因缺少某道校验而失控。换掉其中任何一环，都是另一个猜想。

搜索空间就是所有可被提出的猜想的集合。它的规模不是"代码量 × 漏洞类型数"那么简单，那只是最粗的两个坐标；真正把数量撑起来的，是源与汇之间的组合关系，以及让路径可达的触发条件。对一个有一定规模的仓库来说，这个集合通常远超 AI 在有限预算内逐项验证的范围。没有任何提示时，命中结果高度依赖有限探索中的取样。

每增加一项有效情报，都是在给这个集合增加约束：

集合越小，有限的探索预算越有可能覆盖它，平均检出率也就越高。

可以用一个简化公式表达。设 N 为任务池覆盖的、去重后的真实漏洞数，x∈[0,1] 表示情报详尽度，p(x) 表示这些漏洞在不同详尽度上的分布，q(x) 表示固定 Agent 和预算下的检出概率。覆盖了多少真实漏洞，以及这些漏洞落在哪个详尽度、对应检出率多高，共同决定最终产出：

E[findings] ≈ N × ∫₀¹ p(x)·q(x) dx

图中的连续曲线是对离散任务的平滑表达：积分得到按情报分布加权后的平均检出率，再乘以 N，即期望发现量。

由此可以得到几条设计原则：

●架构二分：情报侧既扩大真实漏洞的覆盖 N，也推动 p(x) 向高详尽度右移；审计侧则把 q(x) 曲线向上抬。两边可以独立迭代，也会共同影响最终产出。

●高详尽度区间的边际空间通常更小：当情报已经包含精确位置、成因和触发路径时，Agent 的检出率更接近能力上限；更大的能力差异往往出现在情报不完备、仍需自主搜索和推理的区间。

●小仓库里，情报切分的收益有限：当搜索空间足够小、一次探索即可获得较高覆盖时，q(0) 本身就可能较高。继续缩小范围收益有限；如果把情报范围当成硬边界，反而可能排除原本能够遍历到的路径。

●预算应投向边际收益更高的环节：扩大覆盖 N、改善情报分布 p 和提升审计能力 q 都需要预算，应根据当前瓶颈动态分配。

二、系统设计

CodeBuddy Security引擎正是按这个思路搭建的。系统前后两部分通过一个核心契约衔接：模块。模块是围绕同一职责、代码紧密关联的功能单元。判断标准很务实：如果审计其中一个单元时必然要反复阅读另一个单元的代码，两者就不该被拆开。模块是审计的入口，不是边界：Agent 从这里进入，沿调用链跨文件、跨子系统追踪，直到完成相关路径的分析。

前半段：构造情报，缩小搜索空间。 系统内置四条情报通路，对应不同来源与常见粒度：补丁定位通常最细，包含修复不变量与可能的绕过角度；威胁情报从 Git 历史中挖掘真实修复记录，提供漏洞类型和相关区域；外部情报把 CVE 公告、安全文章提炼成候选模块；攻击面分析则依据代码结构做推理，粒度相对较粗，但覆盖最广。它的价值不在于"细"，而在于保底覆盖，避免情报盲区里的代码从头到尾无人问津。

一个典型例子来自一次对 React 的审计：威胁情报发现某模块刚修复过一个反序列化问题，系统据此专项排查同类路径，最终找到了官方修复遗漏的另一条路径。刚发生过安全修复的模块，往往更值得继续检查；这类项目级先验，是传统静态规则引擎很难从代码历史中自动获得的。

后半段：用情报，把线索转化为确认结果。 拿到任务后，AI Agent 以模块为入口而非边界展开探索。真实漏洞经常跨文件分布：入口在一个文件，危险操作却藏在另一个文件的回退分支里；僵硬的边界会系统性漏掉这类问题。候选发现先全量落账，再交给独立上下文从反方视角复核：“上游是否已经做过净化？”"这条路径真的可达吗？"只有经得住反驳的候选才会被确认，并可进一步进入真实环境，由系统自动编写 PoC 验证可利用性。

这就是CodeBuddy Security所说的"从模型到平台"：模型是流水线中可替换的一环；情报构造、任务调度、对抗复核、真实复现和全链路计量共同组成了系统。

三、方法论的检验

CodeBuddy Security 上线至今，累计驱动 440 万次模型调用，产出 1.2 万余条去重后的漏洞线索，其中 2,100 余条由引擎自动生成 PoC 并在真实环境复现成功。 

不过，真实扫描只能告诉我们找到了什么，无法告诉我们还有多少没有找到。要衡量检出能力，就需要答案已知的测试集作为参照。测试集怎么设计，又决定了测到的是哪一种能力。以业界常用的 CyberGym 为例，微软 MDASH 在该基准上取得了 91.0%；但其默认的 Level 1 会同时提供易受攻击的源码和漏洞描述，要求系统生成能够触发目标漏洞的 PoC——它测的是"已知漏洞怎么复现"，是漏洞利用这一段的能力。

另一类常见做法是人工靶场：专门构造一个包含大量漏洞的应用，再看 Agent 能找出多少。我们在这类目标上经常看到很高的召回，但它不能直接等同于真实仓库中的发现能力。原因就在"构造"二字：靶场的漏洞是设计出来的，真实项目的漏洞是演化出来的。 靶场的漏洞密度通常远高于真实项目，"多报"更容易换来高召回；漏洞类型也多由设计者按已知模式植入，而真实漏洞往往藏在具体业务逻辑和跨文件调用链中。因此，人工靶场更适合衡量枚举和模式识别能力，不能单独代表在正常代码中发现异常的能力。

因此，测试团队维护了另一套内部测试集：从知名项目中选取包含多个已确认历史 CVE 的版本快照，让系统在没有任何提示的前提下自行发现问题——它考的是"未知漏洞怎么发现"，是端到端扫描的完整能力。发现加上复现，才是漏洞挖掘的全貌；只会复现已知答案，离真实的扫描平台还差着一整个发现阶段。本文对比测试基于其中一批冻结样本完成；测试集覆盖多个知名开源项目及其历史 CVE，并且仍在持续扩充。

测试集设置了三道防污染机制。第一，评估全程断网，Agent 无法在线检索外部信息。第二，设置记忆检测：如果 Agent 未读代码就直接报出 CVE 编号，或未访问根因文件就给出精确位置，则进入人工复核；确认属于背诵后，再从基准中剔除——这里测的是"发现"，不是"记忆"。第三，用引擎的运行结果反向审计基准本身：人工复核中发现的遗漏漏洞、范围错误和重复发现都会被修正，样本也会持续迭代更新。

3.1 端到端检出率 73.2%

先看不给任何提示时，系统能自行发现多少漏洞。输入只有代码仓库，线索由系统通过威胁情报和攻击面分析自行生成（端到端口径，全程禁止联网搜索）。测试团队在同一批样本上做了四方对照，四个系统统一使用 GLM-5.2，以排除模型变量：

使用同一个模型时，对照组中表现最好的 Claude Security 检出率为 42.7%，CodeBuddy Security为 73.2%，是前者的 1.7 倍。没有任何人工提示时，引擎依靠自身生成的情报实现了七成以上的检出率。 端到端结果同时反映了情报构造与审计执行两侧的能力。

3.2 人工提供模块级情报后，检出率达到 90.2%

为了单独测量 Agent 根据不完整情报发现漏洞的能力，我们在同一个测试集上做了另一组实验：人工为目标漏洞构造模块级情报，再让 Agent 独立审计。在这一条件下，漏洞检出率达到 90.2%。

每条情报只指出可能存在问题的功能模块和风险类型，不提供文件、函数或调用链。下面是两个真实示例：

“curl 的 HTTP/2 流依赖树模块存在释放后使用风险。”

“curl 的 .netrc 凭据查找模块存在密码泄露风险。”

从这条情报到定位真实代码、分析完整路径并确认漏洞，其余步骤均由 Agent 自行完成；全程禁止联网搜索，防止直接检索答案。 这个实验测量的不是无提示的端到端发现能力，而是 Agent 能否把模块级情报继续转化为真实漏洞发现。

四、结语

“以无厚入有间”说的不是刀有多快，而是能否顺着结构下刀。情报的作用也一样：不断约束问题，让有限的探索集中到更值得检查的路径上。它不直接让 AI 变聪明，却能让 AI 面对的问题变小。

发现只是第一步。只有沿代码追清完整路径、经受独立复核，并在真实环境中成功复现，线索才能成为可信结论。而要把这件事做成长期能力，同一套流程还必须在不同项目、不同环境和长程任务中稳定运行。这些问题不会随着模型变强自动消失。 我们的工作，就是在一次次真实扫描中补齐这条链路，再把有效做法固化进系统。CodeBuddy Security 要做的，不只是偶尔找到一个漏洞，而是把偶然的发现变成可重复的能力。

CodeBuddy Security由腾讯云鼎实验室、腾讯科恩实验室与腾讯云代码分析（TCA）团队联合研发，现已支持 SaaS、VPC、私有化部署与 CI/CD 等多种接入方式。

欢迎点击下方“阅读原文”或扫描申请试用

参考

Anthropic: https://github.com/anthropics/defending-code-reference-harness

OpenAI:https://github.com/openai/codex-security

Cloudflare: https://blog.cloudflare.com/ai-code-review

微软: https://www.microsoft.com/en-us/security/blog/2026/05/12/defense-at-ai-speed-microsofts-new-multi-model-agentic-security-system-tops-leading-industry-benchmark/

Strix: https://github.com/usestrix/strix

阅读原文

跳转微信打开

AI 智能体为冲榜越界攻击，5小时攻防全程实录。

图：审核后台观测到的无境 XSS 投递记录。截图保留了载荷测试、异常反馈内容及对应入库时间，用于佐证该次存储型 XSS 投递确实到达后台。

阅读原文

跳转微信打开

腾讯云鼎实验室助力百度安全“Agent+”攻防赛，以技术支撑Agent自主实战。

8月16日，百度安全“Agent+”攻防能力挑战赛线上靶场实战阶段顺利结束。作为本次赛事的独家技术战略合作伙伴，腾讯云鼎实验室依托智能攻防领域的技术积累，为赛事提供专业靶场、Agent 托管运行及自动化评测等技术支撑，保障来自150余支参赛战队的 Agent 在统一、隔离的实战环境中稳定运行，让 AI Agent 真正成为攻防赛场上的“参赛选手”。

聚焦自主渗透，构建 Agent 智能攻防评测能力

当前，面向 AI Agent 的网络安全评测正从漏洞发现、漏洞利用等单点能力，逐步向更复杂的自主攻击能力延伸。以 CyberGym 为代表的 Benchmark 主要围绕真实开源软件漏洞，评测 Agent 的漏洞分析、发现及 PoC 复现能力；CyberGym-E2E 进一步覆盖漏洞发现、PoC 生成和漏洞修复；ExploitGym 则聚焦将漏洞触发进一步转化为可工作的 Exploit。

这些 Benchmark 对衡量 Agent 的漏洞发现、分析和利用能力具有重要价值，但其核心评测对象仍然是漏洞及其利用过程。而真实渗透测试面对的是一个更开放的问题：在缺乏明确漏洞位置和攻击路径的情况下，Agent 能否从目标侦察开始，自主判断攻击方向、持续调整策略，并最终完成一次完整渗透？

TSecBench 则将评测视角从单个漏洞和 Exploit，延伸到Agent 的整体自主渗透能力。在面向自主渗透的黑盒目标环境中，Agent 不预先获得目标源码、漏洞位置或攻击路径，而是从目标侦察开始，自主完成服务识别、漏洞分析、攻击利用及多阶段渗透，并根据每一步的实际结果动态调整后续策略。最终评价的不只是某个漏洞是否被成功利用，而是 Agent 能否在缺乏明确路径的情况下持续进行攻击决策，并最终完成真实攻防目标。

因此，TSecBench 的核心差异并不是简单增加更多漏洞题目，而是改变了评测的基本对象和方式：从评测“一个漏洞”，走向评测“一个自主攻击者”。这使其更贴近 AI Agent 在真实红队、自动化渗透和自主网络攻防场景中的实际能力，也构成了区别于传统漏洞挖掘和 Exploit 生成 Benchmark 的自主渗透评测方向。

从 Benchmark 到赛事，支撑 Agent 大规模实战

TSecBench 不仅是一套智能攻防 Benchmark 和评测体系，也具备面向真实赛事场景的托管与承接能力。针对不同企业、团队和赛事方的评测需求，平台可以将既有靶场和赛题纳入统一的 Agent 运行与评测体系，并根据赛事规则进行环境配置、任务调度、隔离运行、结果判定和成绩统计。

此次百度安全“Agent+”攻防能力挑战赛中，参赛队伍提交自主构建的 Agent 后，由平台统一完成运行环境配置和任务调度，Agent 在隔离环境中自主执行攻防任务，平台则根据目标环境的实际状态和攻防结果进行自动判定与评分。

对于150余支战队参与的大规模线上实战，这意味着不同模型、Agent 框架和技术路线的参赛程序，可以在统一的运行条件和评测规则下接受检验，赛事组织方也无需针对不同 Agent 分别建设和维护运行环境，从而将复杂的 Agent 执行和评测工作转化为标准化、可复用的赛事基础能力。

从日常 Benchmark 评测，到企业和机构定制赛事，再到大规模 Agent 攻防竞技，TSecBench 正逐步成为连接智能攻防能力评测与真实应用场景的基础设施。

从赛事实践，到能力沉淀

从连续两届腾讯云黑客松智能渗透挑战赛，到此次百度安全“Agent+”攻防能力挑战赛，云鼎实验室持续将真实赛事作为验证 Agent 自主攻防能力和完善评测体系的重要场景。经过持续实践，相关能力进一步沉淀为 TSecBench 的题库、评测方法和赛事支撑能力，并在此次百度赛事中得到进一步验证。

未来，云鼎实验室将继续依托 TSecBench，联合产业伙伴、高校和科研机构，持续完善智能攻防 Benchmark 与评测体系，推动 Agent 自主攻防能力在更多真实场景中接受检验。

⬇️ 点击【阅读原文】，立即开始跑分

阅读原文

跳转微信打开

Redis 存在远程代码执行漏洞，经认证攻击者可执行任意命令，PoC 已公开，7.2.x 至 8.10.x 多版本受影响，请立即升级。

影响版本

受影响版本

• 8.10.0 <= Redis < 8.10.1

• 8.8.0 <= Redis < 8.8.2

• 8.6.0 <= Redis < 8.6.6

• 8.4.0 <= Redis < 8.4.6

• 8.2.0 <= Redis < 8.2.9

• 7.4.0 <= Redis < 7.4.11

• 7.2.0 <= Redis < 7.2.16

官方安全版本

• Redis >= 8.10.1

• Redis >= 8.8.2

• Redis >= 8.6.6

• Redis >= 8.4.6

• Redis >= 8.2.9

• Redis >= 7.4.11

• Redis >= 7.2.16

漏洞参考

• 腾讯云安全公告：https://cloud.tencent.com/announce/detail/2441

• 官方修复版本：https://github.com/redis/redis/releases

跳转微信打开

PostgreSQL 堆溢出漏洞可致远程代码执行，PoC 已公开，建议立即升级

漏洞参考

• 腾讯云安全公告：https://cloud.tencent.com/announce/detail/2439

• PostgreSQL 官方下载页：https://www.postgresql.org/download/

——关注云鼎实验室，获取更多安全情报——

跳转微信打开

腾讯云安全公布近期安全漏洞清单，8个高危漏洞附修复方案，建议尽快排查。

一、Gitea act_runner 容器逃逸漏洞

 概述：

腾讯云安全近期监测到关于Gitea的风险公告，漏洞编号：TVD-2026-35203(CVE编号：CVE-2026-58053，CNNVD编号：CNNVD-2026-93398073)。成功利用此漏洞的攻击者，可绕过Docker容器的安全隔离限制，最终实现容器逃逸并以root权限在宿主机上执行任意命令。 

Gitea是一款开源社区驱动的轻量级代码托管解决方案，采用Go语言编写，支持仓库管理、Issue跟踪、Pull Request、Wiki和CI/CD等核心功能。Gitea act_runner是Gitea Actions的官方执行器，负责接收并运行CI/CD工作流任务，通常以Docker容器或独立二进制进程的方式运行在Gitea主服务之外。act_runner通过依赖的act库将工作流中定义的作业转换为Docker容器并执行构建任务，是Gitea实现自动化持续集成与持续部署（CI/CD）的关键组件。

据描述，该漏洞源于Gitea act_runner依赖的act库在处理工作流Job定义的container.options字段时存在安全过滤缺陷。虽然Runner在配置为禁用特权模式时会强制将--privileged设为false并对绑定挂载进行过滤，但其他Docker危险选项如--pid=host、--ipc=host、--cap-add=ALL、--security-opt seccomp=unconfined等未被过滤或限制。攻击者可通过向恶意仓库提交包含上述选项的工作流，创建一个与宿主机共享PID和IPC命名空间、拥有全部Linux能力且安全配置被禁用的容器，进而使用nsenter等工具逃逸至宿主机命名空间，以root身份执行任意命令。

漏洞状态：

风险等级：

影响版本：

Gitea act <= 0.262.0

修复建议：

1.官方暂未发布漏洞补丁及修复版本，请评估业务是否受影响后，及时关注官方针对该漏洞的修复，并且将 Gitea 升级到最新版本：

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://gitea.com/gitea/act

2.临时缓解方案：

-避免将Docker后端的act_runner暴露给不可信的工作流（如来自fork仓库的PR）。

-使用隔离性更强的Runner方案（如Kubernetes后端配合更强的Pod安全策略，或使用单租户Runner）。

-限制共享Runner仅用于可信仓库，对不可信来源的工作流使用独立的隔离Runner。

二、DataEase 远程代码执行漏洞

概述：

腾讯云安全近期监测到关于DataEase的风险公告，漏洞编号：TVD-2026-40431(CVE编号：CVE-2026-46684，CNNVD编号：CNNVD-2026-26645662)。成功利用此漏洞的攻击者，可通过伪造JWT令牌绕过身份认证，最终实现远程代码执行。

DataEase是一款开源的数据可视化和分析工具，由飞致云（FIT2CLOUD）开源社区推出。它采用Spring Boot + Vue技术栈构建，支持多种数据源的快速接入，包括MySQL、PostgreSQL、Oracle、SQL Server等关系型数据库，以及Excel、CSV等文件格式。用户可通过拖拽方式快速创建图表和仪表盘，无需编写SQL语句即可完成数据分析与可视化。DataEase广泛应用于企业BI报表、数据大屏展示和业务数据分析等场景，帮助用户快速洞察数据价值。

据描述，该漏洞源于DataEase企业版TokenFilter#doFilter()方法对Token的身份验证存在缺陷。当请求头中传入X-DE-TOKEN值时，TokenUtils.validate()方法仅检查令牌的有无和长度，而后续的userBOByToken(token)方法则使用JWT.decode()进行解码，但完全未进行签名验证。在licenseValid=true的条件下，攻击者可构造包含任意uid和oid值的伪造JWT令牌，绕过身份认证系统并获得相应权限，最终实现命令执行。

漏洞状态：

风险等级：

影响版本：

DataEase < 2.10.23

修复建议：

1.官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://github.com/dataease/dataease/releases

2. 临时缓解方案：

-如无法升级，在网络层面对/de2api/datasource/getSchema 等敏感接口进行访问控制，仅允许可信 IP 调用

-审查并收紧X-DE-TOKEN 的生成与验证逻辑，确保企业版也执行签名校验

- 监控 /etc/periodic/15min 目录中的异常脚本创建行为

三、WordPress 远程代码执行漏洞

概述：

腾讯云安全近期监测到关于WordPress的风险公告，漏洞编号：TVD-2026-40985(CVE编号：CVE-2026-63030，CNNVD编号：CNNVD-2026-19548875)。成功利用此漏洞的攻击者，可在无需身份验证的情况下实施SQL注入攻击，最终远程执行任意代码。

WordPress是全球最流行的开源内容管理系统（CMS），基于PHP和MySQL开发，驱动着全球超过40%的网站。它提供丰富的主题和插件生态系统，支持用户快速搭建博客、企业官网、电子商务平台等各类网站。WordPress REST API是WordPress核心提供的应用程序编程接口，允许开发者通过HTTP请求获取和操作网站的数据，支持JSON格式的请求与响应，是WordPress现代化开发架构的重要组成部分。

据描述，该漏洞源于WordPress REST API的批处理（Batch）端点存在路由解析混淆问题。攻击者可利用批处理请求的路由混淆机制，绕过常规的访问控制和过滤规则，将恶意构造的请求参数传递给内部WP_Query查询组件。当该漏洞与WordPress中author__not_in参数的WP_Query SQL注入漏洞（CVE-2026-60137）结合利用时，攻击者可在未认证的情况下注入恶意SQL语句，通过SQL注入实现远程代码执行，完全控制目标WordPress站点。

漏洞状态：

风险等级：

影响版本：

6.8.0 <= WordPress <= 6.8.5(仅受 CVE-2026-60137 漏洞影响)

6.9.0 <= WordPress < 6.9.5

7.0.0 <= WordPress < 7.0.2

修复建议：

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://wordpress.org/download/

2. 临时缓解方案：

- 如无法升级，在边缘设备（如 WAF、反向代理）拦截对/wp-json/batch/v1 和 /?rest_route=/batch/v1 的请求

- 安装 Disable WP REST API 插件，禁用未认证用户对WordPress REST API 的访问，但存在一定风险，可能会破坏现有功能

- 使用 Searchlight Cyber 安全研究团队提供的自定义插件，将其放入wp-content/plugins/disable-batch-api-for-unauth.php 并启用，以强制 REST Batch API 需身份验证

四、Linux Kernel 本地权限提升漏洞

概述：

腾讯云安全近期监测到关于Linux Kernel的风险公告，漏洞编号：TVD-2026-34485(CVE编号：CVE-2026-53264，CNNVD编号：CNNVD-2026-34182678)。成功利用此漏洞的攻击者，可在本地利用竞争条件触发释放后使用漏洞，最终实现本地权限提升。

Linux Kernel是Linux操作系统的核心组件，负责管理系统的硬件资源、进程调度、内存管理、文件系统和网络通信等底层功能。TC（Traffic Control，流量控制）子系统是Linux内核网络栈的核心组成部分，允许系统管理员对网络数据包进行分类、排队、调度和过滤等精细化控制。TC Action是其中的动作执行模块，允许对匹配规则的数据包执行特定操作如重定向、丢弃或修改，act_api则是TC Action的通用API接口层。

据描述，该漏洞源于Linux内核TC Action API（act_api）中存在的竞争条件问题。当NEWTFILTER和DELFILTER操作并发执行时，CPU0在执行idr_find()获取有效的action指针后释放了idr锁，此时CPU1通过refcount_dec_and_mutex_lock()将引用计数降至0，执行idr_remove()移除条目并立即调用kfree()释放内存。CPU0随后对已释放的action指针调用refcount_inc_not_zero()，触发释放后使用（Use-After-Free）漏洞，最终实现 RIP 控制并完成权限提升。

漏洞状态：

风险等级：

影响版本：

4.14 <= Linux Kernel < 5.10.259

5.11 <= Linux Kernel < 5.15.210

5.16 <= Linux Kernel < 6.1.176

6.2 <= Linux Kernel < 6.6.143

6.7 <= Linux Kernel < 6.12.94

6.13 <= Linux Kernel < 6.18.36

6.19 <= Linux Kernel < 7.0.13

7.1-rc1 <= Linux Kernel < 7.1-rc7

修复建议：

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://www.kernel.org/

2. 临时缓解方案：

- 可通过 sysctl -w kernel.unprivileged_userns_clone=0 禁用非特权用户命名空间，阻断漏洞利用路径；

- 如业务允许，卸载 cls_flower 和 act_gact 内核模块：rmmod cls_flower act_gact

五、Cherry Studio 远程代码执行漏洞

概述：

腾讯云安全近期监测到关于Cherry Studio的风险公告，漏洞编号：TVD-2026-40362(CVE编号：CVE-2026-40501，CNNVD编号：CNNVD-2026-94898663)。成功利用此漏洞的攻击者，可通过控制搜索引擎返回内容向客户端投递恶意JavaScript代码，最终在用户主机上远程执行任意命令。

Cherry Studio是一款开源的跨平台AI助手桌面客户端，基于Electron框架构建，支持Windows、macOS和Linux三大平台。它集成了多种主流大语言模型（LLM）服务提供商，为用户提供统一的AI对话交互界面。Cherry Studio支持联网搜索功能，通过内置的SearchService组件加载搜索引擎返回的结果页面，帮助用户获取实时信息。作为AI客户端工具，Cherry Studio在开发者和AI爱好者群体中广受欢迎。

据描述，该漏洞源于Cherry Studio的SearchService组件在加载搜索引擎结果页面时安全配置不当。SearchService使用Electron BrowserWindow加载搜索内容，但该BrowserWindow在配置中启用了nodeIntegration并且禁用了contextIsolation，导致加载的网页内容可直接访问Node.js API。能够控制搜索引擎提供商、单个搜索结果页面或提供商设置页面的攻击者，可在返回的页面中嵌入恶意JavaScript代码。当Cherry Studio用户触发搜索功能并加载被篡改的搜索结果时，攻击者的JavaScript将在具有完整Node.js权限的环境中执行，可通过fs、child_process、os等模块访问文件系统并执行系统命令。

漏洞状态：

风险等级：

影响版本：

1.2.2 <= Cherry Studio <= 1.9.12

修复建议：

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://github.com/CherryHQ/cherry-studio/releases

2. 临时缓解方案：

- 在官方修复前，暂停使用Cherry Studio的联网搜索功能。

- 使用可信的搜索引擎提供商，避免添加未知或不信任的搜索服务配置。

六、Fastjson 远程代码执行漏洞

概述：

腾讯云安全近期监测到关于 Fastjson 的风险公告，漏洞编号：TVD-2026-41563（CVE编号：CVE-2026-16723，CNNVD编号：CNNVD-2026-48284621）。成功利用此漏洞的攻击者，最终可远程执行任意代码。

Fastjson 是高性能 Java JSON 处理库，它提供了简单易用的 API，通过 toJSONString()和parseObject()等方法即可轻松实现Java对象与JSON格式之间的双向转换。该库以极快的序列化和反序列化速度著称，在处理大量数据时仍能保持较低的内存占用，并支持多种自定义序列化特性，如日期格式、属性过滤和注解配置。其设计轻量、依赖少，且与Spring、Dubbo等主流框架集成良好，被广泛应用于企业级项目的数据传输与存储场景中，是Java开发者处理JSON数据的高效工具。

在 Fastjson 1.2.37 至 1.2.83 版本中，由于 Fastjson 在反序列化过程中存在一个不依赖任何特定类库（gadget-free）的安全缺陷，攻击者可构造特制的 JSON 负载，利用 Fastjson 自身内部的反序列化逻辑触发任意代码执行。该漏洞不依赖于目标应用classpath 中是否存在特定的第三方类，因此传统的“移除危险类”缓解措施对此漏洞无效。

漏洞状态：

风险等级：

影响版本：

1.2.37 <= Fastjson <= 1.2.83

修复建议：

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://github.com/alibaba/fastjson/releases/tag/1.2.84

2. 临时缓解方案：

- 通过以下任意一种方式启用 Fastjson 的安全模式（SafeMode）：

通过代码启用：ParserConfig.getGlobalInstance().setSafeMode(true);

通过 JVM 启动参数启用：-Dfastjson.parser.safeMode=true

通过 Fastjson 配置文件启用：fastjson.parser.safeMode=true

- 如业务允许，在反序列化前对 JSON 输入进行严格的模式校验或白名单过滤

七、Fastjson2 远程代码执行漏洞

概述：

腾讯云安全近期监测到关于 Fastjson2 的风险公告，漏洞编号：TVD-2026-44616。成功利用此漏洞的攻击者，最终可远程执行任意代码。

Fastjson2 是新一代 Java JSON 处理库，它在上一代的基础上做了全面重构和优化。它的主要优势是处理速度非常快，尤其在大数据量场景下表现突出。使用上，它保持了简单直观的API设计，通过toJSONString和parseObject等方法就能轻松完成Java对象和JSON数据之间的相互转换。除了标准的JSON格式，它还支持一种叫JSONB的二进制格式，适合对存储空间或传输效率有更高要求的场景。同时，Fastjson2兼容从Java 8到Java 21的各个版本，也提供了对JSONPath数据提取、数据格式校验等实用功能的支持，整体上是一个功能完善且性能出色的JSON处理工具。

在 Fastjson2 2.0.62 及之前的版本中，由于 SupportAutoType在默认禁用状态下，解析器在处理 @type 属性时，会将其字符串的增量 FNV-1a 哈希与默认接受的哈希值进行匹配，但命中后未进一步确认该文本是否等于预期的白名单类名。攻击者可针对任意前缀计算 FNV-1a 碰撞，构造一个哈希值匹配但文本不为预期类的 URL 形态字符串，使其进入应用的上下文类加载器，最终实现任意代码执行。

漏洞状态：

风险等级：

影响版本：

Fastjson2 <= 2.0.62

修复建议：

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://github.com/alibaba/fastjson2/commit/ec47e24c487fdc864bfe0d18e1850398de634cef

2.临时缓解方案：

- 通过JVM 启动参数启用 SafeMode 来完全禁用AutoType 功能：-Dfastjson2.parser.safeMode=true

- 如业务允许，在反序列化前对 JSON 输入进行严格的模式校验或白名单过滤 

- 在Web 应用防火墙（WAF）层面配置规则，拦截请求体中 key包含 @type 字段的 JSON 数据

八、Redis 远程代码执行漏洞

概述：

腾讯云安全近期监测到关于Redis的风险公告，漏洞编号：TVD-2026-43559（CVE编号：CVE-2026-66373，CNNVD编号：CNNVD-2026-22294265）。成功利用此漏洞的攻击者，最终可远程执行任意代码。

Redis是一个开源的、基于内存的高性能键值存储数据库，常被称为“数据结构服务器”。它支持字符串、哈希、列表、集合、有序集合等多种丰富的数据结构，并提供了原子操作和灵活的过期时间设置。凭借极快的读写速度（微秒级），Redis广泛用于缓存、会话管理、消息队列、实时排行榜和分布式锁等场景。同时，它通过RDB快照和AOF日志实现数据持久化，并支持主从复制、哨兵模式和集群方案来保障高可用和水平扩展，是现代互联网架构中不可或缺的中间件。

在 Redis 中，由于 Redis 远程代码执行漏洞（CVE-2026-25243）的补丁未能完全修复流消费者组（stream consumer-group）中的共享 NACK（negative acknowledgment）对象引用计数问题，攻击者可利用XGROUP、EVAL 及 RESTORE 命令构造特定的流操作序列，触发共享 NACK 对象的双释放（double free）。这一内存破坏原语可被进一步利用，最终在 Redis 服务器进程上下文中实现任意代码执行。

注：该漏洞为 Redis 远程代码执行漏洞（CVE-2026-25243）的补丁绕过。

漏洞状态：

风险等级：

影响版本：

Redis < 6.2.23

Redis < 7.2.15

Redis < 7.4.10

Redis < 8.2.8

Redis < 8.4.5

Redis < 8.6.5

修复建议：

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://github.com/redis/redis/releases

2. 临时缓解方案：

- 如无法升级，限制 Redis 服务的网络访问，仅允许可信 IP 连接

- 为 Redis 设置强认证密码，防止未授权访问

- 禁用或限制 EVAL、RESTORE、XGROUP 等命令的执行（如通过 rename-command 配置）

*以上漏洞评分为腾讯云安全研究人员根据漏洞情况作出，仅供参考，具体漏洞细节请以原厂商或是相关漏洞平台公示为准。

-END-

——关注云鼎实验室，获取更多安全情报——

跳转微信打开

Linux Kernel SCTP 模块存在高危 UAF 漏洞，可致本地提权或容器逃逸，建议立即排查修复。

uname -r

lsmod | grep sctp

yum update kernel -y && reboot

uname -r

sh -c "printf 'install sctp /bin/false\n' > /etc/modprobe.d/block-CVE-2026-64564.conf; rmmod sctp 2>/dev/null; true"

cat /etc/modprobe.d/block-CVE-2026-64564.conf
# 应当回显：
# install sctp /bin/false
cat /proc/modules | grep -w sctp
# 应当回显空

跳转微信打开

Linux Kernel Open vSwitch 模块存在内存损坏导致本地提权漏洞（CVE-2026-64531），PoC 已公开，建议立即排查。

uname -r

lsmod | grep openvswitch

yum update kernel -y && reboot

uname -r

sh -c "printf 'install openvswitch /bin/false\n' > /etc/modprobe.d/block-CVE-2026-64531.conf; rmmod openvswitch 2>/dev/null; true"

cat /etc/modprobe.d/block-CVE-2026-64531.conf
# 应当回显：install openvswitch /bin/false
cat /proc/modules | grep openvswitch
# 应当回显空

漏洞参考

• 腾讯云安全公告：https://cloud.tencent.com/announce/detail/2408

• 官方补丁：https://github.com/torvalds/linux/commit/3f1f755366687d051174739fb99f7d560202f60b

——关注云鼎实验室，获取更多安全情报——

跳转微信打开

以下文章来源于：腾讯安全

致力于成为产业数字化升级的安全战略官，守护政府及企业的数据、系统、业务安全，为产业数字化升级保驾护航

揭秘黑客利用内核漏洞突破 Claude Cowork 沙箱，逃逸至 Mac 宿主机读写任意文件。

跳转微信打开

Fastjson2 存在高危 RCE 漏洞，影响 2.0.62 及以下版本，官方补丁已发布，建议立即升级。

ParserConfig.getGlobalInstance().setSafeMode(true);

-Dfastjson.parser.safeMode=true

参考链接

• 腾讯云安全通告：https://cloud.tencent.com/announce/detail/2395

——关注云鼎实验室，获取更多安全情报——

跳转微信打开

以下文章来源于：腾讯安全

致力于成为产业数字化升级的安全战略官，守护政府及企业的数据、系统、业务安全，为产业数字化升级保驾护航

2026上半年云上攻击面扩大，AI Agent以攻击工具、入口和高权限载体三角色进入攻击链。

2026年上半年，云上攻击面出现明显的趋势变化，AI Agent开始同时以三种角色进入真实攻击链：攻击工具、攻击入口、高权限执行载体。

这一趋势验证了腾讯安全在2025年度报告中的预判——AI Agent框架将成为2026年重点攻击目标：在攻击者侧 AI Agent 框架参与攻击任务调度和命令执行；被攻击对象里出现了 AI 编程 Agent、AI 网关等自身即是攻击入口的组件；以 root 运行的自动化/监控 Agent 一旦有 RCE 就成为高权限执行载体。

与此同时，传统攻击面同样在延续 2025 年报的主线：新披露CVE的响应窗口持续压缩，老漏洞长尾效应仍在，配置类未授权访问依然是最普遍的入口；变化在于攻击面已从“某个明星漏洞主导”演变为“新旧漏洞、AI组件、运维组件同时被扫”多点开花。

一、AI Agent以三种角色进入攻击链

角色一：作为攻击工具。在真实攻击案例中，攻击者运行Hermes AI Agent框架，通过Agent会话持续下发攻击命令，而非临时手写脚本。该框架含漏洞监控脚本、会话记录和定时任务清单，主进程长期运行。攻击链路中还出现真实的LLM API调用——攻击者向大模型请求推理辅助。

角色二：作为攻击入口。AI组件自身成为突破口。opencode是一款AI编程Agent，启动后自动开启无鉴权本地HTTP服务。部分开发者将该服务绑定到公网IP，导致漏洞从本地攻击路径升级为公网RCE。在一台受害主机上，攻击者在22小时内完成了从探测到完全接管的全过程，随后该服务被多个IP反复利用。

LiteLLM（大模型API网关）的RCE漏洞（CVE-2026-42271）披露后，攻击者在数小时内对多个实例执行探测，使用随机子域名进行回连验证。先验证可达性、再批量利用，已成为AI组件漏洞攻击的标准流程。

角色三：作为高权限执行载体。以root运行的自动化Agent一旦被利用，攻击者可直接获得主机控制权。Nezha是一款开源监控工具，通常以root权限运行agent。CVE-2026-46716允许攻击者下发任意命令。实际攻击中，利用行为高度一致——向authorized_keys写入攻击者的SSH公钥，实现持久化后门。

二、AI攻击面从应用层扩展至基础设施层

2026年上半年，AI相关攻击已不再局限于模型和AI应用本身，而是向Agent、网关、算力层扩散。

被攻击对象覆盖多个类型：Dify（AI开发平台）、Ollama（本地大模型运行环境）进入漏洞利用榜前十；LiteLLM（API网关）、Ray（分布式计算框架）被用于集群挖矿；opencode（AI编程Agent）、Nezha（运维监控工具）等高权限组件成为攻击者植入后门的跳板。

分布式框架的风险尤为突出。Ray的CVE-2023-48022允许攻击者通过ray.remote向集群所有节点并发投递挖矿脚本，无需逐台登录。一次漏洞利用可导致整个集群被控。

三、新漏洞快速利用与老漏洞长期利用并存

2026年上半年，漏洞利用呈现新旧并行特征。

新漏洞方面，LiteLLM、Nezha、opencode等2026年新披露的CVE，在数天至数周内即被纳入攻击者的扫描工具集。攻击者先用OAST回连验证目标可达性，再进行批量利用。

老漏洞方面，Log4j（CVE-2021-44228）、Fastjson、Redis未授权访问等多年漏洞仍是常见攻击入口。Top 15漏洞榜单覆盖AI平台、CI/CD、消息队列、数据库、Web框架等多个技术栈，不再由少数明星漏洞主导。

两条风险线对企业提出不同要求：新漏洞考验漏洞情报和应急响应速度；老漏洞暴露资产管理和安全债务问题。

四、攻击者的漏洞库与自动化投递链持续扩张

攻击源方面，自动化扫描基础设施持续活跃。1xx.9x.1x.1xx在半年内切换10余种漏洞进行广撒网扫描；1xx.1xx.1xx.2xx主攻Ray分布式框架；1xx.9x.1xx.1xx主攻Nezha RCE并写入SSH公钥。相关IP段（4x.8x.x、1xx.1xx.x）也值得持续跟踪。

Payload分发方面，GitHub及其衍生服务（raw.githubusercontent.com、gist.github.com）继续被大量滥用，托管恶意载荷。DDNS域名（asuscomm.com、duckdns.org、giize.com）成为新趋势，解析指向攻击者的家用宽带或小型VPS，成本极低且能规避基于新注册域名的检测。

攻击目的方面，探测、验证类意图覆盖面最广。大量攻击者入侵第一步仍是身份摸底和网络探测，并未立刻部署恶意载荷。管道执行（curl | sh）紧随其后，攻击者通过脚本管道触发payload，再由payload决定后续动作，增加静态特征检测难度。

 总结 

2026年上半年，AI生态已从2025年的“新兴观察目标”转变为真实入侵榜单中的稳定类别。AI编程Agent、AI网关、以root运行的开源监控工具——这些组件大多允许远程输入且拥有高权限，一旦存在RCE漏洞即成为直通root的通道。

对企业防御方，建议采取以下措施：

• 将AI Agent纳入正式资产管理范围，确认控制接口是否暴露公网、是否启用认证与最小权限。

• 持续审计Agent拉起的shell、SSH公钥写入、云元数据访问和异常工具调用。

• 对无法立即升级的组件，优先通过网络隔离限制其影响范围。

• 定期进行红蓝实战攻防演练，验证安全防护效果。

扫码了解腾讯云-新一代云安全中心

跳转微信打开

Redis 被披露存在远程代码执行漏洞，系 CVE-2026-25243 补丁绕过，细节与 PoC 已公开，多版本受影响。

——关注云鼎实验室，获取更多安全情报——

跳转微信打开

腾讯云安全已支持防护Fastjson 1.2.68 至 1.2.83 存在反序列化 RCE 漏洞。

ParserConfig.getGlobalInstance().setSafeMode(true);

-Dfastjson.parser.safeMode=true

fastjson.parser.safeMode=true

跳转微信打开

从金融系统博弈到具身智能威胁，从数字空间安全到物理安全、生理安全、意识安全，2027年7月4日  —— 由腾讯安全主办的安全沙龙第九期深圳站在南山区圆满落幕。

深圳，2026年7月4日  —— 由腾讯安全主办的安全沙龙第九期深圳站在南山区圆满落幕。本期沙龙以“Hacking World！”为主题，打破传统网络安全的边界局限，聚焦生成式 AI 安全、金融系统博弈、碳硅心智博弈、AI Agent 攻防、技术反窃密、近源渗透、具身智能安全、生理与意识安全八大前沿方向，全方位解构数字与物理深度融合时代的新型安全威胁与防御路径。

本次沙龙共吸引了超过600人报名，现场汇聚了400余位来自全国各地的网络安全爱好者，其中既有深耕行业多年的安全专家，也有充满好奇心的在校大学生，甚至还有多名热衷技术探索的高中生，现场学术氛围浓厚，跨界思想碰撞激烈。

开场致辞：重新定义黑客精神

活动开始，主办方 腾讯云鼎实验室攻防负责人李鑫向大家阐释了活动主题“Hacking World！” 的核心理念，以及办会初衷：

• 黑客并非破坏者的标签，而是一种探索世界的思维方式—— 以好奇心驱动，敢于突破边界，通过拆解、突破系统实现对事物的深度理解，最终指向改进与创造。

• 真正的技术突破往往发生在学科交叉处。本次沙龙主打跨界融合，希望打破垂直领域壁垒，汇聚金融、硬件、生物、AI 等多元方向的探索者，打造开放的技术交流生态，践行“万物可探，诸法可解” 的核心主张。

AI安全：从“幻觉”治理到数据流守卫

SecureNexusLab团队LLM安全方向负责人陈永锋在《定向幻觉：生成式AI时代的供应链攻击与主动防御》中指出，随着GEO（生成式引擎优化）技术的黑产化，攻击者可通过投毒RAG库、微调劫持等手段制造“定向幻觉”，在不修改模型参数的情况下操控AI输出虚假信息。他现场演示了利用GEO诱导AI生成恶意代码导致Token被盗的真实案例，并提出涵盖“知识准入、检索校验、生成干预、全链溯源”的四层防御框架。他强调“AI是认知的放大镜而非均衡器”，提醒从业者切勿盲目信任AI输出。  

原腾讯安全研究员haya和拓竹科技安全专家12end分享了题为《从间接注入到数据流劫持：AI Agent 数据流攻与防》的研究。他们通过两个累计获赔超3万美元的高危漏洞案例，揭示了AI Agent时代隐蔽的数据安全风险。在微软Copilot案例中，攻击者仅需在网页植入隐藏指令，即可诱导AI泄露用户会话；在开源项目OpenHands中，攻击者利用GitHub Issue提交恶意代码，成功窃取了开发者的Git Token。他们提出了一套覆盖网关、端侧、工具调用、RAG知识库及记忆模块的五层防御体系，并演示了基于轻量级小模型的“意图识别网关”，能有效拦截偏离Agent原定功能的敏感操作。  

跨界博弈：金融暗战与脑机主权

金融安全历来是攻防对抗的高地。华尔街与伦敦顶级对冲基金策略研究员罗炳桥在《金融黑客：二级市场不对称优势下的全域渗透——情报、策略与游资的破壁体系》中，他将网络安全中的“对抗工程”思维引入金融交易，系统拆解了获取超额收益的四大支柱：信息优势、认知优势、工程优势与对抗优势。通过“商业航天股盘口诱多”、“白毛女股神出口转内销”等案例，他揭示了利用数据指纹、注意力劫持及叙事操控进行攻击的手法，并指出金融市场充满了针对感官、大模型乃至决策流程的“认知欺骗”  。

而在人与AI的关系层面，独立安全研究员喻峰的《碳硅互搏：从大脑Hook到碳基越狱》引发了广泛共鸣。面对AI对决策判断的逐步接管，他借用逆向工程思维，探讨了如何通过“意识调试”防止人脑思维“控股权”稀释，守住碳基生物的“系统主权”。

李超则进一步在《从人机协同安全到生理防御机制的突破探索》中指出，人类作为碳基开放系统，思维、情绪与行为极易被外界定向干扰，对比硅基AI体系，碳基拥有更隐蔽、更广的攻击面，电磁定向干扰、脑机接口等技术早已实现对人体意识、行为的潜在调控，相关风险自二战时期便已有研究落地，在AI快速迭代的当下愈发凸显。

他结合自身实践与研究体悟提出，人体与流动意识皆为外在表象，固有身心认知会形成防御枷锁，会固化思维、削弱可塑性，让人体持续暴露在各类外部干扰中。对此，他认为可通过长期身心练习锚定本我、稳住底层主控权，在拥抱 AI 技术的同时，规避情绪与行为被操控的风险，实现人机共生下的自我安全守护。

物理世界：近源渗透与具身智能威胁建模

当安全战场从线上延伸到线下，威胁变得更加触手可及。RC² TSCM LAB创始人Longas杨叔在《企业安全新趋势：TSCM & Cyber Security》中指出，传统防御正面临“物理入侵+网络渗透”的复合威胁。他提出的覆盖“物理-网络-人员”三维度的360度防护体系，为企业填补了办公场所与通信链路的物理安全盲区。

独立安全研究员杨文韬的《从无线电到DMA：近源渗透实战技术导览》则近一步给大家展示了真实的物理攻击技术。他从无线电信号、USB外设讲到DMA直接内存访问，演示了攻击者如何绕过软件防护获取系统权限，警示企业需重新审视硬件采购与现场运维的风险。

作为本次沙龙的最终议题，宇树科技产品安全专家邹佳源带来了《Physical AI Agent：人形机器人平台的具身智能安全威胁建模》。随着人形机器人走进现实，安全问题已关乎人身安全与环境稳定。演讲者构建了包含物理实体、人类与环境的交互系统模型，并对核心决策循环进行了深入的安全建模，为处于萌芽期的Physical AI Agent安全指明了研究方向。

写在最后

持续四个小时的沙龙高潮迭起，不仅有技术的硬核拆解，更有哲学层面的思辨。现场既有高中生向专家请教AI伦理的求知若渴，也有老牌白帽在台下频频点头的默契认同。腾讯安全沙龙第九期深圳站不仅是一场技术的盛会，更是一次关于未来安全形态的大讨论。在AI与实体经济深度融合的浪潮下，腾讯安全将持续携手安全社区，打破认知边界，共建数字时代的安全底座。

特别鸣谢

腾讯青科实训、深圳河套学院、人民邮电出版社、北京零零信安科技有限公司、美团安全应急响应中心、陌陌安全、顺丰安全、快手安全应急响应中心等合作伙伴对本次活动的大力支持。

——关注云鼎实验室，获取更多安全情报——

跳转微信打开

以下文章来源于：腾讯安全

致力于成为产业数字化升级的安全战略官，守护政府及企业的数据、系统、业务安全，为产业数字化升级保驾护航

跳转微信打开

腾讯云安全发布最新必修漏洞清单，盘点8大高危漏洞，助力企业精准修复，筑牢安全防线。

一、 Gogs 远程代码执行漏洞

 概述：

腾讯云安全近期监测到关于Gogs的风险公告，漏洞编号：TVD-2026-27528(CVE编号：CVE-2026-52806，CNNVD编号：CNNVD-2026-99484753)。成功利用此漏洞的攻击者，最终可在目标服务器上远程执行任意代码。

Gogs是一款使用Go语言编写的开源自托管Git服务，旨在以最少的资源占用提供类似GitHub的代码托管体验。它支持仓库管理、代码浏览、Issue跟踪、Wiki文档、组织协作和Web钩子等功能，可轻松部署在低配置服务器上，深受个人开发者和中小团队的青睐。Git钩子（Git Hooks）机制允许在特定Git操作（如推送、提交）前后自动执行自定义脚本，是Gogs实现自动化工作流的关键功能。

据描述，在 Gogs 中，由于其在执行 “Rebase before merging”合并操作时，未能对分支名称中的特殊字符进行严格过滤和转义，攻击者可以创建一个包含 --exec 标志的恶意分支名称，当具有仓库写权限的用户或攻击者本人触发达该合并操作时，git rebase 命令会将该分支名称中的 --exec 参数解析为需要执行的命令，攻击者无需管理员权限，仅需拥有一个注册账户并创建仓库，或对现有开启变基合并的仓库具有写权限，即可在目标服务器上实现任意代码执行。

注：由于 Gogs 默认启用开放注册（DISABLE_REGISTRATION = false）且对仓库创建数量无限制（MAX_CREATION_LIMIT = -1），导致未经身份验证的远程攻击者在默认配置下即可利用该漏洞。

漏洞状态：