Extractable firmware files

1. Summary

CVE-2025-23421 is an information-disclosure flaw in the Qardio Heart Health companion application (iOS 2.7.4, Android 2.5.1) for the QardioARM A100 blood pressure monitor, classified as CWE-552 (Files or Directories Accessible to External Parties) [1]. The device firmware files — or the artifacts needed to reconstruct them — are accessible to a party who should not have them, and the researcher’s writeup points to a “static bin file” retrievable from the mobile application [3]. An attacker who obtains these files can reverse-engineer the firmware’s intended operation, resulting in loss of confidentiality and integrity of the hardware devices enabled by the Qardio apps [1]. No vendor fix exists, as Qardio did not respond to CISA’s coordination attempts [2].

2. Affected products & versions

3. The vulnerability in detail

The flaw lives at the boundary between the Qardio Heart Health mobile companion application and the QardioARM A100 blood pressure monitor it controls. The QardioARM A100 is a Bluetooth Low Energy (BLE) blood pressure cuff driven by an on-device microcontroller; the researcher describes it only as “a small microcontroller” and does not identify its part number (unverified - not in available sources) [3]. Like most consumer IoMT devices of this class, its behavior is governed by device firmware, and that firmware — or the material needed to reconstruct it — is reachable by an external party who is not supposed to have it. NVD and CISA classify the defect as CWE-552, Files or Directories Accessible to External Parties [1][2]: a design or packaging decision leaves sensitive files in a place where an unauthorized party can read them.

The root cause, stated at the level the sources actually support, is that the device firmware files are exposed rather than protected. The independent researcher who reverse-engineered the device (n0ps) references “analyzing the static bin file from the mobile application,” which strongly implies the firmware image ships inside — or is otherwise retrievable from — the mobile app artifact itself [3]. This is the most concrete signal available about the mechanism, but it is important to be precise about what is and is not established: no source specifies the exact defect. It is not documented whether the firmware is a plaintext .bin embedded in the app bundle, an image pulled over some update flow, or a file left at a world-readable path (unverified - not in available sources). What the sources agree on is the outcome — the firmware is obtainable and then reverse-engineerable — not the precise packaging fault that makes it so.

It is worth being concrete about why “files accessible to an external party” is the correct frame here, and what the trust boundary actually is. In a properly designed connected-device product, the device firmware is an asset the vendor controls: it lives on the device, and if it is distributed at all (for updates), it is distributed through an authenticated, integrity-protected channel so that only the device — not an arbitrary third party — can meaningfully obtain or use it. CWE-552 describes the failure of exactly that containment: files that should stay inside the trust boundary end up readable by someone outside it. The single concrete data point the sources provide is that the researcher analyzed a “static bin file from the mobile application” [3] — i.e., the operative artifact was found in association with the client app, not extracted from the physical device’s flash. That is what makes the disclosure practical: the app is freely distributed to any user who downloads it, so anything shipped inside the app artifact inherits the app’s (very wide) distribution. The reader should hold onto that distinction: the sourced fact is an app-side static binary, and the physical device’s own flash is a separate surface the researcher had not yet dumped at publication time.

The mechanism of exposure, as described by CISA and NVD, is that “an attacker could obtain the firmware files and reverse engineer their intended use, leading to loss of confidentiality and integrity of the hardware devices enabled by the Qardio iOS and Android applications” [1]. The CVSS vectors frame the trigger conditions: attack vector Physical (AV:P), attack complexity Low (AC:L), no privileges required (PR:N), and no user interaction (UI:N), with High confidentiality and High integrity impact and Low availability impact [1]. The Physical designation is notable and slightly at odds with the practical description — the requirement is “Bluetooth or physical proximity,” i.e., the attacker must be within range of the device, and it cannot be exploited remotely [4]. If the operative artifact is genuinely a static binary inside the mobile app, the firmware-extraction step arguably needs only a copy of the app rather than the physical device; the AV:P scoring likely reflects the broader device-tampering framing of the advisory rather than a strict requirement for the disclosure path itself. The sources do not fully reconcile this tension (unverified - not in available sources).

