Red Hat Product Security Risk Report 2025

The accelerating pace of change observed in 2024 dramatically intensified in 2025. AI is no longer something to merely consider, it is fundamentally reshaping the technology industry and its surrounding landscape.

In response to this increased velocity and complexity, Red Hat launched 2 new customer-facing product security services: The Security Technical Account Manager (TAM) program, a specialized security-focused TAM offering, and the Red Hat® Enterprise Linux® Security Select Add-On, which provides additional Common Vulnerabilities and Exposures (CVE) fixes beyond the scope of standard support.

This year's risk report begins with our customary vulnerability response statistics, followed by a deeper analysis of the most critical vulnerabilities, including those that garnered significant customer attention. We then explore how we are adapting to the fast-evolving regulatory environment, highlight progress in our security development program, and conclude with key insights from our journey in post-quantum cryptography and AI security.

While AI assisted in generating the graphs and images and the report's initial creation, the core work of fact-checking, review, and the majority of the text remains human authored.

We hope you enjoy reading the report.

- Garth Mollett, Product Security Technical Advisor, Red Hat

Red Hat Security Advisory

Red Hat Security Advisories continue to be the primary notification mechanism for releasing software updates containing fixes for known vulnerabilities in the CVE catalog since its inception more than 20 years ago. While the format, delivery mechanism, and other details have evolved over the years, the primary purpose remains.

The trendline from 2021-2025 once again shows an almost linear upward trend, reaching a new peak of 3,781 security advisories released in 2025.

Table 2. Red Hat Security Advisory by Product Family (this does not include all products) 

We saw a minor reduction in Critical errata and CVEs for the 2nd year in a row, but the numbers continue to climb overall, as in previous years. 

This is more of a reflection on the increasing scope of the portfolio and not an alarming or unexpected increase in vulnerabilities. These Critical numbers just missed a large number of vLLM errata for CVE-2025-68664, which was publicly disclosed on December 23, 2025, with updated packages released in early January 2026.

Common Vulnerabilities and Exposures

An analysis of quarterly CVE counts reveals a consistent trend: A steady volume of Moderate vulnerabilities across all periods and a relatively even distribution among the remaining categories. The spike in Low’s in Q4 is almost entirely attributed to the kernel, which we will look at in a bit more detail below.

Figure 3 shows the impact of the Linux kernel CVE Numbering Authority (CNA) is clear. There was a sharp increase between 2023 and 2024 that matches the program's start in February 2024. Following that, the data shows a stable and steady upward trend through 2025. To accurately assess overall security trends and see the influence of this high-volume source, it is helpful to view the data with the Linux kernel CVEs removed, as shown below.

While this visualization is less dramatic, it still reveals a clear upward trend. Over a 5-year span, the data shows an increase of more than 100%. Even when measured against the 2020 baseline of 1,975 CVEs, the growth remains just under 100%. To better understand this shift, let us examine a side-by-side comparison of 2024 versus 2025.

From this view we can see that CVE counts went up almost everywhere (except for Critical, which is too small to register on the graph above). The majority of the growth from the kernel is Moderate, but for Important vulnerabilities the extra load is almost entirely outside of the kernel. So while we continue to see significant extra workload from the kernel CNA, it is mostly in vulnerabilities that our vulnerability analyst teams do not consider to be of significant risk to standard Red Hat Enterprise Linux use cases. 

It is worth noting we occasionally see Moderate impact kernel CVEs exploited in the wild, but in most cases they affect Android and require physical access to a device, posing much less of a threat to the vast majority of enterprise Linux users. Nevertheless, when we receive these reports, we prioritize fixes, regardless of severity, for any unfixed CVE.

Exploitation in the wild

While total vulnerability reports have increased, active exploitation in the wild has remained flat or decreased slightly compared to last year. It is important to note that this decrease is partially due to the January-to-December reporting window. Many flaws, particularly in the Linux kernel, show active exploitation cycles that span beyond their initial reporting year, a nuance we will explore further in the next section.

Table 3. Exploitation in the wild

