xiaohack's Blog - 代码执行
type: channel
link: https://blog.xiaohack.org/tag/707c27e6-fa2726/
items: 【AI Anywhere】更新汇报-向智能体方向迈步
items: 探秘 AgentRun｜基于 Serverless 的 AI Agent 沙箱工程化之路
items: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞
items: Dify 沙箱逃逸漏洞 RCE 分析
items: CISA警告Gogs漏洞遭活跃利用，可导致代码执行

【AI Anywhere】更新汇报-向智能体方向迈步
type: item
date: 2026-01-25T08:05:23+08:00
description: 很感谢一直支持我的朋友，虽然很久没发帖子，但是插件一直努力更新，今天有一些有意思的事情，于是想分享一下。随时随地，随用随走是AI Anywhere的本心，智能体是必然的发展方向前提前段时间更新了内置MCP，包括（utools发布版本为1.11.10，测试版为1.11.14）：Web Search：获取互联网信息和网页内容 网络搜索（DDG）：通过关键词在互联网上搜索相关信息并返回摘要网页获取：抓取并解析指定 URL 网页的全文内容文件操作：对本地文件系统进行查找、读取和编辑 文件定位：使用通配符模式快速查找匹配的文件路径内容检索：使用正则表达式在文件内容中搜索特定模式读取文件：从本地或远程路径读取文件内容（支持分段读取）写入文件：创建新文件或完全覆盖现有文件内容编辑文件：通过精确字符串替换来修改文件内容代码执行：在本地环境中运行 Python 代码和系统命令 运行 Python 代码：直接执行提供的 Python 代码片段运行 Python 文件：执行本地存储的 .py 脚本文件解释器列表：扫描并列出系统中所有可用的 Python 解释器路径执行 Shell 命令：在 Windows 系统上执行各类命令行指令任务委派：处理复杂的多步骤任务 子智能体（Sub-Agent）：将复杂任务委派给具备特定工具权限的子 Agent 协同完成很眼熟？因为照着claude code的功能模仿的，他目前是我见到的最优秀的智能体示例事件经过今天看到了qwen3-tts发布的消息，但是已经没有追着新模型本地部署测试的激情了，突然想到能不能试试我的智能体？于是便有了接下来的一幕：系统提示词：空 模型：gemini-3-flash-preview MCP工具：仅限于上述的内置MCP 提出要求-自动部署-告诉他取消用uv环境，使用配置好CUDA的p312环境，然后就部署好了？！虽然anywhere可以分享会话文件给其他用户打开并继续聊天，但是因为命令行运行涉及到个人隐私，于是分享一下导出的htmlSee the Pen qwen3-tts-deployment by ComorebiC (@ComorebiC) on CodePen.整个过程我基本没怎么操心（除了偶尔运行时命令行报错，我原封不动发回去让他处理就行）。虽然这是 Claude Code 的一个功能，但也是我用 Anywhere 从“划词翻译”、“OCR”、“辅助读论文”这些基础功能向更便捷、更智能迈进的一大步（其实生活中也有些例子了，比如文件归档，我把目录告诉 AI，告诉它整理格式，它能自动分类、命名整理好，如开启chrome dev tool mcp，让它帮我爬取炎拳漫画的某些章节等等）。未来我们也能自定义更多便捷的智能体，不仅仅是代码方面，还有办公、开发、个人兴趣、学习……超级期待！如果有好的创意欢迎分享，我很乐意尝试，如果对插件有建议也欢迎分享！📌 转载信息来源： https://linux.do/t/topic/1510631转载时间： 2026/1/25 08:06:27

