Skip to main content
CVE-2024-53028VulnerabilityPublished Updated

CVE-2024-53028: Qualcomm Snapdragon · Time-of-check Time-of-use (TOCTOU) Race Condition

Affects Qualcomm SnapdragonSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High.

Data as of 25 Oct 2026, 19:02 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.08% chance of exploitation in 30 days – higher than 0% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 3 Mar 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 2026-10-25.

What to do

AI-suggested

1. Monitor Qualcomm’s official channels closely for patches and apply them promptly once released. 2. Restrict local access to devices with affected Snapdragon chipsets by enforcing strong device authentication and limiting physical and software-based access to trusted users and applications only. 3. Employ application whitelisting and sandboxing to prevent untrusted code execution that could trigger the race condition. 4. Implement runtime integrity monitoring and anomaly detection on devices to identify suspicious memory corruption or privilege escalation attempts. 5. For enterprise deployments, consider network segmentation to isolate vulnerable devices and reduce lateral movement risk. 6. Educate users and administrators about the risks of installing untrusted applications or connecting unknown peripherals that could facilitate local exploitation. 7. Use secure boot and trusted execution environments where available to limit the impact of memory corruption. 8. Regularly audit device firmware and software versions to ensure compliance with security policies.

Description

Memory corruption may occur while processing message from frontend during allocation.

References

Community reviews

Loading reviews…