安全与破解社区 · 先知社区 · 最新文章

前言 11 月初 sshhole 这份披露出来的时候，五步根因链读下来，最不踏实的是第 4 步，也就是"触发前需要一次错误口令尝试"那句。披露把原因归给静态缓冲区被覆盖，可怎么读都觉得只说了一半。手边刚好有几份上游源码包，就把 10.6p1 / 10.6p2 / 7.2p2 / 7.3p1 的 auth-passwd.c 和 xcrypt.c 拉出来逐行对了一遍，又把 musl 1.2.6 的 crypt 后端单独编了个探针，跑了下长度差分。 第一版写完之后，又在隔离容器里补了一轮实测：两个只绑 127.0.0.1 的 sshd 实例，一个已回移修复、一个源码未打补丁，把链条端到端跑了一遍。这一轮证伪了初稿两处判断，也把"版本号能不能当判定依据"钉死了，分别写在第七节和第十一节。证据分级的口径跟着改过，A 级现在包含本地实测。 后半篇是给运维看的：几条只读自查命令、止损顺序、能写成规则的检

引言 以前看 Agent 文件写入，通常先检查一件事：目标路径有没有留在 workspace 里。Claude Code 公开的 CVE-2026-103435 让我开始重新看这个问题。公告描述了检查与写入之间的时间差：权限检查通过时目标还在项目目录内；共享工作区中的另一个进程替换目录项后，Agent 再按原路径写入，文件就可能落到项目目录之外。 Anthropic 的公告 我想弄清楚的是，检查通过时程序确认的究竟是什么。如果它确认的只是一个路径字符串，那么等到真正打开文件时，内核解析到的还会是同一个对象吗？即使函数最后返回拒绝，拒绝之前有没有可能已经改动磁盘？沿着这两个问题，从 Claude Code 公告中的时序开始，再去看 OpenClaw 和 OpenShell 的真实写入与同步函数。 一、路径检查通过后，目标仍可能变化 1.1 从 Agent 工具到文件系统 Agent 发起一次

我把 Hell's Gate 拆开以后，才发现真正难的不是 SSN 从 PE 导出表、x86/x64 桩到 x32dbg 对照实验 我第一次看 Hell's Gate 的资料时，注意力几乎全在“系统调用号”上。那时我的理解很简单：查一张表，找到 NtOpenProcess 的 SSN，写一段 mov eax, ssn ，再执行 syscall ，事情就结束了。 真正打开 PE_Hell's Gate.exe 和源码以后，我才发现这个理解漏掉了太多东西。磁盘上的 PE 文件不是按内存布局存放的； System32 和 SysWOW64 里的 ntdll.dll 不是同一个架构；x86 和 x64 的桩函数甚至不是同一种执行方式；最后，代码虽然生成了新的“动态桩”，但它复制的是内存里的字节，而不是自己重新拼装指令。 这篇文章记录的就是这次拆解过程。我不打算把它写成“看完就懂”的教程，而更想还原

漏洞编号 CVE-2025-10747 漏洞描述 访问URL： https://nvd.nist.gov/vuln/detail/CVE-2025-10747 WordPress和WordPress plugin都是WordPress基金会的产品，WordPress是一套使用PHP语言开发的博客平台，该平台具有在基于PHP和MySQL的服务器上架设个人博客网站的功能。 WordPress plugin WP-DownloadManager 1.68.11及之前版本存在任意文件上传漏洞，该漏洞源于“download-add.php”文件未正确验证文件类型，具有管理员权限或更高访问权限的的攻击者可利用该漏洞上传任何恶意文件，从而远程执行恶意代码。 受影响版本 WordPress plugin WP-DownloadManager <= 1.68.11 环境搭建 Apache V2.4.39 W

一、漏洞说明 CVE官方链接： https://www.cve.org/CVERecord?id=CVE-2026-123158 Linux 平台上，版本早于 10.6p2 的 OpenSSH 中的 sshd 服务：在使用 musl libc、且未启用 PAM 的环境下，缺少针对密码认证绕过漏洞的修复逻辑（问题根源是程序错误判断一段字符串是否为密码哈希值）。在满足特定账号配置的情况下，长度介于 256～1024 字符之间的任意密码都能认证通过。使用 musl libc 并且不开启 PAM 的典型系统：Alpine Linux。 该漏洞源于muslibc的crypt()函数在失败时返回单字符“（而非POSIX规定的NULL），而OpenSSH在未启用PAM的认证路径中，对密码字段为的账户借用其他账户的真实盐值执行cryptO校验。当攻击者提交257~1024字节的超长密码时，musl的cry