CWE-20: Improper input validation continues to do the heavy lifting in our reporting, largely due to its broad and somewhat catch-all nature. The remaining top 3 categories are classic memory safety issues. This is a fact that will come as no surprise to anyone following the landscape, with the Linux kernel being the primary contributor across all 3.

However, when we shift our focus from sheer reporting volume to what is actually being exploited in the wild, the picture changes. CWE-416: Use after free immediately jumps to the top, maintaining its position as the most weaponized weakness from 2024.

Use afterfree bugs can provide multiple useful primitives for exploit writers and are difficult to fully mitigate without performance impacts that are often untenable for general purpose operating system kernels and system libraries. Consequently, it is no surprise that use after free remains the most prevalent bug class exploited in the wild across the Red Hat ecosystem.

Red Hat Product Security looks at several factors to determine if an event or vulnerability should be treated as an incident, and whether it is major or minor. The main factors we consider are the risk to customers and the Red Hat brand. Our highest priority is an easily exploitable vulnerability in mission-critical software. We also consider other types of risk, such as misinformation and panic caused by confusing or exaggerated media coverage.

The incident process prioritizes fixes that would happen regardless of whether or not an incident occurs, provides clear and calm coordination, and maintains open communication channels that are internal and customer-facing. For customers, we often issue additional resources such as Red Hat Security Bulletins (RHSBs) or blog posts that can include more detailed background and mitigations.

While no CVEs reached the threshold to trigger the full major incident process in 2025, the following were still incidents of note.

Sudo logic flaws: CVE-2025-32462 and CVE-2025-32463

The basics: In mid-2025, 2 significant security weaknesses were discovered in the sudo utility, a widely popular mechanism that allows regular users to perform predefined tasks as a different identity, often root or another privileged system account. Both vulnerabilities were logic errors in command line argument handling and allowed users to bypass expected controls.

The details: CVE-2025-32426 was the less dangerous of the 2 flaws under most conditions—a classic logic flaw. For efficient administration across large fleets of machines, sudo allows a single “sudoers” config file to be used with per-host policy in the same file. The -h host option was intended to be used as a diagnostic tool to allow listing policy from other hosts without the need to login or read the entire file. Unfortunately, a check was missing that the -l option for list policy was also present when using the -h option, which meant that the policy from any machine in the file could be used on any machine where a user had sudo access. This ultimately defeats the purpose of the per-host policy entirely. 

CVE-2025-32463 was the more serious of the 2 vulnerabilities, as it allowed any user who could run sudo to run arbitrary code as root. It was a slightly more complex error in the handling of the -R Change root / chroot option. The intended use of the -R option is to run commands with a different root directory; -R /tmp will make the command see /tmp as /. This change of root directory should be the last thing that happens before running the command. However, a change was introduced in 1.9.14 that moved the change root logic to be before other environment setup and parsing logic had occurred. This means that anyone who can run any command with sudo could provide the -R option and set up a fake /etc under the new root, and system config would be read from this directory instead of the real /etc. An exploit was demonstrated against this by replacing nsswitch.conf to cause additional libraries to load, which are then read from a fake /lib instead of the real /lib, loaded into sudo, and executed as root.

The statistics

Affected Red Hat product versions: Red Hat Enterprise Linux 6-10
Severity rating: Important
Embargo time: 7 days
Exploit code published: Yes, proofs of concept (PoCs) were available publicly within 2 days.
Exploitation in the wild: Yes, CVE-2025-32463 was added to the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog 3 months after vulnerability details were publicly disclosed.
Time from public to 1st fix release: 2 days
Time from public to all fixes released: 23 days

Closing thoughts: Both flaws highlight the importance and complexity of implementing logic in policy enforcement. Utilities like sudo, which enforce authorization boundaries, are popular targets for proponents of memory safe languages. While high-performance memory safe languages are almost certainly a good thing for security, flaws like these show that memory safety is not a silver bullet for implementing complex boundary enforcement logic.

MadeYouReset - HTTP/2 Denial of Service: CVE-2025-8671, CVE-2025-9784, CVE-2025-5115, CVE-2025-55163, and CVE-2025-48989

