Stack Overflow in Gin

In Go, a stack overflow occurs when a goroutine exceeds its allocated stack size, triggering a panic like runtime: goroutine stack exceeds 1000000000-byte limit. In a Gin‑based API this usually happens when a handler recursively calls itself based on user‑supplied data without a proper termination condition. For example, an endpoint that processes a nested JSON structure by walking the object tree recursively can be driven into deep recursion by a malicious payload, consuming the goroutine stack and causing a denial‑of‑service.

package main

import (
	"github.com/gin-gonic/gin"
)

func walk(data interface{}, depth int) {
	// Intentional lack of depth limit – user‑controlled JSON can cause deep recursion
	switch v := data.(type) {
	case map[string]interface{}:
		for _, val := range v {
			walk(val, depth+1)
		}
	case []interface{}:
		for _, item := range v {
			walk(item, depth+1)
		}
	default:
		// leaf value – do nothing
	}
}

func nestedHandler(c *gin.Context) {
	var json map[string]interface{}
	if err := c.ShouldBindJSON(&json); err != nil {
		c.AbortWithStatusJSON(400, gin.H{"error": "invalid JSON"})
		return
	}
	walk(json, 0) // may overflow the stack
	c.JSON(200, gin.H{"status": "processed"})
}

func main() {
	r := gin.Default()
	r.POST("/nested", nestedHandler)
	r.Run()
}

The above code has no guard against excessive nesting depth. An attacker can send a JSON payload with thousands of nested objects or arrays, forcing the walk function to recurse until the goroutine stack limit is exceeded. The resulting panic crashes the handler (and, if not recovered, the whole Gin instance), leading to a denial‑of‑service that is exploitable without authentication.

Detecting this class of issue requires observing whether an unauthenticated endpoint can be driven into uncontrolled recursion. middleBrick performs unauthenticated black‑box testing by sending crafted payloads to each discovered route and monitoring for error responses, timeouts, or panics that indicate a stack overflow. When scanning a Gin service, middleBrick will:

• Identify endpoints that accept JSON or XML bodies (e.g., POST /nested).
• Generate payloads with progressively deeper nesting (e.g., {"a":{"b":{"c":{…}}}}) up to a configurable depth.
• Send each payload and look for:
• HTTP 500 responses containing panic stack traces.
• Requests that exceed the scanner’s timeout (default 15 s), suggesting the handler is stuck in deep recursion.
• Any sudden increase in response size or connection resets.
• Correlate findings with the specific route and HTTP method, then report them under the “Input Validation” category with severity “high”.

Because middleBrick needs no agents or credentials, you can run a scan simply with the CLI:

middlebrick scan https://api.example.com

The output will include a finding such as:
{
  "endpoint": "/nested",
  "method": "POST",
  "category": "Input Validation",
  "severity": "high",
  "description": "Possible stack overflow via deep JSON nesting",
  "remediation": "Limit recursion depth or use an iterative walker"
}

This gives developers an actionable starting point to fix the vulnerability before it is exploited in production.

The fix is to bound the recursion depth or replace the recursive walk with an iterative approach. Gin itself does not provide a recursion limiter, but you can add a depth parameter and abort when a threshold is exceeded. Using Go’s context package you can also cancel the operation if it takes too long, which protects against both stack overflow and excessive CPU consumption.

package main

import (
	"context"
	"github.com/gin-gonic/gin"
)

const maxDepth = 100

func walkIterative(data interface{}) error {
	// Use a stack to avoid recursion
	type node struct {
		value interface{}
		depth int
	}
	stack := []node{{value: data, depth: 0}}

	for len(stack) > 0 {
		// pop last element
		last := len(stack) - 1
		cur := stack[last]
		stack = stack[:last]

		if cur.depth > maxDepth {
			return fmt.Errorf("nesting depth exceeds limit (%d)", maxDepth)
		}

		switch v := cur.value.(type) {
		case map[string]interface{}:
			for _, val := range v {
				stack = append(stack, node{value: val, depth: cur.depth + 1})
			}
		case []interface{}:
			for _, item := range v {
				stack = append(stack, node{value: item, depth: cur.depth + 1})
			}
		default:
			// leaf – nothing to do
		}
	}
	return nil
}

func nestedHandler(c *gin.Context) {
	var json map[string]interface{}
	if err := c.ShouldBindJSON(&json); err != nil {
		c.AbortWithStatusJSON(400, gin.H{"error": "invalid JSON"})
		return
	}
	ctx, cancel := context.WithTimeout(c.Request.Context(), 2*time.Second)
	defer cancel()

	if err := walkIterative(json); err != nil {
		c.AbortWithStatusJSON(400, gin.H{"error": err.Error()})
		return
	}
	c.JSON(200, gin.H{"status": "processed"})
}

func main() {
	r := gin.Default()
	r.POST("/nested", nestedHandler)
	r.Run()
}

Key points:

maxDepth caps the allowed nesting; exceeding it returns a 400 error instead of recursing further.
The iterative walkIterative uses a explicit slice as a stack, eliminating the risk of goroutine stack overflow.
A timeout context (context.WithTimeout) ensures that even if a bug slips through, the handler will be cancelled after a reasonable interval, freeing resources.
These changes rely only on Gin’s standard middleware and Go’s standard library—no external agents or runtime patches are required.

After applying the fix, rerun middleBrick:
middlebrick scan https://api.example.com

The scanner should now report a clean score (e.g., “A”) for the /nested endpoint, confirming that the stack‑overflow vector has been mitigated.