HTTP QUERY Method: The Grey Zone Between GET And POST.

22.9.26  SANS  Hack

In June 2026 the IETF published RFC 10008[1], defining a new HTTP method: "QUERY". The HTTP protocol faced already by changes (HTTP/2, HTTP/3) but it’s the first new standard HTTP verb since "PATCH" in 2010!

This new method sits between “GET” and “POST” and can be resumed like this: “QUERY is a GET with a body”. It's safe and idempotent: the request is processed without state change and can be automatically repeated or restarted without concern for partial state changes. The query itself lives in the request body instead of the URL, and it's explicitly cacheable. Servers advertise the body formats they'll accept via a new “Accept-Query” response header.

If you defend web infrastructure, the interesting part isn't the RFC. The risk is that every control you own that pattern-matches on HTTP methods was written before "QUERY" existed. WAF rules, API-gateway allowlists, CSRF middleware, cache keying, load-balancer method handling is written in terms of a known verb set: GET, POST, PUT, DELETE, PATCH.  Drop a sixth verb that behaves like a hybrid of the first two into that world and each control now has to make a deliberate decision about it. Most of them currently make an accidental one.

And the behaviour in the wild is genuinely inconsistent. Researchers found that nginx's limit_except pattern and Django's View class reject QUERY outright, while curl, FastAPI's explicit routes, Caddy and Traefik pass it through untouched. On caching, one researcher built a QUERY-only API and found nginx forwards it happily and caches it never[2].

Think about this HTTP request:

curl -X QUERY https://target.com/api/search \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "q=' OR 1=1--" -v

If your WAF signatures (SQLi, XSS, command injection) are bound to "POST" bodies but never taught that "QUERY" also carries a body, you get a clean inspection bypass. The test is trivial: send the same malicious payload over "POST" and over "QUERY" and diff the outcome. If the "QUERY" version sails through where the "POST" version gets blocked, that's a live gap, not a theoretical one.

Because "QUERY" is cacheable and safe by spec, caches that don't key on the full request body can be poisoned into serving one user's malicious payload to the next, and CSRF middleware hardcoded to the classic state-changing verbs will wave through any "QUERY" endpoint that carries an unintended side effect.

The new method is not popular yet, here is an overview of what I found:

What can you actually do?

Update your rules/regexes to support the new verb:

http.method in ("GET","POST", "QUERY")

I searched across my HTTP-related logs and found no occurrence of QUERY request but it’s for sure a question of time.

And from a malware point of view? Is there a risk? Most of what a modern SOC actually relies on to catch C2 is behavioral, and behavioral detection doesn't care about the verb:

• Beaconing analysis (RITA/AC-Hunter-style connection-count and interval work), jitter/timing, volume, and flow shape are all method-agnostic. A "QUERY" beacon beacons exactly like a "POST" beacon.

• JA3/JA4 and TLS fingerprinting sit below the HTTP method entirely.

• For HTTPS C2 — which is nearly everything now — the method is inside  the TLS tunnel. A network sensor without interception never sees "GET" vs "POST" vs "QUERY" in the first place, so "QUERY" changes nothing unless you're decrypting.

[1] https://www.rfc-editor.org/info/rfc10008/
[2] https://dev.to/alexgeorgiev17/nginxs-limitexcept-block-silently-rejects-the-new-http-query-method-1gcg