HAProxy Affected by Low-Severity Supply Chain Vulnerability, Leading To High-Severity Denial of Service (DoS) Risk

HAProxy, a high-performance open-source TCP/HTTP load balancer and reverse proxy commonly used to improve availability and scalability of web applications and related services, released an advisory (CVE-2025-11230, CVSSv3 7.5) this past October warning users that various versions of several of its products are vulnerable to a Denial-of-Service (DoS) attack when sending JSON documents to various endpoints, including the JSON documents that are encoded in JWT authentication tokens. What’s interesting is that this issue exists because HAProxy uses an open-source dependency in its supply chain (the `mjson` C/C++ library) with a 2-year-old vulnerability.

Essentially, this vulnerability means an adversary can attack HAProxy by including very large numbers encoded as strings in JSON documents; and since a JWT is an encoded set of JSON documents, even JWT handling is affected.

How CVE-2023-30421 in mjson led to the DoS CVE-2025-11230 in HAProxy products

Modern software relies heavily on open-source dependencies; this pattern generally increases quality and time-to-market by avoiding the need for development teams to design and test solutions to common problems, adopting reusable components instead. However, these dependencies then become part of the software supply chain, which means defects in those open-source packages end up in software products like HAProxy.

Like this kind of article? Get new security research content delivered to your Inbox

Subscribe to Checkmarx Zero

Never Miss Checkmarx
Zero Research Updates. Subscribe today!

By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to the processing of my personal data as described therein. By clicking submit above, you consent to allow Checkmarx to store and process the personal information submitted above to provide you the content requested.

In this case, HAProxy needed to decode JSON documents; this is a very common need, as JSON is one of the most popular data formats used for communication with web application APIs. In fact, JSON is hiding in common session token technologies like JWT (which is short for JSON Web Token), so decoding JSON documents is an essential part of HAProxy’s various products. To solve this problem, HAProxy adopted a well-respected, high-performance open-source library called `mjson`.

Unfortunately for HAProxy, `mjson` has a weakness in its parsing that causes it to take a very long time to decode some kinds of strings of digits that are meant to be interpreted as numbers. And mjson hasn’t a release since version 1.2.7 in September 2021. The vulnerability was noticed and reported in 2023, its CVSS score is only 2.9: a Low severity. Basically, this is a result of choosing an algorithm for converting strings to numbers that, while fast for ordinary values, is disproportionately slow for large values.

However, since HAProxy used this library for security-critical functionality, that “low severity” CVE has a high-severity (CVSS 7.5) impact. The slow processing of large numbers can be leveraged by an attacker to consume significant resources, which causes the HAProxy’s watchdog to terminate the slow-running process, and this causes significant damage the availability of the applications behind HAProxy products. Given that HAProxy exists to protect the availability and performance of web applications, a bug that degrades availability is clearly critical for them to address.

HAProxy’s top-notch response

The mjson library hasn’t made a release fixing the reported vulnerability. This isn’t particularly surprising; the dependency has evidence that it is no longer actively maintained, and the low severity means even an active maintainer may not prioritize a repair. This puts HAProxy in a tough situation: they could easily have stopped at just mitigating the risk somewhat, and placing the blame on the dependency.

Instead, HAProxy acknowledged the issue, supported a public CVE, explained the problem clearly, and made the call to maintain their own version (fork) of the mjson library that does not have this flaw. This version is integrated into their open-source code project.

Choosing to be transparent and to take ownership of the issue in a likely-abandoned dependency is excellent behavior. Not every organization is able to do this, and even fewer are willing.

Learning from HAProxy’s pain

Developers, security champions, AppSec analysts and engineers, and others with an Application Security interest can learn a few key lessons from this vulnerability:

1. Low-severity vulnerabilities in your supply chain can lead to high-severity vulnerabilities in your applications, especially when you use those dependencies for security-critical functionality. Your vulnerability management program can’t rely entirely on CVSS base scores to decide what’s important
2. Unmaintained and outdated dependencies are an under-appreciated supply chain risk. Setting policies that flag outdated dependencies for review is an essential risk management activity. Switching to an alternative, committing to maintaining a private fork of the dependency, or taking over maintaining an abandoned project can address the risks; and no tool will tell you which course of action is correct
3. Security-essential functions need rigorous testing against edge cases. Slowness in edge cases can affect availability, odd behaviors with unexpected inputs can cause crashes or expose data or even allow bypasses, and so on. Security testing needs to focus heavily wherever things like authentication tokens or other security-critical capabilities are implemented. API security testing methods like fuzzing (sending very weird data to inputs in a large number of variations) should be in security teams’ toolkits.
4. A good response plan matters. HAProxy responded decisively, enabling to fix the problem effectively once the impact was understood. We can learn a lot by having a “tabletop” session with key players to walk through how our own organizations would respond to a similar event.

Supply chain security isn’t about “run tool, patch criticals and highs”. It’s about understanding both the value and the risks you inherit, and making risk-aware decisions about how to manage the components you depend on.

Subscribe to Checkmarx Zero updates

Never Miss Checkmarx
Zero Research Updates. Subscribe today!

By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to the processing of my personal data as described therein. By clicking submit above, you consent to allow Checkmarx to store and process the personal information submitted above to provide you the content requested.