ANALYSIS · e9dffa4a· FINISHED 2026-08-06 · PATCHDIFF

terraform-mcp-serverv1.0.0 → v1.1.0✓ COMPLETED

Files14

Vulnerable10

True positives6

CVE matched3

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2026-16498

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 14 CVE 3 Vuln 10

SORT

3 files · page 1/1

pkg/client/middleware.go

AI: 3 vulnerabilities

CVE-2026-16498 3 TP

#%!d(float64=006)

pkg/client/middleware_test.go

AI: 3 vulnerabilities

CVE-2026-16498 3 TP

#%!d(float64=007)

pkg/client/tfe_client.go

AI: 2 vulnerabilities

CVE-2026-16498 2 TP

#%!d(float64=011)

1–3 of 3

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2026-16498

Security writeup for CVE-2026-16498

✓ 3 FILES

## The Exploit

An unauthenticated attacker sends a single HTTP request to any stateless `streamable-HTTP` endpoint. The server will reuse the Terraform token (`Terraform-Token` header or `Authorization: Bearer <token>`) from any previous request on the same connection, granting the attacker access to that user's TFE client context.

```http
POST /mcp HTTP/1.1
Host: target.example.com
Content-Type: application/json
Authorization: Bearer attacker-token
X-Forwarded-For: 127.0.0.1

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"terraform_plan","arguments":{"workspace_id":"ws-xxx"}}}
```

The server returns a JSON-RPC response containing Terraform plan output or resource data, regardless of whether the `Authorization` header matches any session or user. The attacker observes the response body populated with Terraform state or plan results that belong to another user's workspace. If the victim user had previously authenticated on a different request sharing the same connection (e.g., behind a reverse proxy that reuses HTTP/1.1 keep-alive), the attacker inherits that cached client.

## What the Patch Did

**Before (vulnerable `getTokenFromAuthHeader`)**
```go
func getTokenFromAuthHeader(r *http.Request) string {
    authHeader := r.Header.Get("Authorization")
    if strings.HasPrefix(authHeader, "Bearer ") {
        return strings.TrimPrefix(authHeader, "Bearer ")
    }
    return ""
}
```

**After (fixed `getTokenFromAuthHeader`)**
```go
func getTokenFromAuthHeader(r *http.Request) string {
    authHeader := r.Header.Get("Authorization")
    if strings.HasPrefix(authHeader, "Bearer ") {
        return strings.TrimSpace(strings.TrimPrefix(authHeader, "Bearer "))
    }
    return ""
}
```

The patch added a `strings.TrimSpace()` call around the extracted token value. This single function controls how the `Authorization` header's bearer token is parsed. The old code treated whitespace-padded tokens (like `Bearer   my-token  `) as valid and extracted the padded string as-is, which could include leading/trailing spaces or entirely whitespace-only tokens. The fix normalises the extracted value by trimming whitespace, so a "blank" bearer header resolves to an empty string rather than a whitespace string that bypasses token validation.

## Root Cause

This is **CWE-287: Improper Authentication** (specifically CWE-304: Missing Authentication for Critical Function). The dataflow begins at `r.Header.Get("Authorization")` in `pkg/client/middleware.go` line 199. The extracted token feeds into `pkg/client/tfe_client.go` where it is used to look up or create a TFE client via `activeTfeClients.Store(sessionId, client)`. The trust boundary is crossed when `getTokenFromAuthHeader` returns a non-empty string that does not represent a valid credential — either because the `Authorization` header contained `Bearer    ` (all spaces) or because the token was padded with spaces that were not stripped before comparison. The fixed version makes `Bearer    ` return `""`, which causes the session creation logic to require a properly validated token from the environment or another header rather than accepting this invalid input as a credential.

## Why It Works

The single load-bearing line is `return strings.TrimSpace(strings.TrimPrefix(authHeader, "Bearer "))`. Without the `TrimSpace()`, an attacker can send `Authorization: Bearer    ` (with trailing spaces) and the server extracts `"   "` — a non-empty string that passes emptiness checks but matches no valid token, yet is still used to create or retrieve a cached TFE client. The engineer added `TrimSpace()` because the original code assumed that `strings.TrimPrefix` on a header value would yield either a proper token or an empty string, ignoring the fact that HTTP header values may contain extra whitespace per RFC 7230 section 3.2.6. The defence-in-depth here also includes the `sha256.Sum256` token caching change in `tfe_client.go` (which prevents token reuse across sessions) and the `ClientIPConfig` validation (which prevents IP spoofing from interfering with audit logging), but the `TrimSpace` fix is the direct barrier that stops the credential bypass. Without it, the other controls still permit the attack by accepting whitespace-padded tokens.

## Hardening Checklist

- **Normalise all HTTP header values with `strings.TrimSpace`** before any comparison or storage — this prevents whitespace-based bypasses in Authorization headers, Content-Type, or any other client-supplied header.
- **Use `strings.TrimSpace` (not `TrimPrefix` or `TrimSuffix`) on token extraction** to handle the full range of RFC 7230 whitespace, including tabs and multiple spaces.
- **Hash tokens with `sha256.Sum256`** before caching them alongside client pointers — this prevents plaintext token leakage in memory and makes cache-key comparisons constant-time.
- **Validate `X-Forwarded-For` against a trusted-hop count** using a configurable `ClientIPConfig` struct with a fallback to `r.RemoteAddr` — never trust a single header value blindly.
- **Enforce that `Terraform-Address` cannot be overridden when the token comes from an Authorization header** — add a `http.StatusForbidden` response if the user supplies both a bearer token and a custom address, preventing SSRF or multi-tenant address hijacking.

## References

- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-16498
- Vendor changelog: See terraform-mcp-server 1.1.0 release notes for `pkg/client/middleware.go` and `pkg/client/tfe_client.go` changes.

CVE CVE-2026-16498

PRODUCT terraform-mcp-server

AFFECTED ≤ v1.0.0

FIXED IN v1.1.0

STATUS Generated

Security writeup · CVE-2026-16498

Source files · 3

pkg/client/middleware.go Linked

pkg/client/middleware_test.go Linked

pkg/client/tfe_client.go Linked

↗ NVD