Back to Intelligence

IETF RFC 10008 HTTP QUERY Method: Defending the Grey Zone Between GET and POST

SA
Security Arsenal Team
September 20, 2026
12 min read

In June 2026, the IETF published RFC 10008, formally defining a new HTTP method: QUERY. It is the first new standardized HTTP verb since PATCH arrived in 2010 — and that fact alone should get every defender's attention. For sixteen years, our web security stack has been built, tuned, and tested against a closed set of methods. WAF rules, reverse proxy allowlists, API gateway policies, SIEM parsing pipelines, and SOC detection content all carry implicit assumptions about which verbs are legitimate. A new method lands squarely in the grey zone: semantically it behaves like a safe, read-only GET, but operationally it carries a request body like a POST — and that combination breaks a surprising number of security controls.

This is not a CVE. There is no patch. The risk here is architectural: attackers are extremely good at finding the seams between what a protocol allows and what a security stack inspects. The QUERY method is a brand-new seam. This post walks through what QUERY actually does, where it creates defensive blind spots, and how to hunt, detect, and harden before exploit frameworks start shipping modules for it.

Technical Analysis

What the QUERY Method Actually Is

RFC 10008 defines QUERY as a safe and idempotent method — like GET — but one that accepts a request body to express the query parameters. The motivating problem is real: complex queries (large filter sets, GraphQL-style payloads, geospatial searches) routinely blow past URI length limits when encoded into a GET query string. Developers worked around this for years by abusing POST for read-only searches, which breaks caching, breaks idempotency assumptions, and pollutes CSRF and safe-method logic. QUERY formalizes the workaround: the semantics of GET, the body of POST.

Key properties defenders must internalize:

  • Safe/idempotent by specification — but safety is a semantic contract, not an enforced property. Server implementations can do anything with it.
  • Carries a request body — typically a structured query document. That means SQL injection, NoSQL injection, XPath injection, template injection, and deserialization attacks now have a new, standards-sanctioned delivery vehicle.
  • Cacheable in principle — caches must incorporate the body into cache keys, which historically is where cache poisoning and cache deception bugs live.
  • New parsing surface everywhere — every HTTP parser, proxy, WAF engine, and logging agent that never expected a body on a 'safe' method now has edge cases.

Where the Defensive Grey Zone Forms

  1. Method allowlists. Many organizations enforce verb restrictions at the reverse proxy or WAF (allow GET POST HEAD; deny everything else). Others explicitly deny only known-dangerous methods (TRACE, TRACK, PUT, DELETE). The first group silently blocks QUERY (availability impact for legitimate apps); the second group silently permits it with zero inspection. Both are failure modes — the second is the dangerous one.

  2. Body-inspection bypass. A large fraction of WAF deployments only parse request bodies for POST/PUT/PATCH. If QUERY passes through the method filter, its body may reach the application completely uninspected — a direct injection-bypass primitive against apps that adopt QUERY for search endpoints.

  3. Logging gaps. Apache, NGINX, IIS, and most cloud load balancer logs capture method, URI, and status — but body-aware logging and SIEM field extraction for a brand-new verb often fails open. CEF/Syslog parsers with hardcoded method lists may drop or mangle QUERY events entirely. Your SOC may be blind to these requests on day one.

  4. Cache deception and poisoning. Intermediaries that cache responses to 'safe' methods without properly keying on the QUERY body can serve one user's query results to another — a data-leak primitive — or be poisoned with attacker-controlled cached content.

  5. CSRF and cross-site assumptions. Controls that treat GET-like methods as non-state-changing may extend trust to QUERY endpoints that developers implement with side effects (because developers routinely violate the spec).

Exploitation Status

As of this writing, QUERY is a newly standardized method with no CVEs, no KEV entries, and no confirmed in-the-wild campaigns — adoption across frameworks, proxies, and WAF engines is just beginning. That is precisely the window in which defenders should act. Every major HTTP evolution (HTTP/2 request smuggling, HTTP/3 parser differentials) produced a wave of exploitation after standardization and before security tooling caught up. Expect security researchers to publish parser-differential and WAF-bypass findings against QUERY implementations throughout 2026 and 2027.

