GHSA-WRWH-RPQ4-87HF
Vulnerability from github – Published: 2026-04-14 20:00 – Updated: 2026-04-16 21:57Summary
An information disclosure vulnerability in the UDR service allows any unauthenticated attacker with access to the 5G Service Based Interface (SBI) to retrieve stored subscriber identifiers (SUPI/IMSI) with a single HTTP GET request requiring no parameters or credentials.
Details
The endpoint GET /nudr-dr/v2/application-data/influenceData/subs-to-notify (defined in 3GPP TS 29.519) requires at least one query parameter (dnns, snssais, supis, or internalGroupIds) to filter results.
In the free5GC UDR implementation, the input validation is present but ineffective because the handler does not return after sending the HTTP 400 error. The request handling flow is:
- The function
HandleApplicationDataInfluenceDataSubsToNotifyGetin./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/api_datarepository.go(around line 2793) checks whether all ofdnn,snssai,internalGroupId, andsupiare empty. - If they are all empty, it builds a
problemDetailsstructure and callsc.JSON(http.StatusBadRequest, problemDetails)to send a 400 response, but it does not return afterwards. - Execution continues and the handler still calls
s.Processor().ApplicationDataInfluenceDataSubsToNotifyGetProcedure(c, dnn,snssai, internalGroupId, supi)defined in./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/processor/influence_data_subscriptions_collection.go. - This processor function queries the data repository and writes the full list of Traffic Influence Subscriptions to the HTTP response body, including
supisfields with SUPI/IMSI values.
As a result, a request without any query parameters produces a response where the HTTP status is 400 Bad Request, but the body contains both the error object and the full subscription list.
The missing return after sending the 400 response in api_datarepository.go is the root cause of this vulnerability.
PoC
No authentication, no prior knowledge of any subscriber identifier required.
curl -v "http://<udr-host>/nudr-dr/v2/application-data/influenceData/subs-to-notify"
Response (HTTP 400):
{"status":400,"detail":"At least one of DNNs, S-NSSAIs, Internal Group IDs or SUPIs shall be provided"}
[{"dnns":["internet"],
"snssais":[{"sst":1,"sd":"000001"}],
"supis":["imsi-222777483957498"],
"notificationUri":"http://pcf.../npcf-callback/v1/nudr-notify/influence-data/imsi-222777483957498/1"}]
Impact
This is an unauthenticated information disclosure vulnerability. Any attacker with network access to the SBI (Service Based Interface) can enumerate SUPIs (Subscriber Permanent Identifiers / IMSI values) of registered users without any credentials or prior knowledge.
In a 5G network, the SUPI is the most sensitive subscriber identifier — its exposure breaks the privacy guarantees introduced by 3GPP with the SUCI (Subscription Concealed Identifier) mechanism, designed specifically to prevent SUPI tracking over the air. This vulnerability completely undermines that protection at the core network level.
Impacted deployments: any free5GC instance where the SBI is reachable by untrusted parties (e.g., misconfigured network segmentation, rogue NF, or compromised internal host).
Note: an additional trigger exists — sending a malformed snssai parameter also bypasses validation due to a missing return after the deserialization error handler, producing the same information disclosure.
Patch
The vulnerability has been confirmed patched by adding the two missing return statements in NFs/udr/internal/sbi/api_datarepository.go, function HandleApplicationDataInfluenceDataSubsToNotifyGet:
- After the
c.JSON(http.StatusBadRequest, problemDetails)call in thesnssaideserialization error branch. - After the
c.JSON(http.StatusBadRequest, problemDetails)call in the empty parameters validation block.
With the patch applied, a request without any query parameters now correctly returns HTTP 400 with only the error message, and no subscriber data is included in the response body.
The fix has been verified: after applying the patch and recompiling the UDR, the endpoint GET /nudr-dr/v2/application-data/influenceData/subs-to-notify returns HTTP 400 with only:
{"status":400,"detail":"At least one of DNNs, S-NSSAIs, Internal Group IDs
or SUPIs shall be provided"}
No SUPI or subscription data is leaked.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/free5gc/udr"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40245"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-202",
"CWE-209"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T20:00:15Z",
"nvd_published_at": "2026-04-16T00:16:29Z",
"severity": "HIGH"
},
"details": "### Summary\nAn information disclosure vulnerability in the UDR service allows any unauthenticated attacker with access to the 5G Service Based Interface (SBI) to retrieve stored subscriber identifiers (SUPI/IMSI) with a single HTTP GET request requiring no parameters or credentials.\n\n### Details\nThe endpoint `GET /nudr-dr/v2/application-data/influenceData/subs-to-notify` (defined in 3GPP TS 29.519) requires at least one query parameter (`dnns`, `snssais`, `supis`, or `internalGroupIds`) to filter results.\n\nIn the free5GC UDR implementation, the input validation is present but ineffective because the handler does not return after sending the HTTP 400 error. The request handling flow is:\n\n1. The function `HandleApplicationDataInfluenceDataSubsToNotifyGet` in `./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/api_datarepository.go` (around line 2793) checks whether all of `dnn`, `snssai`, `internalGroupId`, \n and `supi` are empty.\n2. If they are all empty, it builds a `problemDetails` structure and calls `c.JSON(http.StatusBadRequest, problemDetails)` to send a 400 response, **but it does not return afterwards**.\n3. Execution continues and the handler still calls `s.Processor().ApplicationDataInfluenceDataSubsToNotifyGetProcedure(c, dnn,snssai, internalGroupId, supi)` defined in `./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/processor/influence_data_subscriptions_collection.go`.\n4. This processor function queries the data repository and writes the full list of Traffic Influence Subscriptions to the HTTP response body, including `supis` fields with SUPI/IMSI values.\n\nAs a result, a request without any query parameters produces a response where the HTTP status is 400 Bad Request, but the body contains both the error object and the full subscription list.\n\nThe missing `return` after sending the 400 response in `api_datarepository.go` is the root cause of this vulnerability.\n\n### PoC\nNo authentication, no prior knowledge of any subscriber identifier required.\n\n```bash\ncurl -v \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/subs-to-notify\"\n```\nResponse (HTTP 400):\n```json\n{\"status\":400,\"detail\":\"At least one of DNNs, S-NSSAIs, Internal Group IDs or SUPIs shall be provided\"}\n[{\"dnns\":[\"internet\"],\n \"snssais\":[{\"sst\":1,\"sd\":\"000001\"}],\n \"supis\":[\"imsi-222777483957498\"],\n \"notificationUri\":\"http://pcf.../npcf-callback/v1/nudr-notify/influence-data/imsi-222777483957498/1\"}]\n```\n\n### Impact\nThis is an unauthenticated information disclosure vulnerability. Any attacker with network access to the SBI (Service Based Interface) can enumerate SUPIs (Subscriber Permanent Identifiers / IMSI values) of registered users without any credentials or prior knowledge.\n\nIn a 5G network, the SUPI is the most sensitive subscriber identifier \u2014 its exposure breaks the privacy guarantees introduced by 3GPP with the SUCI (Subscription Concealed Identifier) mechanism, designed specifically to prevent SUPI tracking over the air. This vulnerability completely undermines that protection at the core network level.\n\nImpacted deployments: any free5GC instance where the SBI is reachable by untrusted parties (e.g., misconfigured network segmentation, rogue NF, or compromised internal host).\n\nNote: an additional trigger exists \u2014 sending a malformed `snssai` parameter also bypasses validation due to a missing return after the deserialization error handler, producing the same information disclosure.\n\n### Patch\n\nThe vulnerability has been confirmed patched by adding the two missing `return` statements in `NFs/udr/internal/sbi/api_datarepository.go`, function `HandleApplicationDataInfluenceDataSubsToNotifyGet`:\n\n1. After the `c.JSON(http.StatusBadRequest, problemDetails)` call in the `snssai` deserialization error branch.\n2. After the `c.JSON(http.StatusBadRequest, problemDetails)` call in the empty parameters validation block.\n\nWith the patch applied, a request without any query parameters now correctly returns HTTP 400 with only the error message, and no subscriber data is included in the response body.\n\nThe fix has been verified: after applying the patch and recompiling the UDR, the endpoint `GET /nudr-dr/v2/application-data/influenceData/subs-to-notify` returns HTTP 400 with only:\n```\n{\"status\":400,\"detail\":\"At least one of DNNs, S-NSSAIs, Internal Group IDs \nor SUPIs shall be provided\"}\n```\nNo SUPI or subscription data is leaked.",
"id": "GHSA-wrwh-rpq4-87hf",
"modified": "2026-04-16T21:57:35Z",
"published": "2026-04-14T20:00:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-wrwh-rpq4-87hf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40245"
},
{
"type": "PACKAGE",
"url": "https://github.com/free5gc/udr"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "free5gc UDR nudr-dr influenceData/subs-to-notify leaks SUPI in error response body without authentication"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.