Top Open Source Vulnerabilities In 2026

What are open source vulnerabilities?

An open-source vulnerability is a security weakness or flaw within an open-source software component, library, or framework that can be exploited by malicious actors to compromise systems. These flaws often arise from coding errors, such as input validation failures, and are increasingly common due to the widespread use of third-party libraries.

Unlike proprietary software, open source code is publicly accessible, which means both defenders and attackers can inspect it. This transparency helps with faster identification and patching of vulnerabilities but also allows attackers to exploit known issues if they are not promptly fixed in deployed systems.

Organizations using open source software must track and manage these vulnerabilities actively, often using automated tools like software composition analysis (SCA) to detect and remediate known issues based on vulnerability databases such as the National Vulnerability Database (NVD) or GitHub’s advisory database.

Learn more about open source.

Impact of open source vulnerabilities

Open source vulnerabilities can have a wide range of impacts on systems, applications, and organizations. The consequences often depend on how critical the vulnerable component is, how it’s used, and whether there are existing mitigations. Below are some common impacts:

• Security Breaches: Attackers can exploit unpatched vulnerabilities to gain unauthorized access, escalate privileges, or execute malicious code within a system.
• Data Leaks and Loss: Vulnerabilities in open source components can lead to exposure of sensitive information, including user data, credentials, or intellectual property.
• Service Disruption: Critical services can crash or become unavailable if they rely on compromised components, affecting system availability and uptime.
• Supply Chain Risks: Vulnerabilities in widely-used libraries can propagate across multiple projects and vendors, creating systemic risks throughout the software supply chain.
• Compliance Violations: Use of vulnerable open source components can lead to non-compliance with security standards like ISO 27001, PCI-DSS, or SOC 2, resulting in legal and regulatory consequences.
• Reputation Damage: Public incidents involving open source vulnerabilities can erode customer trust and damage an organization’s brand reputation.
• Increased Remediation Costs: Late detection of vulnerabilities can lead to expensive incident response efforts, patching, and potential system reengineering.

9 recent open source vulnerabilities

1. CVE-2025-6514 / mcp-remote (npm/Node.js) / Critical RCE

mcp-remote is an open-source Node.js client/proxy widely used to connect LLM clients (e.g., Claude Desktop) to remote Model Context Protocol (MCP) servers. As AI integration frameworks grow, this tool saw significant adoption in AI development workflows.

• Published/Detected: July 9, 2025 (GitHub Advisory / public disclosures).
• Technical: OS command injection in the OAuth handshake when mcp-remote connects to a malicious or untrusted MCP server. Crafted authorization responses can be misinterpreted and passed directly to system command execution functions.
• Impact: Remote Code Execution (RCE) on the victim’s system — full OS command execution on Windows, and executable launches on macOS/Linux. Attackers could install malware, steal credentials, access files, or establish persistence.
• What happened: Actively discussed in mid-2025; patched in mcp-remote v0.1.16 in June 2025. No confirmed large-scale real-world exploitation reported, but the high severity and the AI ecosystem context drove rapid updates.
• Remediation & Status: Upgrade to v0.1.16+, only connect to trusted MCP servers over HTTPS, and audit MCP connections.

2. CVE-2025-24813 / Apache Tomcat / Critical RCE via Path Equivalence

Apache Tomcat is one of the most widely deployed open-source Java servlet containers used in web apps, APIs, and enterprise stacks. Apache Tomcat powers a large portion of internet-facing Java applications and is embedded in many commercial and custom enterprise products.

• Published/Detected: March 2025 (security advisories).
• Technical: A path equivalence flaw allows crafted HTTP requests (especially using partial PUT) to bypass security constraints and execute arbitrary code remotely by uploading and activating malicious payloads.
• Impact: Remote Code Execution (RCE) on affected servers. Given Tomcat’s ubiquity, this enabled attackers to compromise enterprise web services, gain unauthorized privileges, and potentially move laterally.
• What happened: PoC exploit code circulated immediately and researchers observed active exploit attempts in the wild. Administrators scrambled for patches.
• Remediation & Status: Fixed in Tomcat versions 11.0.3+, 10.1.35+, and 9.0.99+. Urgent patching was widely advised. 

3. Apache Tomcat CVE-2025-55752 and CVE-2025-55754 / Directory Traversal and Auxiliary Issues

In October 2025, the Apache project disclosed additional flaws in Tomcat affecting versions 9–11 that raised important configuration and traversal risks. These later issues were not default-configuration RCEs but increased risk in environments with relaxed HTTP method controls or improper logging setups.

