Skip to main content
VulnerabilityPublished

CVE-2025-53022: TrustedFirmware-M · Stack-based Buffer Overflow

Source CVE Database V5

0

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

CVSS 3.1 base score
8.6High
How severe the flaw is on the 0–10 CVSS scale.
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:L

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 30 Jul 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

Community reviews

Loading reviews…