CVE-2026-32641: Parseable Log Analytics Platform DOS Vulnerability

CVE-2026-32641 Overview

CVE-2026-32641 is a denial-of-service vulnerability in Parseable, a log analytics platform designed for high-volume data ingestion and analysis. Versions prior to 3.0.0 use unwrap() in src/handlers/http/middleware.rs when parsing the x-amz-firehose-common-attributes header before authentication runs. A remote unauthenticated attacker can send non-UTF-8 header data, malformed JSON, or invalid derived header values to trigger a Rust panic. Repeated requests interrupt request handling, deny service to legitimate clients, and can drive containerized deployments into restart loops. The issue is fixed in Parseable version 3.0.0 and is classified under CWE-248: Uncaught Exception.

Critical Impact
Unauthenticated remote attackers can crash Parseable request handling with a single malformed HTTP header, producing a sustained denial of service and container restart loops.

Affected Products

Parseable log analytics platform, all versions prior to 3.0.0
Deployments exposing the ingest HTTP endpoint that processes x-amz-firehose-common-attributes
Containerized Parseable instances subject to restart loops on process crash

Discovery Timeline

2026-09-18 - CVE-2026-32641 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-32641

Vulnerability Analysis

The vulnerable code path lives in the Actix middleware that rewrites headers for AWS Kinesis Firehose ingestion. Before authentication executes, the middleware reads the x-amz-firehose-common-attributes header and calls unwrap() on three fallible operations: converting the header bytes to a UTF-8 string, deserializing JSON into a Message struct, and constructing HeaderValue instances from the extracted authorization and stream-name fields.

Each unwrap() panics on failure. In Actix Web, a panic inside a middleware future aborts the worker handling the request and, depending on runtime configuration, terminates the process. Because the middleware runs prior to authentication, no credentials are required to reach the vulnerable branch. An attacker sends repeated requests with crafted headers, forcing continuous panics and container restarts.

Root Cause

The root cause is the use of unwrap() on attacker-controlled input in unauthenticated middleware. The header value, its UTF-8 validity, its JSON structure, and the character set of embedded fields are all controlled by the client. Any deviation from the expected shape causes an uncaught panic rather than a graceful HTTP error.

Attack Vector

Exploitation requires only network access to the Parseable HTTP ingest endpoint. The attacker submits an HTTP request containing an x-amz-firehose-common-attributes header populated with non-UTF-8 bytes, malformed JSON, or a JSON payload whose authorization or x_p_stream fields contain characters invalid for HTTP header values. Repeated requests sustain the outage.

rust

// Patch: replace unwrap() with fallible let-chains and gate on Action::Ingest
// Source: https://github.com/parseablehq/parseable/commit/6c583081a4161476128f330b9bb71ed7305eecde

if self.action.eq(&Action::Ingest)
    && let Some(kinesis_common_attributes) =
        req.request().headers().get(KINESIS_COMMON_ATTRIBUTES_KEY)
    && let Ok(attribute_value) = kinesis_common_attributes.to_str()
    && let Ok(message) = serde_json::from_str::<Message>(attribute_value)
    && let Ok(auth_value) =
        header::HeaderValue::from_str(&message.common_attributes.authorization)
    && let Ok(stream_name_key) =
        header::HeaderValue::from_str(&message.common_attributes.x_p_stream)
{
    req.headers_mut()
        .insert(HeaderName::from_static(AUTHORIZATION_KEY), auth_value);
    req.headers_mut().insert(
        HeaderName::from_static(STREAM_NAME_HEADER_KEY),
        stream_name_key,
    );
}

The fix replaces every unwrap() with an Ok(...) pattern in a let-chain, so malformed input falls through instead of panicking. See the GitHub commit for the full change.

Detection Methods for CVE-2026-32641

Indicators of Compromise

Repeated HTTP requests to Parseable ingest endpoints carrying an x-amz-firehose-common-attributes header from unauthenticated sources
Parseable process crash logs containing Rust panic messages referencing middleware.rs and unwrap()
Container orchestrator events showing rapid restart loops or CrashLoopBackOff states for Parseable pods

Detection Strategies

Alert on Parseable worker exits and panic stack traces referencing the Kinesis Firehose header parsing path
Correlate spikes in 5xx responses or dropped connections with inbound requests carrying the x-amz-firehose-common-attributes header
Baseline expected Firehose ingest sources and flag requests bearing that header from unexpected IP ranges

Monitoring Recommendations

Track Parseable container restart counts and process uptime metrics to identify sustained crash loops
Forward Parseable stdout and stderr to centralized logging to capture panic backtraces
Monitor HTTP ingest error rates and request latency at the reverse proxy or load balancer fronting Parseable

How to Mitigate CVE-2026-32641

Immediate Actions Required

Upgrade Parseable to version 3.0.0 or later, which replaces the panicking unwrap() calls with fallible pattern matching
Restrict network access to the Parseable ingest endpoint to trusted Firehose sources until the upgrade is complete
Review container orchestrator alerts for existing restart loops that may indicate active exploitation

Patch Information

The fix is delivered in Parseable 3.0.0. Review the GitHub Security Advisory GHSA-x4q9-j9qh-3rpx, the pull request #1581, and the v3.0.0 release notes. The patch also gates the middleware branch on Action::Ingest, reducing the surface exposed to unauthenticated traffic.

Workarounds

Place a reverse proxy in front of Parseable and strip or reject requests containing the x-amz-firehose-common-attributes header from untrusted clients
Enforce network policies limiting ingest endpoint reachability to known Firehose egress addresses
Apply rate limiting at the proxy layer to slow crash-inducing request floods until the upgrade is applied

bash

# Example: block untrusted sources from setting the vulnerable header at an NGINX proxy
location / {
    if ($http_x_amz_firehose_common_attributes != "") {
        set $trusted 0;
        # Allowlist Firehose CIDRs here, e.g.:
        # if ($remote_addr ~ ^203\.0\.113\.) { set $trusted 1; }
        if ($trusted = 0) { return 403; }
    }
    proxy_pass http://parseable_upstream;
}