Reachable Nil Pointer Dereference in UntypedRequestBinder with Malformed Parameter Definitions

Summary

reproduce_panic.go.txt

reproduce_panic.go.txt

I discovered a reproducible nil pointer dereference panic in go-openapi/runtime caused by a missing nil check inside middleware/request.go.

This issue was initially discovered through fuzzing and later validated by tracing the normal request-processing path inside the middleware.

The panic occurs in:

middleware/request.go:76

Error:

panic: runtime error: invalid memory address or nil pointer dereference

Repository tested:

go-openapi/runtime

Commit tested:

760cc621faab536f7678056e64db44aedde1b01f

Root Cause

The following code dereferences param.Schema without verifying that it is non-nil:

if tpe == nil {
    if param.Schema.Type.Contains(typeArray) {
        tpe = reflect.TypeFor[[]any]()
    } else {
        tpe = reflect.TypeFor[map[string]any]()
    }
}

However, non-body parameters may legitimately have:

param.Schema == nil

which can lead to a nil pointer dereference.

Reachable Execution Path

I traced the following internal request-processing path:

HTTP Request
↓
Context.BindAndValidate()
↓
validateRequest()
↓
validation.parameters()
↓
v.route.Binder.bind()
↓
middleware/request.go:76
↓
panic

I also confirmed that validation.go initializes:

bound: make(map[string]any)

and later executes:

v.route.Binder.bind(
    v.request,
    v.route.Params,
    v.route.Consumer,
    v.bound,
)

This confirms that the isMap == true condition is part of the normal runtime path and is not an artificial fuzzing condition.

Conditions Required

The panic occurs when the following conditions are met simultaneously:

• isMap == true
• binder.Type() == nil
• param.Schema == nil

Examples include malformed parameter definitions such as:

• type="array" without items
• type="number" without a valid format
• empty or unsupported types

Analysis

I traced parameter initialization and found that parameter definitions originate from:

analysis.ParamsFor()
↓
OpenAPI Specification

I did not verify a generic unauthenticated Remote DoS scenario because parameter definitions originate from the application's OpenAPI specification.

Therefore, I currently classify this issue as a reachable panic / stability bug rather than a confirmed remote vulnerability.

Suggested Fix

Add a nil check before accessing param.Schema.

For example:

if tpe == nil {
    if param.Schema != nil && param.Schema.Type.Contains(typeArray) {
        tpe = reflect.TypeFor[[]any]()
    } else {
        tpe = reflect.TypeFor[map[string]any]()
    }
}

Alternatively, reject invalid parameter states before reaching this branch.

Notes

The issue was reproduced through fuzzing and later validated through manual code tracing of the production request-processing path.