<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 21:14:01 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-47780</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-47780</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-47780</guid>
    </item>
    <item>
      <title>GHSA-6gxq-gpr8-xgjp — free5GC UDR has improper `ueId` validation in EE subscription handlers that allows arbitrary identifier persistence</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-6gxq-gpr8-xgjp</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/free5gc/udr&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### 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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/free5gc/udr&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### 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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-6gxq-gpr8-xgjp</guid>
    </item>
  </channel>
</rss>