The basics: In mid-2025, a new denial-of-service (DoS) technique affected multiple implementations of the HTTP/2 protocol. Dubbed MadeYouReset, the flaw was an implementation weakness that allowed bypassing the Rapid Reset mitigations by causing the stream “RESET” to happen server side without the client needing to send a reset signal (RST_STREAM) itself.

The details: The vulnerability takes advantage of the same inconsistent expectation between HTTP/2 protocol layers as the earlier Rapid Reset vulnerability, specifically in how requests are cancelled. However, unlike with Rapid Reset, where the client quickly sends a “RST_STREAM” command after establishing a stream, the client instead quickly sends a malformed control frame. This triggers the server side to generate the RST_STREAM instead, but ultimately leading to the same condition where stream counts at the protocol layer see the stream as closed, yet back-end processing continues, allowing the client to rapidly consume server-side resources without hitting configured limits.

The statistics

Notable affected products: Red Hat Enterprise Linux, Red Hat OpenShift AI, logging for Red Hat OpenShift, Red Hat Data Grid, Red Hat OpenShift Dev Spaces, Red Hat single sign-on, Red Hat JBoss Enterprise Application Platform, Red Hat JBoss Web Server
Severity rating: Important
Embargo time: 82 days
Time from public to first fix release: 0 days, JBoss Web Server was released immediately upon disclosure.
Time from public to all fixes released: Due to the vast scope, fixes for some products are still in progress.
Exploitation in the wild: Yes, but not on the scale of Rapid Reset.

Closing thoughts: This incident highlights the complexity of fixing problems across varying implementations of the same protocol. While some components were patched immediately upon public disclosure, others still have not been completed. For example, the fix for the Undertow component initially triggered memory corruption errors deep within the Java Development Kit (JDK) native level. This required extended collaboration between Red Hat engineering and the OpenJDK team to ensure the solution was stable. Even when a vulnerability is understood, the remediation path can reveal new, unexpected challenges.

In 2025, Red Hat identified 137 publicly reported Software Supply Chain Attacks (SSCAs), representing a 54% year-over-year increase from events recorded in 2024. Of these events, approximately 7.3% were identified as high-impact adversary operations that successfully affected multiple downstream entities. While the total number of attacks rose, the proportion of high-impact events remained relatively stable, highlighting the continued prevalence of opportunistic, wide-net attacks over highly targeted breaches.

High-impact SSCA events

Of the high-impact events identified in 2025, 2 notable cases illustrate the evolving sophistication of supply chain threats:

• Shai-Hulud 2.0 (Sha1-Hulud): A widespread Node Package Manager (npm) and Maven worm that exploited compromised developer accounts to inject malicious code into hundreds of packages. The malware performed automated credential scraping using tools like TruffleHog and exfiltrated stolen data to public GitHub repositories. In cases where it could not authenticate, the worm included wiper functionality to delete user home directories.
• GlassWorm VS Code extension worm: The first self-propagating worm to target Visual Studio (VS) Code extensions on the OpenVSX and Microsoft marketplaces. It used invisible Unicode characters to hide malicious logic from code editors and used the Solana blockchain as a decentralized, immutable Command and Control (C2) infrastructure. The worm harvested credentials for propagation and targeted 49 different cryptocurrency wallet extensions.

Notable attack trends

Attackers in the 2025 SSCAs most frequently used these 3 tactics, techniques, and procedures (TTPs) mapped to the Open Software Supply Chain Attack Reference (OSC&R) framework across the cyber kill chain:

• Publish malicious artifact (T0109): Uploading infected packages to public registries.
• Secret leak (T0198): Discover secret leaks, which are often found in code repositories to advance to the next stage of malicious activities.
• Typosquatting (T0129) or Combosquatting (T0157): Creating deceptively named packages, such as deezcord.js or react-router-dom.js, to trick developers.

Upstream victim trends

Npm remained the most targeted registry in 2025, serving as the primary focus for 40% of SSCAs and marking the 3rd consecutive year its representation of attacks has increased. While npm dominates the threat landscape, the proportion of all other impacted ecosystems, such as PyPI and GitHub, actually decreased and the attack surface became more diversified. Consequently, 2025 saw a larger number of specific attacks directed at Go modules, browser extensions, and the Rust ecosystem. Attackers increasingly favor these platforms to deliver malicious payloads by social engineering, automated version upgrades, and slopsquatting, a new class of attack exploiting AI-generated code hallucinations.