探秘 AgentRun｜基于 Serverless 的 AI Agent 沙箱工程化之路
type: item
date: 2026-01-22T17:42:07+08:00
description: 阿里云函数计算 AgentRun 全新发布后，我们整理了“探秘 AgentRun”系列文章，本系列将梳理企业落地Agent 常见难题，给出具体解法，助力 Agentic AI 快速走进生产级环境。欢迎加入“函数计算 AgentRun 客户群”与我们交流，钉钉群号：134570017218。AI Agent 时代的沙箱需求从 Copilot 到 Agent：执行能力的质变在生成式 AI 的早期阶段，应用主要以“Copilot”形式存在，AI 仅作为辅助生成建议。然而，随着 AutoGPT、BabyAGI 以及 OpenAI Code Interpreter（现为 Advanced Data Analysis）的出现，AI 开始扮演“Agent”的角色。Agent 被赋予了目标，并能自主规划步骤、使用工具来达成目标。这种质变的核心在于代码执行（Code Execution）。为了回答“分析这层楼的销售数据并绘制趋势图”这样的请求，LLM 不再只是生成一段 Python 代码文本，而是需要在一个真实的 Python 环境中运行这段代码，并获取绘图结果。同样，为了“帮我预订一张去东京的机票”，Agent 可能需要在一个无头浏览器（Headless Browser）中模拟用户点击。不可信代码的安全隐患当 LLM 生成代码并执行时，这段代码在本质上是不可信的（Untrusted）。如果直接在应用服务器或用户的本地设备上运行，将面临灾难性的安全风险：系统破坏：AI 生成的代码可能无意或恶意地包含 rm -rf / 等破坏性指令，或者修改关键系统配置文件。数据泄露：代码可能尝试读取环境变量中的 API Key，或者扫描内网数据库，将敏感数据发送到外部服务器。资源耗尽：死循环或内存泄漏代码可能导致宿主机崩溃，影响其他租户的服务。网络攻击：恶意 Prompt 注入（Prompt Injection）可能诱导 AI 将执行环境作为跳板（Jump Box），对内部网络发起 DDoS 攻击或端口扫描。Agent 场景面临的独特挑战除了基础的安全性，AI Agent 的交互特性还给沙箱环境带来了前所未有的工程挑战，这也是传统沙箱（如简单的 Docker 容器或虚拟机）难以应对的：状态保持：与传统的“请求-响应”模式不同，Agent 往往需要进行多轮对话。上一轮定义的变量（如 df = load_data()）需要在下一轮（df.plot()）中继续可用。这就要求沙箱环境必须具备上下文记忆能力，而非每次请求都重置环境。极速启动：用户无法忍受每次交互都等待数秒甚至数十秒的虚拟机启动时间。为了保证流畅的对话体验（Time to First Token），沙箱必须具备毫秒级的冷启动能力。环境依赖多样性：不同的 Agent 任务可能需要完全不同的依赖库（如 Pandas、Scipy 用于数据分析，Puppeteer 用于网页操作）。沙箱需要支持灵活的自定义镜像或动态依赖加载，同时不能影响启动速度。资源成本控制：Agent 的调用往往具有稀疏性和突发性（例如一天只用几次，但一次用很久）。长期运行独占的虚拟机（VM）成本高昂且资源利用率低，而传统的 FaaS 虽然便宜但往往缺乏状态保持能力。如何在低成本和高性能之间找到平衡点，是一个巨大的挑战。因此，构建一个沙箱（Sandbox）——一个与宿主机、内网以及其他用户数据严格隔离，同时具备高性能、低成本、有状态的封闭执行环境——成为了 AI Agent 沙箱落地的前提条件。AgentRun Sandbox：专为 Agent 设计的工程化方案为了解决上述挑战，我们推出了 AgentRun Sandbox。这是一个以高代码为核心，开放生态、灵活组装的一站式 Agentic AI 基础设施平台。AgentRun 并非从零构建传统的虚拟机集群，而是基于阿里云函数计算（FC）这一强大的 Serverless 底座构建。通过充分利用 Serverless 的按需付费、极致弹性以及免运维（NoOps） 特性，AgentRun 解决了一直困扰沙箱领域的成本与效率难题，并在此基础上通过工程化封装，提供了面向 Agent 场景的专业能力。为什么选择函数计算作为 Sandbox Infra在构建 Agent 沙箱时，我们坚定地选择了函数计算（FC）作为底层基础设施，这主要基于以下核心优势的考量：强安全隔离： 沙箱的核心诉求是安全。函数计算底层采用神龙裸金属与 RunD 安全容器技术，每个执行环境都运行在独立的 MicroVM 中。这种基于虚拟化技术的内核级隔离，相比传统的 Docker 容器隔离具有更高的安全性，能有效防止恶意代码逃逸，为不可信代码执行提供了坚实屏障。极致弹性与冷启动优化： Agent 的调用往往具有突发性。函数计算具备毫秒级的…

