CVE-2025-53022: TrustedFirmware-M · Stack-based Buffer Overflow
Source CVE Database V5
Not known to be exploited · CVSS 8.6 High · fixed in 2.1.3 : patch affected systems soon.
Data as of 26 Oct 2026, 10:12 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 40% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.1.3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:LExploitation evidence
Disclosed: evidence found.
CVE published 30 Jul 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
Organizations should immediately verify the versions of TrustedFirmware-M deployed in their embedded devices and ensure they are updated to at least version 2.1.3 or 2.2.1, where this vulnerability is fixed. Firmware upgrade processes should be hardened by implementing strict validation of TLV length fields before processing. Additionally, employing secure boot mechanisms that verify firmware signatures and integrity prior to upgrade can prevent unauthorized or malformed images from being accepted. Device manufacturers should provide updated firmware images and patches, and organizations must establish secure firmware update channels with cryptographic protections. For devices already deployed, network segmentation and monitoring of firmware upgrade traffic can help detect and block malicious upgrade attempts. Where possible, runtime protections such as stack canaries and control flow integrity should be enabled to mitigate exploitation impact. Finally, organizations should conduct thorough security testing of firmware upgrade components to identify and remediate similar vulnerabilities proactively.
Description
TrustedFirmware-M (aka Trusted Firmware for M profile Arm CPUs) before 2.1.3 and 2.2.x before 2.2.1 lacks length validation during a firmware upgrade. While processing a new image, the Firmware Upgrade (FWU) module does not validate the length field of the Type-Length-Value (TLV) structure for dependent components against the maximum allowed size. If the length specified in the TLV exceeds the size of the buffer allocated on the stack, the FWU module will overwrite the buffer (and potentially other stack data) with the TLV's value content. An attacker could exploit this by crafting a malicious TLV entry in the unprotected section of the MCUBoot upgrade image. By setting the length field to exceed the expected structure size, the attacker can manipulate the stack memory of the system during the upgrade process.
References
- trustedfirmware.org/projects/tf-m/ (opens in a new tab)
- git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/+/refs/heads/main/secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c (opens in a new tab)
- trustedfirmware-m.readthedocs.io/en/latest/security/security_advisories/fwu_tlv_payload_out_of_bounds_vulnerability.html (opens in a new tab)