Motivation and attribution

Financially motivated opportunistic attacks remain the most prominent threat to the software supply chain. Analysis of these incidents reveals that the vast majority of attacks target developers and endpoints during the initial stage, while 23% specifically target the cryptocurrency industry and assets, a notable increase from the 17% recorded in 2024.

Motivations

• Financially motivated: 42%
• Espionage operations: 5%
• Disruptive attacks: 5%
• Political hacktivism: 2%
• Unclear or unknown: 46%

Attribution breakdown

Attribution remains a significant challenge, with the vast majority of attacks leaving no definitive fingerprints.

• Unattributed: 88%
  • Up from 82% in 2024
• North Korean state-aligned groups: 8%
  • Examples: Lazarus Group and Contagious Interview
• Chinese groups: 1%
• Russian-based actors: 1%

Recommendations

The analysis of 2025 SSCA data highlights several new and evolving threats that require the following refinements to our previous recommendations.

AI-driven supply chain defense

The 2025 data revealed 2 new AI-related attack vectors: "slopsquatting", which involves exploiting AI-generated code hallucinations and the coercion of local AI command-line interface (CLI) tools, such as Claude and Gemini to perform reconnaissance on developer machines.

Recommendations:

• Implement policies for vetting AI-suggested dependencies before installation.
• Restrict the permissions of AI-assistant CLI tools to prevent them from accessing sensitive system files like SSH keys or .env configurations.

IDE and marketplace hygiene

The rise of the GlassWorm and WhiteCobra campaigns in 2025 demonstrated that VS Code and OpenVSX marketplaces are now primary targets for self-propagating malware.

Recommendations:

• Treat IDE extensions as critical software dependencies. Organizations should move toward approved extension lists and use tools that monitor for "impossible" extension updates, for example, an extension changing publishers while keeping the same name.
• Screen extensions for low download counts, recent publish dates, or a lack of reviews before allowing installation on corporate endpoints.

Enhanced maintainer security

High-impact 2025 events, such as the Qix and DuckDB compromises, were triggered by sophisticated phishing emails targeting package maintainers, for example, using deceptive domains like npmjs.help.

Recommendations:

• Move away from persistent automation tokens for publishing. Use short-lived, environment-specific credentials for continuous integration and continuous delivery (CI/CD) pipelines.
• Restrict publish permissions exclusively to CI/CD systems and authorized maintainers, ensuring developers cannot accidentally publish from local workstations.

Behavioral monitoring of scripts

Attackers in 2025 increasingly hid malicious logic in postinstall scripts and obfuscated payloads in seemingly harmless files like .ico images or invisible Unicode characters.

Recommendation: Configure security tooling to specifically flag packages that execute postinstall scripts, initiate unexpected network calls, or attempt to modify files outside of the designated project directories.

These 2025 updates address the shift toward targeting the developer's local environment and the tools they use for code generation.

The 2025 security landscape was defined by more than just software vulnerabilities; it saw the rise of large-scale, portfolio-wide regulatory requirements. New regulations, most notably the European Union's Cyber Resilience Act (CRA), have fundamentally shifted the requirements for software producers.

This new regulatory environment, combined with a high-velocity program of commercial audits, such as SOC 2, ISO, and IRAP–essential for market access–presents a scalability challenge. The traditional methods of manual, periodic evidence collection are no longer sustainable. This audit burden creates toil, slows development, and is ill-suited for the pace of cloud-native innovation.

Compliance as a natural outcome of security practice

Red Hat's product security strategy is growing to address this challenge. We are designing a sustainable, scalable, and policy-driven program built on a core principle: A system engineered to be provably secure should, as a natural byproduct, achieve compliance.

This approach integrates security and compliance decisions into a natural outcome of the engineering workflow. Rather than treating compliance as a separate, reactive checkbox activity, we are embedding it within our development and operational processes. 

To execute this strategy, we are engineering a new, unified, API-driven compliance framework designed to be independent of any single scanner technology.

