Next.js unstable缓存参数碰撞Exploitarium前端框架服务端对象劫持PoC拆解【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium本文拆解 Exploitarium 安全研究仓库中的Next.js unstable_cache 缓存参数碰撞 PoC当你把Request对象直接传给缓存函数时缓存键会坍缩成同一个空对象导致后来的用户直接拿到第一个用户的请求结果——一次典型的服务端对象劫持。 一句话理解Next.js unstable_cache 缓存机制的坑unstable_cache是 Next.js 官方提供的服务端数据缓存 API同一个缓存组下函数参数相同 → 命中同一条缓存。而缓存键的生成依赖对参数做 JSON 序列化。问题就出在这里三种 Web 原生对象序列化后全部是空对象——JSON.stringify(request) // Request → {} JSON.stringify(searchParams) // URLSearchParams → {} JSON.stringify(formData) // FormData → {}但缓存回调内部依然能读取这些对象的实时内容Cookie、查询参数、表单字段。于是缓存键所有请求都相同 ❌计算结果却取决于第一个请求的内容 ⚠️不同用户的请求被折叠进同一条缓存条目第二个用户拿到的是第一个用户的数据first-writer wins先写者赢。 三种会碰撞的请求形态PoC 生成了三条路由覆盖全部三种对象参数路由直接传入的缓存参数回调里读取的实时内容/api/requestRequest对象Cookie 头、请求 URL/api/urlsearchURLSearchParamssecret查询参数/api/formFormDatasecret表单字段验证逻辑很直观同一个缓存组先发alice、再发bob两次请求如果第二次响应仍是REQ_COOKIEvictimalice JSON{}说明 bob 拿到的是 alice 的缓存结果——碰撞实锤。PoC 还会做反向验证bob 先发、alice 后发证明谁先发请求后来者就拿到谁的数据。 PoC 一键复现步骤环境要求Node.js 20、npm、可联网安装依赖默认使用next16.3.0-canary.70。git clone https://gitcode.com/GitHub_Trending/ex/exploitarium cd exploitarium/nextjs-unstable-cache-object-argument-collision node run_demo.mjs脚本全自动完成四步见 run_demo.mjs 生成一个临时 Next.js 应用并完成npm installnext build 启动next start对三条路由各发 alice/bob 两组对照请求 停服再启不删应用目录用charlie请求命中旧缓存组——验证缓存跨重启持久化在 Data Cache 中✅ 全部断言通过后输出confirmedtrue并生成VULNERABILITY_CONFIRMED.marker自定义端口或版本node run_demo.mjs --port 3561 --next-version 16.3.0-canary.70✅ 如何修复先抽取原始值再进缓存PoC 内置了对照组value control在调用unstable_cache之前先把 Cookie / 查询参数 / 表单字段提取成普通字符串再传入结果 alice 和 bob 各自命中独立缓存条目碰撞消失。// ❌ 危险直接传对象缓存键坍缩为 {} unstable_cache(async (req) { /* 读 req.headers */ }, [group], { revalidate: 3600 }) // ✅ 安全先抽取原始值作为参数缓存键各不相同 unstable_cache(async (cookie) { /* 用 cookie 计算 */ }, [group, cookie], { revalidate: 3600 })核心原则进入unstable_cache的参数只能是可区分的原始值字符串、数字永远不要把Request、URLSearchParams、FormData这类对象直接当参数。 相关文件导读PoC 说明文档nextjs-unstable-cache-object-argument-collision/README.md一键复现脚本含路由生成与断言逻辑run_demo.mjs三条路由的生成逻辑run_demo.mjs#L162-L263alice/bob 对照请求与重启验证run_demo.mjs#L302-L346碰撞判定断言run_demo.mjs#L353-L369⚠️ 结语这个 PoC 演示了缓存框架中一个隐蔽却危险的范式键的视图与值的视图不一致——序列化时看不到对象内容执行时却能读到全部请求细节。它的影响面是敏感数据串号泄漏且缓存会跨重启留存隐蔽性更强。仓库作者声明这些 PoC 均为善意公开的研究成果仅供学习请勿用于任何滥用场景。【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Next.js unstable缓存参数碰撞：Exploitarium前端框架服务端对象劫持PoC拆解
Next.js unstable缓存参数碰撞Exploitarium前端框架服务端对象劫持PoC拆解【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium本文拆解 Exploitarium 安全研究仓库中的Next.js unstable_cache 缓存参数碰撞 PoC当你把Request对象直接传给缓存函数时缓存键会坍缩成同一个空对象导致后来的用户直接拿到第一个用户的请求结果——一次典型的服务端对象劫持。 一句话理解Next.js unstable_cache 缓存机制的坑unstable_cache是 Next.js 官方提供的服务端数据缓存 API同一个缓存组下函数参数相同 → 命中同一条缓存。而缓存键的生成依赖对参数做 JSON 序列化。问题就出在这里三种 Web 原生对象序列化后全部是空对象——JSON.stringify(request) // Request → {} JSON.stringify(searchParams) // URLSearchParams → {} JSON.stringify(formData) // FormData → {}但缓存回调内部依然能读取这些对象的实时内容Cookie、查询参数、表单字段。于是缓存键所有请求都相同 ❌计算结果却取决于第一个请求的内容 ⚠️不同用户的请求被折叠进同一条缓存条目第二个用户拿到的是第一个用户的数据first-writer wins先写者赢。 三种会碰撞的请求形态PoC 生成了三条路由覆盖全部三种对象参数路由直接传入的缓存参数回调里读取的实时内容/api/requestRequest对象Cookie 头、请求 URL/api/urlsearchURLSearchParamssecret查询参数/api/formFormDatasecret表单字段验证逻辑很直观同一个缓存组先发alice、再发bob两次请求如果第二次响应仍是REQ_COOKIEvictimalice JSON{}说明 bob 拿到的是 alice 的缓存结果——碰撞实锤。PoC 还会做反向验证bob 先发、alice 后发证明谁先发请求后来者就拿到谁的数据。 PoC 一键复现步骤环境要求Node.js 20、npm、可联网安装依赖默认使用next16.3.0-canary.70。git clone https://gitcode.com/GitHub_Trending/ex/exploitarium cd exploitarium/nextjs-unstable-cache-object-argument-collision node run_demo.mjs脚本全自动完成四步见 run_demo.mjs 生成一个临时 Next.js 应用并完成npm installnext build 启动next start对三条路由各发 alice/bob 两组对照请求 停服再启不删应用目录用charlie请求命中旧缓存组——验证缓存跨重启持久化在 Data Cache 中✅ 全部断言通过后输出confirmedtrue并生成VULNERABILITY_CONFIRMED.marker自定义端口或版本node run_demo.mjs --port 3561 --next-version 16.3.0-canary.70✅ 如何修复先抽取原始值再进缓存PoC 内置了对照组value control在调用unstable_cache之前先把 Cookie / 查询参数 / 表单字段提取成普通字符串再传入结果 alice 和 bob 各自命中独立缓存条目碰撞消失。// ❌ 危险直接传对象缓存键坍缩为 {} unstable_cache(async (req) { /* 读 req.headers */ }, [group], { revalidate: 3600 }) // ✅ 安全先抽取原始值作为参数缓存键各不相同 unstable_cache(async (cookie) { /* 用 cookie 计算 */ }, [group, cookie], { revalidate: 3600 })核心原则进入unstable_cache的参数只能是可区分的原始值字符串、数字永远不要把Request、URLSearchParams、FormData这类对象直接当参数。 相关文件导读PoC 说明文档nextjs-unstable-cache-object-argument-collision/README.md一键复现脚本含路由生成与断言逻辑run_demo.mjs三条路由的生成逻辑run_demo.mjs#L162-L263alice/bob 对照请求与重启验证run_demo.mjs#L302-L346碰撞判定断言run_demo.mjs#L353-L369⚠️ 结语这个 PoC 演示了缓存框架中一个隐蔽却危险的范式键的视图与值的视图不一致——序列化时看不到对象内容执行时却能读到全部请求细节。它的影响面是敏感数据串号泄漏且缓存会跨重启留存隐蔽性更强。仓库作者声明这些 PoC 均为善意公开的研究成果仅供学习请勿用于任何滥用场景。【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考