• Published/Detected: October 27–28, 2025 (security announcements).
• CVE-2025-55752: a regression-based directory traversal vulnerability in URL rewrites that can bypass protections and upload malicious files if HTTP PUT is enabled.
• CVE-2025-55754: improper console handling allowing possible log manipulation and tricking admins into unsafe actions.
• Impact: Combined with other misconfigurations, these could enable unauthorized uploads or execution, and social-engineering vectors targeting admins.
• What happened: Widely communicated as part of Tomcat’s patch cycle; both were addressed in subsequent releases.
• Remediation & Status: Update to patched Apache Tomcat lines and avoid enabling risky methods (e.g., PUT) without strict controls.

4. Nvidia Triton Inference Server Vulnerabilities / Multiple RCE Risks (CVE-2025-23319, 23320, 23334)

Triton Inference Server is an open-source AI serving platform by Nvidia used to deploy models at scale. It supports multiple frameworks (TensorFlow, PyTorch, ONNX) and is commonly deployed in cloud, Kubernetes, and on-prem AI infrastructure. Because Triton often runs in high-performance GPU-backed production environments, compromise can expose valuable models and sensitive inference data.

• Published/Detected: August 2025 in public security reporting.
• Technical: Three vulnerabilities in the Python backend (out-of-bounds writes, shared memory misconfigurations) that, when chained, could allow remote code execution and manipulation of AI model processes.
• Impact: Potential full server compromise, model theft, unauthorized data access, and deeper network pivoting.
• What happened: Nvidia released Triton 25.07 with fixes; no widespread exploitation reported yet, but researchers warned of imminent risks for unpatched instances.
• Remediation & Status: Update to latest Triton releases and harden server deployments. 

5. CVE-2025-32432 / Craft CMS / Unauthenticated RCE

Craft CMS is a popular open-source content management system used by many web publishers. It is frequently deployed in small-to-medium business websites and custom enterprise portals, often exposed directly to the internet. Because Craft CMS supports plugin extensions and file uploads, vulnerabilities in core features can quickly translate into full server compromise.

• Published/Detected: April 2025 in vulnerability summaries.
• Technical: A flaw in the asset transformation feature allowed attackers to upload and execute arbitrary system code without authentication.
• Impact: Full Remote Code Execution on CMS hosts, compromising web servers and possibly leaking user or internal data.
• What happened: Security advisories and patch updates were issued, urging administrators to patch immediately.
• Remediation & Status: Update Craft CMS to fixed versions and tighten upload controls. 

6. Anthropic MCP Server Flaws (CVE-2025-68143 / 68144 / 68145)

The Git MCP Server from Anthropic (used to let AI tools inspect repositories) had chained vulnerabilities leading to remote tampering risks. These flaws highlighted risks in AI agent tooling where repository access is automated and exposed through model-driven workflows.

• Published/Detected: Reported June–Dec 2025 with social disclosure in early 2026.
• Technical: Path validation bypass, unrestricted git initialization, and argument injection in git_diff — combos could allow RCE or filesystem tampering.
• Impact: Potential remote system compromise when combined with other MCP servers, highlighting agentic system risk.
• What happened: Fixed in version 2025.12.18 in Dec 2025; no confirmed exploitation so far.
• Remediation & Status: Ensure updated MCP server deployments.

7. VS Code Extensions – RCE and File Exfiltration (CVE-2025-65715 / CVE-2025-65716 / CVE-2025-65717)

Visual Studio Code extensions are third-party add-ons for Microsoft’s open-source code editor; flaws in these plugins affect millions of developers.

• Detected/Published: 18 Feb 2026 (industry press reporting on advisories).
• Technical: Several popular extensions (Live Server, Code Runner, Markdown Preview Enhanced) contain logic allowing arbitrary code execution and data exfiltration when processing crafted content in a developer’s workspace.
• Impact: Attackers could perform remote code execution, lateral movement, or leak local files from developer machines, posing supply-chain risk.
• What happened: Patches released slowly; response criticized. Users are urged to update and remove untrusted extensions. 

8. OpenProject / Stored XSS in Roadmap View (CVE-2026-23625)

OpenProject is a popular open-source project management platform used by teams globally to track tasks, milestones, and product roadmaps. OpenProject is often self-hosted within enterprise environments, making it part of internal collaboration and documentation systems.

• Detected/Published: 19 Jan 2026 in NVD/GitHub Advisory.
• Technical: A stored cross-site scripting (XSS) regression in the Roadmap view. User-controlled project names were rendered without proper escaping, enabling injection of HTML/JavaScript that executes in other users’ browsers.
• Impact: Malicious code could be injected into the UI (CWE-79), leading to session hijacking, credential theft, or unauthorized actions via user browsers.
• What happened: Patched in OpenProject 16.6.5 and 17.0.0; mitigations include adding X-Content-Type-Options: nosniff headers. No widespread exploit reports yet but high severity. 

