In June the IETF published RFC 10008 and handed the web a new verb: QUERY. First standard method since PATCH in 2010. Sixteen years of muscle memory in every firewall rule, WAF policy, and cybersecurity playbook, and now there’s a body-bearing request that wants to be treated like a safe read. That’s the joke. The protocol moved. Your method map didn’t.

SANS called it the grey zone between GET and POST, which is a polite way of saying your request classifiers are about to lie to you. QUERY is a read that carries a body. Search without stuffing a novel into the URL. Every control that assumed “body means mutation” and “safe means no body” just inherited an exception. You will not get a friendly migration wizard from the IETF.

QUERY looks like GET with a suitcase

GET made a promise your architecture internalized. Safe. Cacheable. Idempotent. Parameters live in the query string, which is why you’ve spent a career yelling at people who put secrets in URLs and why your WAFs learned to parse query strings like they were the whole conversation. POST made the opposite promise. Here’s a body. Assume side effects. Log it. Inspect it. Sometimes over-inspect it.

QUERY borrows both. Intent leans GET: you’re asking, not replacing. Shape leans POST: the interesting bits ride in the body because a serious filter or export doesn’t fit in 2,000 characters of URL without breaking caches, logs, and every parser that still truncates at 8K. That’s useful for API designers. It’s a classification bug for anyone whose threat-protection rules still switch on the method token alone.

Watch what that does to assumptions you stopped examining. CSRF defenses that ignore GET and challenge POST. Cache keys that never hashed a GET body. Full-packet inspection that only deserializes POST and PUT. API gateways that allow unknown methods through to “be future proof.” Reverse proxies that normalize QUERY into GET and drop the body, or keep the body and relabel it POST so the app logs a mutation that never happened. Mis-parse is enough. An attacker who can send QUERY against an endpoint you thought was GET-only may skip the signatures you hung on POST /search. Your users will hit it first, when some SaaS SDK quietly starts issuing QUERY and your WAF returns 405 for three hours on a Monday.

Your cybersecurity stack still treats verbs as a closed set

Most cyber security programs still inventory HTTP methods the way they inventory TLS versions: a short list, a policy, a checkbox. GET, POST, PUT, PATCH, DELETE, maybe HEAD and OPTIONS for the people who read the RFC. That list felt complete because it was complete enough for 2015 e-commerce. RFC 10008 just reminded you that the registry was never a lock.

Defense in depth only works if each layer sees the same request. Your edge firewall might default-allow methods it doesn’t recognize, because dropping TRACE that one time taught someone the wrong lesson. The WAF behind it might default-deny, which looks like security hardening until the app team opens a hole for “the new search client.” The SIEM parser in the middle might discard unknown methods as malformed. Clean dashboard. Dirty origin.

Brute-force detections are especially smug about this. They watch POST /login, maybe PUT /token, and call it a day. QUERY against a search, export, or Graph-style endpoint can enumerate records without ever looking like a login storm. Rate limits keyed on POST will yawn at it. If your only stuffing story is 401s on a form, QUERY is already outside the plot.

This is a bad look for teams that bought method-agnostic inspection and then scoped the parser to five verbs to save CPU. The budget line said coverage. The config said GET and POST.

Incident response will feel it next. An analyst opens a pcap, filters on POST, and writes “no malicious requests observed.” The QUERY calls that dumped your customer index sit one filter over, unlabeled, because the parser mapped them to OTHER or dropped them. You can’t hunt what your schema refuses to name.

Do this before QUERY shows up in a ticket

You don’t need a new box. You need an honest method inventory and a decision recorded somewhere other than Slack. Start with the devices that terminate TLS, because that’s where classification actually happens.

• Immediate: dump the allowed-methods list on every reverse proxy, API gateway, WAF, and load balancer. Note what each hop does with an unknown verb: allow, deny, or silently pass. Send QUERY against a canary path in staging and confirm the body is logged, inspected, and attributed to the right app. If any hop strips the body or relabels the method, that’s a finding.
• Immediate: add QUERY to your log schema, SIEM field extraction, and packet-filter profiles. Hunt raw access logs for the token. You’ll find SDK noise, scanners, and at least one vendor who shipped it early.
• Ongoing: treat the HTTP method registry like cipher suites. Review it when you review TLS. New verbs get an explicit allow or deny per application, with an owner. “We’ll allow unknown methods so we don’t break clients” is a hope, not a control.
• Ongoing: fold odd-method spikes into incident response. A burst of QUERY or nonsense verbs against an admin API is reconnaissance. Page it like credential stuffing. Identify the hop that accepted the method, capture the body, revoke the token, and tighten the allowlist on the box that should have refused it.

If a front-end you don’t control starts sending QUERY, fail closed on the sensitive apps and fail loud on the rest. Search endpoints can earn an allow once you’ve confirmed payload limits, authn, and that caches won’t store the body next to someone else’s results. Admin APIs, file exports, and anything sitting behind “the firewall is the real MFA” stay deny until a human says otherwise. Threat detection should match on method plus path plus body shape. A JSON blob on QUERY /api/v2/users is an enumeration whether the verb sounds polite. Cap QUERY bodies the same way you cap POST. Recursion, batch filters, and “export all” are the abuse case. The verb is just the envelope.

npm already taught you this lesson. You filed it.

The same rotting-catalog problem just showed up in a different registry. Researchers tied PhantomRaven, a JavaScript information stealer on npm, to a financially motivated actor who presented like a bug bounty hunter. The package was almost certainly LLM-written: verbose comments, placeholder code, token-analysis patterns that scream autocomplete. Your threat detection did not get a clean YARA gift. You got a polite README and a maintainer story that looked enough like work.

QUERY and PhantomRaven are the same operational failure in different clothes. You treated a list as finished. HTTP methods. Package names. Maintainer reputations. Once the list is “done,” nobody owns the next entry. An LLM can now emit a stealer that comments itself like a tutorial. An RFC can now emit a verb that your WAF still files under “other.” Both skip the controls you built for yesterday’s grammar.

Pin what you install. Log what you allow. When a new method, package, or SDK shows up in prod, that is a change ticket, not trivia. The teams that will get this right are the ones who already hunt for verbs and dependencies that aren’t on the sheet, then force a yes or no before the client library makes the choice for them.

Sources

• HTTP QUERY Method: The Grey Zone Between GET And POST (SANS ISC)
• Claimed Bug Bounty Hunter Likely Used LLM to Build PhantomRaven npm Stealer