control-flow hijack

Definition

A control-flow hijack is a security violation in which the control flow of a program, agent, or processor is redirected to a target chosen by an attacker instead of one intended by the legitimate software, instruction set, or orchestration policy. The hijack causes execution to deviate from architecturally valid or policy-valid control flow, and it is one of the canonical primitives of binary and systems security alongside information leakage.

The term is used in three closely related contexts documented in the literature:

1. Multi-agent LLM systems – manipulating inter-agent orchestration so that agents perform unsafe or off-policy actions.
2. Software (binary exploitation) – redirecting execution through memory corruption or transient execution effects (e.g., speculative control-flow hijacks).
3. Hardware (microarchitecture) – CPU bugs that allow operand values to influence the architectural program counter (PC), including division-by-zero traps and unacknowledged memory bus cycles.

Control-flow hijack in multi-agent LLM systems

In LLM-driven multi-agent systems, a control-flow hijack manipulates the orchestration mechanism so that agents are invoked outside the intended task graph. Recent defenses (e.g., LlamaFirewall) attempt to block such hijacks by checking that every inter-agent communication is "related to" and "likely to further" the original objective.

A 2025 study ("Breaking and Fixing Defenses Against Control-Flow Hijacking in Multi-Agent Systems," arXiv:2510.17276) demonstrates attacks that bypass these alignment checks even when enforced by advanced LLMs. The authors argue that the safety and functionality objectives of multi-agent systems fundamentally conflict, and that brittle definitions of "alignment" and incomplete visibility into the execution context allow hijacks to evade detection.

The same paper introduces ControlValve, a defense inspired by control-flow integrity (CFI) and least-privilege principles. ControlValve:

• generates permitted control-flow graphs for the multi-agent system, and
• enforces that every execution complies with the graph, augmented with zero-shot contextual rules per agent invocation.

Control-flow hijack in software and transient execution

Traditional binary-exploitation defenses against control-flow hijack include stack canaries, software control-flow integrity (CFI), and memory-safe languages. A 2020 study ("Bypassing memory safety mechanisms through speculative control flow hijacks," arXiv:2003.05503) showed that these defenses can be bypassed through speculative execution:

• stack protectors, software CFI, and Go bounds checks can be evaded by speculative control-flow hijacks that speculatively or architecturally overwrite control-flow data;
• speculative execution can be steered to a gadget that accesses a secret and transmits it through a side channel;
• multiple gadgets can be stitched together into a speculative return-oriented programming (ROP) attack, demonstrated for the first time in that work;
• software mitigations are possible with moderate performance impact.

Control-flow hijack in microarchitecture

Hardware-level control-flow hijack arises when attacker-controlled data is allowed to reach the architectural program counter along a path not explicitly permitted by the instruction set. The 2024 paper "μCFI: Formal Verification of Microarchitectural Control-flow Integrity" (Ceesay-Seitz, Solt, Razavi; CCS '24) formalizes this as a violation of Microarchitectural Control-Flow Integrity (μCFI):

Microarchitectural control-flow integrity (μCFI) enforces that the microarchitectural control flow is only influenced by instructions for which the ISA explicitly allows a control or data path from their operands to the program counter. A hardware implementation that satisfies μCFI guarantees that attacker-controlled data never manipulates the CF via paths that the ISA does not explicitly allow.

Four information-flow categories are relevant:

Instructions are classified as:

• non-influencing (ni) – the ISA does not specify operand-dependent CF (e.g., arithmetic, logic);
• control-influencing (ci) – operands may select among fixed PC targets (e.g., branches);
• value-influencing (vi) – the ISA explicitly allows operands to set the PC (e.g., jalr); only vi-instructions legitimately transfer operand data to the PC without violating μCFI.

The μCFI study verified four RISC-V CPUs and discovered several control-flow hijack vulnerabilities, including:

• Kronos (CVE-2024-44927) – when integrated with a memory that does not always acknowledge requests in the next cycle, jalr/branch instructions can read from the previous instruction's input register, which an attacker can drive with controlled data to hijack the CF.
• Kronos (CVE-2023-51973) – a data operand of addi, slti, or sltiu can be copied into mtvec (machine trap-vector base address), allowing a user-mode attacker to influence the architectural CF taken in machine mode.

These cases illustrate the broader principle: if attacker-controlled data participates in any path from an instruction's operands to the PC that the ISA does not explicitly sanction, the architectural CF can be hijacked.

Relations to adjacent concepts

• Architectural vs. microarchitectural CFI – architectural CFI ensures the architectural CF of the program is not manipulated outside valid control flows; μCFI extends the guarantee to microarchitectural paths that should not influence the PC.
• Constant-time (CT) programming – when operand-dependent timing or invalid CF depends on secret data, the result is information leakage; when it depends on attacker data, the result is control-flow hijack or delay injection.
• Speculative execution – the same control-flow-data dependency that drives classical ROP can be exercised speculatively, producing a speculative control-flow hijack and a side-channel send.

See also

• Microarchitectural Control-Flow Integrity (μCFI)
• ControlValve
• Constant-time programming
• Speculative return-oriented programming
• LlamaFirewall