9. Global Supply Chain Issue / Log4Shell

Although Log4Shell (CVE-2021-44228) was disclosed in late 2021, its impact remained enormous through 2025, with millions of outdated deployments still vulnerable worldwide.Its long tail of embedded dependencies in enterprise software, appliances, and third-party products kept the vulnerability relevant years after disclosure. Even in 2025, internet scans continued to identify exposed services running outdated Log4j versions, especially in legacy and unmaintained systems.

• Technical: Remote Code Execution via unsanitized user data in logging calls.
• Impact: One of the most exploited vulnerabilities in history, shaping modern software supply-chain risk practices.
• What happened: Patches long available, but widespread vulnerable use in 2025 indicated ongoing systemic risk.
• Remediation & Status: Organizations must audit dependencies and remove vulnerable Log4j versions. 

OWASP top 5 risks for open source software and mitigation strategies

OSS-RISK-1 known vulnerabilities

A known vulnerability in an open source component means that a specific version of that component contains a documented security flaw that could be exploited by attackers. These flaws are publicly disclosed in repositories like the CVE (Common Vulnerabilities and Exposures) database or GitHub Security Advisories when they are discovered by researchers or maintainers. While disclosure makes the vulnerability visible, it doesn’t mean it’s immediately fixed or widely patched.

How to Mitigate:

• Continuously monitor public vulnerability databases (e.g., CVE, GitHub Security Advisories) for issues affecting your open source components. Subscribe to alerts or integrate feeds into your monitoring systems.
• Use software composition analysis (SCA) tools to scan your codebase and identify components with known vulnerabilities across all dependency layers.
• Enforce upgrade policies that require patching or replacing vulnerable components within a defined SLA based on severity.
• Avoid or remove unsupported or unpatched component versions, even if they appear functionally adequate.

OSS-RISK-2 compromise of legitimate package

This risk occurs when attackers manage to add malicious code into an otherwise trusted open source package or its distribution infrastructure. In open source ecosystems, packages are often published to registries (e.g., npm, PyPI) by maintainers. If an attacker gains access to a maintainer’s account, they can publish a compromised version of a legitimate package. 

How to Mitigate:

• Verify the authenticity of packages using available digital signatures or checksums to detect tampering before integration.
• Use package managers with integrity verification features (e.g., npm’s package-lock.json, Python’s pip hash checking).
• Track maintainer activity to spot unusual changes, such as unexpected ownership transfers or new releases from inactive contributors.
• Prefer official or widely-used mirrors and repositories, and avoid sourcing packages from unfamiliar or unofficial locations.

OSS-RISK-3 name confusion attacks

Name confusion attacks exploit the fact that open source package ecosystems often allow anyone to register a package with almost any name. Attackers register package names that look like legitimate ones (for example, by adding or removing a single character, swapping letters, or reusing similar branding) in a technique called typo-squatting.

How to Mitigate:

• Double-check dependency names before installation to catch subtle misspellings or lookalike names.
• Use internal allowlists or curated registries to restrict installations to vetted packages only.
• Enable dependency verification or review gates in your CI/CD pipeline to flag or block suspicious packages before they reach production.
• Train developers on common naming attack patterns and establish code review practices that require inspecting new third-party dependencies.

OSS-RISK-4 unmaintained software

Unmaintained software refers to open source components that are no longer actively developed or supported by their maintainers. This may happen when original contributors lose interest, the project is abandoned or archived, or focus shifts to newer alternatives. When a component enters an unmaintained state, it no longer receives routine fixes for newly discovered functional or security issues. 

How to Mitigate:

• Review the activity level of a project before adoption, checking indicators such as recent commits, release frequency, and responsiveness to issues.
• Periodically reassess all dependencies for signs of abandonment, such as long periods without updates or unanswered security reports.
• Replace unmaintained components with active, community-supported alternatives offering similar functionality.
• Fork the project and maintain it internally only if it’s critical and no viable alternatives exist.

OSS-RISK-5 outdated software

Outdated software describes a situation where a project continues to use an older version of an open source component even though newer versions have been released. Unlike unmaintained components, outdated ones do have updates available but they are not being adopted promptly. This creates a gap between the versions in use and the versions that contain fixes, improvements, or security patches. 

How to Mitigate:

• Implement automated dependency update tools (e.g., Dependabot, Renovate) to keep components up to date.
• Track and report version drift between your dependencies and their latest releases to prioritize upgrades.
• Integrate update testing into CI/CD pipelines to quickly verify compatibility of newer versions.
• Avoid hardcoding old version numbers unless there is a strong, documented justification (e.g., known breaking changes that are being mitigated separately).

OSS-RISK-6 untracked dependencies