The exploitation chain, grounded in the findings, proceeds as follows [1][3][4]. Note that no source documents the actual firmware-extraction procedure, so the chain describes the outcome the sources establish, not a verified step-by-step method:

1. The attacker obtains the operative artifact. The only concrete source signal is a “static bin file from the mobile application” [3], which points to a copy of the Qardio Heart Health mobile app (iOS 2.7.4 / Android 2.5.1) as the source of the firmware image. The CVSS vector nonetheless scores the attack vector as Physical (AV:P) [1], and the requirement is described as “Bluetooth or physical proximity” [4]; this app-artifact-vs-proximity tension is unresolved by the sources and is discussed above.
2. The attacker locates and extracts the device firmware files. The researcher’s reference to a “static bin file from the mobile application” implies the firmware image is retrievable from the app artifact, but the exact extraction procedure is not published (unverified - not in available sources) [3].
3. The attacker reverse-engineers the extracted firmware to understand its internal logic and intended use. Once the firmware image is in hand, reverse engineering is a well-understood workflow (disassembly, string/symbol recovery, control-flow analysis); how tractable it is depends on the target architecture, which the sources do not identify for this device (unverified - not in available sources) [3].
4. The result is loss of confidentiality and integrity of the hardware devices [1]. The researcher separately notes an intent to later dump the device’s on-device microcontroller firmware for interested parties and flash extracted firmware onto an ESP32-C3 development board for analysis in future work — explicitly deferring that work; the ESP32-C3 here is the researcher’s analysis dev board, not the QardioARM A100’s own MCU (which the source leaves unspecified) [3].

A working PoC does exist for a related but different vulnerability in the same advisory — CVE-2025-24836, a BLE denial-of-service in which a Bleak Python script floods the device with continuous startMeasurement commands — but that is a distinct CWE-248 flaw and should not be conflated with the firmware-disclosure issue here [2][3].

The underlying weakness (CWE-552). CWE-552 describes a situation where files or directories that should be restricted are instead reachable by parties outside the intended trust boundary. It is not a memory-safety or injection bug; it is an exposure-of-resources problem. Here, the “resource” is the device firmware, and the “external party” is anyone who can obtain the mobile app or come into proximity of the device. Because firmware encodes how the hardware actually behaves, exposing it collapses the practical barrier to reverse engineering — an attacker no longer has to physically decap a chip or guess at protocol behavior; they can read the intended logic directly and use that knowledge to undermine the confidentiality and integrity assumptions the device was built on. This is why NVD assigns High confidentiality and High integrity impact despite the “only” information-disclosure framing [1].

4. Discovery & timeline

The vulnerabilities were reported to CISA by Bryan Riggins of Insulet Corporation [2][4]. CISA published ICS-Medical advisory ICSMA-25-044-01 on February 13, 2025, as part of a batch of twenty ICS advisories released that day [2][5]. The advisory grouped three CVEs affecting the Qardio ecosystem: CVE-2025-20615 (credentials in a plist enabling an engineering backdoor, CWE-359), CVE-2025-23421 (the firmware-files exposure covered here), and CVE-2025-24836 (BLE startMeasurement flooding DoS, CWE-248) [2]. The independent researcher writeup, “Reversing the QardioArm” by n0ps, was published the same day, February 13, 2025 [3]. Any coordinated-disclosure or coordination dates prior to that publication are not documented in the available sources (unverified - not in available sources). Critically, the vendor response was non-existent: Qardio did not respond to CISA’s requests to collaborate on mitigation, and no patch had been released as of the advisory date [2][4].

5. Technical reference

