HTTP gets a sixth verb, and every allowlist you own was written for five
The IETF published RFC 10008 in June 2026, defining a new HTTP method: QUERY. It is the first new standard verb since PATCH in 2010, and it sits between GET and POST — the SANS Internet Storm Center diary summarises it as "a GET with a body". It is safe and idempotent, so a request can be repeated without partial state changes; the query travels in the body instead of the URL; and it is explicitly cacheable. Servers advertise which body formats they accept through a new Accept-Query response header.
The operational problem is not the RFC. It is that every control that pattern-matches on the method was written when there were five verbs. WAF rules, API-gateway allowlists, CSRF middleware, cache keys, load-balancer method handling — all of them enumerate GET, POST, PUT, DELETE, PATCH. A sixth verb that behaves like a hybrid of the first two forces each of those controls into a decision, and most of them are currently making it by accident.
Behaviour in the wild already disagrees. The diary reports that nginx's limit_except 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 never caches it.
What it means
The risk is not that QUERY is unsafe. It is that your stack disagrees with itself about it. A verb that one layer rejects, another forwards and a third refuses to cache is the classic setup for request smuggling and for controls that are quietly bypassed because they never matched in the first place.
Three checks worth doing this week, in order of how cheaply they pay:
- Send one.
curl -X QUERY https://your-host/your-endpoint -d 'x=1' -vagainst a staging host, through the full chain — CDN, WAF, gateway, app. Write down what each layer did. That is the whole audit, and it takes ten minutes. - Read your method allowlists as enumerations, not as rules. Anywhere the config lists verbs, the list is a snapshot of 2010. Decide explicitly whether QUERY belongs, and if it does not, reject it where you can see the rejection.
- Check the cache. A cacheable method your cache does not understand is either a performance surprise or a correctness one, depending on which way it guesses.
And the part that outlives QUERY: this is what every allowlist does eventually. It encodes the world as it was on the day somebody wrote it, and it keeps enforcing that world silently after the world moves.