CVE-2023-33040: Qualcomm Snapdragon · Buffer Over-read
Affects Qualcomm SnapdragonSource CVE Database V5
Not known to be exploited · CVSS 7.5 High.
Data as of 25 Oct 2026, 19:02 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 27% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 2 Jan 2024
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 2026-10-25.
What to do
AI-suggested
Mitigation should focus on timely identification and patching of affected devices once Qualcomm or device manufacturers release firmware or software updates addressing CVE-2023-33040. Organizations should: 1) Inventory all devices and equipment using affected Snapdragon chipsets, including mobile devices, IoT endpoints, automotive systems, and wireless infrastructure. 2) Monitor vendor advisories and Qualcomm security bulletins for patches or firmware updates and apply them promptly. 3) Implement network-level protections such as rate limiting and anomaly detection on DTLS traffic to detect and mitigate potential exploitation attempts. 4) Use network segmentation to isolate critical systems and reduce exposure to untrusted networks. 5) Employ redundancy and failover mechanisms for critical connectivity to minimize impact of transient DoS conditions. 6) Engage with device vendors to confirm patch availability and deployment timelines. 7) For managed IoT or automotive fleets, coordinate with OEMs and service providers to ensure updates are applied. 8) Consider disabling or restricting DTLS usage in non-critical systems if feasible until patches are applied. These steps go beyond generic advice by emphasizing proactive inventory, vendor coordination, network traffic controls specific to DTLS, and architectural resilience.
Description
Transient DOS in Data Modem during DTLS handshake.