# Critical CVEs: where they appear, examples, and remediation steps

**URL:** https://mazehq.com/learn/critical-cves
**Date:** 2026-10-27

## What are critical CVEs?

Critical [Common Vulnerabilities and Exposures (CVEs)](https://mazehq.com/learn/common-vulnerabilities-and-exposures-cve-basics-and-best-practices) are publicly disclosed security vulnerabilities that pose a severe risk to affected systems. Severity is typically measured using the Common Vulnerability Scoring System (CVSS). Under CVSS v3.1, scores from 9.0 to 10.0 fall into the critical severity range. CVE records identify known vulnerabilities with unique IDs, such as CVE-2024-3094.

Critical vulnerabilities can enable outcomes such as remote code execution, authentication bypass, privilege escalation, or access to sensitive data. However, a critical CVSS score does not automatically mean a vulnerability presents the same risk in every environment. Exposure, exploit availability, affected assets, existing controls, and whether the vulnerability is actively exploited all affect its practical risk.

**Recent critical vulnerabilities:**

1. **Microsoft SharePoint ToolShell (CVE-2025-53770):** Critical unauthenticated remote code execution vulnerability affecting on-premises SharePoint Server.
2. **SAP NetWeaver (CVE-2025-31324):** Critical authorization flaw that allows unauthenticated attackers to upload malicious files and potentially execute code.
3. **Ivanti Connect Secure (CVE-2025-0282):** Stack-based buffer overflow enabling unauthenticated remote code execution on affected gateway appliances.
4. **Cleo managed file transfer products (CVE-2024-50623):** File upload and download vulnerability that can enable remote code execution on Cleo Harmony, VLTrader, and LexiCom.
5. **Palo Alto Networks PAN-OS (CVE-2024-0012):** Authentication bypass that can give unauthenticated attackers administrator privileges on exposed management interfaces.
6. **VMware ESXi (CVE-2025-22224):** Out-of-bounds write vulnerability that can allow a privileged attacker inside a VM to execute code in the host’s VMX process.

**6 steps to remediate critical CVEs:**

1. **Upgrade or patch the vulnerable component:** Install the vendor-provided fix, confirm the corrected version, test where possible, and make sure every affected instance is updated.
2. **Replace unsupported or abandoned dependencies:** Swap unmaintained components for supported alternatives and remove old direct or transitive references from builds and deployments.
3. **Apply vendor-recommended mitigations:** Use temporary vendor guidance such as disabling features, changing settings, or restricting access until a permanent fix is available.
4. **Reduce exposure when immediate patching is impossible:** Limit access, isolate systems, tighten permissions, and increase monitoring while permanent remediation remains scheduled.
5. **Rebuild and redeploy affected software:** Update dependencies or base images in the build process, refresh artifacts, and prevent vulnerable images or builds from being reused.
6. **Verify that the vulnerability is no longer present:** Rescan assets, confirm versions and deployment state, and make sure production workloads are using the fixed artifact.

## Why critical CVEs create significant security risk

Critical CVEs create significant security risk because they can give attackers a practical path to enter systems, gain higher privileges, steal sensitive data, or move across an environment. Their impact is often greater when affected systems are internet-facing, poorly segmented, or connected to privileged credentials and critical services.

- **Remote code execution and privilege escalation:** These flaws can let attackers run malicious code or commands, then increase permissions to administrator or root level.
- **Authentication bypass and unauthorized access:** Attackers may access protected functions, admin interfaces, APIs, or accounts without valid credentials.
- **Data exposure and credential theft:** Critical vulnerabilities can expose sensitive data, secrets, tokens, passwords, or keys that attackers may reuse elsewhere.
- **Lateral movement and system compromise:** After initial access, attackers can use credentials, network access, and trust relationships to compromise additional systems.

## Where critical CVEs commonly appear

Critical CVEs show up across the whole stack, from the operating systems and network appliances that run the business to the libraries, images, and build tools that developers depend on.

### Operating systems and servers

Operating systems and server software provide core services such as networking, authentication, storage, and process management. Vulnerabilities in kernels, remote access services, web servers, and other privileged components can expose an entire host.

A critical flaw may allow remote code execution, privilege escalation, or authentication bypass. Because servers often run sensitive workloads and connect to internal networks, successful exploitation can provide a starting point for broader compromise.

### Web applications and APIs

Web applications and APIs are frequent targets because they are often accessible from the internet. Critical vulnerabilities can result from flaws in application code, frameworks, authentication mechanisms, request processing, or access controls.

Attackers may exploit these weaknesses to execute code, bypass authentication, access restricted data, or perform privileged actions. Public-facing applications require particular attention because attackers can often probe them without first gaining network access.

### Open source libraries and dependencies

Modern applications depend on large numbers of open source packages and transitive dependencies. A critical CVE in one library can therefore affect many applications, even when developers did not directly install the vulnerable package.

The practical risk depends on which version is deployed, whether the application uses the vulnerable code path, and whether the conditions needed to exploit it exist where the application runs. [Software composition analysis](https://mazehq.com/learn/software-composition-analysis-how-it-works-6-best-practices) and software bills of materials can help teams locate affected dependencies and determine where updates are required.

### Containers and container images

Container images combine application code with operating system packages, runtimes, libraries, and other dependencies. Any of these components can contain critical CVEs, including packages inherited from the base image.

A vulnerability can remain present even after a fixed package becomes available if existing images are not rebuilt and redeployed. Container security programs therefore need to scan both image registries and running workloads while tracking the exact packages included in each image.

### Cloud infrastructure and Kubernetes

Cloud environments contain control planes, orchestration software, virtual machines, container runtimes, and supporting services. Critical vulnerabilities in these components can expose workloads, credentials, cluster resources, or management interfaces.

Kubernetes environments add components such as API servers, ingress controllers, operators, and third-party extensions. Teams need to track vulnerabilities across both managed and self-managed components while considering whether vulnerable services are exposed and what permissions they hold.

### Network and security appliances

Firewalls, VPN gateways, routers, load balancers, and other network appliances often sit at sensitive network boundaries. Many also expose remote management interfaces or process traffic from untrusted networks.

A critical CVE in one of these devices can provide access before attackers encounter internal security controls. Patching can also be more difficult than for ordinary servers because updates may require firmware changes, maintenance windows, or device reboots.

### CI/CD and developer tooling

CI/CD systems and developer tools frequently have access to source code, build environments, deployment credentials, package registries, and production infrastructure. Critical vulnerabilities in these systems can therefore provide attackers with unusually valuable access.

Compromised tooling may allow attackers to steal secrets, alter source code, modify build artifacts, or interfere with deployment pipelines. [Vulnerability management](https://mazehq.com/learn/vulnerability-management-process-metrics-and-technologies) should cover build servers, source control platforms, package managers, plugins, runners, and other development infrastructure.

## Examples of recent critical vulnerabilities

The nine CVEs below show the patterns that come up again and again in critical vulnerabilities, from unauthenticated remote code execution on internet-facing servers to flaws that break the boundary between a virtual machine and its host, and each was exploited in the wild.

### CVE-2026-1731: BeyondTrust Remote Support and Privileged Remote Access

**CVSS score:** 9.8 (Critical)
**First published:** February 6, 2026

CVE-2026-1731 is a critical operating system command injection vulnerability affecting BeyondTrust Remote Support and Privileged Remote Access. An unauthenticated remote attacker can exploit the flaw by sending crafted requests through a vulnerable WebSocket interface and could run arbitrary operating system commands on the affected system.

The vulnerability affects Remote Support versions 25.3.1 and earlier and Privileged Remote Access versions 24.3.4 and earlier. Because these products provide admin-level access to enterprise systems, successful exploitation can compromise sensitive remote administration infrastructure. The vulnerability was actively exploited in the wild, and CISA added it to its Known Exploited Vulnerabilities Catalog on February 13, 2026.

### CVE-2026-20127: Cisco Catalyst SD-WAN

**CVSS score:** 10.0 (Critical)
**First published:** February 25, 2026

CVE-2026-20127 is a critical authentication bypass vulnerability affecting Cisco Catalyst SD-WAN Controller and SD-WAN Manager. An unauthenticated remote attacker can exploit the flaw to bypass authentication controls and gain high-privilege access to affected SD-WAN infrastructure. From there, they could make unauthorized changes to network configurations.

The vulnerability matters because SD-WAN controllers manage connectivity and policies across distributed enterprise networks. Cisco identified exploitation associated with the threat actor UAT-8616, which chained the vulnerability with CVE-2022-20775 to obtain root-level access and establish persistence. CISA added CVE-2026-20127 to its Known Exploited Vulnerabilities Catalog on February 25, 2026, and issued Emergency Directive 26-03 requiring federal agencies to address the threat.

### CVE-2026-35616: Fortinet FortiClient EMS

**CVSS score:** 9.8 (Critical, as scored by Fortinet)
**First published:** April 4, 2026

CVE-2026-35616 is a critical improper access control vulnerability affecting Fortinet FortiClient Enterprise Management Server (EMS). An unauthenticated remote attacker can exploit the flaw by sending specially crafted requests to an affected server and could run unauthorized code or operating system commands.

The vulnerability affects FortiClient EMS versions 7.4.5 and 7.4.6. Because FortiClient EMS centrally manages endpoint security configurations, successful exploitation can compromise infrastructure responsible for administering enterprise devices. Security researchers observed active exploitation as a zero-day, and CISA added the vulnerability to its Known Exploited Vulnerabilities Catalog on April 6, 2026.

### CVE-2025-53770: Microsoft SharePoint ToolShell

**CVSS score:** 9.8 (Critical)
**First published:** July 20, 2025

CVE-2025-53770 is a critical deserialization vulnerability affecting on-premises Microsoft SharePoint Server. An unauthenticated attacker can exploit the flaw over a network to execute code on a vulnerable SharePoint server. Microsoft confirmed that exploits for the vulnerability were being used in the wild.

The vulnerability affects SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition. Its combination of network accessibility, no authentication requirement, low attack complexity, and potential impact on confidentiality, integrity, and availability resulted in a CVSS 3.1 score of 9.8.

### CVE-2025-31324: SAP NetWeaver

**CVSS score:** 10.0 (Critical, as scored by SAP)
**First published:** April 24, 2025

CVE-2025-31324 is an authorization vulnerability in the Metadata Uploader component of SAP NetWeaver Visual Composer. An unauthenticated attacker can upload potentially malicious executable files to an affected system, creating a path to remote code execution and compromise of the underlying host.

The vulnerability affects the Visual Composer development server in SAP NetWeaver 7.50. SAP assigned it a CVSS 3.1 score of 10.0, and CISA added it to its Known Exploited Vulnerabilities (KEV) Catalog on April 29, 2025 after evidence of active exploitation.

### CVE-2025-0282: Ivanti Connect Secure

**CVSS score:** 9.0 (Critical)
**First published:** January 8, 2025

CVE-2025-0282 is a stack-based buffer overflow affecting Ivanti Connect Secure, Policy Secure, and Neurons for ZTA gateways. A remote attacker can exploit the vulnerability without authentication to execute arbitrary code on affected appliances.

The vulnerability was particularly significant because Connect Secure appliances provide remote access to enterprise networks and can therefore occupy a sensitive position at the network perimeter. Exploitation can give attackers a way into the internal network, from which they can reach internal resources or establish persistence.

### CVE-2024-50623: Cleo managed file transfer products

**CVSS score:** 9.8 (Critical)
**First published:** October 28, 2024

CVE-2024-50623 is an unrestricted file upload and download vulnerability affecting Cleo Harmony, VLTrader, and LexiCom versions before 5.8.0.21. The flaw can allow an unauthenticated network attacker to upload dangerous files and ultimately achieve remote code execution.

The vulnerability became especially important after attackers began exploiting affected managed file transfer servers. CISA added CVE-2024-50623 to its Known Exploited Vulnerabilities Catalog on December 13, 2024, requiring U.S. federal agencies to apply vendor mitigations or stop using affected products when mitigations were unavailable.

### CVE-2024-0012: Palo Alto Networks PAN-OS

**CVSS score:** 9.3 (Critical, CVSS v4.0, as scored by Palo Alto Networks)
**First published:** November 18, 2024

CVE-2024-0012 is an authentication bypass vulnerability affecting the management web interface of several PAN-OS versions. An unauthenticated attacker with network access to the interface can obtain PAN-OS administrator privileges, allowing them to perform administrative actions and modify firewall configurations.

Attackers can also combine the vulnerability with other flaws, including CVE-2024-9474, to expand their control over a compromised device. Palo Alto Networks reported increasing attacks exploiting CVE-2024-0012, while CISA added the vulnerability to its Known Exploited Vulnerabilities Catalog on the day it was published.

### CVE-2025-22224: VMware ESXi

**CVSS score:** 9.3 (Critical, as scored by Broadcom)
**First published:** March 4, 2025

CVE-2025-22224 is a time-of-check time-of-use (TOCTOU) vulnerability that results in an out-of-bounds write in VMware ESXi and Workstation. An attacker with local administrative privileges inside a virtual machine can exploit the flaw to execute code as the VMX process running on the underlying host. NVD rates the same flaw 8.2 (High) because the attacker first needs administrative privileges inside the virtual machine, which shows how much a CVSS score depends on the assumptions behind it.

The vulnerability creates a potential path across the security boundary separating a guest virtual machine from its host, making it particularly significant in virtualized infrastructure. Broadcom stated that it had information indicating exploitation had occurred in the wild, and CISA added CVE-2025-22224 to its Known Exploited Vulnerabilities Catalog on March 4, 2025.

## 6 steps to remediate critical CVEs

[Remediating a critical CVE](https://mazehq.com/learn/cve-remediation-in-practice-process-examples-and-pro-tips) means removing the vulnerable condition or reducing its exploitability until a permanent fix is available. The correct action depends on where the vulnerability exists, whether a fixed version is available, and how much operational risk the change introduces.

### 1. Upgrade or patch the vulnerable component

The preferred remediation is usually to install the vendor-provided patch or upgrade to a version that no longer contains the vulnerability. This may involve updating an operating system package, application framework, library, appliance firmware, or platform component.

Teams should confirm the fixed version in the vendor advisory and test the update before production deployment when possible. Testing should cover application compatibility, service availability, and any configuration changes introduced by the new version. For widely exploited vulnerabilities, the time spent on testing must be balanced against the risk of leaving the system exposed.

Patch deployment should also account for every affected instance. Updating one server, container image, or development environment is not enough if other systems still run the vulnerable version. Asset inventories and vulnerability scanners can help identify remaining exposure.

### 2. Replace unsupported or abandoned dependencies

Some vulnerable components no longer receive security updates. In these cases, remediation requires replacing the dependency with a maintained version, supported fork, or alternative component.

Unsupported software creates ongoing risk because future vulnerabilities may also remain unpatched. Replacement should include checking compatibility, removing the old package completely, and updating build files, lock files, and deployment artifacts that still reference it.

Teams should also review transitive dependencies, because an abandoned library may still be pulled into an application indirectly through another package. Dependency analysis can help determine whether the vulnerable component can be removed, upgraded through a parent package, or replaced entirely.

### 3. Apply vendor-recommended mitigations

When a permanent patch is unavailable, vendors may publish temporary mitigations. These can include disabling a vulnerable feature, changing configuration settings, restricting access, rotating credentials, or applying filtering rules.

Mitigations should be treated as temporary unless the vendor explicitly states otherwise. Teams should document the workaround, monitor for a permanent fix, and verify that the mitigation remains effective after configuration or infrastructure changes.

It is also important to confirm that the mitigation actually blocks the known attack path. A configuration change that reduces exposure may not prevent exploitation in every scenario. Vendor advisories should be followed closely because mitigation guidance can change as more information becomes available.

### 4. Reduce exposure when immediate patching is impossible

Some systems cannot be patched immediately because of uptime requirements, compatibility constraints, or operational dependencies. In these cases, reducing exposure can lower the likelihood of exploitation.

Common controls include blocking public access, limiting traffic with firewall or allowlist rules, disabling unnecessary services, isolating the host, or tightening account permissions. Network segmentation can also limit what an attacker can reach if the vulnerable system is compromised.

These measures do not remove the vulnerability, so the affected system should remain scheduled for permanent remediation. Teams should also increase monitoring around the asset and look for exploitation attempts, unusual authentication activity, or unexpected outbound connections.

### 5. Rebuild and redeploy affected software

For containers, immutable infrastructure, and many cloud workloads, remediation should happen in the build process rather than by modifying running systems. Teams should update the vulnerable dependency or base image, rebuild the artifact, and redeploy it.

Rebuilding is important because an existing container image or machine image may continue to contain the vulnerable package even after source dependencies are updated. Build caches can also reintroduce outdated packages if they are not refreshed.

Old vulnerable artifacts should be removed, deprecated, or blocked from deployment. Teams should verify that deployment manifests, image tags, and automation pipelines all reference the corrected version so vulnerable builds are not accidentally restored.

### 6. Verify that the vulnerability is no longer present

Remediation is not complete until the fix is verified. Teams should rescan the affected asset, confirm the installed or deployed version, and check that the vulnerable component is no longer detected.

Verification should also confirm that production workloads are actually using the updated artifact. For example, a patched container image in a registry does not resolve the issue if running workloads still use an older vulnerable image.

Teams should validate both the technical fix and the deployment state. This may include checking package versions, container digests, firmware versions, configuration settings, and scanner results. For high-risk CVEs, an additional manual review can help confirm that no vulnerable instances were missed.

## Critical CVE management best practices

### Maintain a complete software and dependency inventory

Teams need to know which software, libraries, operating system packages, container images, and infrastructure components are deployed. Without this inventory, it is difficult to determine whether a newly disclosed CVE affects the environment.

The inventory should include component names, versions, deployment locations, owners, and dependencies where possible. A software bill of materials (SBOM) can provide additional visibility into components packaged inside applications.

Inventory data also needs to stay current. CI/CD pipelines and automated asset discovery can help capture changes as applications are built and deployed instead of relying on periodic manual updates.

### Continuously monitor newly disclosed CVEs

New CVEs are published continuously, and vulnerabilities affecting existing software may be discovered long after deployment. Security teams should monitor sources such as the National Vulnerability Database (NVD), vendor advisories, and security bulletins.

Monitoring should automatically match new vulnerabilities against the organization’s software inventory. This allows teams to identify affected systems soon after disclosure rather than waiting for the next scheduled vulnerability assessment.

Vendor advisories are particularly useful because they may contain affected versions, fixed releases, workarounds, and product-specific details that are not available in the initial CVE record.

### Combine severity with exploitability and reachability

A critical CVSS score indicates potential technical impact, but it does not describe the complete risk to a specific environment. Teams should also determine whether exploitation is practical and whether attackers can reach the vulnerable component.

For example, a critical vulnerability in an unused library function may present less immediate risk than a remotely exploitable vulnerability in an internet-facing service. Required privileges, user interaction, network exposure, and available exploits should all affect prioritization.

[Reachability analysis](https://mazehq.com/learn/reachability-analysis-how-it-works-methods-and-best-practices) is one part of checking exploitability. It determines whether there’s a path from an entry point to the vulnerable code, but a reachable function is not always an exploitable one. Exploitation depends on conditions in the code, such as whether attacker-controlled input actually reaches the vulnerable function and whether it’s validated first, and on conditions outside it, such as a feature being turned on, a service being exposed, or a workload holding permissions worth abusing. The newest AI-native tools check those conditions the way a security engineer would, looking at the code, configuration, controls, and exposure to decide whether each critical CVE can be exploited in your environment, so teams can focus remediation on vulnerabilities with realistic attack paths.

### Prioritize known exploited vulnerabilities

Evidence of active exploitation is a strong signal that a vulnerability requires attention. Sources such as CISA’s Known Exploited Vulnerabilities (KEV) Catalog identify CVEs for which there is evidence of exploitation in the wild.

Teams can use this information alongside severity, asset importance, and exposure to establish remediation priorities. A KEV listing shows that attackers are exploiting a CVE somewhere, not that it can be exploited in your environment, so an actively exploited vulnerability affecting an exposed production system may require faster action than the same CVE on an isolated host where the vulnerable feature is disabled.

Exploit status can change after initial disclosure. Vulnerabilities should therefore be continuously reassessed when exploit code, new attack campaigns, or additional technical details become available.

### Identify vulnerable components across the software supply chain

Vulnerabilities can enter applications through direct dependencies, transitive dependencies, base images, build tools, plugins, and third-party packages. Scanning only application source code can therefore leave significant gaps.

Teams should examine components throughout the software supply chain, including development, build, packaging, registry, and deployment stages. SBOMs and software composition analysis tools can help trace vulnerable packages back to the applications and artifacts that contain them.

This visibility is also useful during incident response. When a high-impact CVE is disclosed, teams can quickly determine which products, repositories, container images, and deployed workloads contain the affected component.

### Automate dependency and vulnerability scanning

Automated scanning helps detect vulnerable components before they reach production. Scans can run when developers commit code, open pull requests, build artifacts, create container images, or deploy workloads.

Results should integrate with existing development workflows so responsible teams receive actionable findings. Policies can also block builds or deployments when they contain vulnerabilities that exceed defined risk thresholds.

Automation should continue after deployment because previously safe components can receive new CVEs later. Combining build-time scanning with recurring scans of deployed assets provides coverage across the software lifecycle.

## Prioritizing and remediating critical CVEs with Maze

While working with security teams, Maze’s founders watched the same thing happen every time a critical CVE was disclosed. Scanners flagged every instance with a 9.8, and nobody had the context to say which of those instances could actually be exploited, so teams either patched everything in a fire drill or carried a queue of critical findings they couldn’t get through. They built Maze so that every vulnerability gets the investigation those teams never had the time to run.

Given unlimited time, a security engineer handed a critical CVE would check whether the vulnerable package is loaded in a running workload, whether the feature or configuration the exploit depends on is turned on, how the workload is exposed, and what its identity and network access can reach. Maze’s AI was built to think the same way, working out what context each finding needs and gathering it from your code, build, and cloud before deciding whether the vulnerability can be exploited in your specific environment, with the evidence behind every verdict attached. A CVSS 9.8 in an internal service that never loads the vulnerable function can drop down the queue, while a lower-scored CVE on an internet-facing workload with broad cloud permissions moves to the top.

Maze Cloud investigates the vulnerabilities your existing scanners find in the workloads running in your cloud, and Maze Code brings the same investigation to your code, using AI to find the vulnerabilities in your code and dependencies. For the vulnerabilities that are exploitable, Maze traces the root cause, writes a fix that matches your environment, and gets it to the developer who owns it.

**Key capabilities of Maze:**

- **An investigation for every critical CVE:** Maze deduplicates findings from your existing scanners, maps which workloads and containers are actually running, and checks each vulnerability against your configuration, controls, and exposure. Vulnerabilities that aren’t exploitable are closed with the full reasoning behind the decision. On average, Maze finds that over 70% of vulnerabilities are not exploitable.
- **Prioritization by real risk:** The vulnerabilities that can be exploited are ranked by how likely they are to be exploited and how much harm they would do to your business, instead of by CVSS score alone.
- **AI-SAST for your code:** AI-SAST runs on every pull request and across your entire codebase, finding business-logic flaws such as authentication and authorization gaps along with injection bugs.
- **AI-SCA for your dependencies:** Maze’s AI traces the path from an entry point to the vulnerable function in your dependencies, then checks whether that code is running and exposed in your cloud, because a dependency can be reachable without being exploitable. If you already run something like Dependabot, Maze investigates and deduplicates those findings too.
- **Fixes where your developers work:** Maze writes a fix that matches your code and routes it to the owner through your ticketing system, as a pull request, or to coding tools your team already uses, such as Claude Code and Cursor.
- **Mitigations when patching isn’t an option:** When a patch can’t be applied right away, or no patch exists yet, Maze recommends a mitigation that makes the vulnerability not exploitable in your environment until the permanent fix ships.
- **Zero-day sweeps:** When a new critical CVE is disclosed, Maze picks it up in near real time and checks every affected workload across code and cloud with the same investigation, so teams know whether they’re affected before scanners have caught up.

[Learn more about Maze](https://mazehq.com/platform) and see how it investigates and fixes critical CVEs across your code and cloud.