Skip to main content
CVE-2024-35419VulnerabilityPublished Updated

CVE-2024-35419: n/a

Source CVE Database V5

0

Not known to be exploited · CVSS 5.5 Medium.

Data as of 26 Oct 2026, 06:26 UTC

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

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 8 Nov 2024

  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-26.

What to do

AI-suggested

1. Restrict and validate all WebAssembly files before loading, ensuring only trusted sources are allowed to execute wasm modules. 2. Implement runtime memory safety checks and bounds checking in the wasm loading and execution environment to detect and prevent heap overflows. 3. Employ sandboxing and process isolation techniques to contain potential crashes and limit the impact of DoS conditions. 4. Monitor application logs and system behavior for abnormal crashes or load_module failures indicative of exploitation attempts. 5. Apply any future patches or updates from the wac component maintainers promptly once available. 6. Consider using WebAssembly runtime environments with built-in security hardening and fuzz testing to identify similar vulnerabilities proactively. 7. Educate developers and system administrators about the risks of loading untrusted wasm files and enforce strict code review and deployment policies. 8. If possible, disable or limit wasm module loading functionality in environments where it is not essential. These steps go beyond generic advice by focusing on controlling wasm input sources, enhancing runtime safety, and operational monitoring specific to this vulnerability.

Description

wac commit 385e1 was discovered to contain a heap overflow via the load_module function at /wac-asan/wa.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted wasm file.

References

Community reviews

Loading reviews…