商丘师范学院第五届网络安全及信息对抗大赛 Web Writeup 1. 传马（Web，困难，90pts） 页面只有一句提示：「好奇怪，为什么这个按钮点不动呢」。打开容器看到的是图片上传站，前端按钮带 disabled 属性。 assets/check.js 里已经把底牌写出来了： /* * 前端校验（全部可被绕过，仅提升"用户体验"） * 注意：提交按钮在 HTML 里带了 disabled 属性，正常情况下点不动。 * 真正的突破口是用 Burp 抓包改 filename / Content-Type。 */ 按钮点不动不影响直接发包。打开浏览器 DevTools，直接删掉 disabled 属性，然后在 DevTools Network 面板里抓到上传请求的 multipart/form-data ，把 filename 和 Content-Type 参数改一下： 把 filename

引言：AI 渗透 Agent 的“塔西佗陷阱” 随着大语言模型（LLM）在网络安全领域的垂直落地，自动化渗透工具正在经历一场从“规则驱动”向“意图驱动”的深刻变革。从早期的简单脚本拼接，到如今基于 ReAct（Reasoning and Acting）框架的复杂 Agent，AI 在漏洞挖掘、资产测绘和红蓝对抗中展现出了惊人的潜力。 然而，在真实的攻防场景中，安全研究员面临的最大阻碍并非“AI 能不能用工具”，而是“AI 得出的结论到底可不可信”。大模型的“幻觉（Hallucination）”在渗透测试中是致命的缺陷。由于 LLM 本质上是基于概率的下一个词预测模型，它极容易受到上下文暗示或碰巧出现的字符串的影响，从而产生假阳性（False Positive）。例如，目标服务器的响应头中碰巧包含了一个 admin 字符，大模型可能就会兴奋地向你报告“已发现未授权越权访问”。 为了跨越这道信