Detection & Response

The goal today is visibility and control, not signature detection of a known exploit. You need to know: (a) is QUERY reaching your infrastructure at all, (b) is anything inspecting it, and (c) is your application layer doing something dangerous with it.

Sigma Rules

These rules assume web server / WAF / proxy logs are ingested into a Sigma-capable pipeline. They are intentionally scoped to the QUERY method — volume should be near zero today, so any hit is investigation-worthy rather than noise.

YAML
---
title: HTTP QUERY Method Observed in Web Server Logs
id: 3f8c2a71-9d4e-4b6a-a521-7e0d1c4b8f92
status: experimental
description: Detects use of the new HTTP QUERY method (RFC 10008) in web server access logs. QUERY is newly standardized and rarely seen in production; any occurrence warrants verification that the destination application and upstream WAF/proxy intentionally support and inspect it.
references:
  - https://isc.sans.edu/diary/rss/33352
  - https://www.rfc-editor.org/rfc/rfc10008.html
author: Security Arsenal
date: 2026/09/18
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-method|upper: 'QUERY'
  condition: selection
falsepositives:
  - Legitimate applications that have adopted RFC 10008 QUERY for search endpoints
level: low
---
title: HTTP QUERY Method Targeting Sensitive or Administrative Endpoints
id: 8a1e5b34-2c7f-4d9e-b638-4f5a2d7c9e31
status: experimental
description: Detects RFC 10008 HTTP QUERY requests directed at administrative, authentication, or API endpoints. Attackers may abuse the new method to bypass WAF body-inspection rules that only cover POST/PUT/PATCH, delivering injection payloads to endpoints that would otherwise be inspected.
references:
  - https://isc.sans.edu/diary/rss/33352
  - https://www.rfc-editor.org/rfc/rfc10008.html
author: Security Arsenal
date: 2026/09/18
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_method:
    cs-method|upper: 'QUERY'
  selection_uri:
    cs-uri-stem|contains:
      - '/admin'
      - '/api/'
      - '/login'
      - '/auth'
      - '/search'
      - '/query'
      - '/graphql'
      - '/internal'
      - '/manage'
  condition: all of selection_*
falsepositives:
  - Legitimate RFC 10008 implementations exposing search/query endpoints
level: medium
---
title: HTTP QUERY Method With Injection Patterns in URI or Referer
id: c47d9f02-6a3b-4e8c-9145-2b6e8d3a7f40
status: experimental
description: Detects RFC 10008 HTTP QUERY requests whose URI contains common injection probes (SQL, template, or path traversal sequences). Because QUERY bodies may bypass WAF body inspection tuned for POST, attackers may probe reflectively via URI parameters first to map application behavior.
references:
  - https://isc.sans.edu/diary/rss/33352
author: Security Arsenal
date: 2026/09/18
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_method:
    cs-method|upper: 'QUERY'
  selection_probe:
    cs-uri-query|contains:
      - 'UNION SELECT'
      - 'union%20select'
      - '../'
      - '..%2f'
      - '{{'
      - '${'
      - '<script'
      - '%3Cscript'
      - ' OR 1=1'
      - '%27%20OR'
  condition: all of selection_*
falsepositives:
  - Authorized vulnerability scanning and penetration testing
level: high

KQL — Microsoft Sentinel

This query hunts across WAF/proxy logs ingested via CEF/Syslog (CommonSecurityLog), Azure Application Gateway / Front Door WAF diagnostics, and native web server syslog. Because QUERY is new, any hit is worth a look — but the query also enriches with response codes and source reputation context to help triage.

