Aggregator

FastGPT v4.14.8 沙箱四层防护（模块黑名单/AST 检查/open 守卫/import 守卫）全被一条 inspect 四步链穿透：currentframe().f_back.f_globals 拿到 worker 模块全局字典，直接调出 _original_open 读 /etc/passwd、_original_import 绕过黑名单。配套 fastgpt-sandbox-au

对自研政务 RAG 系统（gov-rag-demo）做白盒代码审计，发现间接提示注入、权限参数客户端可控、会话 ID 无鉴权、政务高频实体脱敏不足 4 类真实缺陷，定位到行号并完成修复。78 条业务评测用例保持 100% 零回归，安全专项断言全过。附完整复现脚本与修复后状态。

测试一个 APP 的头像审核时，我发现了一个比较有意思的现象：图片里的敏感文字能被拦下来，但部分敏感图片本身却可以正常上传和展示。后来我审核人员给我讲解了实际流程，我又把这个思路带到了直播场景。顺着这两个事件继续往下看，会发现内容风控不只是“模型能不能识别出来”的问题，机器审核、人工复核以及最终处置之间同样存在时间差。 本文从这次实际测试出发，简单拆一下常见的内容风控模型和审核流程，并用伪代码还原

Rust 承诺在编译期消除内存安全问题。本文把 Rust 官方漏洞公告库 RustSec advisory-db 全库拉下来数了一遍：1246 条公告中，346 条（27.8%）带内存类标签。但按年拆开，会看到一个结构性转折 —— 内存类公告里带 CVE 编号的比例，2020 年是 94%（77/82），2025–2026 年只有 6% 和 10%，同期「自称 unsound」的条数升到 35 和

无交互式 Shell 情况下提取完整固件镜像

本文系统介绍了游戏逆向中查找功能 call 的基本方法，围绕“经过发包函数”和“不经过发包函数”两大类场景，分别讲解了堆栈回溯、虚函数表查找、特征对象访问断点、写入断点回溯等实用技巧，并通过背包使用物品、NPC 服务、自动寻路三个实例进行演示。

Go 1.22 起 net/http.ServeMux 的路由匹配改用编码视图（EscapedPath）逐段比较，%2F 不再是段分隔符；匹配命中后通配捕获值按解码视图交付，.. 回退语义恢复。授权中间件按解码路径前缀放行，处理器拼接磁盘路径时越出前缀——同一请求在两份视图里各被信任一次。

IFUNC 的强制绑定可在 constructor 安装 seccomp 前执行 resolver，规则必须由宿主在 dlopen 前落地。

OWASP GenAI LLM TOP 10 2026中文译本

AI Agent 的 Skill/MCP 生态正重演供应链失控，但攻击更易：自然语言即可驱动全权限 Agent。文章解析信任根因、15类投毒与5个注入面，实测混淆算子使检出率99%→10%；给出五条攻击链、PoC，以及聚合检测、SkillSieve、eBPF/FUSE、uprobe等防御与IoC，代码可复现。

本文记录了针对已归档 Python 包 langchain-experimental 的代码审计过程。在该包的 PythonAstREPLTool 组件中，发现其对大模型（LLM）输出内容的过滤机制较弱，且直接使用 exec/eval 执行输入。结合平台判定与最新下载量数据，本文客观分析了该组件在现阶段（已停止维护）存在的安全风险及修复建议。

算是一个 ZCode 都 0day，通过打开恶意的目录触发

STT_GNU_IFUNC 的 resolver 是动态链接器在重定位期主动调用的用户代码:它比 main 早,比一切构造函数早,是 ELF 规范里“留了门”的加载期执行点。 任何“加载器在 main 之前调用的回调点”都是加载期代码执行的支点,IFUNC 是最早的那一个,而它的执行时机由绑定模式决定。

本文通过拆解六款智能渗透 Agent 的源码与真实执行链路，分析它们在状态管理、上下文控制、工具调用和证据约束上的工程设计与取舍。

这并非普通的输入校验遗漏，而是两条基本安全规则同时失守：认证材料的比较未采用常数时间实现，认证材料本身又被写入常规日志

Python 3.8 的 PEP 570 给函数签名引入了 positional-only 参数（`/` 语法），AST 上对应一个新字段 `posonlyargs`。RestrictedPython 的名字校验器 `check_function_argument_names()` 逐字段枚举检查了普通参数、`*args`、`**kwargs`、keyword-only 参数——唯独漏了这个新字段

IBM JCC getConnection 反序列化

vLLM 在 `0.26.0` 之前的两个 derender 端点会接受调用方提交的嵌套 `GenerateResponse`，并在资源边界校验前执行去分词、logprob 处理和 OpenAI 兼容响应构造。拥有相应 API 访问权限的客户端因此可用格式合法、但规模异常的 JSON 竞争 CPU、内存、响应缓冲与带宽，影响同一服务上的其他请求。

应急响应中的主机溯源，长期停留在"手工敲命令 + 截图 + 翻终端历史"的状态： 排查一台被植入木马或 WebShell 的服务器，需要依次查看进程、服务、启动项、计划 任务、网络连接、文件变更和登录活动，再把零散发现串成时间线。动作不难，但重复、 易漏、难复现。HostTraceAI 尝试把 AI Agent 引入这个流程，而引入的前提是先回答 一个问题：凭什么让 AI 动生产主机？本文介绍它的

Vendure 的渠道（Channel）租户边界对订单子实体（Payment / Refund / Fulfillment / OrderHistoryEntry）来说不是机制，而是逐调用点的约定。这些子实体不携带渠道归属，唯一的边界是父订单；受影响版本里多条 Admin mutation 按 ID 全局加载子实体，从不回查父订单渠道。退款路径最典型：渠道检查寄生在"订单行存在"这个业务事实上，l