dbcve.org
Stack-based Buffer OverflowWeakness · CWE-121

CVE-2025-53022

HIGH · 8.6 CVSS v3.1 Published 2025-07-30
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
95/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
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.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

TrustedFirmware-M before 2.1.3 and 2.2.x before 2.2.1 contains a buffer overflow vulnerability in the Firmware Upgrade (FWU) module. The module fails to validate the length field of TLV (Type-Length-Value) structures against maximum allowed sizes when processing upgrade images. When the TLV length exceeds the stack-allocated buffer size, the FWU module overwrites stack memory with attacker-controlled TLV value content, enabling potential arbitrary code execution.

MitigationUpgrade TrustedFirmware-M to version 2.1.3, 2.2.1, or later. Until patches are applied, ensure firmware upgrade images are obtained from trusted sources and verify image authenticity using cryptographic signatures.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
Low
Availability
Low

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify TrustedFirmware-M usage
    Inspect the firmware or bootloader binary for TF-M version strings, or check the build configuration files (such as platform and secure boot configurations) for TrustedFirmware-M references. TF-M is commonly used in ARM Cortex-M based secure systems.
    Affected if The device uses TrustedFirmware-M as its secure firmware component.
  2. Determine the installed TF-M version
    Extract version information from the firmware image, bootloader, or build artifacts. Look for version strings in the format 'TrustedFirmware-M vX.Y.Z' or check the tfm_version field in the TF-M metadata/header if present.
    Affected if The identified version is before 2.1.3, or is in the 2.2.x range before 2.2.1.
  3. Verify the FWU module is enabled
    Check the TF-M build configuration for the presence of the CONFIG_TFM_FWU_SERIAL or CONFIG_TFM_FWU_ENABLE option, or examine the compiled firmware image for FWU-related symbols (such as 'fwu_process_image' or similar). The FWU module is optional and must be explicitly built.
    Affected if The Firmware Upgrade module is compiled into the firmware.
  4. Confirm TLV processing is reachable
    Review the boot and upgrade flow configuration to verify that the FWU module can be invoked during runtime, either via serial interface, USB, or other upgrade mechanisms. Check that image validation paths include TLV parsing.
    Affected if The device supports firmware upgrade functionality and the FWU module is active in the boot flow.

The environment is affected if TrustedFirmware-M versions before 2.1.3 or 2.2.x before 2.2.1 are in use AND the optional Firmware Upgrade (FWU) module is enabled in the build.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade TrustedFirmware-M to version 2.1.3, 2.2.1, or later. Until patches are applied, ensure firmware upgrade images are obtained from trusted sources and verify image authenticity using cryptographic signatures.

Recommended fix High confidence

Upgrade to TrustedFirmware-M 2.1.3 (LTS) or 2.2.1

  1. Identify the current version of TrustedFirmware-M being used in your deployment
  2. Download TrustedFirmware-M version 2.1.3 (for the 2.1.x branch) or version 2.2.1 (for the 2.2.x branch) from the official TrustedFirmware-M repository at git.trustedfirmware.org
  3. Rebuild the TrustedFirmware-M firmware image with the fixed version, ensuring all build configurations remain consistent with your existing setup
  4. Verify the built image passes integrity checks and matches expected cryptographic signatures
  5. Deploy the updated firmware image to affected devices following your standard firmware update procedure
  6. After deployment, confirm the firmware upgrade completes successfully and the system boots to the new TrustedFirmware-M version
Caveat Firmware upgrades carry inherent risk; ensure rollback capability is available and test in controlled environment before mass deployment

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation8.0 h
  • Implementation16.0 h
  • Testing16.0 h
  • Review / QA8.0 h
48.0 hours of engineering $8,320
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $13,312.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2025-53022 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2025-53022 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data