Summary
Envoy's ext_authz filter can dereference a missing request path when processing authorization responses that add or remove query parameters. An unauthenticated downstream client may trigger an Envoy process crash when the deployment accepts path-less CONNECT requests and enables this query-parameter mutation behavior.
Affected context
The issue occurs in Envoy deployments that use the ext_authz filter with query-parameter mutation configured in authorization responses. Exploitation is relevant when the listener accepts path-less CONNECT requests, because these requests do not provide the :path pseudoheader expected by the filter. Deployments that reject such requests or do not use query-parameter mutation may not reach the vulnerable code path.
Exploit preconditions
- Attack surface: An Envoy downstream listener processing HTTP requests
- Required access: Ability to send unauthenticated requests to the affected listener
- Trigger point: Processing a path-less CONNECT request while applying query parameters from an authorization response
- Required configuration: The ext_authz filter must be enabled and configured to add or remove query parameters
- Why exploitation is possible: The filter assumes that a request path exists and dereferences a null path value when parsing the query string
Why this happens
The underlying bug is insufficient validation of an optional request component before dereferencing it. For path-less CONNECT requests, the request path accessor can return null, but the ext_authz completion logic treats the result as present while applying query-parameter mutations. This maps primarily to CWE-476: NULL Pointer Dereference, with CWE-20: Improper Input Validation also applicable because an unusual but valid request shape is not safely handled.
Potential impact
- The Envoy process may crash
- Active connections handled by the affected process could be disrupted
- A client could repeatedly trigger service instability
- Downstream services may experience availability degradation
- An affected proxy instance could become unavailable until it is restarted or replaced
General mitigation guidance
Mitigation generally focuses on ensuring that request metadata is validated before it is consumed and that absent values follow a safe, non-crashing path.
Common defensive patterns include:
- Checking whether the request path exists before parsing or modifying query parameters
- Treating path-less CONNECT requests explicitly according to deployment policy
- Rejecting unsupported request forms at a trusted boundary when they are not required
- Limiting ext_authz response mutation to validated, schema-conforming inputs
- Running multiple proxy instances with health checks and controlled restart or replacement behavior
- Applying least-privilege and resource-isolation controls to reduce the effect of a proxy compromise or repeated crash condition
Maintainers should also use a vendor-provided release containing the relevant corrective change rather than relying only on perimeter filtering.
How teams detect issues like this
Detection can combine configuration review, runtime telemetry, and source analysis.
Useful approaches include:
- Searching Envoy configuration for ext_authz query-parameter mutation settings
- Reviewing listener behavior for acceptance of path-less CONNECT requests
- Adding regression tests covering CONNECT requests without a :path pseudoheader
- Monitoring proxy crash loops, abnormal restarts, and elevated error rates
- Correlating downstream request patterns with Envoy process termination events
- Using static analysis or automated code review rules to flag unchecked optional pointer or accessor results before dereference
- Enforcing configuration policies that require explicit handling of unsupported HTTP request forms
