Skip to main content
CVE-2026-48710VulnerabilityPublished Updated

Mcp google sheets: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based

Affects Kludex mcp-google-sheetsSource GCVE Database

0
Authoritative record:CVE-2026-48710· Medium 6.5

Exploited in the wild · KEV due 16 Sep 2026 · public detection template (Nuclei) · 70% EPSS : upgrade to 0.6.3_1 now.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
6.5Medium
How severe the flaw is on the 0–10 CVSS scale.
KEV deadline
 US federal agencies must patch by this date; a sensible deadline for everyone else. Other KEV due dates
EPSS
70.2% chance of exploitation in 30 days – higher than 99% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 0.6.3_1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Exploitation evidence

t = 0 is the CVE’s publication on cve.org

  1. Disclosed: evidence found.

    CVE published 26 May 2026

  2. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  3. Exploited in the wild: evidence found.

    Listed in CISA KEV 99 days after disclosure

  4. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

Timeline

  1. CVE ID reserved

    by GitHub, Inc.

    , 4 days before disclosure

  2. CVE published

    on cve.org

    , t = 0

  3. In Threat Radar

    record ingested

    , 24 minutes after disclosure

  4. , 99 days after disclosure

  5. KEV remediation due

    US federal deadline

    , 113 days after disclosure

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), CISA KEV (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Kludex mcp-google-sheets to 0.6.3_1.

Affected software

ProductAffectedFixed in
Homebrewmcp-google-sheetspkg:brew/mcp-google-sheetsOther threatsAffected
  • >=0.5.1 <0.6.3_1
Fixed in
  • 0.6.3_1

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

### Summary In affected versions, the HTTP `Host` request header was not validated before being used to reconstruct `request.url`. Because the routing algorithm relies on the raw HTTP path while `request.url` is rebuilt from the `Host` header, a malformed header could make `request.url.path` differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on `request.url` (rather than the raw `scope` path) could therefore be bypassed. ### Details When a client requests `http://example.com/foo`, it sends: ```http GET /foo HTTP/1.1 Host: example.com ``` Affected versions reconstructed the URL by concatenating `http://{host}{path}` and re-parsing the result. The `Host` value is only valid as a `uri-host [ ":" port ]` per [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6), where `uri-host` follows the restricted `host` grammar of [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2). When it contains characters outside that grammar - notably `/`, `?`, or `#` - those characters move the path/query/fragment boundaries during re-parsing, so the parsed `request.url.path` no longer matches the path the server actually received. For example: ```http GET /foo HTTP/1.1 Host: example.com/abc?bar= ``` reconstructs to `http://example.com/abc?bar=/foo`, whose parsed `path` is `/abc` - even though routing used the real path `/foo`. The router still dispatches to `/foo` and the endpoint executes, but any middleware or code that reads `request.url.path` sees `/abc`, so path-based authorization checks can be bypassed. ### Impact Any application running an affected version that relies on `request.url` (or `request.url.path`) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on `request.url.path`. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed `Host` header before forwarding and the application does not trust attacker-controlled host headers (e.g. `X-Forwarded-Host`) elsewhere. ### Mitigation Upgrade to a patched version, which validates the `Host` header against the grammar of [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6) / [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2) when constructing `request.url` and falls back to `scope["server"]` for malformed values.

References

Community reviews

Loading reviews…