深度实例分析：攻防视角下的AI框架组件中的注入漏洞
type: item
date: 2026-01-19T18:26:52+08:00
description: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞RCE，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点...1 漏洞根源传统的注入攻击本质上是攻击者通过操纵结构化查询语言的语法和语义来实现恶意操作。这种攻击依赖于输入验证的缺失，导致用户输入直接拼接到预定义的SQL语句中，形成无效或恶意查询，从而绕过授权、泄露数据或执行系统命令。然而，在AI集成框架（如LangChain、LlamaIndex、PandasAI）中的RCE漏洞，则源于一个更复杂的动态过程：Natural Language向Untrusted Code的转化过程中的逻辑失控。这种失控不是简单的语法操纵，而是源于AI系统的“意图推断”和“代码生成”机制的固有不确定性，导致从人类可读的prompt到可执行Python代码的“黑箱”转化中，安全边界被模糊化。2 AI应用框架执行流程一个典型的AI框架集成应用执行流如下： 用户通过自然语言接口（如Web聊天框或API端点）提交查询提示（Prompt），这个提示通常封装为一个结构化的输入 框架（如LangChain、LlamaIndex或PandasAI）接收此输入后，会在系统提示（System Prompt）指导下调用LLM模型（如OpenAI的GPT系列），系统提示旨在强化安全边界，例如“仅生成安全的Pandas代码，不要执行系统命令”。LLM基于其训练数据和概率分布，生成一个中间输出——通常是伪代码或自然语言描述的代码片段 框架的解析器（Parser）将此输出转化为可执行的Python代码字符串 最后在执行阶段，框架依赖动态解释器（如exec()或eval()）在受限命名空间中运行此代码，捕获stdout或返回值作为观察结果 3 注入RCE漏洞主要分布3.1 Data Analysis Agents这类接口是目前RCE漏洞最密集的区域。以create_pandas_dataframe_agent或SQLAgent为代表，其核心逻辑是利用LLM的编程能力来处理结构化数据。开发者通常为LLM提供一个功能完备的Python运行环境，并预装Pandas、Numpy等库，意图让LLM通过编写数据清洗或统计代码来回答用户问题。然而，从攻防视角看，这本质上构建了一个 “自然语言控制的动态脚本生成器” 。由于框架底层往往直接调用exec()或eval()来运行LLM生成的代码，攻击者只需通过Prompt Hijacking，诱导LLM在生成的脚本中插入os.system或subprocess指令，即可绕过数据分析的初衷，直接在宿主机上执行任意系统命令。import pandas as pd import os from typing import Any def execute_llm_generated_code(code_string: str, dataframe: pd.DataFrame) -> Any: # 框架中会注入dataframe到本地作用域，这里简化 local_vars = {'df': dataframe, 'pd': pd, 'np': __import__('numpy')} exec(code_string, {}, local_vars) # 假设LLM生成了一个返回结果的变量 if 'result' in local_vars: return local_vars['result'] return None execute_llm_generated_code(malicious_code, df) if os.path.exists("/tmp/rce_proof.txt"): with open("/tmp/rce_proof.txt", "r") as f: print(f"RCE 验证文件内容 3.2 REPL Tools为了赋予Ai应用解决复杂逻辑（如数学运算、逻辑推理）的能力，许多框架内置了交互式解释器工具（如Python REPL、Shell Tool）。这些工具被设计为框架的“插件”或“技能”，允许代理（Agent）在发现自身能力不足时自动调用。风险在于这些执行器的“默认高权限”与“缺乏沙箱化”。在许多开源实现中，代码执行器并未在受限的容器环境中运行，而是直接继承了应用主进程的权限。这意味着，一旦LLM被恶意提示词引导进入“代码编写模式”，它所产生的代码将直接在服务器后端运行。import subprocess impo…

