Vulnerability hunting is the process of discovering and reporting vulnerabilities in software or hardware systems before they are known and assigned a CVE (Common Vulnerabilities and Exposures) ID. This helps organizations and software maintainers mitigate zero-day vulnerabilities before threat actors, allowing for the prevention of potential attacks and leading to more robust and secure software.
Checkmarx’ Research group has several processes, one of them being vulnerability hunting focused on open-source packages used by customers. Open-source packages are popular for various reasons but also come with a critical caveat: the presence of security flaws or malicious code that can compromise the applications that depend on them.
In this blog, we will present some of our findings and a retrospective on the most common challenges reported by our Security Researchers while doing vulnerability hunting.
Reported Vulnerabilities
Checkmarx has uncovered multiple vulnerabilities with a direct impact on customers’ security. These vulnerabilities, if left unaddressed, could have had consequences for open-source software and enterprises that make use of this software:
- CVE-2024-8374 exposes a critical Remote Code Execution (RCE) vulnerability within an open-source 3D printing software. This blog post provides a detailed analysis of the vulnerability, including how the researcher explored its potential exploitation in the context of Supply Chain Attacks.
- CVE-2024-4068 is a Denial-Of-Service vulnerability in NPM’s popular brace expansion library “braces”. It has been discovered that an attacker could send imbalanced braces to make the parser enter in a loop that never frees memory and eventually exhausts JavaScript’s heap memory, crashing the application.
- CVE-2023-46943 demonstrates the importance of not having Hard-Coded Credentials in your software, especially in authentication technologies, such as JSON Web Tokens (JWTs). If you want to learn more about this vulnerability and its impact, check this blog post.
- CVE-2023-50447 is an Arbitrary Code Execution vulnerability in Pypi’s popular image manipulation library “Pillow”, where attackers can potentially execute code and execute system commands if they have control over the environment keys passed to “PIL.ImageMath.eval()”.
- CVE-2021-25641 is an Insecure Deserialization vulnerability in Apache Dubbo that allows an attacker to send a malformed stream containing a malicious object to the exposed service, resulting in Remote Code Execution. You can find more details in this blog post.
Over the past year, the team has discovered many other vulnerabilities (you can find more here) that were reported to the respective maintainers following a responsible vulnerability disclosure program. Unfortunately, this process is not always as smooth and efficient as it should be.
Vulnerability Hunting Challenges
Vulnerabilities, Bugs or Features?
A common difficulty is whether the project maintainers consider the issues vulnerabilities or just software bugs. This could lead to disputes and long discussions involving maintainers, reporters, and the open-source community.
A vulnerability is a defect that can be exploited to compromise the security of the software in at least one of three aspects – Integrity, Confidentiality, or Availability. The other is a software defect that causes it to function incorrectly or have an unintended behavior. In other words, a vulnerability is a type of bug, but not all bugs lead to security vulnerabilities. It should be easy to understand the differences between the two, but many times the different entities cannot easily reach an agreement.
Fix Responsibility
Deciding who’s responsible for securing the vulnerabilities is one of the main challenges that often leads to disputes.
Many open-source packages are designed to be used mostly as utilities for the development of main projects. This means that the users are often expected to configure the package securely or ensure that only trusted input is passed to the functionality within the package’s scope. This is because the package might be working as intended and its functionality should not be restricted.
Consider an HTTP client package designed to make outbound connections. If not properly sanitized, its usage can be exploited as a Server-Side Request Forgery (SSRF) vulnerability. This could allow requests to be carried out via server to any URL or network location, allowing an attacker to communicate with the server’s internal services or access sensitive information. In such cases though, given it is the nature of the package to perform external communications, it should be the responsibility of the dependent application to apply the best security practices to avoid exposing the dangerous functionality to threat actors that may abuse it.
However, even in situations where the vulnerability could be seen as a legitimate issue on the package, such cases are not always agreed upon.
Vulnerability Disclosure Process
After finding vulnerabilities, Checkmarx follows a responsible vulnerability disclosure process, reporting the vulnerabilities privately with the maintainers to ensure mitigation before the findings can be made public. It is a fully coordinated process to ensure timely resolution before the findings are found by any malicious actors.
However, this process often presents unique challenges:
- Contact identification – difficulty in locating the correct contact for reporting, leading to delay and potential misdirection.
- Communication Challenges – disagreements may arise during the vulnerability assessment process, hindering effective communication.
- Validity disputes – initial skepticism regarding the validity or the severity of the reported vulnerabilities that can lead to delays in their respective resolution.
- Prolonged discussions – the time between initial vulnerability report and final resolution and disclosure can be excessively long, which can increase the risk of exploitation.
- Duplicate findings – finding that the reported vulnerabilities have already been reported by another research.
- Coordination challenges – the need for better coordination in addressing vulnerabilities as fast as possible, streamlining the disclosure process.
Conclusion
While the process of CVE Hunting plays a crucial role in enhancing the security of software, it is equally important to continue improving the process that underlines each vulnerability finding and disclosure. We take these challenges as lessons for 2025, and so can you. Doing so will create a smoother experience for security researchers, reporters, and the whole open-source community, and ensures that everyone is motivated to help maintain a safe and secure software environment.