---
name: v8-security-triaging
description: Guides the initial analysis and impact assessment of a V8 security report, strictly excluding implementation or fixing.
---

# Skill: V8 Security Triaging

Use this skill to orchestrate the initial analysis and impact assessment of a V8
security vulnerability report.

## Core Mandates

- **Strategic Orchestration**: You are the **Orchestrator**. Your goal is to
  manage specialized subagents to verify reporter claims empirically while
  keeping your own context lean.
- **Technical Skepticism**: Treat all reporter claims (e.g., "OOB write", "RCE",
  "Silent Write") as **hypotheses**, not facts. Your primary job is empirical
  verification.
- **Mandatory Local Reproduction**: A report MUST NOT be classified as a
  "Vulnerability" unless it is empirically reproduced locally (e.g.,
  demonstrating a crash, memory corruption, or a clear security boundary
  violation). If the provided POC does not reproduce the claimed behavior, do
  NOT classify it as a vulnerability. Instead, report that it did not reproduce
  in the final report.
- **Scope Limitation**: This skill is strictly for **triaging and impact
  analysis**. It does NOT include implementing a fix or creating a CL. Fixing is
  a separate task that must be explicitly requested by the user after triage is
  complete.
- **No External Actions without Approval**: NEVER upload a CL, post a comment,
  or modify issue metadata on Buganizer or Gerrit without explicit user approval
  of the exact content and action.
- **Buganizer First**: Use the Buganizer MCP (`render_issue`) as the primary
  source of truth. Use `render_issue_with_external` if content is redacted.
- **Sandbox Bypasses vs. Regular Bugs**:
  - **Sandbox Bypass**: Reports that start with in-sandbox memory corruption
    (using `--sandbox-testing` or `--expose-memory-corruption-api` or the
    Sandbox API). These are strictly governed by the V8 Sandbox threat model.
  - **Regular Bug**: Vulnerabilities that do not require an initial in-sandbox
    write primitive.
- **Title Accuracy**: If the reporter provided a generic title, identify a more
  descriptive and accurate title based on the crash state or root cause.
- **Component Verification**: Propose only actual Buganizer components. Use
  `mcp_Buganizer_list_components` to verify existence and
  `mcp_Buganizer_get_component` to verify the component path and ID before
  posting.
- **Remote Execution Priority**: Always use `use_remoteexec = true` in GN
  arguments for all local builds to speed up the process, even if a reporter
  provides a configuration where it is set to `false`. Remote execution is
  strictly an environmental optimization and does not affect reproduction logic.
- **Environmental Awareness**: During information gathering, identify if the
  crash involves **specialized execution modes** (e.g., REPL mode,
  `DebugEvaluate`, or experimental features) that might have different security
  properties.
- **Attachment Access**: Only attempt to retrieve attachment content (e.g.,
  `poc.js`) using the Buganizer MCP tools. If the tools fail, **MUST** ask the
  user to provide the content manually. Do not speculatively search for
  restricted attachments.
- **ClusterFuzz Check**: Check the issue's comments for indications that the
  crash has already been uploaded to ClusterFuzz. If not uploaded, provide the
  user with manual upload instructions in Step 5.
- **Exhaustive Verification**: Never classify a bug based solely on the report.
  Exhaustive technical verification via `v8-poc-classification` is mandatory.
- **Official Documentation**: Always refer to
  [triaging.md](../../../docs/security/triaging.md) for the definitive rules on
  labeling and classification.
- **Strict Subagent Delegation**: To maintain a lean context, the Orchestrator
  **MUST NOT** call Buganizer, Gerrit, or local execution tools directly during
  Phases 1-4. All technical tasks must be delegated to subagents via
  `invoke_agent`. The Orchestrator's role is strictly limited to reviewing
  subagent summaries and coordinating the next step.

## Strategic Orchestration Guidelines

When executing a triage task, delegate tactical steps to subagents:

- **Researcher**: Fetching report details, identifying experts
  (`find_experts_for_file`), and locating Buganizer components.
- **Builder**: Setting up the environment (`git checkout`) and building specific
  variants (Release, ASan, non-ASan).
- **Tester**: Baseline reproduction across multiple configurations and security
  boundary checks.
- **Generalist**: POC minimization, flag bisection, and "healing" POCs
  (replacing natives with standard JS).
- **Debugger**: Interactive crash analysis in GDB to verify primitives and
  attacker control.

## Workflow

### 0. Phase: Prepare isolated worktree