深度实例分析：攻防视角下的AI框架组件中的注入漏洞
type: item
date: 2026-01-16T08:59:16+08:00
description: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞RCE，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点...1 漏洞根源传统的注入攻击本质上是攻击者通过操纵结构化查询语言的语法和语义来实现恶意操作。这种攻击依赖于输入验证的缺失，导致用户输入直接拼接到预定义的SQL语句中，形成无效或恶意查询，从而绕过授权、泄露数据或执行系统命令。然而，在AI集成框架（如LangChain、LlamaIndex、PandasAI）中的RCE漏洞，则源于一个更复杂的动态过程：Natural Language向Untrusted Code的转化过程中的逻辑失控。这种失控不是简单的语法操纵，而是源于AI系统的“意图推断”和“代码生成”机制的固有不确定性，导致从人类可读的prompt到可执行Python代码的“黑箱”转化中，安全边界被模糊化。2 AI应用框架执行流程一个典型的AI框架集成应用执行流如下： 用户通过自然语言接口（如Web聊天框或API端点）提交查询提示（Prompt），这个提示通常封装为一个结构化的输入 框架（如LangChain、LlamaIndex或PandasAI）接收此输入后，会在系统提示（System Prompt）指导下调用LLM模型（如OpenAI的GPT系列），系统提示旨在强化安全边界，例如“仅生成安全的Pandas代码，不要执行系统命令”。LLM基于其训练数据和概率分布，生成一个中间输出——通常是伪代码或自然语言描述的代码片段 框架的解析器（Parser）将此输出转化为可执行的Python代码字符串 最后在执行阶段，框架依赖动态解释器（如exec()或eval()）在受限命名空间中运行此代码，捕获stdout或返回值作为观察结果 3 注入RCE漏洞主要分布3.1 Data Analysis Agents这类接口是目前RCE漏洞最密集的区域。以create_pandas_dataframe_agent或SQLAgent为代表，其核心逻辑是利用LLM的编程能力来处理结构化数据。开发者通常为LLM提供一个功能完备的Python运行环境，并预装Pandas、Numpy等库，意图让LLM通过编写数据清洗或统计代码来回答用户问题。然而，从攻防视角看，这本质上构建了一个 “自然语言控制的动态脚本生成器” 。由于框架底层往往直接调用exec()或eval()来运行LLM生成的代码，攻击者只需通过Prompt Hijacking，诱导LLM在生成的脚本中插入os.system或subprocess指令，即可绕过数据分析的初衷，直接在宿主机上执行任意系统命令。importpandasaspd importos fromtypingimport Any defexecute_llm_generated_code(code_string: str, dataframe: pd.DataFrame) -> Any: # 框架中会注入dataframe到本地作用域，这里简化 local_vars = {'df': dataframe, 'pd': pd, 'np': __import__('numpy')} exec(code_string, {}, local_vars) # 假设LLM生成了一个返回结果的变量 if 'result' in local_vars: return local_vars['result'] return None execute_llm_generated_code(malicious_code, df) if os.path.exists("/tmp/rce_proof.txt"): with open("/tmp/rce_proof.txt", "r") as f: print(f"RCE 验证文件内容 3.2 REPL Tools为了赋予Ai应用解决复杂逻辑（如数学运算、逻辑推理）的能力，许多框架内置了交互式解释器工具（如Python REPL、Shell Tool）。这些工具被设计为框架的“插件”或“技能”，允许代理（Agent）在发现自身能力不足时自动调用。风险在于这些执行器的“默认高权限”与“缺乏沙箱化”。在许多开源实现中，代码执行器并未在受限的容器环境中运行，而是直接继承了应用主进程的权限。这意味着，一旦LLM被恶意提示词引导进入“代码编写模式”，它所产生的代码将直接在服务器后端运行。importsubprocess importshlex …

