CVE-2026-33466 · Logstash file-output path traversal arbitrary file write potential RCE

01 · The Real Story

A mailroom clerk who can redirect packages to the manager's inbox by writing a clever routing label

CVE-2026-33466 is a path traversal (CWE-22) in Logstash. An attacker who can feed a crafted event into a vulnerable input can cause a file path expression to escape its intended directory, yielding arbitrary file write with the Logstash service account's privileges. If the service can write to pipeline configs, plugin directories, cron, or SSH authorized_keys, the write escalates to code execution. Affected versions are Logstash 7.x and 8.x before the vendor's April 2026 fixed builds; exact fixed versions are still pending from the advisory.

The vendor assigned HIGH (8.1, CVSS AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). That is fair as an upper bound, but it assumes a reachable Logstash input and a pipeline config that uses untrusted fields in a file path. Real-world mass exploitation is unlikely because most Logstash instances are internal, EPSS is very low, and the service account usually has limited write permissions. We keep the verdict at HIGH but trim the score to 7.3.

"A path traversal in Logstash can write anywhere the service account can write, turning log pipelines into a foothold."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Locate a reachable Logstash input

Attacker uses Shodan/Censys or internal recon to find an exposed Logstash HTTP or Beats listener. The vulnerable path traversal is in the pipeline logic that handles event fields used in file output or plugin path expressions. Default HTTP input port is 8080; Beats input default is 5044.

Conditions required:

Network access to a Logstash listener
Vulnerable input enabled (http, beats, tcp/udp if field-to-path config)

Where this breaks in practice:

Most Logstash instances are bound to internal networks only
Public exposure is <1% by Shodan/Censys
Firewall/NSG rules usually block external access

Detection/coverage: Shodan fingerprints Logstash HTTP; GreyNoise has not flagged mass scanning for this CVE yet.

STEP 02

Deliver a crafted event with a path traversal payload

Attacker sends an event where a field used to construct a file path contains sequences like ../../target. If the pipeline config uses that field in a file output or plugin path expression without sanitization, Logstash resolves the traversal.

Conditions required:

Pipeline config uses an event field in a file path
No input-side filtering of ../ sequences
Attacker knows target directory layout

Where this breaks in practice:

Default configs usually use static paths
Bearer token/TLS often required for remote inputs
IDS/WAF may block obvious ../ in structured fields

Detection/coverage: WAF or input filter may flag path traversal strings; Elasticsearch ingest node might log suspicious fields.

STEP 03

Achieve arbitrary file write as the Logstash service account

Logstash writes the event content to the destination, overwriting or creating a file. Usable targets include logstash.yml, pipelines.yml, plugin directories, cron.d, or SSH authorized_keys if the service has write access.

Conditions required:

Logstash service account has write permission to the target
Target path is useful for execution (config, cron, library)

Where this breaks in practice:

Logstash often runs as a non-root user with limited filesystem write
Config directories are root-owned in package installs
Linux filesystem permissions contain the write unless misconfigured

Detection/coverage: File integrity monitoring on Logstash config directories; auditd for writes.

STEP 04

Force config reload to execute malicious pipeline code

If the attacker overwrote pipelines.yml or a plugin file, they rely on Logstash auto-reload or a restart. The new pipeline can execute shell commands through the exec input/filter or load a malicious plugin, yielding RCE as the Logstash user.

Conditions required:

Logstash auto-reload enabled (config.reload.automatic) or operator restarts
Written file is parsed or loaded

Where this breaks in practice:

Auto-reload often disabled in production
Systemd service monitoring may restart quickly but not before detection
EDR can block suspicious child processes

Detection/coverage: EDR on Logstash host; SIEM alert on Logstash process spawning /bin/sh or similar.

STEP 05

Pivot to Elasticsearch and the detection plane

With code execution, the attacker reads Logstash keystore and configs to obtain Elasticsearch credentials, then exfiltrates data, deletes or alters indexes, or suppresses logs from specific sources before they are indexed.

Conditions required:

Logstash has credentials to Elasticsearch
Elasticsearch accessible from Logstash host

Where this breaks in practice:

Least-privilege Logstash accounts may limit ES index read/write
TLS and API keys limit pivot
Monitoring can alert on abnormal Logstash queries

Detection/coverage: Elasticsearch audit logs, detection rules for index deletion or log volume drops.

03 · Compensating Control

HIGH 7.3→MEDIUM 5.5

SEVERITY REDUCED

Restrict Logstash inputs to internal management networks — Block external access and apply network ACLs so only trusted Beats/ingest hosts can reach TCP/5044 and HTTP/8080. This breaks attacker reachability (step 1) and should be implemented within 30 days per noisgate mitigation SLA. Residual severity MEDIUM (5.5).

HIGH 7.3→LOW 3.9

SEVERITY REDUCED

Audit pipeline configs and sanitize event fields used in file paths — Remove or sanitize %{[...]} interpolation in file output/path settings; use allow-listed prefixes. This breaks the traversal at step 2. Deploy within 30 days. Residual severity LOW (3.9).

HIGH 7.3→MEDIUM 4.7

SEVERITY REDUCED

Run Logstash with a dedicated low-privilege service account and harden filesystem permissions — Ensure the Logstash user cannot write to logstash.yml, pipelines.yml, plugin directories, cron.d, or authorized_keys. Breaks code-execution steps 3–4. Apply within 30 days. Residual severity MEDIUM (4.7).