KQL — Microsoft Sentinel / Defender
let timeframe = 24h;
union isfuzzy=true
    (CommonSecurityLog
     | where TimeGenerated > ago(timeframe)
     | where RequestMethod =~ "QUERY"
     | project TimeGenerated, SourceIP, RequestURL, RequestMethod, DeviceAction, DeviceVendor, DeviceProduct, ReceivedBytes, SentBytes),
    (Syslog
     | where TimeGenerated > ago(timeframe)
     | where SyslogMessage has "QUERY /"
     | project TimeGenerated, HostIP, Computer, SyslogMessage, SeverityLevel),
    (AzureDiagnostics
     | where TimeGenerated > ago(timeframe)
     | where Category in ("ApplicationGatewayAccessLog", "FrontdoorAccessLog", "AzureFirewallApplicationRule")
     | where httpMethod_s =~ "QUERY"
     | project TimeGenerated, clientIP_s, requestUri_s, httpMethod_s, httpStatus_d, ruleName_s, Category)
| extend SourceIP = coalesce(SourceIP, clientIP_s, HostIP)
| summarize Requests = count(), DistinctTargets = dcount(coalesce(RequestURL, requestUri_s, SyslogMessage)) by SourceIP, bin(TimeGenerated, 1h)
| where Requests > 0
| sort by Requests desc

Velociraptor VQL

For IR scoping or proactive hunts, this artifact pulls QUERY-method requests directly out of web server access logs on Linux hosts — useful when you suspect a server is receiving QUERY traffic but your central logging pipeline isn't parsing the new verb yet.

VQL — Velociraptor
-- Hunt for RFC 10008 HTTP QUERY requests in web server access logs
-- Adjust glob patterns to match your log layout (IIS: C:\inetpub\logs\LogFiles\**\*.log)
LET logs = SELECT FullPath FROM glob(globs=[
    '/var/log/nginx/access*.log',
    '/var/log/nginx/*access*.log',
    '/var/log/apache2/access*.log',
    '/var/log/apache2/*access*.log',
    '/var/log/httpd/access*_log'
])

SELECT FullPath,
       Line,
       parse_string_with_regex(string=Line,
           regex='^(?P<ClientIP>[0-9.]+).*\[(?P<Timestamp>[^\]]+)\] "QUERY (?P<URI>[^ ]+) HTTP/[^"]+" (?P<Status>[0-9]+)') AS Parsed
FROM foreach(row=logs,
    query={
        SELECT FullPath, Line
        FROM parse_lines(filename=FullPath, accessor='file')
        WHERE Line =~ '"QUERY '
    })

Remediation / Validation Script

Run this against your external-facing endpoints to determine (1) whether your edge stack accepts QUERY at all, (2) whether your WAF inspects its body, and (3) whether your origin servers are logging it. Pair with a WAF policy audit.

Bash / Shell
#!/bin/bash
# HTTP QUERY (RFC 10008) exposure validation - Security Arsenal
# Usage: ./query_method_audit.sh example.com

TARGET="${1:?Usage: $0 <hostname-or-url-base>}"
BASE="https://${TARGET}"

echo "[*] Auditing ${BASE} for HTTP QUERY method handling"
echo "========================================================"

echo ""
echo "[1] Baseline: does the edge accept QUERY at all?"
curl -s -o /dev/null -w "  Status: %{http_code} | Size: %{size_download}\n" \
  -X QUERY "${BASE}/" -H "Content-Type: application/query" -d '{"q":"healthcheck"}'

echo ""
echo "[2] WAF body-inspection test: QUERY with benign SQLi probe in body"
echo "    (Compare against same probe via POST - if POST is blocked and QUERY is not, you have an inspection gap)"
echo "  -- via QUERY:"
curl -s -o /dev/null -w "  Status: %{http_code}\n" \
  -X QUERY "${BASE}/search" -H "Content-Type: application/json" \
  -d '{"q":"'"'"' OR 1=1--"}'
echo "  -- via POST (control):"
curl -s -o /dev/null -w "  Status: %{http_code}\n" \
  -X POST "${BASE}/search" -H "Content-Type: application/json" \
  -d '{"q":"'"'"' OR 1=1--"}'