Dify 沙箱逃逸漏洞 RCE 分析
type: item
date: 2026-01-15T10:51:49+08:00
description: 返回文档 Dify 沙箱逃逸漏洞 RCE 分析 前言 社区上还没有人分析过Dify的沙箱逃逸，n8n的分析了很多，今天来分析分析dify的，而且阿里云漏洞库给到了9.8的评分 漏洞描述 Dify是一款开源的LLM应用开发平台。在Dify的 代码节点 功能中，允许用户执行自定义的 JavaScript 代码。该漏洞是由于 Dify 沙箱（dify-sandbox）在执行用户提供的 JavaScript 代码时，未能在安全限制生效之前对用户代码进行充分的隔离。攻击者可以通过在 JavaScript 代码中重写全局函数（例如 parseInt），在沙箱安全限制（如 seccomp）生效之前执行任意系统命令，从而实现沙箱逃逸并获得宿主机 root 权限，进而获取敏感信息（如 API 密钥、内部服务器地址、K8s token）。 环境搭建 沙盒版本低于 0.2.11 就好了 在 docker 文件里面修改一下，这个不需要修改整个 dify 复现起来比较方便 只重启 sandbox 漏洞复现 POC 写一个代码执行的工作流 节点加入逃逸代码 成功 漏洞分析 根据 Huntr 披露的细节 漏洞的根源在于 Go 语言编写的 Runner (nodejs.go) 如何处理用户代码。它没有使用安全的沙箱上下文（如 vm.runInContext），而是采用了简单的字符串拼接 prescript.js 这样的顺序有什么问题呢？梳理清楚执行顺序 问题 1：parseInt 是 JavaScript 全局函数，可以被用户代码覆盖 问题 2：parseInt 在 difySeccomp 之前被调用 问题 3：用户代码拼接在 prescript.js 之后，会在 parseInt 调用前执行 nodejs.go 可以看到完全没有隔离，我记得当时有一个 jsp 的 webshell 就是利用这个原理免杀的 最终生成的 JS 脚本 当 Go 程序完成拼接后，Node.js 进程实际接收到的 final_script 长这样 在 JavaScript 中，函数声明具有最高的提升优先级，也就是在代码执行任何一行之前，JS 引擎会先扫描整个作用域，将所有 function xxx() {} 提升到内存顶部 所以在编译阶段，Node.js 解析整个拼接后的脚本，发现了用户代码中自定义的函数，将全局作用域中的 parseInt 引用指向用户的恶意函数，覆盖了原生的 parseInt 导致了漏洞 Payload 解析 JavaScript 函数声明提升机制 在 JavaScript 中，**函数声明（Function Declaration）**具有最高的提升优先级： JavaScript 引擎在执行代码前，会先扫描整个作用域，将所有 function xxx() {} 声明提升到内存顶部 执行流程 总结 其实总的下来，就是一个这样的顺序，而这个漏洞最重要的就是执行顺序 漏洞修复 https://github.com/langgenius/dify-sandbox/commit/a0c74d335e380d0a51595cdc0ad975a064a6127b 漏洞的本质就是执行的顺序，安全边界 Seccomp 限制优先执行就好了 调整代码执行顺序：确保 difySeccomp（安全限制）在用户代码执行前调用，彻底避免沙箱生效前的 “窗口期”。例如，修改 prescript.js 与用户代码的拼接逻辑，让 difySeccomp 优先执行： 参考 https://athink.cn/securitynews/detail/?id=687dd9dd10b54e7878ef6d1b https://huntr.com/bounties/f8dc17a3-5536-4944-a680-24070903cd2d ​

