Envoy Gateway is a popular open-source project, letting you manage Envoy Proxy as either a standalone service or as a gateway in Kubernetes. It’s widely used for controlling ingress traffic to applications—in other words, it sits in front of your web apps, handling every incoming request.

But if you're running a version prior to 1.2.7 or 1.3.1, you should know:
There was a log injection vulnerability (CVE-2025-25294) that could let attackers tamper with your access logs by crafting special HTTP headers, such as the User-Agent. This isn’t just noisy—it can poison your logs, mess up your analytics, or even trick downstream log consumers into bad data or actions.

What Happened? (Plain English)

Earlier versions of Envoy Gateway set up access logging using a default text-based config. This log takes pieces of the incoming HTTP request and writes them straight into the log file, such as IP address, path, and User-Agent.

Problem:
If someone sends a nasty User-Agent value—one that uses JSON control characters or line breaks—Envoy Proxy was just dumping that straight into its logs, as is.

Attackers could make your log files contain extra, fake fields, or even break their format entirely. This is log injection.

Security tools misfire: Alerts may not fire or may generate noise.

- Potential hidden persistence: If other automation relies on logs, this could be a chain of attack.

Suppose your default access log line looks like this

{"start_time":"2024-06-01T12:34:56Z","method":"GET","path":"/foo","user_agent":"<user-agent>","status":200}

If an attacker sends this header

User-Agent: attacker" ,"fake_field":"hacked

…the log line output will look like

{"start_time":"2024-06-01T12:34:56Z","method":"GET","path":"/foo","user_agent":"attacker" ,"fake_field":"hacked","status":200}

See what happened? The attacker injected a new field: "fake_field":"hacked".

Worse, someone could even insert a line break (if the log parser doesn't sanitize) and inject a *whole* new log line.

Here’s a simple curl command you can use to simulate an attack

curl -H 'User-Agent: attacker","is_admin":"true' https://your-envoy-gateway-url/

After the request, your access logs could end up looking like this (if you haven’t patched)

{"start_time":"2024-06-04T12:00:00Z","method":"GET","path":"/","user_agent":"attacker","is_admin":"true","status":200}

Or even (if line breaks are allowed)

{"start_time":"2024-06-04T12:00:00Z","method":"GET","path":"/","user_agent":"attacker"}
{"is_admin":"true"}

How to Fix (and How it Was Fixed)

Good news: The fix is simple.
Update to Envoy Gateway 1.2.7 or 1.3.1 or later.

What changed? From 1.2.7+ and 1.3.1+, the default access log now uses a JSON formatter, which properly escapes values.

You can also mitigate by customizing your logging config to use JSON and not raw %REQ(USER-AGENT)% strings.

How?

Modify your Envoy Gateway deployment’s EnvoyProxy.spec.telemetry.accessLog settings. Here’s an example YAML spec:

spec:
  envoyProxy:
    telemetry:
      accessLog:
        format:
          type: JSON
          fields:
            start_time: "%START_TIME%"
            method: "%REQ(:METHOD)%"
            path: "%REQ(:PATH)%"
            user_agent: "%REQ(USER-AGENT)%"
            status: "%RESPONSE_CODE%"

This makes sure all special characters are *escaped* rather than blindly injected.

References

- Envoy Gateway Release Notes – GitHub
- CVE-2025-25294 – NVD entry
- Envoy Docs: Access Logs
- Security Advisory

Review your logs for suspicious User-Agents or extra injected fields.

Bottom line:
If you’re running Envoy Gateway before 1.2.7/1.3.1 and haven’t set up JSON logging, your access logs could be vulnerable to data manipulation.
Update now, double-check your configs, and keep your logs (and downstream automation) trustworthy.


*Feel free to share or adapt this post to keep your team or community secure.*

Timeline

Published on: 03/06/2025 19:15:27 UTC