HAProxy CVE-2025-11230 DoS: Mitigate mjson Numeric Parsing

HAProxy Technologies has published an advisory for CVE‑2025‑11230, a high‑severity denial‑of‑service flaw rooted in an Inefficient Algorithm Complexity (CWE‑407) in the embedded mjson JSON parser; specially crafted JSON payloads that include extremely large numeric values can trigger pathological parsing behavior in the mystrtod routine and cause HAProxy processes to hang or be terminated by the watchdog, effectively taking reverse proxy and ingress services offline until patched.

Background / Overview​

HAProxy is a widely deployed open‑source and commercial load balancer and reverse proxy used to protect and scale web applications. Many HAProxy features accept and inspect JSON payloads—most notably the sample fetch functions used in ACLs and routing decisions such as json_query, jwt_header_query, and jwt_payload_query. When those functions call into the lightweight mjson parser, they inherit any parsing weaknesses present there. HAProxy’s advisory confirms that CVE‑2025‑11230 affects deployments that use those JSON parsing functions and that the only reliable mitigation is upgrading to fixed HAProxy builds. This advisory follows an earlier disclosure about the underlying mjson parser’s mystrtod routine (tracked as CVE‑2023‑30421) that described similar inefficient numeric parsing behavior for maliciously constructed digit strings. In the mjson context that issue required an enormous number of iterations to convert pathological numeric inputs, and the same algorithmic root cause is being exploited within HAProxy to create a practical, network‑accessible DoS. Why this matters: HAProxy is positioned at the edge of many production networks; a DoS of the proxy itself is not merely a local outage but a direct availability impact on all backend applications. The flaw’s reach is widened because the trigger is a network‑accessible JSON input in common sample fetches—no authentication or special privileges are required for a hostile actor to craft and send exploit payloads. Public vulnerability trackers and vendor advisories assign a CVSSv3 base score of 7.5 (High) for this CVE.

---

Technical analysis​

The root cause: inefficient numeric parsing in mjson​

At the center of CVE‑2025‑11230 is an algorithmic weakness in the mjson library’s numeric conversion routine (commonly referenced as mystrtod). Some implementations of string‑to‑double conversion optimise for common cases but degrade catastrophically for specially formatted numeric strings (for example, extremely long mantissa/exponent combinations). When fed such inputs, the conversion routine can spin for a large number of iterations or allocate disproportionately, creating CPU and scheduling pressure. The original mjson item (CVE‑2023‑30421) documented an input that required billions of iterations to parse; HAProxy’s use of mjson exposes that behavior over the network. Key technical points:

• The vulnerability is a classic algorithmic complexity problem (CWE‑407), not a buffer overflow or memory corruption. The code is correct on normal inputs but has a worst‑case that is exploitable.
• The exploit vector is a JSON value that looks like a number but is structured to force the parser into the worst performance path (examples include extremely large exponent notation like 1e1000000000000000 or crafted digit strings).
• In HAProxy, the runtime effect is that the worker handling the request spends far longer than expected parsing the JSON, triggering the watchdog or starving worker threads and causing process restart or service disruption.

Why HAProxy magnifies the impact​

A low‑severity or local‑only weakness in a library can become high impact depending on context. HAProxy’s configuration allows JSON sampling to influence routing, ACLs, and JWT inspection—all features commonly evaluated on incoming requests at the proxy layer. Because HAProxy forwards network requests and often runs with minimal latency budgets, a slow path inside JSON parsing directly maps to failing front‑end availability: the proxy’s watchdog kills and restarts processes to protect resources, but that restart itself causes downtime and connection loss for clients. Several security analyses emphasize that algorithmic DoS against a front‑end proxy yields outsized operational damage compared to the same bug in a background library.

---

Affected builds and vendor remediation​

HAProxy’s advisory enumerates fixed versions across community and enterprise branches. Operators should treat these fixed builds as the canonical remediation and plan immediate upgrades:

• HAProxy Community Edition fixed versions: 2.4.30, 2.6.23, 2.8.16, 3.0.12, 3.1.9, 3.2.6.
• HAProxy Enterprise and ALOHA appliances have matching fixes listed in the vendor advisory; HAProxy also released patched container/image tags for Kubernetes Ingress Controller lines.
• Distribution maintainers (for example Debian) have tracked the CVE and published package fixes/mappings; Debian’s tracker shows fixed package revisions mapped to the CVE and identifies the Git commit used to repair the behavior in the HAProxy source tree. This is useful for package‑based rollouts.

Important note: HAProxy’s fix was implemented by privately forking or embedding a more efficient numeric conversion routine inside its mjson copy (rather than waiting for an upstream library release). The vendor also reported the issue to the upstream mjson maintainer, but as of public advisories the upstream mjson project did not yet ship a universal fixed release. Multiple vulnerability databases (Snyk, Recorded Future) reference the upstream CVE history and note the lack of an upstream mjson patch at time of reporting. Operators that depend on separate mjson packages (binaries or embedded in other products) should therefore verify upstream status independently.

