What is the CVSS score of CVE-2025-70099?

CVE-2025-70099 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Which versions of lwext4 are affected by CVE-2025-70099?

lwext4 1.0.0 contains a denial-of-service vulnerability affecting IoT devices, bootloaders, and forensic tools that process EXT4 filesystem images.

Is there a public PoC exploit available for CVE-2025-70099?

Yes, a public proof-of-concept exploit is available for CVE-2025-70099. Prioritise patching immediately. EPSS: 0.0%.

How to fix or mitigate CVE-2025-70099?

Within 24 hours: inventory all systems running lwext4 1.0.0 (embedded IoT, bootloaders, forensic platforms). Within 7 days: implement input validation and network controls to restrict untrusted filesystem image sources; disable directory iteration features if unused. Within 30 days: evaluate migration to actively maintained filesystem libraries or develop application-level safeguards pending vendor update.

lwext4 CVE-2025-70099

HIGH

NULL Pointer Dereference (CWE-476)

2026-06-01 mitre

Denial Of Service Null Pointer Dereference N A

7.5

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (mitre) · only source for this CVE.

CVSS VectorVendor: mitre

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 02, 2026 - 16:22 vuln.today

CVSS changed

Jun 02, 2026 - 16:22 NVD

7.5 (HIGH)

CVE Published

Jun 01, 2026 - 00:00 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

A NULL pointer dereference in the ext4_dir_en_get_name_len function in include/ext4_dir.h of lwext4 1.0.0 allows attackers to cause a denial of service by supplying a specially crafted EXT4 filesystem image with malformed directory entries. During directory iteration, the code may fail to validate the directory entry pointer before accessing the name_len field, resulting in a segmentation fault. This affects versions based on (or equivalent to) the 2016-era codebase (1.0.0).

AnalysisAI

Denial of service in lwext4 1.0.0 allows remote attackers to crash applications by supplying a malformed EXT4 filesystem image that triggers a NULL pointer dereference in ext4_dir_en_get_name_len during directory iteration. The flaw affects the 2016-era lwext4 codebase commonly embedded in IoT, bootloaders, and forensic tools that mount untrusted EXT4 images. Publicly available exploit code exists, though EPSS rates real-world exploitation probability as very low (0.02%, 4th percentile).

Technical ContextAI

lwext4 is a lightweight, portable EXT2/3/4 filesystem implementation written in C, widely embedded in resource-constrained environments such as bootloaders, embedded Linux derivatives, microcontroller firmware, and disk forensic utilities where the full kernel ext4 driver is impractical. The vulnerable function ext4_dir_en_get_name_len in include/ext4_dir.h reads the name_len field from an ext4_dir_en directory entry structure without first validating that the pointer to the entry itself is non-NULL or that the entry lies within the bounds of the parsed directory block. This is a classic CWE-476 (NULL Pointer Dereference) caused by missing input validation when iterating over an attacker-controlled on-disk structure, and reflects an entire class of filesystem-parser bugs where on-disk metadata is trusted to be well-formed.

RemediationAI

No vendor-released patch identified at time of analysis - the GitHub issue at https://github.com/gkostka/lwext4/issues/89 documents the bug but no tagged patched release is linked in the provided references, so integrators should track that issue and apply any upstream fix or carry a local patch that validates the directory entry pointer and name_len bounds before dereference in ext4_dir_en_get_name_len. As compensating controls until an upstream fix lands, restrict the parser to images from trusted sources only (do not auto-mount user-supplied USB/SD/network images), wrap mount operations in a separate process or sandbox so a segfault cannot crash the host application, and where feasible run image parsing under seccomp or with watchdog-based restart so a DoS does not become a persistent outage. Trade-off: process isolation and sandboxing add complexity and may not be feasible on the deeply embedded targets that lwext4 is designed for.