CVE-2024-45506

What it actually does

A remote flaw in HAProxy 2.9.x before 2.9.10, 3.0.x before 3.0.4, and 3.1.x through 3.1-dev6 permits crafted network traffic to trigger denial of service, typically via crashes or resource exhaustion.

Why it matters to the business

Unexpected service outages and degraded availability for any applications or sites relying on the affected load-balancing component, increasing operational recovery costs.

How an attack unfolds

An unauthenticated remote attacker identifies an exposed HAProxy instance and transmits specially formed requests that exploit the flaw, causing the process to terminate or become unresponsive.

How to fix it

Upgrade HAProxy to 2.9.10, 3.0.4 or later. For pimcore/pimcore deployments, apply the fix present in commit 38a29e2f4f5f060a73974626952501cee05fda73.

How to confirm the fix worked

Confirm running HAProxy versions meet or exceed the fixed releases, review pimcore source for the referenced commit, and perform functional load tests to verify continued operation under malformed traffic.

Typical attack path

1. Scan for publicly reachable HAProxy endpoints
2. Send crafted requests matching the vulnerable code paths
3. Trigger repeated crashes or resource exhaustion
4. Confirm service unavailability to complete the denial-of-service condition

How to detect it

Review HAProxy process and error logs for unexpected restarts or crashes, correlate with spikes in malformed requests, and inspect upstream traffic for patterns that precede outages.

What your security team should do

• Apply the listed fixes or upgrades without delay
• Inventory all deployments that depend on the affected HAProxy versions
• Add network-level rate limiting and request validation in front of load balancers
• Monitor EPSS and KEV updates for any future change in exploit likelihood