CVE-2024-56528: Snowplow Stream Collector DOS Vulnerability

CVE-2024-56528 Overview

CVE-2024-56528 affects Snowplow Stream Collector versions 3.x prior to 3.3.0. The vulnerability allows unauthenticated remote attackers to send oversized payloads to the Collector, exhausting its capacity to process legitimate requests. Successful exploitation renders the Collector unresponsive and prevents event data from entering the analytics pipeline. Deployments behind a reverse proxy that enforces payload size limits are not affected. The flaw is classified under [CWE-400] Uncontrolled Resource Consumption and carries a network-based attack vector with no privileges or user interaction required.

Critical Impact
Remote attackers can disrupt data collection pipelines by submitting oversized HTTP payloads, causing loss of telemetry and business-critical event data.

Affected Products

Snowplow Stream Collector 3.x prior to 3.3.0
Snowplow open-source deployments without an upstream payload-limiting proxy
Self-hosted Snowplow pipelines relying on the Collector as the ingestion endpoint

Discovery Timeline

2025-04-03 - CVE-2024-56528 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-56528

Vulnerability Analysis

CVE-2024-56528 is a denial-of-service condition rooted in uncontrolled resource consumption within the Snowplow Stream Collector HTTP ingestion path. The Collector accepts inbound tracker events over HTTP or HTTPS and forwards them to a downstream stream such as Kafka, Kinesis, or Pub/Sub. Versions before 3.3.0 do not enforce an upper bound on the size of incoming request payloads at the application layer.

When an attacker submits very large payloads, the Collector consumes memory and processing threads attempting to parse and handle the request. This starves the service of resources needed to process legitimate tracker events. The result is a service that stops accepting new requests, causing event data to be dropped at the network edge.

Because Snowplow Collectors typically sit at the front of analytics pipelines, an outage cascades into downstream enrichment, loading, and reporting systems. Lost events cannot be recovered once the client tracker moves on.

Root Cause

The root cause is the absence of an application-level payload size limit in the Stream Collector request handler. The service trusts the caller to submit reasonably sized events and does not reject oversized bodies before allocating resources to process them. This maps directly to [CWE-400] Uncontrolled Resource Consumption.

Attack Vector

Exploitation requires only network access to the Collector endpoint. An attacker sends one or more HTTP POST requests with an oversized body to the tracker endpoints exposed by the Collector, such as /com.snowplowanalytics.snowplow/tp2 or /i. No authentication, session, or user interaction is required. Repeated submission of large payloads sustains the denial-of-service condition.

No verified proof-of-concept code has been published. The vulnerability is described in the Snowplow Security Update Advisory.

Detection Methods for CVE-2024-56528

Indicators of Compromise

HTTP POST requests to Snowplow Collector tracker endpoints with Content-Length values significantly larger than typical event payloads (normal Snowplow events are under 100 KB).
Sudden spikes in Collector process memory usage, JVM heap pressure, or thread pool saturation.
Client-side tracker retries and 5xx responses from the Collector coinciding with large inbound requests.
Gaps or drop-offs in enriched event volume in downstream Snowplow pipeline stages.

Detection Strategies

Monitor request body size distributions at the reverse proxy or load balancer fronting the Collector and alert on outliers.
Correlate Collector health metrics such as response latency, error rate, and heap usage with inbound payload size logs.
Instrument the Collector with request size histograms exported to your metrics platform to establish a baseline.

Monitoring Recommendations

Forward Collector access logs and infrastructure metrics into a centralized analytics or SIEM platform for correlation with pipeline health.
Alert on sustained periods where the Collector returns non-2xx responses to a significant portion of tracker traffic.
Track downstream stream ingestion rates (Kafka, Kinesis, Pub/Sub) and alert on abrupt drops that suggest an upstream Collector outage.

How to Mitigate CVE-2024-56528

Immediate Actions Required

Upgrade Snowplow Stream Collector to version 3.3.0 or later, which introduces payload size enforcement at the application layer.
If immediate upgrade is not possible, place the Collector behind a reverse proxy or load balancer that enforces a strict maximum request body size.
Review Collector logs and pipeline throughput metrics for signs of prior exploitation and quantify any data loss.

Patch Information

Snowplow addressed CVE-2024-56528 in Stream Collector version 3.3.0. Refer to the Snowplow Security Update Advisory for the full list of fixed versions and upgrade guidance. Open-source users should pull the updated container image or artifact and redeploy across all Collector instances.

Workarounds

Configure NGINX with client_max_body_size set to a conservative value such as 1m in front of the Collector.
Configure an AWS Application Load Balancer or CloudFront distribution with request body size limits and WAF rules that drop oversized POST requests to tracker paths.
Apply rate limiting on Collector endpoints to reduce the impact of repeated oversized submissions from a single source.

bash

# NGINX reverse proxy configuration example
server {
    listen 443 ssl;
    server_name collector.example.com;

    # Reject payloads larger than 1 MB before they reach the Collector
    client_max_body_size 1m;

    location / {
        proxy_pass http://snowplow_collector_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 30s;
    }
}