• CVE: CVE-2025-23421 [1]
• Related CVEs (same advisory): CVE-2025-20615 (CWE-359), CVE-2025-24836 (CWE-248) [2]
• CWE: CWE-552 — Files or Directories Accessible to External Parties [1]
• CVSS v3.1: 6.4 (MEDIUM), vector AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L [1]
• CVSS v4.0: 6.9 (MEDIUM), vector AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N [1]
• What the key metrics mean here: AV:P (Physical) is the score-suppressing metric — it assumes the attacker needs proximity/physical access, which holds the base out of the HIGH band despite C:H/I:H. PR:N/UI:N mean no credentials and no victim interaction are needed once in range. A:L/VA:L reflect that this is primarily a disclosure-and-integrity issue, not an availability one. The High confidentiality and integrity impacts capture that reading firmware both leaks proprietary logic and enables tampering with device behavior [1].
• Code/commit refs: none — no patch or fix commit exists; the researcher’s firmware dump/PoC is deferred and not yet published [2][3].
• Hardware: the QardioARM A100’s own microcontroller is described by the researcher only as “a small microcontroller” and is not identified by part number (unverified - not in available sources) [3]. The ESP32-C3 mentioned in the researcher’s writeup is a development board the researcher plans to flash extracted firmware onto for analysis in future work — it is the analysis target, not the device’s MCU [3]. (Related-CVE context: BLE characteristic UUID 583CB5B3-875D-40ED-9098-C39EB0C1983D transmits device commands [3].)

6. Consequence & CFSE path analysis

Real-world consequence: An attacker who acquires the Qardio companion app — their own freely-downloaded copy, with no victim device required — can, per the researcher’s “static bin file from the mobile application” signal [3], obtain the QardioARM A100 firmware and reverse-engineer it. What is exposed is proprietary device logic and operational control data for the hardware, and the extraction gives an attacker the blueprint needed to understand and potentially subvert how the device operates. Because a single-SKU consumer device of this kind typically ships one firmware image across all units, knowledge derived from one exposed image plausibly generalizes to every device in the field — though the sources do not explicitly confirm fleet-wide image sharing (unverified - not in available sources).

Why the CFSE Path Score differs from CVSS. The published CVSS baselines land in the MEDIUM band (v4.0 6.9, v3.1 6.4), driven down primarily by the AV:P Physical attack-vector assumption. The CFSE path analysis instead models a single risk path terminating in DATA_PRIVACY, and treats the exposure realistically: the only concrete source signal is that the firmware is a “static bin file from the mobile application” [3], i.e., an attacker-owned artifact obtainable through the attacker’s own copy of the companion app, so no victim device is actually required to begin. That reframing is why the path scores UNDER the CVSS direction — CVSS’s proximity penalty overstates the practical barrier if the firmware is genuinely obtainable from the app artifact alone. This rationale rests on the “static bin file from the mobile application” signal only; it does not assume any over-the-air (OTA) update path, which is explicitly unverified and in fact contradicted by that same signal (unverified - not in available sources).

CFSE consequence bands and verdict:

• Dominant path: terminates in DATA_PRIVACY, lands in the HIGH band.
• DP:3 — what is exposed is proprietary device logic and operational control data, not ordinary PII.
• AT:1 — authority is held low because extraction is read-only and only enables downstream reverse engineering; it yields no signing key and no fleet control.
• CH:2 — one app-to-firmware boundary crossing.
• SR:3 / SX:3 — broad reuse, on the plausible-but-unconfirmed assumption that the same firmware image is shared fleet-wide. This is the load-bearing soft spot of the verdict: the HIGH band materially depends on this reuse assumption, which the sources do not establish (unverified - not in available sources); if fleet-wide sharing did not hold, the reuse bands and thus the band placement would need to be revisited.
• OR:1 — low recovery burden.
• Banding: base HIGH band kept as final, with no cap or systemic uplift.
• Verdict: path_verdict = HIGH, direction UNDER relative to the published MEDIUM CVSS baselines (v4.0 6.9, v3.1 6.4).

Verdict: HIGH.

Grounding caveats carried from the findings: (a) the SR:3/SX:3 “same firmware image shared fleet-wide” reasoning is plausible and typical for a single-SKU consumer device, but is not explicitly stated in the sources and is the single assumption the HIGH band leans on hardest (unverified - not in available sources); (b) whether the exposed firmware contains signing keys or enables fleet control (which would justify a higher AT) is not documented — the AT:1 hold is the conservative, source-consistent choice; (c) the “no victim device required” reframing depends on the firmware being obtainable from the app artifact, which is implied by the researcher’s phrasing but not proven, and does not rely on any OTA path (unverified - not in available sources).

