> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # HTTP QUERY Method: The Grey Zone Between GET And POST. - URL: https://f4n6.co.uk/security-feed/http-query-method-the-grey-zone-between-get-and-post/ - Published: 2026-09-18T08:54:59.000Z - Updated: 2026-09-18T08:54:59.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary In June 2026 the IETF published RFC 10008, defining QUERY, the first new standard HTTP method since PATCH in 2010\. QUERY is safe and idempotent by specification, carries its query in the request body rather than the URL, and is explicitly cacheable; servers advertise accepted body formats via a new Accept-Query response header. The security exposure is not the method itself but the controls around it: WAF signatures, API-gateway allowlists, CSRF middleware, cache keying and load-balancer method handling were all written against a fixed verb set of GET, POST, PUT, DELETE and PATCH, and most will make an accidental decision when a QUERY request arrives. Testing described in the source shows a clean WAF inspection bypass is achievable today by moving a SQL injection payload from POST to QUERY, and cache implementations that do not key on the full request body can be poisoned into serving one user's payload to another. No exploitation of QUERY has been observed in the author's HTTP logs as of 2026-09-18, so this is a hardening gap to close before adoption grows, not an active campaign. EMEA financial services clients running internet-facing APIs behind WAFs, API gateways and CDNs are the impacted population. ## 2\. Regulatory framing No specific DORA/NIS2 article is directly engaged by this item. This is a proactive control-gap advisory with no incident, no exploited vulnerability and no third-party failure; a generic mapping to incident management or testing articles would be compliance-checkbox padding. Clients who choose to treat the WAF and cache-keying gaps as findings from DORA Art. 24 (digital operational resilience testing, general requirements) may do so, since the source supplies a concrete test procedure, but the trigger is a client decision to test, not a fact distinctive to this item. ## 3\. Technical analysis & attack chain There is no confirmed attack chain: the source describes a capability gap and a proof-of-concept test, not observed exploitation. The steps below are the attack path the source demonstrates as viable. 1. Attacker identifies an endpoint that accepts a body-carrying method and sits behind a WAF whose SQLi, XSS and command-injection signatures are bound to POST bodies. 2. Attacker sends the malicious payload over QUERY instead of POST. The source's example request is `curl -X QUERY https://target.com/api/search -H "Content-Type: application/x-www-form-urlencoded" -d "q=' OR 1=1--" -v`. 3. The WAF does not inspect the QUERY body because its rules were never taught that a sixth verb carries one, and the payload reaches the backend uninspected. 4. Separately, where a cache in front of the endpoint serves QUERY responses but does not key on the full request body, a response generated for one user's request can be served to a different user whose request hashes to the same cache key, poisoning the cache. 5. Separately again, CSRF middleware hardcoded to the classic state-changing verbs (POST, PUT, DELETE, PATCH) applies no CSRF protection to a QUERY endpoint that carries an unintended side effect, so a cross-site request to that endpoint is waved through. The verification test is the actionable part: send the same malicious payload over POST and over QUERY to the same endpoint and diff the outcomes. If the QUERY version is not blocked where the POST version is, the gap is live in that environment. This is a single-sourced finding from one SANS Internet Storm Center diary entry; the underlying component behaviours are attributed to named researchers but we have not independently corroborated them, so verify in your own stack before enforcing. Component behaviour, as reported in the source: | Layer | Component | QUERY behaviour | | --------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Clients | curl | Works today via \-X QUERY | | Clients | Node.js/fetch (server-side), Python (httpx, requests), Go net/http, Rust reqwest | Arbitrary method strings already accepted, so QUERY works between internal services now | | Browsers | fetch()/XHR | Can send it, but QUERY is not CORS-safelisted, so it always triggers an OPTIONS preflight; browser HTTP cache should not be assumed to cache QUERY responses yet | | Clients/servers | .NET 10 | First-class support out of the box | | Clients/servers | HTTP.jl (Julia) | Merged June 2026, client and server, with retries, redirect handling and Accept-Query | | Proxies | nginx | Proxies it, never caches it; four identical QUERY requests hit the backend four times where four POSTs hit it once; the limit\_except pattern silently rejects QUERY | | Proxies | Caddy, Traefik | Pass it through untouched | | Servers | Apache | Needs config adjustment to recognise the method and handle OPTIONS/CORS | | Frameworks | FastAPI | Explicit routes pass it through | | Frameworks | Django | The View class rejects it outright | | Frameworks | Spring (Java) | Maintainers deliberately scoping support down to teaching the framework that QUERY exists, pending adoption feedback | | CDN | Cloudflare, Akamai | Co-authored the RFC; edge/CDN support expected to lead framework support, but reliable at-scale QUERY caching is not there yet | Two second-order effects follow from the table. First, the nginx caching behaviour means QUERY traffic bypasses any cache-based load shedding: a flood of identical QUERY requests reaches the origin every time, which is a denial-of-service consideration for origins that assumed cacheable lookups would be absorbed upstream. Second, the split between components that reject QUERY (nginx limit\_except, Django View) and components that pass it through (Caddy, Traefik, FastAPI explicit routes) means the same request can be blocked at one layer and forwarded at another, so defenders cannot assume a single choke point handles it. On malware and C2, the source assesses the risk as low. Behavioural C2 detection (connection-count and interval analysis, jitter, volume, flow shape) is method-agnostic, so a QUERY beacon beacons exactly like a POST beacon. JA3/JA4 TLS fingerprinting sits below the HTTP method entirely. For HTTPS C2, the method is inside the TLS tunnel and a network sensor without interception never sees it, so QUERY changes nothing unless traffic is being decrypted. We concur with that assessment and note it is the author's judgement, not a measured result. ## 4\. Mitigation & containment ### P1, within 24 hours - Inventory which of your edge components terminate or inspect HTTP: WAF, API gateway, CDN, load balancer, reverse proxy. For each, determine from vendor documentation or a lab test whether it inspects QUERY bodies, rejects QUERY, or forwards it uninspected. The source's component table above is a starting point, not a substitute for testing your own versions and configurations. - Run the differential test against your internet-facing endpoints: same payload, POST versus QUERY, diff the WAF verdict. Any endpoint where QUERY passes and POST blocks is a live inspection gap; treat it as a WAF rule defect. - Add explicit QUERY handling to WAF and API-gateway method rules rather than relying on a default allow. The source's suggested form is `http.method in ("GET","POST","QUERY")` extended to your full expected verb set; anything not in the set should be denied by default at the edge. ### P2, within 72 hours - For caches and CDNs in front of body-carrying endpoints, confirm whether QUERY responses are cached and, if so, whether the cache key includes the full request body. If body keying cannot be confirmed, disable QUERY caching at that layer until it can be. - Review CSRF middleware configuration for any endpoint that could accept QUERY, and extend CSRF protection to cover it rather than only the classic state-changing verbs. - If you run nginx with limit\_except, be aware it silently rejects QUERY; confirm whether silent rejection is the behaviour you want at that layer, and make it an explicit decision either way. If you run Apache, apply the config adjustment the source says is needed for method recognition and OPTIONS/CORS handling. ### P3, within 7 days - Add QUERY to HTTP method allowlists in logging and detection content so the verb is visible if it appears, and alert on QUERY requests arriving at endpoints not designed to serve them. The author reports zero QUERY occurrences across their HTTP logs as of publication, so any appearance in yours is currently anomalous and worth investigating on that basis. - Track adoption in your dependency stack: .NET 10 has first-class support and Spring is deliberately scoping its implementation down pending feedback, so internal services may begin speaking QUERY before your edge controls are ready. Confirm internal service-to-service traffic that already permits arbitrary method strings (Node.js, Python httpx/requests, Go net/http, Rust reqwest) is not exposing QUERY to untrusted networks. - Re-run the P1 differential test after each WAF, gateway or CDN rule update, since vendor updates may change QUERY handling without announcement. ## 5\. Indicators of compromise No indicators of compromise available in the source material. This advisory describes a control gap, not an observed intrusion, and the source contains no domains, IPs, hashes or other atomic indicators. Behavioural indicators: | Behaviour | Where to observe | Confidence | | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | QUERY-method requests arriving at endpoints not designed to serve them | WAF, API gateway, reverse proxy and web server access logs, filtered on HTTP method | Moderate; the source author reports no QUERY occurrences in their logs, so presence is anomalous by current baseline | | Identical QUERY requests repeatedly reaching origin without cache absorption | nginx and origin access logs; compare request counts for QUERY versus POST to the same endpoint | Moderate; four identical QUERY requests hitting the backend four times is reported nginx behaviour | | WAF verdict divergence between POST and QUERY carrying the same payload | WAF logs, when running the POST-versus-QUERY differential test | High for the test itself; this is the source's own verification procedure | ## 6\. Detection The source contains no file artefacts, command-line flags, mutexes, registry keys or malware strings, so a YARA rule is not applicable. HTTP method values are not threat artefacts in themselves and a rule matching the string QUERY would fire on legitimate traffic and vendor documentation, not on an attack. For network and proxy logging, the source supports one detection: QUERY requests are currently rare enough that their appearance is worth alerting on. The following Sigma rule fires on any QUERY-method request recorded in web server or proxy logs. It is a visibility rule, not a malicious-activity rule; treat hits as triage input. ```yaml title: HTTP QUERY method request observed id: 7c1f2a44-8e3b-4d19-9f6a-2b5c8d1e0f47 status: experimental description: > RFC 10008 (June 2026) defines the QUERY HTTP method. As of September 2026 the method is not in observed use (the source author reports zero occurrences in their HTTP logs), so any appearance warrants review. Many WAF and gateway controls do not inspect QUERY bodies, so hits should be checked against the endpoint's intended verb set. references: - https://isc.sans.edu/diary/rss/33352 - https://www.rfc-editor.org/info/rfc10008/ author: Adverse Trace date: 2026-09-18 logsource: category: webserver detection: selection: http.method: 'QUERY' condition: selection falsepositives: - Legitimate early adoption of RFC 10008 by APIs or internal services - .NET 10 services using first-class QUERY support level: low ``` ## 7\. Sources - SANS Internet Storm Center, Xavier Mertens (@xme), "HTTP QUERY Method: The Grey Zone Between GET And POST.", https://isc.sans.edu/diary/rss/33352, 2026-09-18 - IETF, RFC 10008 information page, https://www.rfc-editor.org/info/rfc10008/, referenced by the primary source, publication June 2026 - dev.to, alexgeorgiev17, "nginx's limit\_except silently rejects the new HTTP QUERY method", https://dev.to/alexgeorgiev17/nginxs-limitexcept-blocks-silently-rejects-the-new-http-query-method-1gcg, referenced by the primary source as the basis for the nginx caching and limit\_except findings ## 8\. Adverse Trace position We assess this as a medium-severity hardening advisory for EMEA financial services clients with internet-facing APIs, and low severity for everyone else: the gap is real and demonstrable with a trivial test, but there is no observed exploitation, the method has near-zero prevalence in the wild, and C2 relevance is assessed as minimal because behavioural detection and TLS-layer fingerprinting are method-agnostic. The single-sourced nature of the component behaviour findings is the main caveat: the nginx, Django, Caddy, Traefik, FastAPI and Apache behaviours come from one diary entry citing individual researchers, so clients should verify against their own versions before treating any row of the table as fact. We will monitor for QUERY appearing in client telemetry, for WAF and CDN vendor advisories on QUERY body inspection, and for the first public report of QUERY-based inspection bypass or cache poisoning in the wild, and we will reissue this advisory with an updated severity if any of those occur. --- [Read the original source →](https://isc.sans.edu/diary/rss/33352?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*