hunting-search-engine-injection

name	hunting-search-engine-injection
description	Hunt injection into search and analytics engines such as Elasticsearch, OpenSearch, and Solr where untrusted input reaches a query DSL body, a query-string or Lucene query, a script field, or a stored scripting expression. Covers request data that becomes query structure (a filter clause, a field selector, an aggregation) rather than a bound term, a raw query-string parameter whose Lucene syntax the caller controls, and script injection through inline or stored scripts that run in the engine. Use when an application forwards user input into a search cluster as query JSON, a query string, or a script. The untrusted value that becomes query or script structure is the source, the search or script call is the sink, and the missing field allowlist or the enabled dynamic script is the bug.
license	MIT

Hunting search-engine injection: when a search query is attacker-shaped

Search and analytics engines take rich structured queries, and applications frequently build those queries from user input. The injection surface has three shapes. First, the query DSL body: when a request object is merged into the query JSON, the attacker can add filter clauses, select fields the caller was not meant to read, or attach aggregations that reveal data across the index. Second, the raw query string: a query_string or Lucene query parameter exposes operators, field selectors, and wildcards, so a caller who controls it can query fields and ranges outside the intended scope. Third, scripting: inline or stored scripts run inside the engine, and untrusted input reaching a script is code execution in the cluster. You find these by separating bound search terms from query structure and scripts, and tracing untrusted input into the latter.

When to use

• An application forwards user input into a search or analytics cluster as query JSON or a query string.
• A request object is merged into the query DSL, or a raw Lucene/query-string parameter is caller-controlled.
• Inline or stored scripts run in the engine and untrusted input can reach a script or its parameters.

Scope check

Test search-engine injection only against clusters and applications you own or are authorized to assess, on non-production data. A confirming query or script can read across indices or run code in the cluster, so stay inside the authorized boundary. If you can't name the authorization, stop.

The loop

1. Establish the query and script sinks and split them. Inventory every search call and separate the parts that bind a search term from the parts that carry structure: the query DSL body, field and index selectors, aggregations, raw query-string parameters, and inline or stored scripts. This is the false-positive killer: a query that binds the user's term into a fixed match clause over a fixed field is not injectable. Name the structure-carrying and script sinks first.

2. Trace untrusted input into the query DSL body. Follow request objects merged into the query JSON. If the caller can add clauses, choose the field to match, or attach an aggregation, they can read beyond the intended documents and fields. Confirm whether the query is assembled from a fixed template with the term bound, or built by merging an untrusted object.

3. Trace untrusted input into raw query strings. A query_string, simple_query_string, or Lucene query parameter exposes the full query syntax: field selectors, ranges, wildcards, and boolean operators. If the raw parameter is caller-controlled, the caller can query fields and documents outside scope even without touching the JSON structure. Confirm whether the raw syntax is exposed or the term is bound into a constrained query.

4. Trace untrusted input into scripts. Inline scripts, stored-script parameters, and script fields run in the engine. Untrusted input concatenated into a script body is code injection; untrusted input as a script parameter is safe only if the script body is fixed. Confirm whether dynamic scripting is enabled and whether any script body is built from input.

5. Check the defenses that actually stop it. Binding the user term into a fixed query template, allowlisting the fields and indices the caller may select, avoiding query_string in favor of a constrained match query, disabling inline dynamic scripts, and using stored scripts with bound parameters each remove a vector. A per-request field or index restriction enforced by the application, not just by a convention, is what holds. Determine which stands at the sink.

6. Confirm and record. Confirm by supplying an in-scope input that changes the query's reach, selecting a field or an index outside the intended scope, or, where scripting is exposed, a script that returns a distinguishing result, without exfiltrating out-of-scope data. Kill the lead if the user term is bound into a fixed template, if field and index selection is allowlisted, if raw query-string syntax is not exposed, and if dynamic scripting is disabled. Record the input, the sink, and the change in the query's reach.

Where search-engine injection leaks

• A merged request object becomes query structure. Merging user JSON into the query DSL lets the caller add clauses and pick fields; bind the term into a fixed template instead.
• query_string exposes the whole query language. A raw Lucene parameter hands the caller field selectors and ranges, so a search box becomes a cross-field query tool.
• Field and index selectors are authorization boundaries. If the caller chooses the field or index, they read data the endpoint was scoped to hide; allowlist both.
• Scripts run in the cluster. Inline dynamic scripts built from input are code execution; stored scripts with bound parameters are the safe form.
• The engine has no per-user document security by default. Application-level scope is the only boundary unless document-level security is configured, so a widened query reads everything the service can.

Worked example (a confirm and a kill)

Confirm. A search endpoint merges the request body into the query DSL to support flexible filters. A crafted body adds a clause selecting a field the endpoint was meant to exclude and an aggregation over it, returning aggregated values of a sensitive field across the index. The response confirms field-selection injection. Confirmed search-engine query injection to cross-field disclosure, high, remediation = build the query from a fixed template that binds only the user's search term, and allowlist the fields, indices, and aggregations the endpoint may use.

Kill. The endpoint binds the user term into a fixed match query over an allowlisted field set on a fixed index, never exposes query_string, and dynamic inline scripting is disabled cluster-wide with only stored scripts taking bound parameters. A crafted body cannot add clauses, choose a field, or run a script. Killed, kill_reason = "user term bound into a fixed template over allowlisted fields and indices, no raw query-string exposed, inline scripting disabled; no untrusted value becomes query or script structure."

Rationalizations to reject

• "We pass the search term straight through." → If it enters as raw query_string or as merged JSON, the caller controls query structure, not just the term. Bind it into a fixed template.
• "The engine is internal." → The application scope is the only per-user boundary by default; a widened query reads across the index regardless of network placement.
• "We only allow filtering." → An attacker-chosen filter field or aggregation is exactly the disclosure vector; allowlist which fields and aggregations are permitted.
• "Scripts are convenient for scoring." → Inline dynamic scripts from input are code execution; use stored scripts with bound parameters and disable inline scripting.
• "There is no sensitive data in search." → Field and index selection can reach adjacent indices and fields the endpoint never intended to expose; confirm the allowlist, do not assume the contents.

Executing this in practice

You need every search call split into term-binding and structure-carrying parts, the script sinks, the untrusted inputs that reach each, and the field/index allowlist and scripting configuration. For each structure-carrying sink, ask whether the caller can add clauses or pick fields and indices; for each script sink, whether input reaches a script body. Reading the query construction shows the intent; selecting an out-of-scope field or running a distinguishing script shows whether the boundary holds.

Related

• hunting-nosql-operator-and-where-injection - the document-store sibling; both let a request object become query structure rather than a bound value.
• hunting-orm-and-query-builder-injection - the same value-versus-structure line applied to relational mappers.
• auditing-graphql-attack-surface - a query API is a common source of the filter and field objects that land in these search sinks; trace the two together.
• adjudicating-taint-paths - use it to confirm an untrusted field reaches the query DSL, a raw query string, or a script through framework indirection.
• FINDING-SCHEMA.md - source = the untrusted value that becomes query or script structure, sink = the search or script call, evidence = the change in the query's reach.