A memory leak vulnerability in the free5GC PCF (Policy Control Function) allows any unauthenticated attacker with network access to the PCF SBI interface to cause uncontrolled memory growth by sending repeated HTTP requests to the OAM endpoint. The root cause is a router.Use() call inside an HTTP handler that registers a new CORS middleware on every incoming request, permanently growing the Gin router's handler chain. This leads to progressive memory exhaustion and eventual Denial of Service of the PCF, preventing all UEs from obtaining AM and SM policies and blocking 5G session establishment.
File: free5gc/pcf/internal/sbi/api_oam.go
Function: setCorsHeader(), called by HTTPOAMGetAmPolicy()
The function setCorsHeader() invokes s.router.Use() on every incoming HTTP request:
func (s *Server) setCorsHeader(c *gin.Context) {
// BUG: router.Use() inside a handler — executes on every request
s.router.Use(cors.New(cors.Config{
AllowMethods: []string{"GET", "POST", "OPTIONS", "PUT", "PATCH", "DELETE"},
AllowAllOrigins: true,
AllowCredentials: true,
MaxAge: CorsConfigMaxAge,
}))
// Redundant manual header setting
c.Writer.Header().Set("Access-Control-Allow-Origin", "*")
c.Writer.Header().Set("Access-Control-Allow-Credentials", "true")
// ...
}
func (s *Server) HTTPOAMGetAmPolicy(c *gin.Context) {
s.setCorsHeader(c) // ← called on every GET /npcf-oam/v1/am-policy/:supi
// ...
}
In the Gin framework, router.Use() appends a new HandlerFunc to the router's internal middleware slice. This operation is not idempotent — it does not replace existing middleware but appends a new instance on every call. After N requests, Gin executes N CORS middleware instances before reaching the actual handler:
Request N → [cors_mw_1 → cors_mw_2 → ... → cors_mw_N → actual_handler]
Since s.router holds a permanent reference to the accumulated...
1.4.3Exploitability
AV:NAC:LPR:NUI:NScope
S:UImpact
C:NI:NA:H7.5/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H