<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Nrf:v4.2.1 — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/nrfv4.2.1/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Sat, 09 May 2026 14:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/nrfv4.2.1/feed.xml" rel="self" type="application/rss+xml"/><item><title>free5GC NRF Type Confusion Vulnerability in /oauth2/token Endpoint</title><link>https://feed.craftedsignal.io/briefs/2026-05-free5gc-nrf-type-confusion/</link><pubDate>Sat, 09 May 2026 14:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-free5gc-nrf-type-confusion/</guid><description>The free5GC NRF's /oauth2/token endpoint is vulnerable to a type confusion vulnerability due to incorrect parsing of form data, leading to a denial-of-service via unauthenticated requests.</description><content:encoded><![CDATA[<p>A type confusion vulnerability exists in the free5GC NRF (Network Repository Function) version 4.2.1, specifically within the <code>/oauth2/token</code> endpoint. This endpoint, which is intentionally unauthenticated as it is the OAuth2 token issuance endpoint, is susceptible to a parser-level bug. The vulnerability lies in how the <code>NFs/nrf/internal/sbi/api_accesstoken.go</code> handler processes incoming form data. The handler uses reflection on the <code>models.NrfAccessTokenAccessTokenReq</code> struct, but incorrectly treats most fields as <code>models.PlmnId</code> types. This leads to a panic when the parsed value is assigned to a field with an incompatible type, such as slices or different struct pointers. Although the Gin recovery mechanism catches the panic, converting it to an HTTP 500 error, the endpoint remains vulnerable to repeated denial-of-service attacks via single, unauthenticated form-encoded POST requests. This issue affects free5GC version 4.2.1.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Attacker sends an HTTP POST request to the <code>/oauth2/token</code> endpoint of the free5GC NRF at <code>http://10.100.200.3:8000</code>.</li>
<li>The request includes a <code>Content-Type</code> header set to <code>application/x-www-form-urlencoded</code>.</li>
<li>The request body contains a URL-encoded parameter, such as <code>requesterPlmnList</code>, <code>requesterSnssaiList</code>, <code>requesterSnpnList</code>, <code>targetSnpn</code>, <code>targetSnssaiList</code>, or <code>targetNsiList</code>, with a value intended to trigger the type confusion. For example: <code>requesterPlmnList={&quot;mcc&quot;:&quot;208&quot;,&quot;mnc&quot;:&quot;93&quot;}</code>.</li>
<li>The NRF&rsquo;s <code>api_accesstoken.go</code> handler parses the form data and reflects over the <code>models.NrfAccessTokenAccessTokenReq</code> struct.</li>
<li>Due to incorrect type handling, the handler attempts to assign a value of type <code>*models.PlmnId</code> to a field of an incompatible type (e.g., <code>[]models.PlmnId</code> for the <code>requesterPlmnList</code> field).</li>
<li>The <code>reflect.Set</code> operation panics due to the type mismatch.</li>
<li>The Gin recovery middleware catches the panic and converts it into an HTTP 500 Internal Server Error.</li>
<li>The NRF process continues to run, but the specific request is not processed successfully, and an error message is logged.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>The type confusion vulnerability (CWE-843) in the <code>/oauth2/token</code> endpoint allows an attacker to cause a denial-of-service (DoS) condition by sending crafted requests. Although the Gin recovery mechanism prevents the NRF process from crashing entirely, each malicious request consumes resources (CPU, log writes due to stack trace generation) and degrades the performance of the token issuance service. An attacker can repeatedly send these requests, potentially impacting legitimate clients and overwhelming the logs. The vulnerability affects free5GC version 4.2.1. There are at least 6 crashing fields which all crash due to the same root cause.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Monitor webserver logs for HTTP POST requests to the <code>/oauth2/token</code> endpoint (IOC: <code>http://10.100.200.3:8000/oauth2/token</code>) containing parameters known to trigger the vulnerability (e.g., <code>requesterPlmnList</code>, <code>requesterSnssaiList</code>, <code>targetSnpn</code>) and deploy the &ldquo;Detect free5GC NRF Type Confusion Attempt&rdquo; Sigma rule.</li>
<li>Apply the upstream patch available at <code>https://github.com/free5gc/nrf/pull/83</code> to address the vulnerability.</li>
<li>Upgrade the go/github.com/free5gc/nrf package to a version greater than or equal to 1.4.3 to remediate CVE-2026-44325.</li>
<li>Implement input validation on the <code>/oauth2/token</code> endpoint to ensure that the types of the request parameters match the expected types in the <code>models.NrfAccessTokenAccessTokenReq</code> struct.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>type-confusion</category><category>denial-of-service</category><category>free5GC</category></item></channel></rss>