As a founding member of the Open Security Controls Assessment Language (OSCAL) foundation, we are pursuing 2 key foundational pillars:

1. Gemara (engineering-first standard): An engineering-focused logical model that serves as a common language for defining and validating technical controls.
2. OSCAL (standardized reporting): The National Institute of Standards and Technology (NIST)-developed standard used as the data format for formal, machine-readable Governance, Risk, and Compliance (GRC) reports and audit packages.

This initiative is being rolled out in 2 phases. The first phase, a proof of concept that is now complete, delivered a new command line tool called complyctl. The tool, now included in Fedora 42, successfully validated the framework's plugin-based architecture and allowed us to demonstrate that we could modernize our compliance tooling without disrupting existing systems. 

The 2nd phase, currently in development, is focused on building a Kubernetes-native toolkit with the goal of establishing a continuous and automated evidence collection pipeline that replaces high-effort, manual audit tasks. 

Red Hat further deepened its commitment to secure development in 2025 by expanding and refining Secure Development Lifecycle (SDLC) activities. This unwavering focus on the SDLC aims to mitigate risks for customers by developing every Red Hat product and service with inherent trust and reliability. Red Hat is actively using AI tools and techniques to assist in expediting and enhancing existing SDLC activities.

Security Architecture Review

Red Hat has significantly advanced its security assurance processes using an augmented workflow for the Security Architecture Review (SAR). While the fundamentals of a SAR remain unchanged, this updated process uses AI tools to help expedite and enhance the review. The new SAR process is divided into multiple steps incorporating human intervention to ensure confidence in the analysis. AI capabilities are used to parse architectural diagrams and apply relevant guides and generate a security review checklist tailored to the product's architecture.

The new SAR process aims to provide efficiency and expertise. AI tools allow rapid processing of large amounts of data while human engineers from both Product Security and Product Development teams provide manual validation.

Penetration testing

As of the end of November 2025, the Product Security pen-test team has successfully completed penetration testing on 38 products, yielding a total of 150 findings across the Red Hat software and managed service portfolio. As with SAR, our penetration testing capabilities are now heavily augmented with AI, for both test plan creation and general workflow automation.

Table 6. Finding type results

These findings provide granular insights, categorized as 25 vulnerabilities, 86 weaknesses, and 39 informational findings.

SAST automation

Another area where AI provided significant assistance in 2025 is in our SAST scanning capabilities. To help mitigate the ongoing challenge of alert fatigue with SAST results, we have deployed an AI-powered interpreter into the workflow. Rather than simply labeling a line of code as potentially vulnerable, the system uses a specialized AI model combined with a retrieval system that is able to analyze the findings in both the context of the larger code base and external reference materials. This system has already been validated against major codebases and has significantly reduced noise and toil. 

RapiDAST

Our RapiDAST tool has continued its evolution through 2025, with improvements aimed at tracking emerging threats as well as improvements to accuracy and efficiency. One standout innovation is the introduction of support of large language model (LLM) security scanning via the integration of the Garak scanner, allowing for targeted evaluation of LLM-specific vulnerabilities and weaknesses.

Additionally, we have made improvements to the usability and reliability of scan results. We introduced the advanced SARIF filtering for false positives allowing results to be filtered using Common Expression Language (CEL), which can dramatically reduce noise.

The integration of RapiDAST into Red Hat Engineering teams’ CI/CD pipelines has steadily progressed, receiving positive feedback and achieving widespread adoption. This momentum is expected to continue into next year, reinforcing RapiDAST’s ongoing relevance and impact in secure software development practices.

For more information on RapiDAST, find the project on GitHub. Community contributions and feedback are always encouraged.

Project Boann

As the size and scope of our operations continue to grow in both volume and complexity, the need for integration of results from various tools and data sources into a single view becomes essential. In 2025 we launched our open source Single pane of glass (SPoG) project, dubbed “Project Boann.”

The project has 2 key components: a pipeline that collects and normalizes data to the Open Cybersecurity Schema Framework (OCSF), and an LLM chat interface, which will evolve into an agent interface going forward.

The project is under active development with more details and source code in our Github repos: 

