Transient execution target analysis

Use this skill to turn published transient-execution research into a target-specific prerequisite map. Background research creates hypotheses. It does not establish that a target is vulnerable.

Start with passive architecture evidence and source review. Any deployment, active timing experiment, co-location attempt, sustained workload, external timer, or secret-recovery test requires target authorization plus a matching durable approval for each provisioning command and experiment step — provisioning containers, VMs, or throwaway hosts is shell-command and write work that a target grant alone never authorizes. Every active step also needs a bounded lab or owned target, rate limits, and a stop condition. See docs/durable-approvals.md.

Model the attack as prerequisites

Create a Hypothesis for each link below and attach target-specific Evidence. Mark missing links as gaps instead of filling them with assumptions.

1. The attacker can run code near sensitive tenant data.
2. Attacker and victim can share the relevant hardware, process, address space, cache, or predictor state.
3. Reachable code contains a transient gadget such as delayed bounds or type resolution with an attacker-controlled alternate layout.
4. The transient path can address useful data despite pointer cages, process isolation, MPK, VM boundaries, or other memory controls.
5. The path can encode a secret-dependent difference in cache or other microarchitectural state.
6. The attacker can establish or probabilistically obtain the required cache state across repeated trials.
7. Amplification can raise the difference above scheduler, workload, and network noise.
8. A local or remote observer can measure the amplified difference.
9. Runtime lifecycle and resource accounting allow enough calibrated repetitions before termination, migration, or isolation.
10. Detection and response do not act before useful disclosure is possible.

Passive target mapping

Collect public or user-provided evidence for:

• Runtime and engine versions, pointer representation, sandbox design, process topology, tenant scheduling, and hardware families.
• Timer restrictions, shared memory and threading APIs, outbound sockets, WebSockets, subrequests, durable execution, keep-alive behavior, and per-invocation accounting.
• Cache topology and replacement behavior from vendor manuals or owned-host inspection.
• Process, VM, namespace, seccomp, pointer-cage, MPK, site-isolation, and heap-separation controls.
• Detection inputs, evaluation cadence, normalization formulas, action latency, and behavior for long-lived or I/O-heavy workloads.
• Patch history for the runtime, JIT, typed arrays, object layouts, bounds checks, speculative mitigations, and memory isolation.

Do not copy a Cloudflare-specific gadget to another engine and call it applicable. Translate it into constraints first. For example, replace "raw TypedArray backing-store pointer" with "a transiently reachable host-width pointer or equivalent address-bearing field," then verify whether the new runtime has one.

Strategy generation

Rank candidates by the number and quality of satisfied prerequisites, the likely disclosure boundary, and the cost of falsification. Prefer these passive checks:

• Source and patch review for type or bounds checks whose resolution can be delayed.
• Object-layout and pointer-representation review against current engine versions.
• Scheduler and lifecycle review for placement affinity and long-running executions.
• Detector review for end-of-invocation blind spots, attacker-influenced denominators, and missing I/O timing features.
• Defense review that distinguishes a blocked gadget from a blocked attack class.

For each candidate, state the cheapest safe falsifier. Examples include proving separate processes, showing no attacker-controlled outbound timing channel, confirming that a pointer cage removes the required address reach, or showing that in-flight detection isolates work before the minimum sampling budget.

Approved validation ladder

Only proceed after target authorization plus matching durable approvals identify the owned lab or target, permitted workload, external endpoints, maximum duration, data handling, and stop condition. Transient-execution exploit code is exactly the class that attacks co-tenancy: run it under microVM isolation (or dedicated hardware) per docs/lab-runtime-hardening.md, never in a default shared-kernel container, and confirm the validation host is not co-tenanted with unrelated workloads.

1. Reproduce architecture and cache assumptions on one owned process with synthetic public data.
2. Establish a local signal with no isolation boundary crossed.
3. Add the target's timer restrictions and noise without reading a secret.
4. Test isolation using a fixed non-sensitive marker in two owned tenants. If anything other than the marker is recovered or the marker leaks where it should not, halt immediately, preserve the Evidence, and report to the user.
5. Stop after the minimum evidence proves or refutes the boundary.

Never aim at unrelated tenants, recover real credentials, or use production secrets. Do not optimize leakage rate after the proof bar is met. Reset or recreate target state between runs and trials — cache, branch-predictor, and workload state is mutable, and reusing contaminated state across runs invalidates the result. Save calibration data, negative controls, runtime and hardware identity, timestamps, resource use, and detector outcomes as Evidence, registered through the Evidence Interface (src/server/evidence/artifact-service.ts).

Mandatory teardown

Transient targets are destroyed at the stop condition, not left running:

1. Destroy the transient target (container, VM, or rented host) as soon as the ladder ends, pauses, or is abandoned.
2. Independently verify removal — the process, container, or host no longer exists — rather than trusting the destroy command's exit code.
3. Record the verified teardown as Evidence alongside lifecycle events: lab start attestation, containment events, egress policy fingerprint, and stop/destroy confirmations.
4. If teardown fails, recover within a bounded window, escalate to the user, and never leave an owned paid host idle or unregistered.

Defensive conclusions

Map each confirmed prerequisite to one or more controls:

• Remove address-bearing fields from untrusted heaps or confine them with a memory sandbox.
• Add process, VM, or hardware memory domains between tenants.
• Restrict high-resolution local clocks, shared-memory clocks, and stable remote timing patterns.
• Break placement affinity and periodically move suspicious workloads.
• Evaluate detection during long-lived execution, not only when an invocation ends.
• Preserve raw hardware counters alongside ratios. Do not let attacker-controlled I/O dilute the denominator.
• Detect repeated timer-like I/O around compute-heavy sampling bursts.
• Rotate processes and memory layouts to cap the useful sampling window.

Treat every control as reducing one or more prerequisites. Avoid claiming that one mitigation eliminates Spectre as a class unless the target's full chain has been ruled out.

Output

Return:

• A prerequisite matrix with Evidence, confidence, gaps, and falsifiers.
• A graph update proposal using requires, uses, amplified-by, observed-through, constrained-by, blocked-by, and may-evade relationships.
• Ranked Hypotheses with a passive first step and a stop condition.
• Defensive recommendations tied to the exact prerequisite they break.
• A separate durable approval request — or finalized Validation Plan — for any active validation, covering the provisioning commands and every ladder step.

Background sources

• Cloudflare, A revisit of remote Spectre attacks on Cloudflare Workers, August 19, 2026.
• Kocher et al., Spectre Attacks: Exploiting Speculative Execution.
• Schwarzl et al., Dynamic Process Isolation.
• Cloudflare, Workers security model.

The Cloudflare post describes research performed in 2024 and early 2025 against Workers controlled by the researchers. Cloudflare reports that it mitigated the demonstrated chain with improved detection, the V8 memory sandbox, and MPK-based in-process isolation. Re-check current target versions and architecture before using any claim.