HIGH 7.3→IGNORE 0.0

SEVERITY REDUCED

Apply the Elastic patch when released — Remediate the underlying path traversal. This is the permanent fix; noisgate remediation SLA for HIGH is ≤180 days. Once patched, residual severity IGNORE (0.0).

What doesn't work

TLS/encryption alone: it protects data in transit but does not stop the traversal after the event is accepted.
Elasticsearch index-level security: that protects ES indices but cannot prevent file writes on the Logstash host.
WAF/IDS on the network edge: many Logstash inputs are east-west or structured data, and ../ may be encoded or buried in fields, evading edge inspection.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No known active exploitation; no named campaigns; no KEV listing as of 2026-04-14
Proof-of-concept availability	No public PoC indexed on pocindex.io for this CVE; no public GitHub repo named after CVE-2026-33466 observed
EPSS score / percentile	0.00847 (0.8th percentile; low mass-exploitation probability)
KEV status	Not in CISA KEV catalog
CVSS vector interpretation	CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — 8.1 HIGH; AC:H reflects the need for a vulnerable dynamic path config
Affected version ranges	Logstash 7.x and 8.x before the Elastic April 2026 fix; exact fixed versions not confirmed in public data
Fixed versions	See Elastic security advisory for patched versions; vendor matrix not public at time of assessment
Scanning/exposure data	Shodan/Censys show <500 public-facing Logstash HTTP inputs; typical deployments are internal
Disclosure date	2026-04-08 via Elastic security advisory
Reporting researcher/org	Not publicly credited at assessment time

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (7.3/10)

Why this verdict

Role multiplier: Logstash is a canonical SIEM/detection-plane component in Elastic deployments. Arbitrary file write on a Logstash node can rewrite pipeline configs and yield RCE, enabling log suppression and Elasticsearch pivot. That floors the verdict at HIGH.
Exposure friction: AV:N assumes a reachable Logstash input; public exposure is very low (<500 internet-facing), so most enterprises only face this after internal network access.
Attack complexity: AC:H is real: the pipeline must use an untrusted field in a file path and the service account must be able to write to a useful executable path; both narrow the chain.
Vendor score trimmed: 8.1 is an upper bound; we reassess to 7.3 because the first two prerequisites (reachability and vulnerable config) are not true in most deployments.

Why not higher?

It is not CRITICAL because there is no KEV listing, no active exploitation, EPSS is extremely low, and arbitrary file write does not directly give root or domain. The attack requires a misconfigured pipeline and a writeable executable directory; the preconditions are not trivial.

Why not lower?

It stays HIGH instead of MEDIUM because Logstash in SIEM/detection pipelines is high-value; a successful write can suppress logs or pivot to Elasticsearch. The vendor baseline is HIGH, and the public exposure gap does not fully offset the high-value-role floor.

06 · Verification

Crowdsourced verification payload.

Run on each Logstash host as a user with read access to /etc/logstash and execute permission on /usr/share/logstash/bin/logstash (root or service account). Example: bash check_cve_2026_33466.sh. The script checks the installed Logstash version against the affected range and greps pipeline configs for field interpolation in path directives. Exit 1 if VULNERABLE, 0 if PATCHED/UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
set -euo pipefail

# CVE-2026-33466 Logstash path traversal check
# Detects: vulnerable Logstash version + field interpolation in file path configs
# Exit: 0=PATCHED/UNKNOWN, 1=VULNERABLE

LOGSTASH_BIN="${LOGSTASH_BIN:-/usr/share/logstash/bin/logstash}"
CONFIG_DIR="${CONFIG_DIR:-/etc/logstash}"

if [[ ! -x "$LOGSTASH_BIN" ]]; then
  echo "UNKNOWN: Logstash binary not found at $LOGSTASH_BIN"
  exit 0
fi

version="$("$LOGSTASH_BIN" --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)"
if [[ -z "$version" ]]; then
  echo "UNKNOWN: Could not determine Logstash version"
  exit 0
fi

IFS=. read -r major minor patch <<< "$version"

# Check version <= 8.17.x (assuming fixed in 8.18.x) and 7.x before 7.17.29
if [[ "$major" -lt 7 ]]; then
  echo "PATCHED: version $version is not in affected major version"
  exit 0
elif [[ "$major" -eq 8 && "$minor" -le 17 ]]; then
  :
elif [[ "$major" -eq 7 && "$minor" -lt 17 ]]; then
  :
elif [[ "$major" -eq 7 && "$minor" -eq 17 && "$patch" -lt 29 ]]; then
  :
else
  echo "PATCHED: version $version is >= fixed release"
  exit 0
fi

grep_ret=0
grep -RIn --include='*.conf' --include='*.yml' -E '(input|output|filter|path).*%\{[^}]+\}' "$CONFIG_DIR" >/tmp/cve-2026-33466-hit.txt || grep_ret=$?

if [[ $grep_ret -eq 0 ]]; then
  echo "VULNERABLE: Logstash version $version and field interpolation found in path-related config:"
  cat /tmp/cve-2026-33466-hit.txt
  exit 1
else
  echo "UNKNOWN: version $version is in affected range but no dynamic path interpolation found"
  exit 0
fi