What is the CVSS score of CVE-2026-38640?

CVE-2026-38640 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.2%.

Which versions of relibc are affected by CVE-2026-38640?

relibc, the Redox OS C standard library, contains a denial-of-service vulnerability (CVE-2026-38640, CVSS 7.5) that can crash processes through malformed input.

Is there a public PoC exploit available for CVE-2026-38640?

Yes, a public proof-of-concept exploit is available for CVE-2026-38640. Prioritise patching immediately. EPSS: 0.2%.

How to fix or mitigate CVE-2026-38640?

Within 24 hours: Identify any systems running Redox OS or relibc and assess their criticality within your infrastructure. Within 7 days: For affected systems, implement input validation to restrict untrusted data reaching assertion paths; establish process restart mechanisms to minimize availability impact. Within 30 days: Monitor Redox OS release notes and security advisories for patched relibc versions; prepare deployment plan for when patches become available.

relibc CVE-2026-38640

HIGH

Uncontrolled Resource Consumption (CWE-400)

2026-06-25 mitre

Denial Of Service 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

vuln.today AI

7.5 HIGH

Availability-only crash with no auth or interaction where the assert path is remotely reachable, hence A:H/PR:N/UI:N; C:N/I:N as no data or integrity impact.

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

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (mitre).

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 26, 2026 - 14:22 vuln.today

CVSS changed

Jun 26, 2026 - 14:22 NVD

7.5 (HIGH)

CVE Published

Jun 25, 2026 - 00:00 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

A reachable unwrap in the __assert_fail function (/assert/mod.rs) of relibc commit 61f42d allows attackers to cause a Denial of Service (DoS) via a crafted string.

AnalysisAI

Denial of service in relibc (the Redox OS C standard library implementation, commit 61f42d) lets attackers crash a process by supplying a crafted string that reaches a panicking unwrap() inside the __assert_fail function in /assert/mod.rs. Any program linked against the affected relibc that routes attacker-influenced data through an assertion failure path can be forced to abort. Publicly available exploit code exists, but the issue is not listed in CISA KEV and EPSS is low (0.17%, 6th percentile), indicating no observed widespread exploitation.

Technical ContextAI

relibc is Redox OS's Rust implementation of the C standard library (libc), used both by the Redox microkernel operating system and by Rust/C programs targeting it. The defect lives in the assertion-failure handler __assert_fail (/assert/mod.rs), which is invoked when a C assert() macro fails. The handler contains a reachable unwrap() on a fallible operation (e.g. parsing/formatting the assertion's string arguments); when that operation returns an error or None, the unwrap() triggers a Rust panic and aborts the process. The mapped weakness is CWE-400 (Uncontrolled Resource Consumption), though the concrete mechanism here is an unhandled error/panic causing process termination rather than resource exhaustion - the practical effect is an availability-only crash.

RemediationAI

No vendor-released patch version is identified at time of analysis; the upstream fix is tracked as a GitLab merge request (https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/986) against issue 262 (https://gitlab.redox-os.org/redox-os/relibc/-/issues/262), so an upstream fix is in progress but a released, tagged patched version is not independently confirmed. Until a fixed commit/release is available, build relibc from a tree that includes the MR-986 change (which replaces the panicking unwrap() in __assert_fail with graceful error handling), or, as a compensating control, avoid compiling production code with assert() calls that can receive attacker-controlled strings - disabling assertions via NDEBUG removes the vulnerable path entirely at the cost of losing assertion-based debugging checks. Where feasible, validate or sanitize external input before it reaches assertion-bearing code paths; this narrows reachability but does not eliminate the underlying defect.