Skip to main content
CVE-2025-51824VulnerabilityPublished

CVE-2025-51824: n/a

Source CVE Database V5

0

Not known to be exploited · CVSS 6.5 Medium.

Data as of 25 Oct 2026, 19:02 UTC

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

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 11 Aug 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

Given the lack of available patches, European organizations should implement several specific mitigations: 1) Conduct an inventory to identify all embedded systems and devices using libcsp 2.0, particularly those running Zephyr OS or similar environments. 2) Isolate vulnerable devices from untrusted networks by implementing network segmentation and strict access controls to limit exposure to potential attackers. 3) Employ intrusion detection and anomaly monitoring focused on USART communication channels to detect unusual activity that may indicate exploitation attempts. 4) Collaborate with device vendors and open-source communities to track the release of patches or updated libcsp versions addressing this vulnerability and prioritize timely deployment once available. 5) Where feasible, apply firmware updates or configuration changes to disable or restrict the use of the vulnerable csp_usart_open() function or related services until a patch is released. 6) Implement strict input validation and sanitization at the application layer interfacing with libcsp to reduce the risk of malformed input triggering the buffer overflow. 7) Develop incident response plans tailored to embedded device compromise scenarios to quickly contain and remediate potential exploitation.

Description

libcsp 2.0 is vulnerable to Buffer Overflow in the csp_usart_open() function at drivers/usart/zephyr.c.

References

Community reviews

Loading reviews…