Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-33063 is a high-severity NULL Pointer Dereference (CWE-476) vulnerability in Free5Gc Free5Gc. Its CVSS base score is 8.7 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 48th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-33063 is an Improper Null Check vulnerability (CWE-476) in the AUSF component of free5GC, an open-source 5G core network implementation. AUSF versions prior to 1.4.2 are affected, including all deployments of free5GC v4.0.1 that utilize the UE authentication service at the `/nausf-auth/v1/ue-authentications` endpoint. The flaw occurs in the `GetSupiFromSuciSupiMap` function, which attempts an interface conversion from `interface{}` to `*context.SuciSupiMap` without checking if the underlying `SuciSupiMap` value is nil, triggering a panic with the error "interface conversion: interface {} is nil, not *context.SuciSupiMap" and leading to denial of service.
A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted UE authentication request to the affected endpoint, causing the AUSF service to panic and crash. This results in a complete denial of service for the AUSF authentication service, disrupting 5G core network authentication operations. The vulnerability carries a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), reflecting its high availability impact and ease of remote exploitation without privileges or user interaction.
free5GC AUSF version 1.4.2 patches the issue by addressing the nil check in the interface conversion. No direct application-level workaround exists, though restricting access to the AUSF API to trusted sources is recommended as a mitigation. Key resources include the patching commit (https://github.com/free5gc/ausf/commit/3b9ac4403c2756dc89a5ed3cdcefe688458588aa), pull request (https://github.com/free5gc/ausf/pull/52), issue discussion (https://github.com/free5gc/free5gc/issues/778), and GitHub security advisory (https://github.com/free5gc/free5gc/security/advisories/GHSA-4jrw-92fg-4jwx).
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-13513
Vulnerability Data
free5GC is an open source 5G core network. free5GC AUSF prior to version 1.4.2 has is an Improper Null Check vulnerability leading to Denial of Service. All deployments of free5GC v4.0.1 using the AUSF UE authentication service (`/nausf-auth/v1/ue-authentications` endpoint) are…
more
affected. A remote attacker can cause the AUSF service to panic and crash by sending a crafted UE authentication request that triggers a nil interface conversion in the `GetSupiFromSuciSupiMap` function. This results in complete denial of service for the AUSF authentication service. The `GetSupiFromSuciSupiMap` function attempts to perform an interface conversion from `interface{}` to `*context.SuciSupiMap` without checking if the underlying value is nil. When `SuciSupiMap` is nil, the code panics with "interface conversion: interface {} is nil, not *context.SuciSupiMap". free5GC AUSF version 1.4.2 patches the issue. There is no direct workaround at the application level. The recommendation is to apply the provided patch or restrict access to the AUSF API to trusted sources only.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including static analysis) directly finds null-dereference bugs before deployment.
Documented development standards and tools can enforce null-safety rules and safe pointer usage.
Engineering principles can mandate defensive coding such as explicit null checks before dereference.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices (static analysis, code review, safe coding standards) directly prevent NULL dereference bugs during development.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect NULL dereference defects before release.
Secure SDLC mandates defensive coding practices that can prevent NULL dereferences.
Application security requirements can specify input validation and pointer-safety rules.
Secure architecture principles encourage defensive design that avoids unsafe pointer use.
Secure coding standards directly require NULL-pointer checks and safe dereference patterns.