- **Orchestrator Instruction**: "Use v8-workflow skill to create a fresh
  worktree (cr-NNN, where NNN is the bug number) and respective branch for
  investigation. Choose "Isolated Strategy", don't ask user. Switch to the new
  worktree and work there to avoid contamenating current workspace. Use "tmp"
  subdirectory for temporary files."

### 1. Phase: Intake (Delegation)

Task the **Researcher** subagent with gathering all necessary data from
Buganizer.

- **Orchestrator Instruction**: "Invoke the Researcher to render Buganizer issue
  `<id>`, extract the POC and d8 flags, find top experts for affected files, and
  identify the correct component. Instruct the subagent to return only a concise
  technical summary."
- **Extraction**: The summary must include the POC script, required `d8` flags,
  the reporter's environment (commit hash/version), and the identified
  **introduction commit (regression range)**.
- **Version and Commit Identification**: Always retrieve the current V8 version
  number from `src/utils/version.h` and the specific git hash using
  `git rev-parse HEAD`. Prioritize referencing specific git hashes over generic
  terms like "HEAD" in triage reports.
- **Attachment Check**: Ensure the subagent checks for mentioned files (e.g.,
  "poc.html", "crash.log") that are NOT in the attachments list.
- **Stop Condition**: If the subagent reports that critical attachments (POC,
  flags, etc.) are inaccessible or redacted, the Orchestrator **MUST** stop
  immediately and ask the user to provide them manually before proceeding to
  Phase 2.
- **Mapping**: Include identified experts and the specific Buganizer component
  (e.g., `Blink > JavaScript > Maglev`).

### 2. Phase: Exhaustive Reproduction (Delegation)

Task the **Tester**, **Builder**, and **Generalist** subagents with confirming
the issue. You MUST confirm the bug exists before proceeding.

- **Baseline**: Task **Tester** to reproduce with the reporter's exact flags and
  revision.
- **Escalation**: If initial attempt fails, task **Builder** and **Tester** to
  verify across Release, Debug, and ASan variants at HEAD.
- **Healing (Initial)**: If still failing, task **Generalist** to analyze and
  "heal" the POC for environmental dependencies.
- **Summary**: Review the subagent's reproduction command and result. Stop if
  reproduction fails after exhaustive attempts.

### 3. Phase: Security Boundary Verification (Delegation)

Task the **Tester** and **Generalist** to determine if the bug violates a
security boundary.

- **Boundary Check**: Task **Tester** to replace
  `--expose-memory-corruption-api` in `reporter_flags` with `--sandbox-testing`
  and run with updated `reporter_flags` and `--run-as-[sandbox]-security-poc`.
- **Investigation Loop**: If the crash stops reproducing with the security flag,
  task **Generalist** to identify why and attempt to "heal" the POC by replacing
  forbidden syntax with standard JS while maintaining the bug trigger.
- **Conclude**: Review the subagent's conclusion on whether the bug is a
  security vulnerability or a regular bug.

### 4. Phase: Impact Determination & Minimization (Delegation)

Task the **Debugger**, **Tester**, and **Generalist** to provide technical proof
of impact.

- **Crash/Corruption Priority**: Task **Generalist** to make the POC either
  crash or demonstrate clear memory corruption.
- **Verification**: Task **Tester** to verify on Standard Release and ASan
  builds.
- **Minimization**: Task **Generalist** to reduce the POC and flags to the
  smallest possible set using the methodology in `v8-poc-classification`.
  - **Security Impact Check**: If minimization/bisection shows that a
    vulnerability only reproduces with flags disabled in production (e.g., a
    developer flag), it should be classified as `Security_Impact-None`.
- **Deep Dive**: Task **Debugger** to capture the crash in GDB and verify the
  primitive (Read/Write) and attacker control. Review the provided backtrace.

### 5. Phase: Drafting Findings

Draft a concise synthesis based on verified subagent findings.

- **Mandatory First Sentence**: "This analysis is AI-generated using the
  `v8-security-triaging` skill (Conversation ID: `<id>`)." You **MUST** retrieve
  the `<id>` from the `INVOKER_INFO_SESSION_ID` environment variable.
- **Formatting Requirement**: Use a **bulleted list** format for the main points
  (Status, Classification, Rationale, etc.) and ensure there are **double line
  breaks** between each list item for optimal rendering in Buganizer.