Untracked dependencies refer to software components being used in a project that developers are not explicitly aware of or managing. These can arise from indirect (transitive) dependencies pulled in by direct dependencies, or from sources outside standard package managers (e.g., manual downloads, embedded libraries, or legacy artifacts). These dependencies are not included in bills of materials (SBOMs) or routinely scanned by security and compliance tools.

How to Mitigate:

• Use comprehensive SCA tools that detect both direct and transitive dependencies across all ecosystems in your stack.
• Ensure your build process generates and consumes SBOMs, and verify that SBOMs are complete and accurate.
• Avoid manual or ad hoc installation of components outside formal dependency management systems.
• Periodically audit your application’s runtime and build environments for untracked libraries or files.

OSS-RISK-7 license risk

License risk arises when an open source component lacks a clear license, has a license incompatible with the way the software is used, or contains obligations that downstream users cannot meet. In open source, licenses govern how software may be used, modified, and redistributed. Without a valid license, the legal status of the software is undefined. Using it could expose your organization to infringement claims or unexpected compliance requirements. 

How to Mitigate:

• Use tools that detect and classify licenses in all components, including transitive dependencies.
• Define a license policy specifying which open source licenses are acceptable and which are prohibited in your organization.
• Review license terms carefully for obligations like source disclosure, copyleft propagation, or attribution requirements.
• Avoid using components without a declared license, as their legal usage is undefined.

OSS-RISK-8 immature software

Immature software refers to open source projects that lack basic quality and engineering practices typical of production-ready libraries. Immature projects may not use standard development practices like semantic versioning, regression testing, formal code reviews, or sufficient documentation. They may lack a clear contribution or release process and have few active contributors. Such components may behave unpredictably, introduce bugs, or contain latent security issues.

How to Mitigate:

• Evaluate project maturity indicators such as availability of tests, versioning practices (e.g., semantic versioning), documentation quality, and contributor governance.
• Favor components that follow standard development best practices, even if less feature-rich.
• Avoid depending on projects that lack visibility into change history, release notes, or contributor accountability.
• Contribute tests, documentation, or bug reports if the component is valuable but underdeveloped, and you are willing to support it.

OSS-RISK-9 unapproved change

An unapproved change (or mutable dependency) occurs when updates to an open source component can happen without developers explicitly noticing, reviewing, or approving them. This can happen when dependencies are pulled from sources that aren’t versioned or are mutable, such as URLs that point to a development branch instead of a fixed version, or repositories where tags are moved. 

How to Mitigate:

• Always use versioned package sources, and avoid integrating from URLs that point to latest or mutable content.
• Use secure transport protocols (e.g., HTTPS) for all downloads and artifact transfers.
• Verify component integrity using hashes or signatures, and enforce this validation during build or deploy stages.
• Pin exact versions in dependency files, and block upgrades unless reviewed and approved.

OSS-RISK-10 under/over-sized dependency

Under/over-sized dependencies highlight the risk of adding dependencies that are either too small or too large relative to their actual value to your project. Under-sized dependencies often provide very minimal functionality yet introduce a full dependency with its own potential security and supply chain risk footprint. Because every dependency expands the attack surface, tiny micro-libraries can disproportionately increase risk.

How to Mitigate:

• Evaluate the scope and purpose of each dependency, and assess whether its inclusion is justified by the functionality used.
• Avoid using micro-packages that wrap trivial functionality, especially if they add further dependencies.
• Audit large libraries to understand how much of their functionality is actually used in your project.
• Periodically prune unused or low-value dependencies to reduce complexity and attack surface.

Manage your open source security the DevSecOps way with Mend.io

We all rely heavily on open source and third-party components that help us to develop and deliver innovative software products at scale and speed. Although application security has become a top concern for stakeholders, many teams unfortunately still view security as a heavy time-consuming task that slows them down.

We’re here to remind you that open source security is crucial to application security, and that contrary to popular belief, it doesn’t have to hinder rapid development. DevSecOps tools can help us integrate automated testing early and often in the DevOps pipeline, to ensure the open source components you rely on are secure and up-to-date without compromising on speed.

Learn more about Mend for open source security

Additional guides on open source topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of open source.

Dependency management

Authored by Mend.io

• Dependency Management: Protecting Your Code
• What Is Patch Management & How To Get It Right
• Maven Update Dependencies Automatically

Open source license compliance

Authored by Mend.io

• Best Practices For Open Source Governance
• Automate Open Source License Compliance
• Top Open Source Licenses Explained

Apache Kafka

Authored by Instaclustr

• Apache Kafka on AWS: Features, pricing, tutorial and best practices
• Apache Kafka: Architecture, deployment and ecosystem [2025 guide]
• Apache Kafka tutorial: Get started with Kafka in 5 simple steps