VYPR
Medium severity4.9GHSA Advisory· Published Jun 11, 2026· Updated Jun 11, 2026

free5GC UDR has improper `ueId` validation in EE subscription handlers that allows arbitrary identifier persistence

CVE-2026-47780

Description

free5GC UDR accepts arbitrary ueId values via a flawed regex in two EE subscription handlers, allowing persistent database pollution and broken trust boundaries.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

free5GC UDR accepts arbitrary ueId values via a flawed regex in two EE subscription handlers, allowing persistent database pollution and broken trust boundaries.

Vulnerability

The free5GC Unified Data Repository (UDR) EE subscription handlers HandleCreateEeSubscriptions and HandleQueryEeSubscriptions in api_datarepository.go improperly validate the ueId parameter. The validation regex ^(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)$ ends with the catch-all alternative .+, which matches any non-empty string and bypasses the intended 3GPP identifier checks. This vulnerability affects all versions of free5GC containing the flawed regex; the tested deployment appears to be a standard free5GC release up to the date of the advisory [1][2].

Exploitation

An attacker able to reach the UDR SBI interface (e.g., from the internal network or via a compromised component) can send a crafted POST request to /nudr-dr/v2/subscription-data/{ueId}/context-data/ee-subscriptions with an arbitrary ueId, such as ARBITRARY_STRING. The flawed regex accepts the value, and the handler stores the subscription record in the UDR database, returning HTTP 201 Created with a Location header pointing to the newly created resource. The same arbitrary identifier can then be retrieved using the corresponding GET endpoint, confirming persistence [1][2].

Impact

Successful exploitation allows an attacker to inject arbitrary ueId values into the UDR data store, polluting the database with non-standard identifiers and breaking trust boundaries that other network functions rely on. This can lead to unauthorized data creation, data corruption, and potential misrouting or misassociation of UE subscription information. The compromise is at the UDR data-model level, affecting the integrity and availability of subscription data for event exposure subscriptions [1][2].

Mitigation

As of the published advisory, no fixed version of free5GC has been released. The recommended mitigation is to correct the regex to remove the . |.+ alternation and enforce strict validation of 3GPP SUPI/GPSI identifier formats. Until a patch is applied, administrators should restrict network access to the UDR SBI endpoint and monitor for unexpected entries in the EE subscription tables. The CVE is not listed in CISA's Known Exploited Vulnerabilities catalog as of the publication date [1][2].

AI Insight generated on Jun 11, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

1

Patches

0

No patches discovered yet.

Vulnerability mechanics

Root cause

"The regular expression used for ueId validation ends with the catch-all alternative `|.+`, which matches any non-empty string and defeats the intended 3GPP identifier checks."

Attack vector

An attacker with network reachability to the UDR SBI endpoint can send a POST request to `/nudr-dr/v2/subscription-data/{ueId}/context-data/ee-subscriptions` with an arbitrary non-3GPP `ueId` value (e.g., `ARBITRARY_STRING`). The flawed regex accepts any non-empty string, so the request is processed and the attacker-chosen identifier is persisted in the UDR backend. A subsequent GET request to the same path retrieves the stored record, confirming persistent database pollution [ref_id=1][ref_id=2].

Affected code

The vulnerable logic is present in two handlers in `api_datarepository.go`: `HandleCreateEeSubscriptions` and `HandleQueryeesubscriptions`. Both rely on the same `regexp.MatchString()` validation pattern for `ueId`: `^(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)$`. The final alternative `|.+` acts as a universal match for any non-empty string, defeating the intended 3GPP identifier checks [ref_id=1][ref_id=2].

What the fix does

The recommended fix removes the trailing `|.+` branch from the regex, changing the pattern to `^(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+)$` [ref_id=1][ref_id=2]. This restricts accepted input to explicitly supported 3GPP identifier formats (IMSI, NAI, MSISDN, EXTID, GCI, GLI) and prevents arbitrary non-3GPP strings from passing validation. The patch does not show any other changes beyond this regex correction.

Preconditions

  • networkNetwork reachability to the UDR SBI endpoint (e.g., `10.22.22.5:80` in the tested environment)
  • configThe UDR must expose the vulnerable EE subscription handlers (POST/GET on `/subscription-data/{ueId}/context-data/ee-subscriptions`)

Generated on Jun 11, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

2

News mentions

0

No linked articles in our index yet.