CVE-2026-11835 Overview
CVE-2026-11835 is a Time-of-Check Time-of-Use (TOCTOU) vulnerability combined with missing input validation in the Caliptra Core ROM. The flaw resides in the UpdateResetFlow::run() function when the root-of-trust operates in subsystem mode. A compromised local attacker can supply an AXI staging address that the ROM does not validate against the strap-configured SS_EXTERNAL_STAGING_AREA_BASE_ADDR. This gap allows firmware to be modified between verification and loading into the Instruction Closely Coupled Memory (ICCM), silently bypassing secure boot. Attestation continues to report the originally verified image digest, masking the compromise from remote verifiers. The issue affects Caliptra Core ROM versions 2.1.0 through 2.1.1.
Critical Impact
Attackers with compromised MCU firmware and AXI manager access can substitute unverified firmware into ICCM while attestation reports the trusted digest, defeating the root-of-trust guarantee.
Affected Products
- Caliptra Core ROM 2.1.0
- Caliptra Core ROM 2.1.1
- Caliptra subsystem-mode deployments using external AXI staging areas
Discovery Timeline
- 2026-08-04 - CVE-2026-11835 published to the National Vulnerability Database
- 2026-08-04 - Last updated in NVD database
Technical Details for CVE-2026-11835
Vulnerability Analysis
Caliptra is an open silicon root-of-trust that performs measured and attested boot for confidential computing platforms. In subsystem mode, the ROM coordinates firmware updates with a Manageability Control Unit (MCU) using an external staging area referenced by an AXI address. The UpdateResetFlow::run() routine reads a firmware image from an attacker-supplied AXI staging address, computes and verifies its digest, then loads the code into ICCM for execution.
The vulnerability arises because the staging address is not checked against the strap-provisioned SS_EXTERNAL_STAGING_AREA_BASE_ADDR. A caller with AXI manager access can point the flow at SRAM the MCU can still mutate. The TOCTOU window between hash verification and the copy into ICCM allows the memory contents to be swapped. The classification aligns with Improper Input Validation [CWE-20].
Root Cause
The ROM trusts a caller-supplied AXI address without enforcing the platform strap boundary. Because the staging buffer is not required to reside in memory Caliptra exclusively controls, the verified bytes and the loaded bytes are not guaranteed to be identical. Attestation records the digest computed during verification, not the bytes actually executed, hiding the substitution.
Attack Vector
Exploitation requires local privilege: the attacker must already control the MCU firmware and hold AXI manager access to SRAM reachable by Caliptra. During an update-reset flow, the attacker directs Caliptra to a staging address in mutable SRAM, allows the ROM to verify a legitimate image, then rewrites the buffer before ICCM load completes. The resulting device boots unverified firmware while producing attestations that reference the trusted image. See the Caliptra GitHub Security Advisory GHSA-49mm-5gq5-v97f for the maintainer analysis.
Detection Methods for CVE-2026-11835
Indicators of Compromise
- Update-reset flows referencing AXI staging addresses that fall outside the range defined by SS_EXTERNAL_STAGING_AREA_BASE_ADDR.
- MCU firmware writes to staging SRAM occurring after Caliptra has begun the verification step of UpdateResetFlow::run().
- Divergence between the firmware digest reported in attestation quotes and hashes measured out-of-band on the running ICCM image.
Detection Strategies
- Instrument the MCU or platform fabric to log every AXI transaction targeting the staging region during update-reset and flag addresses outside the configured base.
- Compare Caliptra attestation reports against a golden manifest of approved firmware digests and investigate any mismatch with observed behavior.
- Audit SRAM access rights so only Caliptra can write to the staging region during the verification-to-load window.
Monitoring Recommendations
- Collect Caliptra ROM boot logs and correlate them with MCU update events in a central telemetry pipeline.
- Alert on repeated update-reset invocations with unexpected staging addresses, which may indicate exploitation attempts.
- Track ROM version inventory to identify devices still running Core ROM 2.1.0 or 2.1.1.
How to Mitigate CVE-2026-11835
Immediate Actions Required
- Inventory silicon and firmware using Caliptra Core ROM 2.1.0 or 2.1.1 and prioritize remediation for subsystem-mode deployments.
- Treat MCU firmware compromise as a prerequisite that must be independently prevented; harden MCU update and signing pipelines.
- Constrain SRAM regions reachable by Caliptra so only memory controlled exclusively by the root-of-trust is used for staging.
Patch Information
Refer to the Caliptra GitHub Security Advisory GHSA-49mm-5gq5-v97f for the fixed Core ROM release and integration guidance. Vendors integrating Caliptra should rebuild ROM images with the patched UpdateResetFlow::run() logic that validates the AXI staging address against SS_EXTERNAL_STAGING_AREA_BASE_ADDR before use.
Workarounds
- Configure platform straps and AXI access control so the staging area is physically unwritable by the MCU during Caliptra verification and load.
- Disable or gate update-reset flows in production until patched ROM images are deployed.
- Require out-of-band attestation validation that compares runtime memory measurements with the attested digest to detect substitution.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
