Known vulnerabilities in dependencies

Known vulnerabilities in dependencies arise when open-source libraries or components integrated into a software application contain publicly disclosed security flaws. These vulnerabilities, often documented in resources like CVE databases, can compromise confidentiality, integrity, or availability. An attacker may exploit them to execute malicious actions, such as unauthorized access, data exfiltration, or system disruption. Examples include the infamous Log4Shell vulnerability (CVE-2021-44228) in Apache Log4j and the Equifax breach (CVE-2017-5638) caused by a flaw in Apache Struts.

In this lesson, you will explore how known vulnerabilities in open-source dependencies arise, how attackers exploit them, and effective measures to secure your applications. From real-world examples to mitigation strategies, you’ll gain insight into protecting your codebase from these common risks.

Sofia is a backend developer who was working on a financial application. Her team used several popular open-source libraries to streamline development. While debugging an issue, she noticed unusual traffic patterns originating from her application. A closer inspection revealed a malicious actor exploiting a flaw in an outdated library version used in their project.

First, Sofia checked the application logs and identified suspicious activities targeting a specific API endpoint.

She decided to run a security scanner on the project, and a known CVE in an open source library was discovered within the code base with a high severity score.

Type in snyk test in the terminal below to see the vulnerability (note, the vulnerability is of a fictitious library).

Sofia verified the vulnerability allowed remote code execution under specific conditions, which the current system met. Looking at Snyk Advisor, she noticed a recommended package that is secure.

Then she updated the library to the new version and applied additional mitigations, such as restricting network access to sensitive endpoints. Keep reading below to see what this might look like in a real application.

Let’s explore the mechanics of how a known vulnerability, like the one Sofia faced, could be exploited and mitigated. In this example, the vulnerability resided in a dependency used for input validation, exposing the application to a remote code execution (RCE) attack. The following sections break down the vulnerable code.

The application uses a fictitious outdated library for handling user input, which contains a vulnerability allowing crafted payloads to execute arbitrary code.

Here, vulnerableLib contains a flaw where a crafted payload ({"input": "malicious code"}) can execute arbitrary commands. The root cause is inadequate sanitization of inputs within the library.

The fictitious Python application integrates a library to parse and validate data but uses a version vulnerable to injection attacks.

The library fails to escape user-provided input, enabling attackers to inject harmful commands.

A fictitious PHP-based web application uses a dependency for managing JSON input, which contains a known RCE vulnerability.

The outdated InputProcessor library allows crafted JSON payloads to execute arbitrary PHP commands due to unsanitized input processing.

A fictitious C# application relies on a vulnerable library for handling user requests.

Here, the vulnerable Process method executes embedded commands in the user input, creating an RCE vector.

A fictitious Go service uses a flawed library to process user input.

This library exposes the application to arbitrary code execution if a malicious payload is submitted.

A fictitious Java application uses an older version of a library that processes JSON input.

The library fails to validate or sanitize JSON strings, leaving the application susceptible to injection attacks.

The following fictitious C++ application uses a third-party library for parsing JSON input. However, an outdated version of this library contains a vulnerability that allows remote code execution when a crafted payload is provided.

The application relies on VulnerableJsonParser, an outdated library with a flaw that allows malicious input to execute arbitrary code.

To mitigate known vulnerabilities in dependencies, start by keeping them up to date and regularly reviewing changelogs and CVE disclosures. Using a security scanning tool like Snyk in your CI/CD pipeline helps detect vulnerabilities early, including those in transitive dependencies. It's also important to apply the principle of least privilege by restricting what dependencies can access, using containerization or security tools to limit potential damage. Regularly auditing and removing unused dependencies reduces unnecessary risk, while monitoring exploitability through threat intelligence sources ensures you prioritize the most critical vulnerabilities.

The updated JavaScript code uses a secure, patched version of the library, secure-input-lib, instead of the vulnerable one. This library ensures proper input validation and escapes potentially malicious characters that could exploit vulnerabilities. Additionally, no changes are made to the logic surrounding the library usage, which keeps the application simple and ensures backward compatibility. By replacing the outdated library, the risk of remote code execution (RCE) or injection attacks is mitigated.

In the Python code, the vulnerable library has been replaced with secure_input_lib, a patched version that addresses the known vulnerabilities. Furthermore, the application adds explicit input validation to check that the input is a string, rejecting invalid data early. This prevents unexpected input types from being passed to the library, which could potentially trigger an exploit. Together, the updated library and stricter input checks significantly reduce the risk of injection or RCE attacks.

The PHP snippet now utilizes a secure version of the InputProcessor library, which resolves the vulnerabilities in the previous implementation. Additionally, it introduces input validation to ensure that the provided data is a string, blocking malicious payloads before they reach the library. This two-pronged approach ensures that both the dependency and the application handle inputs securely, effectively closing the vulnerability.

The C# application now employs SecureInputProcessor, a fixed version of the library, which no longer allows execution of embedded malicious commands. The code also includes an additional check to ensure that user input is neither null nor empty. This validation prevents malformed or dangerous inputs from reaching the library, strengthening the system’s defense against RCE exploits.

In the Go code, the vulnerable vulnerablelib has been replaced with securelib, a patched library that properly sanitizes inputs. Additionally, the application validates input using a basic check to ensure it is non-empty. By eliminating the flawed library and proactively validating input data, this approach mitigates the exploitation risk, ensuring safer processing of user input.

The Java application substitutes the insecure InputProcessor library with a patched and secure version. An additional input validation step has been introduced to ensure that the data contains only alphanumeric characters and spaces, rejecting inputs that deviate from expected formats. These changes prevent attackers from injecting malicious payloads and leveraging the library’s flaws to execute arbitrary commands.

To fix this vulnerability, the application replaces the outdated JSON library with a patched, secure version. Additionally, input validation is added to ensure only expected JSON structures are processed.

This mitigates the risk by updating the library (from VulnerableJsonParser to SecureJsonParser), validating the input (using isValidJson()), and adding error handling.

To deepen your understanding of managing and mitigating known vulnerabilities in dependencies, explore the following resources:

• OWASP OSS Top 10
• Snyk Open Source. A tool to scan, fix, and monitor open-source dependencies for vulnerabilities.
• Snyk Advisor