Join our Newsletter — 33% off our NHI Course
Home› Glossary› Threats, Abuse & Incident Response› Branch Target Injection
Threats, Abuse & Incident Response

Branch Target Injection

← Back to Glossary
By NHI Mgmt Group Updated October 29, 2026 Domain: Threats, Abuse & Incident Response

Branch Target Injection is a speculative execution attack that manipulates a processor’s indirect branch predictor so the CPU speculatively runs attacker-influenced instructions. It can be used to read data through transient execution and cache effects, even though the mis-speculated work is later discarded.

What Branch Target Injection Is

Branch Target Injection is a speculative execution attack against the branch prediction machinery in modern CPUs. It does not change the architectural result of a program, but it can steer transient execution down an attacker-influenced path long enough to leak data through microarchitectural side effects.

The important distinction is that the processor may later discard the mis-speculated work, while the cache and predictor effects can remain observable. That makes the attack class relevant to confidential data handling even when the vulnerable code never appears to misbehave at the software level.

How the Attack Works

Indirect branches are harder for processors to predict than simple direct branches, so they rely on predictor state learned from prior execution. Branch Target Injection aims to poison that state, causing speculation to fetch and execute instructions from an attacker-chosen target or an attacker-shaped gadget sequence.

During the speculative window, the CPU may perform loads and other operations that touch secret-dependent memory. Those transient effects can then be measured indirectly, often through cache timing, even though the wrong-path instructions never commit architecturally.

Why It Matters for System Security

This matters because speculative execution weaknesses can cross trust boundaries that software authors assume are already enforced. A process, VM, browser tab, or sandbox may appear isolated at the architectural level while still exposing information through shared microarchitectural state.

Branch Target Injection is especially concerning in multi-tenant or shared-hardware environments, where an attacker can influence predictor state and then observe whether transient execution reveals something useful. The real danger is not the incorrect branch itself, but the side channel left behind by the CPU’s optimisation.

For background on the broader security context that this class sits within, see the OWASP Top 10, which is a baseline reference for understanding how software weaknesses can expose sensitive data.

Defence, Detection, and Exposure Review

Organisations reduce exposure by identifying where untrusted code, sensitive workloads, and shared processors overlap. Exposure review usually starts with asset inventory, hypervisor and cloud tenancy mapping, and vendor guidance for the exact CPU family and platform in use.

Mitigations typically rely on a combination of microcode updates, compiler or runtime hardening, and workload segregation. When patching or platform updates are not yet possible, compensating controls such as reducing co-residency, tightening sandbox boundaries, and limiting where sensitive secrets are processed can materially lower risk.

Detection is harder than with conventional malware because the attack often looks like normal execution from the software stack’s point of view. After a patch or configuration change, teams should still review for signs of prior compromise, especially if sensitive data was exposed on affected hosts or if the environment supports untrusted execution.

Branch Target Injection can also be relevant to identity material when secrets, session tokens, or key material are processed on vulnerable systems. If an attacker can read data transiently, the post-exploitation response may need to include credential rotation and session invalidation, not just software remediation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
MITRE ATT&CKT1182 — Address Space Layout Randomization BypassBranch Target Injection is a speculative-execution technique used to bypass memory isolation assumptions.
Recommendation — Map speculative-execution activity to T1182 and hunt for transient data exposure paths.
NIST SP 800-53 Rev 5SI-14 — Non-PersistenceTransient execution and shared-state exposure make limiting persistence and residual effects materially relevant.
Recommendation — Use SI-14 to reduce retained risk from transient execution and shared-resource exposure.
CIS Controls v8CIS-4 — Secure Configuration of Enterprise Assets and SoftwareCPU and platform hardening for speculative-execution mitigations depends on secure configuration management.
Recommendation — Apply CIS-4 to harden affected platforms and keep speculative-execution mitigations enabled.
NIST CSF 2.0PR.DS-01 — Data-at-rest is protectedThe attack class can expose sensitive data even when it is not architecturally committed.
Recommendation — Use PR.DS-01 to protect sensitive data that could be exposed through transient execution.

Practitioner Guidance

Why practitioners should care: This is a hardware-assisted data exposure problem, not just a performance issue. Treat it as a workload isolation and secrets-handling concern whenever untrusted and sensitive execution share the same physical platform.

What to watch for: Pay attention to mixed-trust deployments, dense virtualisation, and browser or sandbox contexts that share CPU resources. Those environments make speculative side channels more operationally meaningful than they would be on a dedicated single-purpose host.

Practitioner takeaway: The safest response is to pair platform-level mitigation with workload separation, because software-only assumptions do not fully contain a microarchitectural leak.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org