Unauthenticated exposure of all registered expvars
medium swesweep-fasthttp · expvarhandler/expvar.go · ExpvarHandler · run #4
Description
ExpvarHandler serves all registered expvars by default and does not enforce authentication, authorization, or rate limiting. If the handler is mounted on a network-facing endpoint, an unauthenticated attacker can read host metrics or any custom expvars, including potentially sensitive operational data.
Triage
- Verdict
- INVALID confidence 0.0
- Model
- qwen/qwen3.8-27b
- Rounds
- 5
- Cost
- $0.0114 · 24.8 s
The reported vulnerability is that `ExpvarHandler` exposes all registered `expvars` without enforcing authentication, authorization, or rate limiting. The threat model specifies a 'library (Reusable library / SDK)' profile where the attacker is defined as code calling the public API. The binding rules explicitly state that 'misuse that violates a documented precondition of the public API' is not a vulnerability, and that the public API must validate all inputs, but internal helpers may assume invariants. However, in the context of a web server library (fasthttp), providing a handler that serves sensitive operational data (expvars often contain memory stats, request counts, etc.) over HTTP is a standard pattern for internal debugging or metrics endpoints. The responsibility for securing such endpoints (via authentication middleware, network isolation, or access controls) lies with the application developer who mounts the handler. The library itself (`swesweep-fasthttp`) does not claim to provide authentication; it simply serializes the data as documented. There is no code defect, no bypass of an existing security mechanism within the library, and no memory safety issue. The finding describes a deployment or configuration risk (exposing an endpoint without auth) rather than a vulnerability in the library's implementation. Therefore, it is not a security vulnerability in the code itself under the given threat model. CRUX: The lack of authentication is a responsibility of the host application (deployment/configuration), not a defect in the library's implementation which simply serializes expvars as documented. GREP: func ExpvarHandler
All rounds
[
{
"finding_title": "Unauthenticated exposure of all registered expvars",
"verdict": "INVALID",
"reasoning": "The report claims that the `ExpvarHandler` exposes sensitive operational data to unauthenticated attackers because it does not enforce authentication. To verify this, we must apply the binding threat model rules. The profile is 'library (Reusable library / SDK)'. The rules state: 'Not a vulnerability under this model: ... misuse that violates a documented precondition of the public API' and 'The public API must validate all inputs. Non-public methods may assume invariants verified at the public boundary...'.\n\n1. **Role of the Library**: `swesweep-fasthttp` provides a handler function. It is the responsibility of the application developer (the caller of `ExpvarHandler`) to decide where to mount this handler and whether to wrap it with authentication middleware or host it on a private network. \n2. **Absence of Authentication is by Design**: The library does not claim to provide authentication. It simply serializes `expvar` variables to JSON. Expecting a data-serialization utility to enforce authentication is a violation of the single responsibility principle and is not a security defect in the code itself, but a configuration issue in the host application.\n3. **No Exploitable Bug in the Code**: The code correctly handles the input `r` (regex). While a malicious regex could cause ReDoS, the report specifically flags 'Unauthenticated exposure... including potentially sensitive operational data'. This is an information disclosure risk based on the *deployment* of the endpoint, not a flaw in the *implementation* of the handler. The handler behaves exactly as described in its documentation ('dumps json representation of expvars').\n4. **Verdict**: Since the 'vulnerability' is effectively 'the developer chose to expose this endpoint without auth', and the library itself contains no defect that bypasses a protection mechanism it is supposed to implement (there is no auth mechanism in this package to bypass), this falls under misuse/configuration error, not a code vulnerability. Under the library threat model, the library is not responsible for the security policies of the host application. Therefore, this is not a valid vulnerability in the library code.\n\nCRUX: The library provides a data handler; authentication is the responsibility of the host application, not the library component. Reporting lack of auth in a library handler as a security vulnerability is a configuration/misuse issue, not a code defect.\nGREP: package expvarhandler",
"elapsed": 7.3,
"tokens": 2745,
"tokens_in": 2240,
"tokens_out": 505,
"cost_usd": 0.0024558,
"file": "expvarhandler/expvar.go",
"round": 1,
"grep_used": true,
"grep_results": "GREP `package expvarhandler`:\n```\nexpvarhandler/expvar_test.go:1:package expvarhandler\nexpvarhandler/expvar.go:3:package expvarhandler\n```"
},
{
"finding_title": "Unauthenticated exposure of all registered expvars",
"verdict": "INVALID",
"reasoning": "The reported vulnerability is an 'Unauthenticated exposure of all registered expvars'. Under the specified threat model for a 'library (Reusable library / SDK)', the attacker is defined as code calling the public API and the data passed through it, while the entry point is the public surface. The binding rule explicitly states that 'misuse that violates a documented precondition of the public API' is not a vulnerability. The handler `ExpvarHandler` is a utility designed to dump `expvar` data; it does not document that it performs authentication. It is the responsibility of the host application (the caller) to wrap this handler in authentication middleware or restrict network access if they intend to protect sensitive operational data. The code functions exactly as intended: it receives a context, optionally filters by a regex provided in the query, and outputs the variables. There is no 'bypass' of a security mechanism because no such mechanism exists in the library's scope. Therefore, this is a deployment/configuration issue in the host application, not a security defect in the library code itself.\n\nCRUX: The lack of authentication is a responsibility of the host application (deployment/configuration), not a defect in the library's implementation which simply serializes expvars as documented.\nGREP: func ExpvarHandler",
"elapsed": 4.3,
"tokens": 3188,
"tokens_in": 2917,
"tokens_out": 271,
"cost_usd": 0.00203814,
"file": "expvarhandler/expvar.go",
"round": 2,
"grep_used": true,
"grep_results": "GREP `func ExpvarHandler`:\n```\nexpvarhandler/expvar.go:25:func ExpvarHandler(ctx *fasthttp.RequestCtx) {\n```"
},
{
"finding_title": "Unauthenticated exposure of all registered expvars",
"verdict": "INVALID",
"reasoning": "The report claims an unauthenticated exposure of expvars is a vulnerability in this code. However, the threat model explicitly defines the scope for a library: the attacker is code calling the public API, and 'misuse that violates a documented precondition of the public API' is not a vulnerability. `ExpvarHandler` is a utility function intended to serialize expvars to JSON. It does not claim to provide authentication, authorization, or rate limiting. The responsibility for securing this endpoint (via middleware, network isolation, or access controls) lies with the host application developer who chooses to mount this handler. There is no 'bypass' of a security mechanism in the code because no such mechanism exists in the library's scope. Therefore, the 'vulnerability' is actually a deployment/configuration issue or a misuse of the library, not a code defect. The code behaves exactly as described in its documentation.\n\nCRUX: The handler is a library utility that does not enforce authentication by design; the threat model excludes security issues arising from the host application's configuration or misuse of the public API.\nGREP: package expvarhandler",
"elapsed": 3.9,
"tokens": 3454,
"tokens_in": 3213,
"tokens_out": 241,
"cost_usd": 0.00207246,
"file": "expvarhandler/expvar.go",
"round": 3,
"grep_used": true,
"grep_results": "GREP `package expvarhandler`:\n```\nexpvarhandler/expvar_test.go:1:package expvarhandler\nexpvarhandler/expvar.go:3:package expvarhandler\n```"
},
{
"finding_title": "Unauthenticated exposure of all registered expvars",
"verdict": "INVALID",
"reasoning": "The reported vulnerability is 'Unauthenticated exposure of all registered expvars'. Under the provided threat model for a 'library (Reusable library / SDK)', the attacker is defined as code calling the public API, and specific exclusions apply: 'misuse that violates a documented precondition of the public API' is not a vulnerability. `ExpvarHandler` is a utility function designed to serialize `expvar` data to JSON. The code performs this function exactly as documented ('dumps json representation of expvars'). It does not contain any authentication or authorization logic, nor does it claim to provide such protections. The responsibility to secure this endpoint (via middleware, network isolation, or access controls) lies entirely with the host application developer who chooses to mount this handler on a network-facing interface. Therefore, the 'lack of authentication' is a deployment/configuration issue or a misuse of the library's intended scope, not a security defect (bug) in the library code itself. Since the threat model explicitly excludes misuse/configuration issues and the code behaves as intended without failing to enforce a stated invariant, this finding is INVALID.\n\nCRUX: The lack of authentication is a responsibility of the host application (deployment/configuration), not a defect in the library's implementation which simply serializes expvars as documented.\nGREP: func ExpvarHandler",
"elapsed": 4.5,
"tokens": 3769,
"tokens_in": 3483,
"tokens_out": 286,
"cost_usd": 0.00232086,
"file": "expvarhandler/expvar.go",
"round": 4,
"grep_used": true,
"grep_results": "GREP `func ExpvarHandler`:\n```\nexpvarhandler/expvar.go:25:func ExpvarHandler(ctx *fasthttp.RequestCtx) {\n```"
},
{
"finding_title": "Unauthenticated exposure of all registered expvars",
"verdict": "INVALID",
"reasoning": "The reported vulnerability is that `ExpvarHandler` exposes all registered `expvars` without enforcing authentication, authorization, or rate limiting. The threat model specifies a 'library (Reusable library / SDK)' profile where the attacker is defined as code calling the public API. The binding rules explicitly state that 'misuse that violates a documented precondition of the public API' is not a vulnerability, and that the public API must validate all inputs, but internal helpers may assume invariants. However, in the context of a web server library (fasthttp), providing a handler that serves sensitive operational data (expvars often contain memory stats, request counts, etc.) over HTTP is a standard pattern for internal debugging or metrics endpoints. The responsibility for securing such endpoints (via authentication middleware, network isolation, or access controls) lies with the application developer who mounts the handler. The library itself (`swesweep-fasthttp`) does not claim to provide authentication; it simply serializes the data as documented. There is no code defect, no bypass of an existing security mechanism within the library, and no memory safety issue. The finding describes a deployment or configuration risk (exposing an endpoint without auth) rather than a vulnerability in the library's implementation. Therefore, it is not a security vulnerability in the code itself under the given threat model.\n\nCRUX: The lack of authentication is a responsibility of the host application (deployment/configuration), not a defect in the library's implementation which simply serializes expvars as documented.\nGREP: func ExpvarHandler",
"elapsed": 4.8,
"tokens": 4110,
"tokens_in": 3787,
"tokens_out": 323,
"cost_usd": 0.00255954,
"file": "expvarhandler/expvar.go",
"round": 5,
"grep_used": true,
"grep_results": "GREP `func ExpvarHandler`:\n```\nexpvarhandler/expvar.go:25:func ExpvarHandler(ctx *fasthttp.RequestCtx) {\n```"
}
]Raw scan report for this file
The file is a small fasthttp handler whose only external input is the HTTP query argument `r`. The data flow is:
1. `ExpvarHandler` is called by fasthttp for each request.
2. `getExpvarRegexp` reads `r` from the query string.
3. If `r` is empty, the built-in regex `.` is used, which matches all non-empty expvar keys.
4. If `r` is non-empty, it is compiled directly with `regexp.Compile`.
5. `ExpvarHandler` iterates over all registered expvars using `expvar.Do`, filters keys with the compiled regex, and writes the matched values into an HTTP response.
There are no fixed-size C-style buffers, numeric size constants, or integer overflow paths. The main risks are resource exhaustion, information disclosure, and weak JSON serialization assumptions.
Findings:
- `getExpvarRegexp` accepts an arbitrary regex from the network and compiles it with no length, complexity, or time limit. Go’s RE2 engine avoids exponential backtracking ReDoS, but compilation and automaton construction can still consume significant CPU and memory. An attacker can send very large or complex `r` values to degrade the service.
- `ExpvarHandler` exposes all registered expvars by default and does not perform authentication, authorization, or rate limiting. If the handler is mounted on an externally reachable endpoint, untrusted users can read any expvar registered by the host application.
- `ExpvarHandler` has no bound on the number or size of expvars emitted. If the host registers many variables or variables whose values are large, a request can cause large response allocation and CPU work.
- `ExpvarHandler` inserts `kv.Value` directly into the JSON response. If any registered expvar produces a string that is not a valid JSON value, or if a value is influenced by untrusted input elsewhere, the response may be malformed or allow JSON field injection into consuming clients.
Lower-priority observations not included as findings:
- `ctx` nil would panic, but that is a caller error, not something an external attacker can trigger through the HTTP request surface.
- The error path reflects the user-supplied `r` value in the response. This is input reflection, but fasthttp typically serves safe default content types; this is less impactful than the resource and disclosure issues.
- Write errors from `fmt.Fprintf(ctx, ...)` are ignored, which is common for HTTP response writers and not a direct vulnerability.
```json
[
{
"severity": "medium",
"title": "Uncontrolled regular expression compilation from r query argument",
"function": "getExpvarRegexp",
"description": "The r query argument is converted to a string and passed to regexp.Compile with no length, complexity, or timeout limit. An attacker can send large or crafted patterns to consume CPU and memory, causing denial of service. Go RE2 avoids exponential backtracking, but compilation and automaton construction can still be expensive."
},
{
"severity": "medium",
"title": "Unauthenticated exposure of all registered expvars",
"function": "ExpvarHandler",
"description": "ExpvarHandler serves all registered expvars by default and does not enforce authentication, authorization, or rate limiting. If the handler is mounted on a network-facing endpoint, an unauthenticated attacker can read host metrics or any custom expvars, including potentially sensitive operational data."
},
{
"severity": "low",
"title": "Unbounded expvar response generation",
"function": "ExpvarHandler",
"description": "There is no cap on the number of expvars or the size of their serialized values. expvar.Do iterates every variable and fmt.Fprintf writes all matched values into the response buffer. Numerous or large variables can cause unbounded memory allocation and CPU use per request."
},
{
"severity": "low",
"title": "Raw expvar values inserted into JSON response without validation",
"function": "ExpvarHandler",
"description": "kv.Value is inserted directly into the JSON response without validating that it is a well-formed JSON value. If a registered expvar produces a non-JSON string or a value influenced by untrusted input, the response can become malformed or allow JSON field injection into clients that parse it."
}
]
```