---

Practical attack scenarios and impact assessment​

Realistic attack flow​

1. An attacker crafts an HTTP request with a JSON body or header containing a deliberately malformed numeric value (long mantissa/exponent) designed to trigger the slow numeric parse path.
2. The request hits an HAProxy instance configured to evaluate JSON via sample fetches like json_query, jwt_header_query, or jwt_payload_query.
3. The HAProxy worker thread spends an excessive amount of CPU time parsing the numeric value; the internal watchdog detects stuck workers and restarts the process or kills the worker thread to recover.
4. While the attacker continues to hammer the proxy with further crafted requests, the watchdog restarts cannot keep up and service availability degrades or stops entirely.

Blast radius & consequences​

• Edge proxies, API gateways, ingress controllers and Kubernetes Ingresses that place HAProxy in front of many services are high‑impact targets: one exploited proxy instance can render dozens of backend services unreachable.
• Stateful connections and in‑flight requests may be disrupted when the watchdog restarts workers; clients experience dropped or failed requests, and automated systems may interpret this as backend failure leading to route flapping or cascading failover.
• The vulnerability is network accessible and does not require authentication—any external actor who can reach the proxy’s listener can attempt exploitation unless network controls restrict access. Multiple public advisories and trackers therefore treat the practical severity as high.

Exploitability and proof‑of‑concepts​

• Public writeups for the upstream mjson issue included proof‑of‑concept inputs that cause the numeric conversion routine to perform billions of iterations; similar payloads will impact HAProxy’s mjson usage.
• At the time of disclosure, exploitation in the wild had not been widely reported, but the EPSS/scan probability metrics for algorithmic DoS are non‑zero; given the simplicity of constructing malicious JSON payloads against exposed endpoints, defenders should assume opportunistic scanning and exploitation attempts will follow public disclosure.

---

Detection, mitigation, and remediation guidance​

Immediate triage (first 24–72 hours)​

• Inventory: Identify HAProxy instances that use JSON sample fetch functions. Search configurations for occurrences of json_query, jwt_header_query, and jwt_payload_query. This is the primary risk surface.
• Isolate: If feasible, restrict the ingress network paths to HAProxy listeners so only trusted clients can reach JSON‑parsing entry points (apply WAF rules, IP allowlists, or network ACLs).
• Rate‑limit: Apply aggressive per‑source rate limits and request-body size limits at upstream network devices or at HAProxy itself (where safe) to reduce the chance of sustained exploitation.
• Temporary configuration mitigation: As a stopgap, consider removing or disabling rules that use the JSON sample fetchers if business operations allow; be aware that this can change request routing and authentication logic and must be tested. HAProxy’s advisory notes no simple configuration workaround exists besides upgrading, but removing the converters from configurations can prevent the slow parse path at the cost of functional behavior.

Patch and upgrade plan (recommended)​

1. Identify the HAProxy branch you run (2.4, 2.6, 2.8, 3.x, or HAProxy Enterprise).
2. Schedule a staged rollout: upgrade a test canary first, validate behavior under synthetic traffic that mimics production loads, then progress to a pilot group, and finally to full production.
3. Use vendor provided fixed builds—the HAProxy advisory lists the fixed versions for each branch (for example, 2.4.30, 2.6.23, 2.8.16, 3.0.12, 3.1.9, 3.2.6). Follow your change control process to deploy those packages or images.
4. After upgrade, audit HAProxy logs to verify the absence of crashes/hangs and monitor worker restart rates and watchdog invocations for at least 7–14 days.

Detection and hunting signals​

• Elevated CPU consumption and long‑running worker threads at the HAProxy process level correlated with incoming requests that include JSON numeric values.
• Frequent watchdog restarts, worker timeouts, and process restarts around the time of traffic bursts.
• WAF/edge logs showing repeated long JSON bodies or suspicious numeric patterns (very long exponent notation or digit strings).
• SIEM rules: flag requests where JSON numeric values exceed reasonable length thresholds or include unusual exponent notation like an exponent with extremely large digits.

---

Operational recommendations and risk management​

• Prioritization: Treat edge HAProxy instances, production ingress controllers, and HAProxy instances that front critical business services as top priority for patching. The operational impact of downtime at the proxy level justifies expedited rollouts and emergency change windows.
• Test harnesses: Add unit and integration tests that include worst‑case numeric parsing inputs as part of your HAProxy validation pipeline; this reduces the risk of regressions and surfaces performance impacts early.
• Policy & hardening: Where possible, limit the usage of inline JSON parsing/ACL logic on public listeners. Offload complex parsing to dedicated, hardened microservices or to WAFs that can throttle or reject malicious payloads before they reach the proxy.
• Supply chain visibility: Because the fix was applied by vendor‑forking mjson into HAProxy, organizations that rely on other products embedding mjson must track those downstream packages separately. Upstream library patches may lag vendor‑specific backports: confirm patch status across all products that include the same library code.