• https://github.com/RedHatProductSecurity/boann-ocsf-security-data-platform
• https://github.com/RedHatProductSecurity/boann-security-risk-agent

We welcome feedback and contributions from the community.

Post-quantum cryptography migration

The advent of quantum computing represents a fundamental, long-term threat to digital trust and software supply chain integrity. In 2025, Red Hat moved from planning to execution, leading the industry by shipping hybrid Post Quantum Cryptography (PQC) key exchange (ML-KEM) by default in Red Hat Enterprise Linux 10.1. This provides customers with immediate, out-of-the-box protection against Harvest Now, Decrypt Later data secrecy attacks. Furthermore, we modernized our production signing infrastructure to dual-sign Red Hat package managers (RPMs) with both classical RSA and PQC (ML-DSA) signatures, a critical step in providing verifiable authenticity and protecting our customers against the future threat of quantum forgery. Initial analysis across the portfolio has confirmed that like Red Hat, most organizations’ greatest risks are not in the code but in the complex, interdependent technology supply chain. Critical dependencies from upstream open source projects like Go, which impacts Kubernetes and Sigstore, to hardware-level components like HSMs and firmware, are not yet aligned on PQC timelines. Red Hat is actively leading this cross-industry collaboration to establish clear roadmaps and help unblock the vast open source ecosystem.

AI security update

In 2025, the focus of AI shifted from traditional LLMs to tool orchestration via the Model Context Protocol (MCP), which lets LLMs control external tools for increased organizational efficiency. However, this shift introduces new security risks, specifically the potential for a LLM to execute unsafe commands, underscoring the need for proper risk assessment and controls. This interest in MCP highlights the broader movement toward autonomous agentic AI systems, a field that is expanding with the emergence of new interoperable standards like Google's Agent2Agent (A2A) protocol. This protocol defines how independent AI agents communicate and collaborate for modular, enterprise-scale automation.

Red Hat Product Security continues its research on AI security, safety, and governance. Our whitepaper, “Blueprints of Trust: AI System Cards for End‑to‑End Transparency and Governance,” introduces Hazard-Aware System Card (HASC), a novel framework designed to enhance transparency and accountability in the development and deployment of AI systems. The HASC framework expands on existing system card concepts by integrating a dynamic record of an AI system's security and safety posture. It proposes a standardized system of identifiers, including a new AI Safety Hazard (ASH) ID, to work with existing identifiers like CVEs, ensuring clear communication of fixed flaws. 

We published hazard-aware AI System Cards: - 

• Ask Red Hat AI Assistant
• AI System Card - OpenShift Lightspeed.

Building on this foundation, 2026 will see an increased focus on transparency as a core aspect of AI security, with further adoption of mechanisms such as model cards, AI Bills of Materials (AIBOMs), and model signing.

Red Hat Product Security, now in its 25th year, has progressed significantly from a time when open source struggled for enterprise recognition and major commercial software vendors dismissed Linux as merely an interesting pursuit for hobbyists and startups. A full quarter of a century later, governments themselves are mandating standards for transparency in software production and vulnerability response.

The most significant shift is the accelerating rate of change itself, a trend often hard to pinpoint in an annual reflection, yet visible upon deeper inspection. When Red Hat Product Security launched in 2001, the internet had transitioned from an academic concept to the essential infrastructure for all businesses. Despite the dot-com bust, the movement toward the online world did not stall; instead, it rapidly intensified. This acceleration has continued year after year, culminating in the recent widespread adoption of generative AI.

Gen AI isn’t just another change, it is a change accelerator, an amplified feedback loop. We are entering an era where software and businesses will be able to operate at a scale and velocity beyond what the human mind can comprehend.

The full scope of this change's impact on security is only beginning to emerge. While the initial reaction for many may be to resist or slow down, history suggests this is not a viable option. We must be prepared to adapt, embrace this change, and lean into it. Just as we did in the past, championing transparency and open source values, we must now become the catalyst for positive change, ready to lead the way once again.

While the tools we use to defend the ecosystem have changed dramatically in the last 25 years, our core mission remains the same: Trust is our most critical deliverable. Innovation is accelerating rapidly, and we are prepared to ensure the open source ecosystem remains undeniably safe through this acceleration.