7. Remediation & mitigations

There is no vendor patch. Qardio was non-responsive to CISA, and no fix had been released as of the February 13, 2025 advisory [2][4]. The only mitigations offered are user-side and defensive [2]:

• Disable Bluetooth when the device is not in use [2].
• Do not use the device in public or within Bluetooth range of potentially malicious actors [2].
• Only use trusted mobile apps from trusted providers [2].
• Contact Qardio customer support for additional information [2].

The engineering fix that follows directly from CWE-552 and from the only concrete source signal (a “static bin file from the mobile application” [3]) is to stop shipping the device firmware image inside the client app artifact, and/or to restrict access to any firmware files so they are not readable by an external party. Concretely, for this specific bug that means: (a) remove the firmware .bin from the distributed iOS IPA / Android APK bundle so that downloading the app no longer hands an attacker the image; (b) if the device genuinely needs firmware delivered to it, deliver it only over an authenticated, integrity-protected channel targeted at the device rather than embedding it in a freely-distributed client; and (c) where a firmware image must exist on-device, apply secure-boot / signature verification on the device’s microcontroller so that a leaked image cannot be trivially re-flashed or repurposed (the device MCU is not identified in the sources, so the concrete secure-boot mechanism cannot be named here — this is the generic on-device hardening step) (unverified - not in available sources). None of these fixes is stated or committed to in any available source — they are the logical remediations implied by the CWE-552 classification, not vendor commitments (unverified - not in available sources). Because the exact packaging defect is undocumented, and because whether any OTA/update delivery exists at all is unconfirmed, the precise fix cannot be pinned down further from the sources (unverified - not in available sources). Since there is no patch, no fix-version-based detection is possible; the practical detection posture is limited to the proximity/usage hygiene above, plus (for a defender who controls a build) inspecting the shipped app bundle for an embedded firmware binary.

8. Sources

1. NVD — CVE-2025-23421 — NVD (NIST) — https://nvd.nist.gov/vuln/detail/CVE-2025-23421 — Canonical CVE record: description, CWE-552, both CVSS vectors/scores, affected app versions. Credibility: primary advisory.
2. ICSMA-25-044-01: Qardio Heart Health iOS and Android Application and QardioARM A100 — CISA (ICS-Medical) — https://www.cisa.gov/news-events/ics-medical-advisories/icsma-25-044-01 — Authoritative advisory grouping all three CVEs, affected products (A100 all versions), researcher credit, and vendor non-response. Credibility: primary advisory.
3. Reversing the QardioArm — n0ps (independent researcher blog) — https://n0psn0ps.github.io/2025/02/13/Reversing-the-QardioArm/ — Original technical writeup: “static bin file from the mobile application,” device described as having “a small microcontroller” (part number unspecified), plan to flash extracted firmware onto an ESP32-C3 dev board and possibly dump the device microcontroller firmware later, BLE UUID context. Credibility: researcher-primary.
4. Zero-Day Flaws Found in Qardio Heart Health iOS & Android Apps — CyberInsider — https://cyberinsider.com/zero-day-flaws-found-in-qardio-heart-health-ios-and-android-apps/ — Press summary confirming unauthorized firmware file access, physical/Bluetooth proximity requirement, attribution, and vendor non-response. Credibility: reputable press.
5. CISA Releases Twenty Industrial Control Systems Advisories (Feb 13, 2025) — CISA — https://www.cisa.gov/news-events/alerts/2025/02/13/cisa-releases-twenty-industrial-control-systems-advisories — Confirms the release date and batch context for ICSMA-25-044-01. Credibility: primary advisory.
6. High-Severity Qardio App Vulnerability CVE-2025-24836 Risks Health Data — IntegSec — https://integsec.com/blog/high-severity-qardio-app-vulnerability-cve-2025-24836-puts-personal-health-data-at-risk — Companion analysis of the related Qardio CVEs; useful for cross-referencing the shared attack surface. Credibility: reputable press.