- **Content**:
  - **Classification**: Vulnerability / Bug / Not a Bug (Intended Behavior) /
    Failed to Reproduce. **MANDATORY**: Only classify as "Vulnerability" if
    local reproduction was successful. If reproduction fails, classify as
    "Failed to Reproduce".

  - **Security Impact**: Provide the label (e.g., `Security_Impact-Head`) and a
    short explanation. Skip or simplify the CVSS vector unless requested.

  - **Proposed Severity**: Provide the proposed severity (e.g., `S1`) based on
    [triaging.md](../../../docs/security/triaging.md) and Chromium guidelines.

  - **Introduced In / Regression Range**: Provide the commit or version where
    the vulnerability was introduced, if identifiable.

  - **Rationale**: Explain the technical conclusion. For sandbox bypasses,
    explicitly state if it violates the threat model.

  - **Local Reproduction Findings**: Follow the structure and mandatory fields
    defined in the **Classification Guidelines** of `v8-poc-classification`.
    Ensure all technical data (Status, Reproduction command, Result, Build
    (including version from `src/utils/version.h` and git hash), Verified
    Impact, and optional GDB Backtrace) is included here.

  - **Proposed Owner**: Based on expert discovery. Include a very short (half
    sentence) explanation for the choice (e.g., "author of affected code",
    "primary maintainer of subsystem").

  - **Proposed Component**: Propose the most specific Buganizer component
    possible (e.g., `Parser`, `Maglev`, `Turbofan`) if the current component is
    the top-level V8 engine component or is otherwise incorrect. Include the
    component path and ID.

  - **Proposed Title**: If the current title is generic, propose a more
    descriptive title.

  - **ClusterFuzz Upload Info (User Only)**: If a real crash or memory
    corruption is confirmed and it has NOT yet been uploaded to ClusterFuzz,
    provide all necessary details for a manual upload (repro file, job name,
    issue ID, and flags) to the user. Explicitly advise the user to perform the
    upload.

### 6. Phase: Verification & Self-Correction (Audit)

Task a **Generalist** subagent acting as a "Security Triage Auditor" to review
the draft.

- **Orchestrator Instruction**: "Audit the attached triage draft against
  `docs/security/triaging.md` and the Technical Quality Checklist. Ensure the
  classification is technically sound and the formatting is correct. If errors
  are found, distinguish between text-only corrections and missing technical
  work."
- **Loop-back Mandate**: If the Auditor identifies missing technical evidence
  (e.g., skipped boundary checks, missing GDB analysis, or unverified impact on
  Release builds), the Orchestrator **MUST** return to the relevant previous
  phase (Phase 2, 3, or 4) and re-delegate the work to the appropriate subagent
  before proceeding.
- **Review**: The auditor must verify that:
  - The classification (Vulnerability vs. Bug) is consistent with the
    reproduction results (e.g., if it needs experimental flags, it's a Bug).
  - The "Local Reproduction Findings" section contains the exact d8 command, V8
    version, git hash, and the observed result.
  - The formatting (double line breaks between list items) is strictly followed.
  - The conversation ID is valid or "N/A".
- **Action**: Present the *audited and verified* analysis to the user for
  approval ONLY after all technical gaps identified by the auditor have been
  addressed.

## Technical Quality Checklist

- [ ] **Classification Accuracy**: Does the result match the criteria in
  `docs/security/triaging.md`? (e.g., `nullptr` is a Bug, safe termination is
  Intended Behavior).
- [ ] **Boundary Verification**: Was the POC tested with the security filter
  flag (`--run-as-[sandbox]-security-poc`)?
- [ ] **Mandatory Data**: Are the V8 version and git hash included in the Build
  description?
- [ ] **Formatting**: Are there double line breaks between all bulleted list
  items?
- [ ] **Impact Evidence**: Is the Verified Impact supported by GDB analysis or
  ASan/UBSan logs?
- [ ] **Component Mapping**: Does the proposed component exist with the stated
  ID and is it the most specific one available (not just `V8`)?

## Common Misclassification Pitfalls

- **Experimental Flags**: If a bug requires `--experimental-*` flags and is not
  part of `--future` or `--wasm-staging`, it is a **Bug**, not a Vulnerability.
- **DCHECK vs. CHECK**: `DCHECK` failures are **Bugs**. `CHECK` failures are
  **Intended Behavior** (safe termination) unless they are in-sandbox and part
  of a sandbox bypass claim.
- **Sandbox Read-only**: Sandbox bypasses that only provide **Read** access are
  currently **Bugs**.
- **d8-only Flags**: Bugs requiring flags like `--shell` or `--isolate` are
  **Bugs**.
- **nullptr Dereference**: Always a **Bug**, never a Vulnerability.