echo ""
echo "[3] Method enumeration: which verbs does the edge accept?"
for METHOD in GET POST PUT PATCH DELETE OPTIONS TRACE CONNECT QUERY; do
  CODE=$(curl -s -o /dev/null -w "%{http_code}" -X "${METHOD}" "${BASE}/" --max-time 10)
  echo "  ${METHOD}: ${CODE}"
done

echo ""
echo "[4] Local log check (run on origin servers): recent QUERY requests"
if [ -d /var/log/nginx ] || [ -d /var/log/apache2 ] || [ -d /var/log/httpd ]; then
  grep -h '"QUERY ' /var/log/nginx/*access*.log /var/log/apache2/*access*.log /var/log/httpd/*access*log 2>/dev/null | tail -20
else
  echo "  No standard web log directories found on this host."
fi

echo ""
echo "[*] Interpretation:"
echo "  - QUERY returning 2xx/3xx while WAF only inspects POST = body-inspection bypass risk"
echo "  - QUERY returning 405/501 = method rejected (safe default, but verify apps that need it)"
echo "  - Log hits with QUERY = confirm the request was intentional and inspected end-to-end"

Remediation

There is no patch for a protocol feature — remediation means deliberate policy instead of accidental exposure. Prioritize the following:

  1. Make an explicit allow/deny decision on QUERY at every enforcement point. Reverse proxies, API gateways (Kong, Apigee, AWS API Gateway, Azure APIM), WAFs (ModSecurity/CRS, cloud WAFs), and CDN edge rules should all carry an explicit QUERY stance. The secure default for organizations with no RFC 10008 adoption is deny — add it to the blocked-methods list alongside TRACE/TRACK. In NGINX-style configs this means verifying your limit_except / method-validation logic doesn't silently pass unknown verbs; in cloud WAFs, add a custom rule matching httpMethod == "QUERY".

  2. If you adopt QUERY, extend body inspection to it. Update WAF rulesets so the body-parsing and attack-signature phases apply to QUERY exactly as they do to POST/PUT/PATCH. For ModSecurity/OWASP CRS, verify REQUEST_METHOD is not used as a gate that skips body rules for non-POST methods. Test with a known-bad payload delivered via QUERY and confirm it is blocked.

  3. Fix the logging pipeline before you need it. Verify your SIEM parsers (CEF, Syslog, IIS/advanced logging, load balancer schemas) actually capture and normalize the QUERY verb — many hardcoded method lists will drop or misclassify it. Add a parser test case and a low-fidelity detection (the Sigma rules above) so the first QUERY request you see isn't the attacker's.

  4. Audit intermediary caching. If QUERY responses pass through CDNs or shared caches, confirm the cache key includes the request body where appropriate, or disable caching of QUERY responses entirely until vendor support is documented. Cache-key confusion on a safe method is a cross-user data-leak vector.

  5. Track vendor implementation advisories. Watch for security advisories from your framework (Express, Django, Spring, ASP.NET, Rails), proxy (NGINX, HAProxy, Envoy), and WAF vendors as they add QUERY support through 2026–2027 — parser differentials between layers are the most likely source of the first QUERY-related CVEs, mirroring the HTTP/2 request-smuggling wave.

  6. Add QUERY to your threat model and pen-test scope. Any application adopting QUERY for search/query endpoints should receive injection, deserialization, and authorization testing specifically over the new method — do not assume test coverage from POST-based endpoints carries over.

Executive Takeaway

QUERY is a legitimate, useful protocol addition — and exactly the kind of protocol change that creates exploitable seams between what the network allows and what security controls inspect. The organizations that get hurt won't be the ones running broken software; they'll be the ones whose WAF inspected POST bodies, whose SIEM parsed six verbs, and whose proxy allowed anything it didn't recognize. Close that grey zone now, while QUERY traffic is rare enough that every occurrence is worth an analyst's eyes.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

managed-socmdrsecurity-monitoringthreat-detectionsiemhttp-query-methodrfc-10008waf-bypassweb-securityietf

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.

Book a SOC AssessmentSee AlertMonitor in Action