Why this matters now

In June 2026 the IETF published RFC 10008, standardising a new HTTP method: QUERY. It is designed to behave like GET — safe (no server-side state change) and idempotent (safe to retry) — while carrying a request body the way POST does, so complex queries no longer have to be crammed into a URL.

That is a genuinely useful gap in HTTP to fill. It is also, right now, a gap most security tooling doesn't know exists. WAF rules, reverse-proxy routing, framework middleware, and load-balancer policies written before June 2026 were built around an implicit assumption: state-changing, body-carrying requests are POST/PUT/PATCH/DELETE, and GET is safe and body-less. QUERY breaks that assumption cleanly in half — safe like GET, body-carrying like POST — and a method allowlist written six months ago has no reason to mention it.

Five concrete abuse vectors

1. WAF inspection gaps. Rule sets tuned to inspect POST/PUT bodies for injection payloads, and to treat GET as low-risk, may simply not apply body inspection to QUERY at all — or may pass it through a GET-shaped code path that never looks at the body. A payload that would be caught on POST can ride through unexamined on QUERY.

2. Cache poisoning. Caches conventionally key on URL (plus select headers) because GET requests don't carry meaningfully varying bodies. QUERY requests do. A cache that keys on URL alone, and starts caching QUERY responses because it looks GET-like and safe, can be poisoned: an attacker sends a QUERY with a malicious body to a cacheable endpoint, and subsequent legitimate requests to the same URL are served the attacker's cached response.

3. CSRF blind spots. CSRF middleware commonly assumes only POST/PUT/DELETE can change state and exempts GET-like methods from token checks. If an endpoint implements a side effect behind QUERY — even inadvertently, by reusing a handler written for POST — that endpoint may be reachable without a CSRF token, because the framework filed QUERY under "safe."

4. CORS and preflight handling. Browsers, frameworks, and CDNs need to agree on how QUERY triggers (or doesn't trigger) CORS preflight. Where components in the chain disagree — one treats it as a "simple request," another requires preflight — the result is either broken legitimate traffic or a bypass of the preflight check that was supposed to gate cross-origin access.

5. Request smuggling. Front-end and back-end components that parse QUERY requests differently — one honouring the body, another treating it as GET-equivalent and ignoring it, or disagreeing on where the body ends — reopen the same class of front-end/back-end desync bugs that HTTP request smuggling has always exploited, this time with a method most smuggling detection tooling has never been tested against.

Why this is worse than a typical new-feature gap

None of these five vectors require a bug in QUERY's specification. They fall out of the mismatch between what QUERY actually is (safe and body-carrying — a combination no prior standard method had) and what every downstream security control assumed a safe method looks like (no body worth inspecting). The vulnerability, such as it is, lives in the gap between components, not in any one of them — which is exactly the kind of issue that's easy for a single team to miss because no individual component is "wrong" in isolation.

Defender checklist

• Differential-test your WAF. Send the same payloads via POST and via QUERY to the same endpoints and diff the outcomes. Any payload that's blocked on POST but passes on QUERY is a rule-set gap, not a false negative to shrug off.
• Audit cache-key construction. Confirm your CDN/reverse-proxy cache keys incorporate full-body hashing for QUERY, not just URL and headers. If QUERY responses are being cached at all, verify that decision was deliberate.
• Re-read CSRF middleware for hardcoded method lists. if method in ['POST', 'PUT', 'DELETE'] style checks need QUERY added explicitly wherever the endpoint can have a side effect — including handlers repurposed from an existing POST route.
• Verify load balancer, reverse proxy, and framework QUERY support end to end, not just at the origin. A component that silently downgrades or drops QUERY can produce a working-in-testing, broken-or-bypassed-in-production surprise.
• Validate CORS preflight behaviour for QUERY across every hop — browser, CDN, application server — rather than assuming consistency.
• Check request-smuggling detection tooling for QUERY coverage. Most existing desync-testing tooling predates this method; confirm it's actually exercising QUERY paths, not silently skipping them.

What this doesn't mean

This is not a claim that RFC 10008 is unsafe, or that QUERY shouldn't be adopted. It's a straightforward consequence of introducing a new method into an ecosystem full of components that made reasonable-at-the-time assumptions about the closed set of methods they'd ever see. The fix is inventory and testing, not avoidance — teams that adopt QUERY deliberately and audit the chain end to end will generally be in a better position than teams that never adopt it but leave default method-handling behaviour unexamined, since frameworks and proxies may start accepting QUERY on upgrade regardless of whether an application intentionally uses it.

Evidence-led coverage with Eresus Guard

Method-level gaps like this are exactly the kind of finding that's easy to verify once and then silently drift out of date as proxies, frameworks, and WAF rule sets get upgraded independently. Eresus Guard's DAST and configuration checks can be pointed at QUERY-specific test cases across an asset inventory, with the evidence — what was tested, on which component, with which result — kept in one reviewable record instead of a one-time Slack message. Explore the Eresus Guard workspace or plan a scoping call.

Sources

• RFC 10008: The New HTTP QUERY Method and the Attack Surface Still Catching Up — Hive Security