---

Broader lessons: algorithmic complexity is a supply‑chain risk​

CVE‑2025‑11230 is a textbook example of how a low‑severity, algorithmic weakness in a small dependency can escalate into a high‑impact availability incident when embedded inside a critical runtime like a proxy. The mjson upstream disclosure (CVE‑2023‑30421) was rated lower severity in isolation, but HAProxy’s context (network‑exposed JSON evaluation at the edge) changed the risk model. This supply‑chain amplification illustrates three enduring lessons:

• Small dependencies can create systemic risk when used in security‑critical code paths.
• Algorithmic complexity vulnerabilities are often invisible to static testing because they are correctness/performance issues rather than memory corruption defects.
• Vendors may need to backport or fork fixes into their products faster than upstream projects can respond; operators must track vendor advisories and distribution package fixes rather than relying solely on upstream library releases.

The community response to CVE‑2025‑11230 also highlights the importance of cross‑referencing vendor advisories and distribution trackers (for example, Debian’s security tracker lists the fixed package revisions and the HAProxy commit that remedied the issue), which is essential for robust patch management.

---

Threat model — who should be most worried​

• Public‑facing HAProxy instances that evaluate or inspect JSON payloads using sample fetch functions are highest risk.
• Kubernetes clusters using HAProxy Kubernetes Ingress Controller (KIC) should upgrade ingress controller images promptly; the advisory lists fixed image tags for KIC.
• Multi‑tenant reverse proxies and API gateways where untrusted clients can send arbitrary JSON should be prioritized because an attacker from the network can trigger the condition without privileges.
• Internal HAProxy deployments that accept traffic from less‑trusted segments or partner networks are also in scope and should be treated as high priority for patching.

---

What remains unverified and cautionary notes​

• Upstream mjson status: HAProxy reported the problem to the mjson maintainer; however public trackers (Snyk and others) indicated no fixed upstream mjson release had been made available at the time of HAProxy’s advisory. Operators should not assume upstream fixes exist—verify upstream project releases and prefer vendor‑packaged fixes if included. The absence of a universal upstream fix increases the importance of tracking each vendor’s embedding of mjson.
• Exploitation in the wild: while the EPSS and early community signals show non‑zero exploit probability, there were no widespread, confirmed mass‑exploitation reports at the time of initial vendor publication. That said, algorithmic DoS payloads are trivial to construct and easy to scan for, so the threat of opportunistic exploitation is real—treat this as an urgent patch scenario rather than a low‑priority item.

---

Step‑by‑step remediation checklist​

1. Inventory HAProxy instances and note which configurations use json_query, jwt_header_query, or jwt_payload_query.
2. Schedule upgrades to the vendor‑listed fixed versions for your HAProxy branch:
   • Community: 2.4.30, 2.6.23, 2.8.16, 3.0.12, 3.1.9, 3.2.6.
3. For Kubernetes: pull the patched HAProxy KIC images listed in the advisory and perform a canary deployment.
4. If immediate upgrade is impossible, apply network controls and rate‑limiting to reduce exposure, and consider temporarily removing JSON sample fetchers from critical listeners (test impact first).
5. Post‑patch: monitor worker restart counts, watchdog events, and HAProxy logs for residual issues; run synthetic tests that include previously problematic inputs to validate the fix.
6. Update your SBOM and dependency tracking to reflect the vendor fix and to identify other products embedding mjson that may need attention.

---

Conclusion​

CVE‑2025‑11230 is a high‑visibility example of how a relatively small, algorithmic weakness in a third‑party library can become an availability crisis when the library is embedded in an edge component like HAProxy. The remediation path is straightforward but urgent: upgrade to the fixed HAProxy builds as listed by the vendor, and apply compensating controls where upgrade windows are constrained. Operators should also use this incident as a prompt to improve dependency visibility and test for algorithmic worst‑case inputs in critical parsing components. The practical risk—easy to trigger, network‑accessible, and directly affecting service availability—means HAProxy instances in production should be treated with high priority for mitigation and patching.

---

Bold actions to take now:

• Immediately identify HAProxy instances using JSON sample fetchers and plan upgrades to the vendor‑stated fixed versions.
• Apply ingress rate limits and request size caps while you patch.
• Verify distribution/package fixes (for example, Debian/Ubuntu package updates) and apply them through your standard patch pipelines.

Contextual note: this advisory should be handled as an operational emergency for edge proxies and ingress controllers—the window between public disclosure and opportunistic scanning is short for simple DoS vectors like this. For teams managing HAProxy, the priority is clear: patch, validate, and harden.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center