先知技术社区

写在前面 happy-dom 是一个用 JavaScript 实现的 DOM 运行时。它被大量前端项目放进 Vitest / Jest 的测试环境，也被用在 SSR 预渲染、HTML 转换和爬虫里。这些场景有一个共同点： HTML 往往来自不可信的一方 ——用户评论、富文本、抓回来的第三方页面、上传的模板。 在浏览器里，页面里写了 ，浏览器就会去加载它，这是规范行为，没有人觉得奇怪。问题在于，当同一段 HTML 被交给服务端的 happy-dom 时，去加载它的是 服务器进程 ，而服务器进程通常站在内网里、握着云凭证、能访问只监听 localhost 的管理接口。同一个行为，换一个执行者，性质就从"渲染页面"变成了"服务端请求伪造"。 CVE-2026-118660 说的就是这件事。它的成因短得可以用两行配置描述，但从一段字符串到一次出网请求，中间要经

前言 在日常的 Web 安全研究中，文件上传与解压功能一直是高危漏洞的温床。从 2018 年 Snyk 安全团队首次披露 Zip Slip 漏洞以来，这种利用压缩包内文件名的路径穿越缺陷，广泛存在于各类支持解压的 Web 应用、中间件乃至开发框架中。攻击者通过构造包含 ../ 序列的恶意压缩包，可以绕过应用的上传目录限制，将任意文件写入服务器的敏感位置（如系统配置、计划任务、启动项等），进而实现从“任意文件写入（Arbitrary File Write）”到“远程代码执行（RCE）”的致命跨越。 近期，笔者在对开源 HTTP 文件服务器 Gohttpserver 进行代码审计与安全测试时，完整复现了该漏洞的利用链路。Gohttpserver 是一款基于 Go 语言编写、广受好评的轻量级文件服务器，其内置的 --upload 功能极大地方便了日常的文件传输与共享。然而，正是因为其主打“轻量、

本文记录了针对开源 LLM 应用平台 Dify 沙箱模块的一次安全测试过程。在研究其网络架构与源码时，发现由于默认配置中存在硬编码的通信凭证，在特定部署条件下（如端口暴露于公网），可能存在未经授权执行代码的风险。 文章详细复现了从鉴权绕过到获取底层系统信息的完整链路。针对此问题，官方团队基于开发者体验（DX）的考量，认为该设计属于预设功能并无缺陷。本文不针对此定性做过多主观评价，仅从客观的技术视角还原漏洞细节，并从企业自托管运维的视角，给出了一套切实可行的纵深防御建议，以供安全同仁交流探讨。 摘要 dify 该服务中存在硬编码的默认 API 密钥（ ） dify-sandbox 。能够访问 Dify 内部网络的攻击者可以 middleware.Auth() 通过 X-Api-Key: dify 请求头绕过该密钥，从而执行任意 Python 代码。本报告详细描述了完整的攻击链，从代码来源到实

前言 云上攻防做久了会有存在一个习惯，拿到凭据就直奔 VM而后翻数据、翻 IMDS，容器端口不对外往往被当成跑代码的黑盒。Azure 容器相关服务（ACR、ACI、ACR Tasks）攻击面经常被忽略，传统替换镜像插入反弹 shell 的方案在云环境很不稳定，对此可用一种新的攻击手段：把 IMDS 元数据窃取逻辑写进容器 Entrypoint，不需要持久反弹 shell，直接外排密钥。 这篇文章记录的是一次以密钥为目标的演练。整个过程最值得写的不是哪条命令好用，而是常规手段 ENTRYPOINT 反弹 Shell 反复失败后思路的转变，变成了让容器自己在启动时替我干活，于是整条链路的性质都变了。 场景 起点：从供应链的配置拿到一个低权限账号，容器上的权限为 Contributor 目标：拿到 Key Vault 里那个名为 Image 的密钥 阶段一：权限测绘与注册表接管 1、拿当前登录账

前言（踩坑经验分享） 最近在对白链（Whitechain）的桥接协议（bridge-contracts）进行代码审计时，我发现了一个逻辑非常严密的 Critical 级别漏洞（假充值漏洞）。理论上，攻击者可以利用该漏洞以零成本掏空目标链的流动性池。 我用 Foundry 编写了完美的 PoC 并在本地跑通了全流程，随后提交至 HackenProof 平台。但遗憾的是，这份报告最终被官方以“Out of Scope（超出审计范围）”为由关闭了。 这次“踩坑”经历非常典型。在 Web3 赏金平台，除了比拼技术实力，读懂项目方的“威胁模型（Threat Model）”同样重要。借此机会，我写下这篇复盘文章，一来分享漏洞挖掘的技术细节与 Foundry PoC，二来总结一下在 Bug Bounty 挖掘中，如何让自己的报告更契合平台的规则，希望能给各位提供一些参考经验。 一、 漏洞详情与代码分析