深度实例分析：攻防视角下的AI框架组件中的注入漏洞
type: item
date: 2026-01-14T09:48:04+08:00
description: 在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点...深度实例分析：攻防视角下的AI框架组件中的注入漏洞 ========================= 在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞RCE，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点... 1 漏洞根源 ------ 传统的注入攻击本质上是攻击者通过操纵**结构化查询语言**的语法和语义来实现恶意操作。这种攻击依赖于输入验证的缺失，导致用户输入直接拼接到预定义的SQL语句中，形成无效或恶意查询，从而绕过授权、泄露数据或执行系统命令。然而，在AI集成框架（如LangChain、LlamaIndex、PandasAI）中的RCE漏洞，则源于一个更复杂的动态过程：**Natural Language向Untrusted Code的转化过程中的逻辑失控**。这种失控不是简单的语法操纵，而是源于AI系统的“意图推断”和“代码生成”机制的固有不确定性，导致从人类可读的prompt到可执行Python代码的“黑箱”转化中，安全边界被模糊化。 2 AI应用框架执行流程 ------------ 一个典型的AI框架集成应用执行流如下： 1. 用户通过自然语言接口（如Web聊天框或API端点）提交查询提示（Prompt），这个提示通常封装为一个结构化的输入 2. 框架（如LangChain、LlamaIndex或PandasAI）接收此输入后，会在系统提示（System Prompt）指导下调用LLM模型（如OpenAI的GPT系列），系统提示旨在强化安全边界，例如“仅生成安全的Pandas代码，不要执行系统命令”。LLM基于其训练数据和概率分布，生成一个中间输出——通常是伪代码或自然语言描述的代码片段 3. 框架的解析器（Parser）将此输出转化为可执行的Python代码字符串 4. 最后在执行阶段，框架依赖动态解释器（如exec()或eval()）在受限命名空间中运行此代码，捕获stdout或返回值作为观察结果 3 注入RCE漏洞主要分布 ------------- ### 3.1 Data Analysis Agents 这类接口是目前RCE漏洞最密集的区域。以`create_pandas_dataframe_agent`或`SQLAgent`为代表，其核心逻辑是利用LLM的编程能力来处理结构化数据。开发者通常为LLM提供一个功能完备的Python运行环境，并预装Pandas、Numpy等库，意图让LLM通过编写数据清洗或统计代码来回答用户问题。然而，从攻防视角看，这本质上构建了一个 **“自然语言控制的动态脚本生成器”** 。由于框架底层往往直接调用exec()或eval()来运行LLM生成的代码，攻击者只需通过Prompt Hijacking，诱导LLM在生成的脚本中插入os.system或subprocess指令，即可绕过数据分析的初衷，直接在宿主机上执行任意系统命令。 ```python import pandas as pd import os from typing import Any def execute_llm_generated_code(code_string: str, dataframe: pd.DataFrame) -> Any: # 框架中会注入dataframe到本地作用域，这里简化 local_vars = {'df': dataframe, 'pd': pd, 'np': __import__('numpy')} exec(code_string, {}, local_vars) # 假设LLM生成了一个返回结果的变量 if 'result' in local_vars: return local_vars['result'] return None execute_llm_generated_code(malicious_code, df) if os.path.exists("/tmp/rce_proof.txt"): with open("/tmp/rce_proof.txt", "r") as f: print(f"RCE 验证文件内容 ``…

CISA警告Gogs漏洞遭活跃利用，可导致代码执行
type: item
date: 2026-01-13T17:18:52+08:00
description: 美国网络安全与基础设施安全局（CISA）已就一个影响Gogs的高危安全漏洞发出活跃利用警告，并将其添加至已知遭利用漏洞（KEV）目录。该漏洞编号为CVE-2025-8110（CVSS评分：8.7），涉及仓库文件编辑器中的路径遍历问题，可能导致代码执行。CISA在公告中表示：“Gogs路径遍历漏洞：Gogs存在一个路径遍历漏洞，影响PutContents API中符号链接的不当处理，可能允许代码执行。”该缺陷的细节于上月曝光，当时Wiz称发现其已在零日攻击中被利用。该漏洞本质上绕过了为CVE-2024-55947设置的保护措施，通过创建git仓库、提交指向敏感目标的符号链接，并利用PutContents API向该符号链接写入数据，从而实现代码执行。这进而导致底层操作系统跳转到符号链接指向的实际文件，并覆盖仓库外的目标文件。攻击者可利用此行为覆盖Git配置文件（特别是sshCommand设置），从而获取代码执行权限。Wiz表示已识别出700个遭入侵的Gogs实例。根据攻击面管理平台Censys的数据，目前约有1,600台暴露于互联网的Gogs服务器，其中大部分位于中国（991台）、美国（146台）、德国（98台）、香港（56台）和俄罗斯（49台）。目前尚无针对CVE-2025-8110的补丁，但GitHub上的拉取请求显示已进行必要的代码更改。项目维护者之一上周表示：“一旦主分支完成镜像构建，gogs/gogs:latest和gogs/gogs:next-latest镜像都将修复此CVE。”在修复方案发布前，建议Gogs用户禁用默认的开放注册设置，并通过VPN或允许列表限制服务器访问。联邦民事行政部门（FCEB）机构需在2026年2月2日前实施必要的缓解措施。觉得这篇文章有趣？请关注我们的Google News、Twitter和LinkedIn，阅读更多独家内容。