Pickle Me 非预期： flag就在源码当中，应该是出题人忘记更改了 预期解： 这道题目给了预期解，我们可以发现只给了白名单： builtins.getattr os.walk 要求我们手写opencode来实现读取flag，包括源码也给了提示要求我们进行 __global__ 逃逸，其实这里的思路很简单，通过 os.walk 拿全局字典，然后 __getitem__ 进行遍历拿到 popen 函数最后进行RCE即可 这是一个完整的链子： getattr(getattr(os.walk, "__globals__"), "__getitem__")("popen")("cat /flag").read() 这里需要用pker工具，我们先编写一个脚本，随后用pker编译即可 getattr = GLOBAL("builtins", "getattr") walk = GLOBAL("o

漏洞描述 openssh在2026年11月06日发布更新，在security更新中称修复了一个密码身份验证绕过漏洞 CVE编号为CVE-2026-123158，在NVD中漏洞描述为 在 Linux 系统上，OpenSSH 10.6p2 之前的版本中，当使用 musl libc 库且未启用 PAM 时，sshd 服务缺少针对密码认证绕过漏洞的变通方案（该漏洞源于对字符串是否为密码哈希的错误识别）。对于某些账户配置，任何长度在 256 到 1024 个字符之间的密码都能成功验证。Alpine Linux 就是一个使用 musl libc 库且未启用 PAM 的平台示例。 环境搭建 检查docker版本 本文使用的docker为29.1.3版本 docker --version docker ps >/dev/null && echo docker-ok 创建工作目录 下载源码 分别下载open

在最近的一次 SRC 项目里，笔者遇到了一个基于若依（RuoYi）二次开发的高校能源管控平台。通过 JimuReport 组件的未授权配置漏洞，我们不仅获取了核心业务数据，顺藤摸瓜获得了数据库访问权限，还发现了一个能直接下发物理设备指令的未授权接口。 在复盘该漏洞时，笔者遇到了一个技术分歧：目前业界有较多文章声称该模块存在参数注入漏洞，可导致远程代码执行（RCE）。然而，在实战评估中，准确界定漏洞的真实危害边界比盲目相信网传 PoC 更为重要。本文将分为两部分：第一部分记录真实靶标上的业务级降维打击；第二部分则是笔者针对底层字节码的逆向分析，还原那个被高估的“RCE 幻象”被拦截的真实原因。 第一部分：真实靶标的降维打击（未授权与业务沦陷） 一、突破：被 Shiro 放行的报表引擎 目标系统的 /prod-api/ 路径下暴露了大量积木报表（JimuReport）的接口。按若依常见的配置，

解包一个看起来完全正常的 tar，解完之后目标目录本身变成了一条指向别处的符号链接，归档里那个普普通通的 txt 文件落在了目录之外，把外部同名文件覆盖掉。全程没有报错， extractall() 正常返回。 凑齐这条链只需要两样东西：一条 名字是空串 的符号链接，加一个普通文件成员。 CPython 的 tarfile 从 3.12 起提供三档过滤器， fully_trusted 什么都不查， tar 查结构性越界， data 在 tar 之上再剥掉危险元数据，3.14.0 起默认走 data 。CVE-2026-114583 打穿的就是这道阀，而且穿得极不对称：3.13.12 和 3.13.13 四档全失，3.13.14 起 data 能挡但 tar 漏，3.13.18 把 tar 补上了而默认档照旧中招，3.14.9 反过来默认安全、显式写 tar 仍然漏。 CVE-2026-114

0x01 公告事实核对 下表是公告陈述与核对结果的对照。转述类稿子最常见的毛病是把公告没写的东西当成公告里写了的，技术上的计算错误反而是少数，所以这一节全部按"能否在原始数据里找到"来判定。 项目 公告 / 转述稿 核到的原始值 判定 GHSA 编号 — GHSA-f8c7-rwf9-fmgm ， type=reviewed ，GitHub 已审阅 A CVE 编号 CVE-2026-111057 identifiers 里确有该 CVE；但 nvd_published_at = null A（NVD 侧尚无记录） 标题 未认证 RCE Mercury: Unauthenticated Remote Code Execution in /api/terminals - access control bypass A 严重性 critical severity = critical A CV

前言 在当今的软件开发生态与 CI/CD 流水线中，开源基础组件扮演着至关重要的角色。它们如同构建高楼大厦的钢筋水泥，被广泛集成在各类上层应用之中。然而，由于基础组件往往处于底层，其隐藏的安全漏洞具备极强的隐蔽性和破坏力。 Eclipse JGit 是 Java 生态中用于操作 Git 仓库的核心开源库。它允许开发者在 Java 代码中无缝实现 clone、commit、push 等 Git 操作。得益于其便捷性，许多知名企业级应用（如 Jenkins、各类 DevOps 平台、低代码平台的代码拉取模块）都在底层直接或间接地集成了 JGit。 2025 年，官方披露了 JGit 存在一个严重的 XML 外部实体注入（XXE）漏洞，编号为 CVE-2025-4949。该漏洞影响 JGit 的 ManifestParser 以及 AmazonS3 transport 模块。 本文将基于 JDK

01 前言 去年底的一次红队演练，入口机是台 linux webshell，从配置文件翻到了一个服务账号的明文口令信息，巧合的是可以通过 3389 远连到几台一样的 win 主机，均隶属于管理员组但非 system 权限，这个被加进本地组不是镜像带来的而是人手动做的，推测管理员凭据都是一样但我没明文，在主机的 SAM 里。主机不在域内，进程里有个杂牌的 EDR ，其规则对落地文件和读 SAM 都会有覆盖。当前 EDR 环境下，你是否能做到不依赖 mimikatz、secretsdump、不调用任何现成的 SAM 解析库、不碰活注册表、不硬要提权 NTsystem 来拿 NTLM 。 02 当前场景 1、多台win主机，镜像部署，服务账号凭据，均隶属于管理员组但非 system 权限，无域环境 2、防护为杂牌 EDR 3、可通的网段有多个 4、可访问的端口、服务、文件，未发现可进一步利用的

TL;DR 近期作者在学习 Chrome V8 漏洞利用相关技术，看了一下 Starlabs的师傅分享的一篇文章 ，从中学习了 V8 漏洞分析与利用的思路。顺着这套研究范式，作者选择了一个 V8CTF 里的漏洞开展实践 —— 该漏洞暂无 CVE 编号，暂无公开利用信息，正好适合练手 本文记录了对该漏洞的根因分析、POC 构造、调试踩坑以及利用思路的完整实践过程 简介 受影响产品 Google Chrome 及其他产品内置的 V8 JS 引擎 Bug ID crbug-516833326 补丁链接 https://chromium-review.googlesource.com/c/v8/v8/+/7876872 翻阅补丁后可以确定，漏洞位于 V8 的 UnwindAndFindHandler 栈展开逻辑，和 Fast API 异常展开过程中 MaterializedObjectStore

基于 339 个 Windows PE 样本的复测与误报分析 项目地址： https://github.com/mrxiaofaker/PE_CodeCave 当前分析版本： 0727f0d 这个项目最早不是为了做“漏洞扫描器”。 我一开始只是想用 C 写一个自己的 PE 分析工具。那时候我在学节表、RVA、文件偏移这些东西，觉得只看资料记不住，干脆把“找代码洞”做成一个能运行的程序。输入 PE，解析节区，扫描连续的 0x00 、 0x90 、 0xCC ，再把结果输出成 HTML 和 JSON。 我一开始觉得逻辑挺直观：可执行节里有连续空白字节，大小超过阈值，那就是 Code Cave。 我拿本地一个 Windows 应用目录跑了一批样本。339 个 PE，最后 339 个都有“代码洞”，其中 333 个直接顶到单文件 150 条上限。那一刻我第一反应不是“发现了什么”，而是这套判断标准

第一章：引言与漏洞概述 在当今的 Web 生态中，轻量级、无数据库的 Flat-File CMS（如 Grav、Flextype、Kirby 等）因其部署简单、性能优异而受到大量中小型站点的青睐。然而，摆脱了关系型数据库的束缚，并不意味着摆脱了传统 Web 漏洞的阴影。相反，由于高度依赖文件系统进行数据存储与解析，此类系统在输入处理、模板渲染及数据反序列化层面的安全设计往往面临更为严峻的考验。 近期披露的 CVE-2026-77939 正是一个典型的架构级安全缺陷。该漏洞存在于 Flextype CMS 的 API 查询模块中，由于其未能对用户输入进行有效的边界隔离，直接将外部数据交由 Symfony ExpressionLanguage 引擎进行求值（Evaluate）。更为致命的是，底层框架在初始化引擎时，打破了 Symfony 原生的沙箱限制，向求值作用域（Context）内暴露了包

前言 随着大语言模型（LLM）的爆发，AI Agent（智能体）已经从简单的“对话机器人”演进为能够调用外部工具、执行复杂任务的系统级应用。在多代理（Multi-Agent）架构中，“子代理编排（Subagent Orchestration）”或“交接（Handoff）”机制被广泛采用，以解决单次对话上下文过长、单点任务过于复杂的问题。 然而，当安全研究员将视线从 LLM 的“幻觉”与“提示注入（Prompt Injection）”转移到框架底层的业务逻辑时，往往能发现更致命的系统级漏洞。 本文基于开源 AI 机器人框架 AstrBot (v4.25.5)，深度剖析一个由于子代理交接机制未进行安全边界隔离，导致的底层权限绕过，并最终实现远程命令执行（RCE）的 0day 级漏洞。文章将从源码审计、靶场搭建、LLM 社工绕过，直至自动化 Exp 的武器化编写，完整复现这条 AI 框架攻击链。

鉴权分析 与鉴权有关的类如下： SecurityConfig WebMvcConfigurer public(.*?)Interceptor { public(.*?)filter { server-admin路由， # 不参与权限判断的接口 common: apis: /user/userInfo,/user/password/change,/permAssignment/stationGroupList,/logout,/user/password/check SecurityConfig白名单， WebMvcConfig白名单， 各种过滤器，com.某cms.web.inteceptor.*，其中也存在白名单， server-front路由， ServerFrontWebMvcConfig白名单， 存在两个拦截器， service-gateway中的白名单， 看了白名单路由没啥用，过

本文内容仅供技术学习与交流使用，严禁用于任何非法用途。请遵守《中华人民共和国网络安全法》等相关法律法规，因违规使用产生的一切后果，由使用者自行承担，与作者无关。 一、引言 随着 AI Agent 逐渐具备代码生成与工具执行能力，越来越多的应用开始采用生成式 UI（Generative UI）技术，由大模型动态生成 Python 代码，并通过沙箱执行后构建交互界面。这种方式提高了应用的灵活性，同时也对不可信代码的执行隔离提出了更高要求。 目前，WebAssembly（WASM）已被应用于部分 AI 代码执行场景，通过独立运行环境和虚拟文件系统限制代码对宿主资源的访问。但 当沙箱内部的代码能够通过跨语言接口调用宿主运行时 API 时，原有的权限隔离可能失效 ，本文以 Prefab UI 为研究对象，结合实际执行链、漏洞复现和源码分析， 还原从 Pyodide 沙箱到 Deno 宿主文件系统的权

前言 最近几天，“Sorry”勒索病毒的关注度明显有所提升。各大媒体平台陆续发布了相关的防范文章和科普视频，也有不少读者与客户向我们留言，问什么的都有：它是不是一个新家族、是不是只针对某一类操作系统、中了之后还能不能恢复。 防范知识的集中普及，对整个行业来说始终是好事。不过我们也注意到，这一轮讨论中有不少结论，与我们在一线处置中掌握的情况存在一些出入。有些出入不影响防护建议本身，有些则可能导致误判，比如把防护重心放错了方向。 从今年 3 月到现在，Solar 应急响应团队对这一威胁保持了持续跟踪，先后发布了首期预警、攻击路径复盘、零设备环境下的极限溯源拆解，以及管家婆 0day 攻击链分析等多篇文章，也处置了相当数量的真实案例。基于此，我们整理了近期最常被问到的七个问题，做一次集中解答。文中所有结论均来自我们的实战处置记录与样本分析，观点仅供大家参考，也欢迎同行交流指正。 TellYouT

CVSS 10.0 / 无认证 RCE / 影响 < 0.8.0 / 修复 0.8.0 GHSA-5882-5rx9-xgxp Crawl4AI 是当下最流行的开源 LLM 爬虫框架之一，官方 Docker 镜像默认把 API 暴露在 11235 端口，POST /crawl 端点默认不启用 JWT 认证。这个端点接受一个 hooks 参数，允许调用方注入 Python 代码，在爬取生命周期的各个事件点执行。代码在 exec() 里跑，外面套了一层"沙箱"——一个手写的 builtins 白名单。 问题出在白名单里多了一项： import 。 0x00 漏洞信息 项 值 CVE CVE-2026-26216 GHSA GHSA-5882-5rx9-xgxp CVSS 10.0 类型 未认证远程代码执行 影响版本 crawl4ai < 0.8.0 修复版本 0.8.0 攻击向量 POST /

新社区上线，积分、稿费翻倍啦！

写在前面 先向各位读者说明一件事：上周，我们先后发布了两篇关于某国产 ERP 系统漏洞的分析文章。发布后，出于内容严谨性与合规表达的考虑，我们主动对文章做了下架处理，并就相关内容与相关方完成了沟通。目前问题已妥善处理，现将两篇文章合并修订后重新发布：漏洞结论与防护建议保持不变，部分内容做了进一步脱敏。给本周等待更新的读者说一声抱歉，也感谢大家的理解。 回到正题。六月底，我们发布了 Weaxor 与 TellYouThePass 两大家族借管家婆软件攻击国内中小企业的全链路复盘；七月的 JADEPUFFER 复盘中，我们又跟踪了全球首个 AI 自主完成的勒索攻击。两篇文章留下过同一个判断： 勒索组织的漏洞武器化速度正在发生质变，0day 正在取代 Nday 成为主攻方向。 这个判断的第三次验证，来得比我们预想的更快。 7 月底至今，Solar 应急响应团队接连处置了多起 .weax 勒索事件

写在前面 先说明为什么写这篇案例。 做应急响应数百起，我们处置过大量勒索事件，其中不乏手法精密的攻击：0day 漏洞、无文件落地、内存加载。但这起案件不一样， 它的攻击技术难度并不高，真正难的从来不是技术，而是人。 攻击者没有用任何高深的手法，入口只是一次"图省事"的端口映射：第三方运维人员私自将内网服务器的 3389 远程桌面映射到公网，事后又不愿承认。我们在应急响应中遇到过太多次类似场景：运维私开测试端口、用 frp 做内网穿透、在路由器上随手做一条映射，方便是方便了，门也敞开了。而事后追问时，第一反应往往是否认。 这篇文章，完整还原我们从"日志被清空、线索近乎中断"的现场，用逆向思维反推出入口、再用证据链坐实全过程的思路。 为保护受害单位信息，文中内容已做脱敏处理，仅分享溯源思路与防范建议，供同行参考。 文中涉及两台 Windows 服务器，为便于阅读，统一标注为： A 主机 ：最先

前言 在 AI 大模型与 Agent 蓬勃发展的今天，像 FastGPT 这样允许用户自定义工作流（Workflow）的平台，不可避免地引入了大量出站网络请求。为了防御 SSRF（服务端请求伪造），开发者通常会采用黑名单机制。 然而，在 FastGPT v4.14.11 及更早版本中，存在一个 CVSS 评分高达 7.7 的 SSRF 漏洞（CVE-2026-42345）。令人深思的是：代码中明明存在 isInternalAddress 这样的防御函数，甚至硬编码了各大云厂商的元数据地址，为何防线依然被轻易击穿？ 本文将从代码审计切入，结合动态复现，揭示这场由“字符串信任危机”与“默认配置失效”共同导致的防御崩塌。 一、 代码审计：寻找防线 系统在处理用户输入的 HTTP 请求时，会调用 packages/service/common/system/utils.ts 中的 isIntern

【升级通知】2026 年 11 月 1 日 00:00 至 06:00 先知社区新版本迭代升级，期间社区暂停访问。

如果模型明确回复“不能执行”，我们通常会认为这次操作已经被成功拦截。但模型说了“不能执行”，就意味着底层工具一定没有被调用吗？

Qdrant 分布式集群的 6335 内部端口，从 1.19.1 到 1.20.0 连修两轮：先堵只读 key 调 AddPeerToKnown，再把 enforce_internal_auth 默认打开。但不配 api_key 的集群仍然全裸——匿名能加 peer、往 collection 写数据、读 telemetry。我写了个假 6335，集群真把向量数据推了过去。

自今年6月以来，我们持续跟进weax勒索病毒在国内的多起攻击事件。近期，该家族已将加密文件后缀改为 `.rox`。在此前发布的畅捷通T+案例中，我们已对这一变化作出预警。 围绕tellyouthepass（sorry勒索病毒）、weaxor等相关勒索家族，我们也持续发布过溯源分析。建议结合往期文章阅读，了解其攻击手法的延续与变化。

在此之前接触过不少pyjail沙箱逃逸题目，玩法颇多，这里总结一下Pyjail基础解法最简单的Python沙箱把 __builtins__ 换成了一个白名单字典，没有所谓的危险方法。pyjail的基础解法就是利用Python 里任何对象都能顺着类继承链爬到 object遍历所有子类，从而执行open、eval等危险函数。基础payload获取os模块恢复 __builtins__其中warning

CVE-2026-16723漏洞复现、代码分析及漏洞修复（附漏洞环境与poc）

artex流程优化思路分享及落地

针对华为 HG532 系列路由器 upnp 守护进程（监听 37215）做静态审计，定位 /ctrlt/ DeviceUpgrade_1 的 Upgrade action 处理函数：其从 SOAP XML 取 NewDownloadURL 与 NewStatusURL 两个字段后，未经任何过滤直接 snprintf 拼入 upg 命令模板并交给 system()， 且该服务以 root 权限运行。

CVE-2025-63888（CVSS 9.8）是ThinkPHP 5.0.24模板文件包含漏洞。业务层将用户可控参数直接传入view()函数，底层模板驱动路径校验缺失，攻击者可传入绝对路径/穿越路径包含恶意文件，利用TP模板 {php} 标签编译执行PHP代码，达成RCE。本文完整完成代码审计与漏洞复现，分析数据流与攻击链路并给出修复方案。

Mercury 3.2.3 的 BLOCKED_PATTERNS 里少了一个逗号，Python 把两条正则拼成一条，/lab 和 /api/terminals 同时失守——匿名 POST 换个终端就拿到 shell。3.2.4 补了逗号只关一半，/api/kernels 仍能建内核执行任意代码，/api/contents 还能匿名写文件。补丁与公告隔了两个月。4 版本实测 + mercury-au

本文在自建Gitea与gitea-runner上复现Gheist的「投递工作流—读取密钥—编码入日志—经平台API取回」无C2外带链路，测绘脱敏引擎的匹配规则与载荷尺度效应，回答载荷为何选base32，并给出以金丝雀变换指纹为核心的检测点与防御优先级。

本文逆向分析了 CVE-2025-6101 的官方修复补丁，发现其在沙箱底层硬编码了 allow_unsafe_eval=True，导致针对 ast_parsers.py 的 AST 绕过依然可以触发未授权 RCE。文章完整还原了从 interface.py 到 ast_parsers.py 的双阶段攻击链路，并提供了详细的 PoC 与底层源码分析。

两个互不相通的容器，竟然能利用内部 Artifactory 的对象属性交换数据，甚至进一步影响其他会话。原本只是用来缓存依赖的服务，没想到还能成为数据传递的通道。

长安杯 计算机部分 writeup

FoxIO于2026年10月20日披露Header Accordions攻击，QPACK解码器成为HTTP/3服务端的新型内存放大器。本文复现三条利用路径，实测Bun 1.4.3以588.7 KB流量放大4045倍触发OOM，并验证两个新版补丁的有效性。

羊城杯wp

CVE-2025-41242是Spring Framework高危路径穿越漏洞，利用Java字符高位截断（幽灵比特）特性，构造特殊Unicode字符生成畸形 %uXXXX 编码，实现跨组件解析不一致绕过，突破Spring路径黑名单校验，在Jetty底层还原出目录穿越符号读取敏感文件。本文从代码审计、漏洞复现到补丁验证完整复盘该漏洞，分析利用链并给出安全防御方案。

本文详细记录了对某智能灯泡的低功耗蓝牙（BLE）安全测试全过程。文章从 Wireshark 与 nRF52832 抓包环境的搭建切入，直击物联网设备通信痛点，演示了如何捕获设备指令、逆向分析 GATT 读写 Payload，并成功利用 nRF Connect 实施重放攻击接管设备。文末针对实测漏洞，提出了引入随机数、挑战-应答机制及链路层加密等安全防护建议。

题目质量很高

CVE-2026-23918 是 **Apache HTTP Server 2.4.66** 版本中 `mod_http2` 模块存在的高危内存破坏漏洞。

近期，公安部网安局在护网专项工作中发布提醒文章，文中明确点名Sorry、Weax两个勒索家族近期攻击十分活跃，制造、商贸、医疗、教育、科技等行业的企业接连中招。作为长期奋战在一线的应急响应团队，我们对这个提醒的感受比大多数人都要直接，因为我们就身处这些案例的现场。

本文复现 CVE-2026-109618 PHP2Shell OOM 堆破坏 RCE 漏洞，基于 Docker 靶场验证绕过 ASLR 的完整利用链，并对照官方补丁验证修复效果，总结复现坑点与安全加固方案。

Mercury 是一个基于 Python 的框架，主要用于将 Jupyter Notebook 快速转换为交互式的 Web 应用程序。在早期的版本中，其内核管理接口存在严重的访问控制缺陷。

(本文首发于个人博客：https://23w-8h.github.io/2026/10/20/Whitechain-%E8%B7%A8%E9%93%BE%E6%A1%A5%E6%BC%8F%E6%B4%9E%E6%8C%96%E6%8E%98%E5%A4%8D%E7%9B%98%EF%BC%9A%E4%BB%8E%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E5%88%