摘要 在处理用户上传的归档文件时，安全校验的边界一旦出现偏差，就可能引发灾难性的后果。本文将深入分析开源的学术优化工具 GPT Academic（受影响版本 ≤ 3.91）中存在的任意文件读取漏洞（CVE-2025-25185）。文章依托真实的漏洞复现截图，从核心源码的逐行拆解、恶意 Payload 的底层构造，到 Web 交互与文件读取的最终触发，完整还原了从代码审计到实战利用的全生命周期。本文旨在为安全从业者提供一种关于压缩包解压场景的深度思考与防御思路。 一、 漏洞背景与攻击面概述 现代 Web 应用中，文件上传与处理是极为常见的业务需求。GPT Academic 作为一款深受科研人员喜爱的 LLM 辅助工具，提供了“上传论文/代码压缩包进行智能解析”的功能。为了支持这一功能，开发者必须实现服务端的解压逻辑。 CVE-2025-25185 的核心正是出在这个解压环节。在 Linux

引言 我最初接触对抗样本时，注意力主要放在FGSM、PGD这类白盒攻击上，觉得只要理解了梯度怎么被利用、扰动怎么让模型出错，就对这个问题有了比较完整的认识。后来把迁移攻击和经典黑盒攻击放在同一条线索上重新梳理，我才发现之前的理解偏窄：现实中的攻击者往往看不到模型内部，查询也受限，此时对抗样本能否迁移、查询成本高不高、一些正常功能会不会被组合成新的传递或攻击路径，都会影响风险评估。 基于这个发现，本文尝试从威胁模型、攻击目标和算法选择入手，把白盒攻击、迁移攻击和黑盒攻击串起来，帮助读者建立“威胁模型—攻击目标—算法选择—防御评估”的整体认识，而不是只盯着攻击成功率。这次研究让我意识到，对抗样本的意义在于更真实地评估模型鲁棒性和安全部署风险：白盒攻击暴露脆弱点，迁移和黑盒攻击提醒我们现实攻击可能性不能低估。 一、对抗样本与基本概念 1.1 什么是对抗样本 什么是人工智能模型 假设我们训练了一个

一、漏洞说明 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

解析 H.266 码流时，DCI 里那个 4 bit 的 num_ptls_minus1 只要填成保留值 15，GStreamer 1.28.8 就会在结构体末尾之外写入最多 1026 字节；官方描述里也写明标准管线走不到这段代码，所以至今没有补丁。 一、漏洞说明 1、漏洞本身 出问题的是 gst-plugins-bad 里的 libgstcodecparsers ，具体函数 gst_h266_parser_parse_dci() 。它解析 H.266 的 DCI（解码能力信息，NAL 类型 13）时，先读 4 bit 的 num_ptls_minus1 ，再按这个值循环解析同样数量的 profile_tier_level 结构。字段只有 4 bit，合法取值 0–14，15 是保留值，代码却把上限校验写成 15。保留值被放行后，循环多跑一次，第 16 个元素写到数组末尾之外。 函数定义在

信息收集 首先，通过fofa，hunter信息收集发现了如下资产 https://xxxx.edu.cn:8081 https://xxxx.edu.cn:9443 但是直接访问发现显示路由校验失败 不是显示没有授权、404而是路由校验失败 所以这里猜测如果有了合适的路由大概率就能够正常访问了 于是在这个思路的加持下打算点一下上帝之眼查看具体路径 然后复制全部路径放BP里进行爆破 爆破下发现都是200，我都以为要出货了，没想到访问后显示需要登录（bushi） 随便调了一个URL https://xxxxxx.edu.cn:8081/subpages/admin/home/home 发现显示报错；没辙了只能把接口发给ai做进一步测试 AI果然还是厉害，发现这个路径还隐藏了一个token参数 https://xxxxxxx.edu.cn:8081/subpages/admin/home/hom

写在前面 员工修改了泄露密码，企业就安全了吗？ 不一定。密码只是攻击者已经拿到手的一部分数据。真正需要回答的还有三个问题：密码从哪台电脑泄露？电脑里是否仍有恶意组件？已经泄露的登录会话是否还能继续使用？ 近期，思而听江鹭威胁情报中心监测到某制造企业多条账号凭据泄露记录。客户收到预警后，修改了部分业务系统口令，并临时禁用了公共邮箱。我们没有停在这一步，而是继续追踪消息源、下载窃密日志包并开展上机取证，最终定位到该企业海外分公司的一台个人Windows 11电脑。 调查确认，这不是一次简单的账号撞库。该主机遭遇了Vidar信息窃取木马，419条浏览器明文凭据和3,860条Cookie被打包外流。更早之前，一套恶意加载器已经在主机上驻留50余天。窃密发生时，用户正在正常使用浏览器，没有需要其确认的弹窗。 阅读说明：本文基于一起授权溯源事件复盘。客户名称、员工姓名、账号、真实域名、主机名、IP地址

TurboFan 把两条返回类型不同的 JS→Wasm 调用点内联进同一个函数时，帧状态判等函数漏掉了 Wasm 签名的比较，两份帧状态被判成同一份；一次惰性反优化之后，返回值按错误的类型物化——对象地址被读成整数，整数被当成对象指针。

前言 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

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

商丘师范学院第五届网络安全及信息对抗大赛 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