CVE-2023-31413

This is a secrets-in-logs problem, not a break-in. Filebeat's httpjson input, when debug logging is turned on, writes the outbound Authorization or Proxy-Authorization header into its own logs — so the very credential Filebeat uses to reach an API ends up sitting in plaintext wherever those logs land. Nothing is executed and nothing is remotely reachable; the flaw is that a token you meant to keep secret leaks into a lower-trust destination.

The score is a genuine 3.3 and the preconditions earn it: an attacker needs local access to the logs, debug logging has to be enabled, and the httpjson input has to be in use with authenticated requests. That's a specific stack of conditions, and debug logging is usually a temporary troubleshooting state, not a standing one. The realistic harm is a captured credential quietly widening a foothold someone already has.

We keep this low and treat it as a hygiene item rather than a patch emergency. The angle that matters is where Filebeat logs get shipped — often into the same centralized logging platform many teams can read — so a leaked API token can travel much further than the host that logged it. Our follow-up is scoped: find Filebeat deployments through 7.17.9 and 8.6.2 using httpjson with debug enabled, and rotate any credential that may have been logged.