DEV Community: Vulert

Four OpenClaw Flaws Enable Data Theft, Privilege Escalation, and Persistence

Vulert — Mon, 18 May 2026 07:21:05 +0000

Four OpenClaw flaws have been disclosed by cybersecurity researchers, exposing serious risks in AI-agent environments where autonomous systems can access files, credentials, execution tools, and enterprise workflows. The vulnerabilities, collectively named Claw Chain by Cyera, can be chained together to achieve data theft, privilege escalation, sandbox escape, and persistence.

The vulnerabilities are tracked as CVE-2026-44112, CVE-2026-44113, CVE-2026-44115, and CVE-2026-44118. The most severe issue, CVE-2026-44112, has a CVSS score of 9.6 and can allow attackers to redirect writes outside the intended sandbox boundary.

OpenClaw is an open-source autonomous AI agent platform that can interact with local filesystems, tools, credentials, integrations, and execution environments. This makes vulnerabilities in OpenClaw especially important because attackers may be able to weaponize the agent’s own privileges against the host environment.

What is Claw Chain?

Claw Chain is the name given to a set of four chainable vulnerabilities in OpenClaw. Individually, the flaws affect sandbox isolation, file access, command validation, and owner-level access control. When combined, they can allow an attacker to move from limited execution inside the OpenShell sandbox to sensitive data exposure, owner-level privilege escalation, and persistent control.

The chain is especially concerning because it abuses behavior that may look like normal agent activity. AI agents are designed to read files, execute tools, manage workflows, and interact with runtime environments. If an attacker can influence those actions through a malicious plugin, prompt injection, compromised external input, or supply-chain content, traditional security tools may struggle to distinguish attack behavior from legitimate automation.

Overview of the Four OpenClaw Flaws

CVE	Vulnerability Type	Severity	Potential Impact
CVE-2026-44112	TOCTOU filesystem write escape	Critical	Sandbox escape, configuration tampering, backdoor placement, persistence
CVE-2026-44113	TOCTOU filesystem read escape	High	Reading files outside the sandbox, credential exposure, sensitive data theft
CVE-2026-44115	Incomplete disallowed input validation	High	Command allowlist bypass, execution of unapproved commands at runtime
CVE-2026-44118	Improper access control / owner context spoofing	High	Privilege escalation to owner-level control of runtime operations

CVE-2026-44112: TOCTOU Filesystem Write Escape

CVE-2026-44112 is a time-of-check/time-of-use race condition in the OpenShell managed sandbox backend. The vulnerability allows attackers to bypass sandbox restrictions and redirect write operations outside the intended mount root.

This is the most severe issue in the Claw Chain set. If exploited successfully, an attacker may be able to tamper with configuration files, plant backdoors, modify trusted runtime behavior, and establish persistent control over the compromised host.

In an AI-agent environment, write access is particularly dangerous. Agents may routinely create files, update configuration, write logs, store outputs, and modify workflow artifacts. If those writes can be redirected outside the sandbox, the agent’s normal automation capabilities can become an attacker’s persistence mechanism.

CVE-2026-44113: TOCTOU Filesystem Read Escape

CVE-2026-44113 is another time-of-check/time-of-use race condition in OpenShell. Instead of redirecting writes, this flaw allows attackers to bypass sandbox restrictions and read files outside the intended mount root.

This can expose highly sensitive data, including system files, credentials, API tokens, internal artifacts, configuration files, secrets, and application data. In many environments, AI agents are connected to SaaS tools, internal systems, and local development environments, making read access outside the sandbox a serious data theft risk.

Even if the attacker does not immediately gain code execution, stolen credentials or configuration files may be enough to enable further compromise.

CVE-2026-44115: Command Allowlist Bypass Through Heredoc Expansion

CVE-2026-44115 is an incomplete list of disallowed inputs vulnerability. It allows attackers to bypass command allowlist validation by embedding shell expansion tokens inside a heredoc body.

This creates a gap between what OpenClaw validates and what the shell actually executes at runtime. A command may appear safe during validation, but shell expansion can cause unapproved behavior later.

For AI-agent platforms, this class of bug is especially risky because agents often rely on tool execution, shell commands, and automated workflows. If an attacker can manipulate command content through prompt injection, malicious plugins, or compromised inputs, they may be able to execute commands that were supposed to be blocked.

CVE-2026-44118: Owner Context Spoofing and Privilege Escalation

CVE-2026-44118 is an improper access control vulnerability that allows non-owner loopback clients to impersonate an owner. The issue stems from OpenClaw trusting a client-controlled ownership flag called senderIsOwner instead of deriving ownership from a properly authenticated session.

By manipulating this ownership context, a lower-privileged local client may gain access to owner-only operations. These operations can include gateway configuration, cron scheduling, and execution environment management.

OpenClaw has addressed the issue by issuing separate owner and non-owner bearer tokens and deriving senderIsOwner exclusively from the token that authenticated the request. The spoofable sender-owner header is no longer emitted or trusted.

How the Claw Chain Attack Works

The exploitation chain can unfold in four major steps:

A malicious plugin, prompt injection, compromised external input, or supply-chain artifact gains execution inside the OpenShell sandbox.
The attacker uses CVE-2026-44113 and CVE-2026-44115 to read sensitive files, expose credentials, and bypass execution restrictions.
The attacker exploits CVE-2026-44118 to obtain owner-level control over the agent runtime.
The attacker uses CVE-2026-44112 to modify configuration, plant backdoors, and establish persistence.

This chain is dangerous because it turns the AI agent into the attacker’s operational tool. Instead of dropping obvious malware immediately, the attacker can use the agent’s own permissions and workflows to access data, change configuration, and maintain control.

Why These OpenClaw Flaws Matter

The OpenClaw flaws matter because autonomous AI agents are no longer simple chat interfaces. They increasingly act as execution platforms that can interact with files, terminals, APIs, SaaS tools, calendars, repositories, customer systems, and cloud environments.

This changes the security model. A prompt injection or malicious plugin is no longer just a content manipulation issue. It can become a pathway to filesystem access, command execution, credential exposure, and persistence if the agent runtime has weak boundaries.

Cyera warned that each step of the attack chain may resemble normal agent behavior to traditional controls. That makes detection harder and increases the blast radius when an agent is connected to sensitive tools or data sources.

Affected Versions and Fixed Release

Cyera reported that the vulnerabilities affect OpenClaw versions prior to the April 2026 patches. CVE database entries for CVE-2026-44118 identify OpenClaw before 2026.4.22 as affected.

OpenClaw users should update to version 2026.4.22 or later to receive the fixes for the Claw Chain vulnerabilities.

Security teams should confirm the installed OpenClaw version across all environments, including developer machines, self-hosted agent servers, automation hosts, staging environments, and public-facing deployments.

Recommended Mitigation Steps

OpenClaw users should take the following actions immediately:

Upgrade OpenClaw to 2026.4.22 or later.
Review all OpenClaw deployments, including local developer instances and cloud-hosted agent runtimes.
Audit installed plugins, skills, and third-party integrations.
Remove untrusted or unused plugins from agent environments.
Restrict agent access to sensitive files, secrets, and configuration directories.
Rotate credentials that may have been accessible to OpenClaw agents.
Review logs for unusual file reads, writes, shell commands, cron changes, and gateway configuration updates.
Apply least privilege to agent runtime accounts.
Limit network exposure of OpenClaw services and loopback-accessible gateways.
Require human approval for high-risk actions such as shell execution, credential access, configuration changes, and scheduled tasks.

Detection Guidance

Defenders should review OpenClaw and host-level telemetry for suspicious behavior that may indicate exploitation or attempted exploitation.

Useful signals include:

Unexpected reads of sensitive files outside the sandbox mount root.
Unexpected writes to configuration files, startup scripts, cron jobs, or plugin directories.
Use of shell expansion tokens inside heredoc bodies.
Execution of commands that were not expected from approved workflows.
Changes to gateway configuration or execution environment settings.
Owner-only actions initiated by non-owner clients.
New scheduled tasks, startup hooks, or suspicious persistence mechanisms.
Outbound connections from agent processes to unknown destinations.

Because agent behavior can look legitimate, detection should combine application logs, host telemetry, process monitoring, filesystem monitoring, and identity context.

Why AI Agent Security Needs a Different Approach

Traditional application security often focuses on user input, authentication, authorization, and server-side code execution. AI-agent security must include all of those areas, but it also needs to account for tool use, prompt influence, plugin supply chains, filesystem access, autonomous decisions, and long-running memory or workflow state.

The Claw Chain vulnerabilities show that agent security failures can happen across multiple layers at once. A prompt injection may influence execution, a sandbox escape may expose files, an access-control flaw may elevate privileges, and a write escape may enable persistence.

Organizations using agent platforms should apply zero-trust principles to agent runtimes. Agents should not be trusted simply because they run locally or act on behalf of a user. Every file access, command execution, plugin action, and privileged operation should be constrained and auditable.

How Vulert Can Help

Vulert helps developers and security teams stay ahead of vulnerabilities by continuously monitoring open-source dependencies and software components without requiring access to source code.

Vulert can analyze manifest files and SBOMs such as package-lock.json, yarn.lock, composer.lock, requirements.txt, pom.xml, go.sum, Gemfile.lock, Cargo.lock, SPDX SBOMs, and CycloneDX SBOMs.

For vulnerabilities like the OpenClaw flaws, fast visibility is essential. Vulert helps teams identify affected components, understand fixed versions, and respond quickly before attackers can abuse vulnerable software in production environments.

You can review the vulnerabilities in the Vulert Vulnerability Database:

Conclusion

The four OpenClaw flaws known as Claw Chain demonstrate how AI-agent vulnerabilities can create a complete attack path from initial execution to data theft, privilege escalation, and persistence. The vulnerabilities affect sandbox boundaries, command validation, file access, and owner-level authorization.

OpenClaw users should upgrade to 2026.4.22 or later, audit plugins and workflows, rotate exposed credentials, review logs for suspicious file and command activity, and apply least privilege to agent runtimes.

As AI agents gain more access to enterprise systems, they become powerful automation tools and high-value attack surfaces. Organizations should secure them with the same seriousness applied to servers, CI/CD systems, cloud credentials, and production applications.

FAQs

What are the OpenClaw flaws?

The OpenClaw flaws are four chainable vulnerabilities tracked as CVE-2026-44112, CVE-2026-44113, CVE-2026-44115, and CVE-2026-44118. They can enable data theft, privilege escalation, sandbox escape, and persistence.

Why are AI-agent vulnerabilities dangerous?

AI agents often have access to files, credentials, tools, APIs, and execution environments. If compromised, attackers can use the agent’s own permissions to steal data, escalate privileges, or establish persistence.

How can Vulert help?

Vulert helps teams monitor vulnerabilities, identify affected components, and receive alerts using manifest files and SBOMs without requiring source code access.

NGINX CVE-2026-42945 Exploited in the Wild, Causing Worker Crashes and Possible RCE

Vulert — Mon, 18 May 2026 07:12:10 +0000

NGINX CVE-2026-42945 is a newly disclosed heap buffer overflow vulnerability affecting NGINX Open Source and NGINX Plus. The flaw exists in the ngx_http_rewrite_module module and has reportedly come under active exploitation in the wild shortly after public disclosure.

The vulnerability carries a CVSS v4.0 score of 9.2 and can allow an unauthenticated attacker to crash NGINX worker processes using crafted HTTP requests. Under specific conditions, remote code execution may also be possible, especially on systems where Address Space Layout Randomization, or ASLR, is disabled.

NGINX is widely used as a web server, reverse proxy, API gateway, load balancer, and ingress component. Because of its broad deployment across production infrastructure, organizations should treat this vulnerability as urgent and apply fixes immediately.

What is NGINX CVE-2026-42945?

CVE-2026-42945 is a heap buffer overflow vulnerability in NGINX’s ngx_http_rewrite_module. The flaw affects certain rewrite configurations involving unnamed Perl-Compatible Regular Expression captures, such as $1 or $2, combined with a replacement string containing a question mark.

According to public vulnerability descriptions, the vulnerable condition exists when a rewrite directive is followed by another rewrite, if, or set directive, and the rewrite logic uses unnamed PCRE captures with a question mark in the replacement string.

An attacker who can send crafted HTTP requests to a vulnerable NGINX configuration may trigger memory corruption in the worker process. The most direct impact is a worker crash and restart. In more dangerous scenarios, code execution may be possible, although reliable exploitation depends on environmental factors and memory protections.

Affected NGINX Versions

The vulnerability affects NGINX Open Source versions 0.6.27 through 1.30.0. Fixed versions include:

NGINX Open Source 1.30.1
NGINX Open Source 1.31.0

For NGINX Plus, administrators should review F5’s official advisory and upgrade to the relevant fixed releases for their branch, including fixed NGINX Plus releases such as R36 P4 and R32 P6, where applicable.

Security teams should inventory all NGINX deployments, including standalone servers, containers, load balancers, reverse proxies, Kubernetes ingress controllers, API gateways, and embedded NGINX builds inside appliances or platform images.

Why CVE-2026-42945 is Dangerous

The danger of NGINX CVE-2026-42945 comes from a combination of broad exposure, unauthenticated attack access, and active exploitation. NGINX often sits directly on the internet and handles all incoming traffic before requests reach the application layer.

A worker crash can still have serious consequences. If attackers repeatedly trigger crashes, they may disrupt active connections, degrade service availability, interrupt API traffic, and create instability across high-traffic environments.

The possible remote code execution risk makes the issue even more concerning. Public analysis indicates that RCE requires stricter conditions, including a vulnerable configuration and, in many cases, reduced memory protections such as disabled ASLR. However, defenders should not assume that exploitation is impossible. Memory corruption vulnerabilities can evolve as attackers refine techniques.

Active Exploitation Reported

VulnCheck has reported exploitation attempts against honeypot networks after the vulnerability became public. The exact goals of the observed activity remain unclear, but active scanning and exploitation attempts mean defenders should move quickly.

Threat actors often adopt newly disclosed vulnerabilities rapidly, especially when they affect internet-facing infrastructure. Even if a reliable RCE exploit is difficult, denial-of-service through worker crashes may be easier to trigger and can still cause business disruption.

Organizations should assume exposed NGINX instances may be probed and should prioritize patching, configuration review, and monitoring for crash patterns.

Technical Overview

At a high level, CVE-2026-42945 is triggered by specific rewrite-module behavior. The risk condition involves:

Use of ngx_http_rewrite_module
A rewrite directive followed by rewrite, if, or set
Unnamed PCRE capture references such as $1 or $2
A replacement string that contains a question mark ?
Crafted HTTP requests that reach the vulnerable configuration path

The result may be a heap buffer overflow in the NGINX worker process. Since NGINX uses worker processes to handle requests, a crash may cause the worker to restart. In production environments, repeated crashes can cause dropped requests and service instability.

The vulnerability requires a specific configuration pattern, so not every NGINX deployment is equally exposed. However, because rewrite rules are common in web routing, redirects, legacy URL handling, API gateways, and reverse proxy setups, administrators should review configurations carefully.

How to Check Your NGINX Version

Administrators can check the installed NGINX version with:

nginx -v

For more detailed build information, use:

nginx -V

If the output shows an affected version, prioritize upgrading to a fixed release. For containerized environments, check the NGINX version inside the running container image, not only on the host system.

How to Search for Risky Rewrite Rules

Administrators should review NGINX configuration files for rewrite rules that use unnamed captures and question marks in replacement strings. Common locations include:

/etc/nginx/nginx.conf
/etc/nginx/conf.d/*.conf
/etc/nginx/sites-enabled/*
/usr/local/nginx/conf/nginx.conf

You can start by searching for rewrite directives:

grep -R "rewrite" /etc/nginx/

Also review nearby if, set, and additional rewrite directives in the same block. If your configuration uses unnamed captures such as $1 or $2, evaluate whether named captures can be used instead and apply vendor guidance.

Recommended Mitigation Steps

The safest mitigation is to upgrade to a fixed version. Security teams should take the following actions:

Upgrade NGINX Open Source to 1.30.1, 1.31.0, or a later fixed version.
Upgrade NGINX Plus to the fixed release recommended by F5 for your branch.
Review all rewrite rules for vulnerable patterns involving unnamed PCRE captures and question marks.
Use named captures where possible, following vendor guidance.
Verify that ASLR is enabled on Linux hosts.
Monitor for unexpected NGINX worker crashes, restarts, segmentation faults, or abnormal 5xx spikes.
Review container images and base images that include NGINX.
Restart or reload NGINX after applying updates and confirm the patched version is active.
Prioritize internet-facing NGINX servers, reverse proxies, ingress controllers, and API gateways.

Temporary configuration changes may reduce exposure if immediate upgrading is not possible, but patching should remain the primary remediation path.

ASLR and Remote Code Execution Risk

Address Space Layout Randomization is a memory protection mechanism that makes exploitation of memory corruption bugs more difficult. Public analysis notes that remote code execution is most practical when ASLR is disabled.

Administrators can check ASLR status on Linux with:

cat /proc/sys/kernel/randomize_va_space

A value of 2 generally indicates full ASLR. A value of 0 means ASLR is disabled and should be treated as a serious hardening gap.

To enable ASLR temporarily:

sudo sysctl -w kernel.randomize_va_space=2

To make it persistent, add the following to /etc/sysctl.conf or an appropriate sysctl configuration file:

kernel.randomize_va_space = 2

Enabling ASLR is not a replacement for patching, but it is an important layer of defense against memory corruption exploitation.

Kubernetes and Ingress Considerations

Kubernetes environments may also be exposed if NGINX is embedded inside ingress controller images. In these deployments, the host system’s NGINX version may not matter. What matters is the NGINX version compiled into the controller image.

Administrators should check the ingress controller version and image details. For NGINX-based ingress controllers, review the project’s security guidance and confirm whether the embedded NGINX build includes a fixed version.

Teams should also review ingress annotations and rewrite-target configurations, especially where regex capture groups are used for routing or rewriting paths.

Detection Guidance

Organizations should monitor for signs of exploitation attempts and operational impact. Useful signals include:

Repeated NGINX worker process crashes
Unexpected NGINX restarts
Segmentation fault messages in system logs
Sudden increases in HTTP 502, 503, or 504 responses
Suspicious requests targeting rewrite-heavy routes
Unusual request patterns with encoded characters or question marks
High request volume from unknown IPs against redirect or rewrite endpoints

Check NGINX error logs and system logs:

/var/log/nginx/error.log
/var/log/nginx/access.log
journalctl -u nginx
dmesg

If worker crashes are observed, preserve logs before restarting or rebuilding systems. Correlate timestamps with access logs to identify the request paths and source IP addresses involved.

Related openDCIM Exploitation Activity

VulnCheck also reported exploitation activity targeting critical openDCIM vulnerabilities, including CVE-2026-28515 and CVE-2026-28517. These issues involve missing authorization and operating system command injection, and they may be chained with other flaws to achieve remote code execution.

While openDCIM is separate from NGINX, the timing is important. It shows that attackers continue to move quickly against newly disclosed internet-facing infrastructure vulnerabilities. Organizations should review both web server exposure and application-layer management tools.

How Vulert Can Help

Vulert helps developers and security teams stay ahead of vulnerabilities by continuously monitoring open-source dependencies and software components without requiring access to source code.

For vulnerabilities like NGINX CVE-2026-42945, fast alerts and clear affected-version visibility are critical. Vulert helps teams identify vulnerable components, understand the fixed versions, and respond quickly when active exploitation begins.

You can review this vulnerability in the Vulert Vulnerability Database:
CVE-2026-42945 Vulnerability Details.

Conclusion

NGINX CVE-2026-42945 is a serious heap buffer overflow vulnerability in ngx_http_rewrite_module. It affects NGINX Open Source versions 0.6.27 through 1.30.0 and relevant NGINX Plus releases. The vulnerability can cause worker crashes and may allow remote code execution under specific conditions.

Active exploitation has already been reported, so organizations should not delay remediation. Upgrade to fixed versions, review rewrite configurations, verify ASLR is enabled, monitor for worker crashes, and inspect internet-facing NGINX systems first.

NGINX is often the front door to critical applications. A vulnerability at this layer can disrupt services and expose organizations to broader risk. Fast patching and continuous vulnerability monitoring are essential.

FAQs

What is CVE-2026-42945?

CVE-2026-42945 is a heap buffer overflow vulnerability in NGINX’s ngx_http_rewrite_module that can cause worker crashes and possible remote code execution.

Can CVE-2026-42945 lead to remote code execution?

Possible remote code execution has been reported under specific conditions, especially where ASLR is disabled. The easier and more direct impact is worker-process crash and denial-of-service.

How can Vulert help?

Vulert helps teams monitor vulnerabilities, identify affected components, and receive alerts using manifest files and SBOMs without requiring source code access.

PraisonAI CVE-2026-44338 Auth Bypass Targeted Within Hours of Disclosure

Vulert — Mon, 18 May 2026 07:03:09 +0000

CVE-2026-44338 is a newly disclosed authentication bypass vulnerability in PraisonAI, an open-source multi-agent orchestration framework. The vulnerability allows unauthenticated access to sensitive API endpoints when the legacy Flask API server is used.

The issue is serious because threat actors were observed probing vulnerable PraisonAI instances within hours of public disclosure. According to Sysdig, targeted scanning began less than four hours after the advisory was published, showing how quickly attackers are now reacting to vulnerabilities in AI and agent-based frameworks.

The vulnerability affects PraisonAI versions 2.5.6 through 4.6.33 and has been patched in version 4.6.34. Users should upgrade immediately, audit exposed deployments, review model provider billing, and rotate credentials referenced in agents.yaml.

What is CVE-2026-44338?

CVE-2026-44338 is a missing authentication vulnerability in PraisonAI’s legacy Flask-based API server. The vulnerable server component, src/praisonai/api_server.py, shipped with authentication disabled by default.

In the vulnerable configuration, the server hard-codes AUTH_ENABLED = False and AUTH_TOKEN = None. As a result, any caller who can reach the API server may access protected functionality without providing an authentication token.

The most important exposed endpoints are:

GET /agents — exposes configured agent metadata and the agent file name.
POST /chat — can trigger the locally configured agents.yaml workflow.

This means an attacker does not need credentials to enumerate agent configuration or trigger agent workflows if the vulnerable legacy server is exposed.

Affected PraisonAI Versions

The affected versions are:

PraisonAI 2.5.6 through 4.6.33

The fixed version is:

PraisonAI 4.6.34

If your deployment is using the legacy Flask API server from an affected PraisonAI version, you should treat it as vulnerable until upgraded or isolated.

Why This Vulnerability Matters

CVE-2026-44338 is not just a simple missing-login bug. In an AI-agent environment, triggering an exposed workflow can have unpredictable consequences depending on what the configured agents are allowed to do.

If agents.yaml connects to external tools, model providers, file systems, internal APIs, databases, cloud resources, or messaging services, an unauthenticated attacker may be able to abuse those workflows indirectly.

The impact depends on the operator’s configuration, but possible risks include:

Unauthenticated enumeration of configured agents through /agents.
Unauthenticated triggering of workflows through /chat.
Consumption of model or API quota.
Exposure of agent execution results.
Abuse of tools or integrations connected to the agent workflow.
Potential exposure of sensitive prompts, workflow design, or internal automation logic.

Targeted Within Hours of Disclosure

Sysdig reported that exploitation attempts began extremely quickly after public disclosure. The advisory was published on May 11, 2026 at 13:56 UTC, and the first targeted request against the vulnerable path was observed at 17:40 UTC the same day.

The observed scanner used the user agent CVE-Detector/1.0 and sent a request to GET /agents without an Authorization header. According to Sysdig, the request returned 200 OK, confirming that the bypass was successful on the probed instance.

The activity appeared to be reconnaissance rather than full exploitation. Sysdig did not observe a POST /chat request during the scanning passes. However, the speed of the activity shows that attackers are quickly adding AI-framework vulnerabilities to their scanning workflows.

Indicators of Compromise

Security teams should review logs for the following indicators associated with reported scanning activity:

Source IP: 146.190.133.49
User-Agent: CVE-Detector/1.0
Endpoint: GET /agents
Missing Authorization header

Defenders should also review requests to AI-agent-related endpoints such as:

/agents
/chat
/api/agents
/api/agents/config
/praisonai/version.txt
/docs

Generic probing paths such as /.env, /admin, /users/sign_in, /eval, /calculate, and /Gemfile.lock may also appear in reconnaissance activity.

Why AI-Agent Vulnerabilities Are Becoming High-Risk

AI-agent frameworks are increasingly used to automate workflows, connect tools, call APIs, process files, and interact with external systems. This makes authentication and access control critical.

A traditional unauthenticated endpoint might expose data or allow a single action. In an AI-agent system, an unauthenticated workflow trigger could potentially execute a chain of tasks, call external services, consume paid model quota, or expose results from connected systems.

This is why authentication-disabled-by-default configurations are especially risky in AI infrastructure. If exposed to the internet, attackers can find and test them quickly.

Recommended Mitigation Steps

Users and administrators should take the following actions immediately:

Upgrade PraisonAI to 4.6.34 or later.
Migrate away from the legacy api_server.py entry point.
Do not expose PraisonAI API services directly to the internet.
Bind development-only services to 127.0.0.1 or a private network.
Require authentication for all agent APIs.
Review access logs for GET /agents and POST /chat requests without Authorization headers.
Look for the CVE-Detector/1.0 user agent in logs.
Audit model provider billing from May 11, 2026 onward.
Rotate any credentials, API keys, tokens, or secrets referenced in agents.yaml.
Review agent workflows to ensure they do not expose sensitive files, internal APIs, or privileged automation.

Detection Guidance

Until all deployments are upgraded, defenders should add network and application-layer monitoring for unauthenticated access to PraisonAI endpoints.

Useful detection logic includes:

Alert on GET /agents requests without an Authorization header.
Alert on POST /chat requests without an Authorization header.
Alert on requests with User-Agent: CVE-Detector/1.0.
Review traffic to Python package fingerprinting paths such as /pyproject.toml, /poetry.lock, and /requirements.txt.
Monitor for unusual Python subprocess creation after agent workflow execution.
Monitor unexpected outbound network connections from agent processes.
Review unexpected file writes triggered by agent workflows.

Because successful unauthenticated requests may look similar to legitimate requests in application logs, perimeter logs, reverse proxy logs, and WAF telemetry are especially important.

Impact on Model Billing and API Quotas

One practical risk of CVE-2026-44338 is abuse of model provider quotas. If an attacker can trigger workflows through /chat, they may cause repeated model calls and increase costs.

Teams should review billing and usage dashboards for OpenAI, Anthropic, Google, Azure AI, AWS Bedrock, or any other provider connected to PraisonAI workflows. Look for unusual spikes, unexpected prompts, abnormal token usage, or activity from unfamiliar IP addresses.

If suspicious activity is found, rotate API keys and review whether the agent workflow exposed sensitive data in prompts or responses.

How Vulert Can Help

Vulert helps developers and security teams monitor open-source dependencies and software vulnerabilities without requiring access to source code.

For vulnerabilities like CVE-2026-44338, fast alerts matter. Attackers began probing exposed PraisonAI instances within hours of disclosure, so teams need rapid visibility into affected components and fixed versions.

You can review this vulnerability in the Vulert Vulnerability Database: CVE-2026-44338 Vulnerability Details.

Conclusion

CVE-2026-44338 is a high-risk authentication bypass vulnerability in PraisonAI’s legacy Flask API server. It affects versions 2.5.6 through 4.6.33 and is fixed in 4.6.34.

The vulnerability exposes sensitive endpoints such as /agents and /chat, allowing unauthenticated users to enumerate agent configuration and potentially trigger configured workflows. Because those workflows may connect to models, tools, APIs, and internal resources, the real-world impact depends heavily on deployment configuration.

The most important lesson is speed. Sysdig observed targeted probing less than four hours after disclosure, showing that AI and agent frameworks are now part of rapid attacker scanning pipelines. Users should upgrade immediately, remove public exposure, enforce authentication, review logs, audit billing, and rotate credentials referenced in agents.yaml.

FAQs

What is CVE-2026-44338?

CVE-2026-44338 is a missing authentication vulnerability in PraisonAI’s legacy Flask API server that allows unauthenticated access to sensitive endpoints.

What should PraisonAI users do now?

Users should upgrade to 4.6.34 or later, avoid exposing the API publicly, enforce authentication, review logs, audit model billing, and rotate credentials referenced in agents.yaml.

How can Vulert help?

Vulert helps teams monitor vulnerabilities, identify affected dependencies, and receive alerts using manifest files and SBOMs without requiring source code access.

CISA Adds Cisco SD-WAN CVE-2026-20182 to KEV After Admin Access Exploits

Vulert — Mon, 18 May 2026 06:58:54 +0000

CVE-2026-20182 is a critical authentication bypass vulnerability affecting Cisco Catalyst SD-WAN Controller and Cisco Catalyst SD-WAN Manager. The flaw has received a maximum CVSS score of 10.0, meaning it represents the highest level of severity.

The U.S. Cybersecurity and Infrastructure Security Agency has added CVE-2026-20182 to its Known Exploited Vulnerabilities catalog after evidence of active exploitation. Federal Civilian Executive Branch agencies are required to remediate the issue by May 17, 2026.

Cisco has confirmed that successful exploitation could allow an unauthenticated, remote attacker to bypass authentication and obtain administrative privileges on an affected system. Because Cisco SD-WAN controllers manage routing, policies, and connectivity across distributed environments, compromise of this layer can create serious enterprise-wide risk.

What is CVE-2026-20182?

CVE-2026-20182 is an authentication bypass vulnerability in Cisco Catalyst SD-WAN Controller, formerly known as SD-WAN vSmart, and Cisco Catalyst SD-WAN Manager, formerly known as SD-WAN vManage.

The vulnerability exists in peering authentication and control connection handling. According to Cisco, an unauthenticated remote attacker may exploit the issue to bypass authentication and gain administrative privileges on an affected system.

This makes CVE-2026-20182 especially dangerous because exploitation does not require valid credentials, prior access, or user interaction. A remote attacker who can reach the affected service may be able to gain administrative access.

Why CVE-2026-20182 is Critical

The risk is not limited to one device. Cisco Catalyst SD-WAN controllers are part of the control plane that helps manage SD-WAN routing, policies, overlays, device relationships, and network behavior. If attackers gain administrative access to this layer, they may be able to affect how traffic flows across the organization.

Cisco’s advisory lists no workarounds for this vulnerability. That means organizations should not rely on temporary configuration changes as a substitute for upgrading. The primary defense is to follow Cisco’s fixed-release guidance and apply the required updates as quickly as possible.

The vulnerability is also more urgent because CISA added it to the KEV catalog. KEV inclusion means the vulnerability is known to be exploited in real-world attacks and should be prioritized immediately.

CISA KEV Deadline: May 17, 2026

CISA added CVE-2026-20182 to the Known Exploited Vulnerabilities catalog on May 14, 2026. The remediation due date for Federal Civilian Executive Branch agencies is May 17, 2026.

Even if your organization is not a U.S. federal agency, CISA KEV listing should be treated as a strong warning. Attackers are already exploiting the vulnerability, and unpatched SD-WAN infrastructure may be targeted quickly.

Active Exploitation Linked to UAT-8616

Cisco Talos attributes exploitation activity involving CVE-2026-20182 with high confidence to a threat cluster tracked as UAT-8616. This is the same cluster previously associated with exploitation of CVE-2026-20127, another Cisco Catalyst SD-WAN authentication bypass vulnerability.

Cisco Talos observed similar post-compromise behavior after exploitation. Reported actions include attempts to add SSH keys, modify NETCONF configurations, and escalate to root privileges.

These actions are important because they suggest attackers are not only gaining initial access. They may be attempting to establish persistence, manipulate SD-WAN configuration, and expand control over compromised environments.

Related Cisco SD-WAN Exploitation Activity

Cisco Talos has also tracked multiple threat clusters exploiting related Cisco SD-WAN vulnerabilities, including CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122. When chained together, those vulnerabilities can allow remote unauthenticated attackers to gain unauthorized access to affected devices.

Public reporting has linked exploitation activity to web shell deployment, command execution, credential theft, cryptocurrency mining, proxy tools, and post-exploitation frameworks such as Sliver and AdaptixC2-based tooling.

The broader pattern shows that Cisco SD-WAN infrastructure has become an attractive target for multiple threat clusters. Organizations should not treat CVE-2026-20182 as an isolated issue. It should be handled as part of a larger SD-WAN security review.

Potential Impact of CVE-2026-20182

Successful exploitation of CVE-2026-20182 may allow attackers to gain administrative privileges on Cisco Catalyst SD-WAN systems. The potential impact includes:

Unauthorized administrative access to SD-WAN controller or manager systems
Modification of SD-WAN and NETCONF configurations
Addition of unauthorized SSH keys for persistence
Possible escalation attempts toward root privileges
Deployment of web shells or post-exploitation tooling
Credential theft, including administrative hashes, JWT-related material, or cloud credentials
Manipulation of routing, policies, and traffic flows across the SD-WAN environment

For organizations that depend on Cisco SD-WAN for branch connectivity, data center routing, cloud access, or global network management, this type of compromise could have wide operational and security consequences.

Affected Products

The vulnerability affects:

Cisco Catalyst SD-WAN Controller, formerly SD-WAN vSmart
Cisco Catalyst SD-WAN Manager, formerly SD-WAN vManage

Administrators should review Cisco’s official advisory for exact affected releases and fixed-release information. Cisco has stated that there are no workarounds, so upgrading to a fixed version is essential.

Recommended Actions for Security Teams

Organizations using Cisco Catalyst SD-WAN should act immediately. Recommended actions include:

Review Cisco’s official advisory for CVE-2026-20182.
Upgrade affected Cisco Catalyst SD-WAN Controller and Manager systems to fixed releases.
Do not delay patching while waiting for investigation results if systems are exposed.
Identify whether management or control-plane services are reachable from untrusted networks.
Restrict access to SD-WAN management interfaces and control-plane services.
Review control connection and peering logs for unexpected activity.
Check for unauthorized SSH keys added to administrative accounts.
Review NETCONF configuration changes for suspicious modifications.
Inspect for web shells, unusual JSP files, or unexpected command execution.
Search for post-exploitation tools such as Sliver, AdaptixC2-based agents, XMRig, KScan, gsocket, or unknown Nim-based binaries.
Rotate credentials and review tokens if compromise is suspected.
Preserve logs and forensic evidence before rebuilding or restoring systems.

Detection and Investigation Guidance

Defenders should look for indicators of compromise related to unauthorized SD-WAN peering, unexpected administrative activity, suspicious configuration changes, and new persistence mechanisms.

High-priority areas to review include:

Control connection events
Unexpected peer relationships
New or modified SSH authorized keys
NETCONF activity on management interfaces
Unexpected JSP files or web shell artifacts
Unusual bash command execution
Unknown binaries or miners on SD-WAN systems
Suspicious access to REST API authentication material
Unexpected access to AWS credentials or cloud-related secrets

If compromise is suspected, organizations should involve incident response teams quickly. SD-WAN control-plane compromise can affect routing trust, administrative control, and the integrity of network policy.

Why SD-WAN Controllers Are High-Value Targets

SD-WAN controllers are valuable because they manage connectivity across branches, data centers, cloud environments, remote sites, and enterprise applications. They sit close to the network control layer, which makes them attractive for attackers seeking persistence, traffic manipulation, credential theft, or broader network access.

A compromised SD-WAN controller may allow attackers to influence how traffic is routed, inspect sensitive network paths, modify policies, or maintain access across distributed infrastructure. This is why authentication bypass vulnerabilities in SD-WAN products deserve immediate prioritization.

How Vulert Can Help

Vulert helps developers and security teams stay ahead of vulnerabilities by continuously monitoring software components and open-source dependencies without requiring access to source code.

For fast-moving vulnerabilities like CVE-2026-20182, timely vulnerability intelligence is critical. Vulert helps teams track disclosed vulnerabilities, understand affected components, and respond faster when new advisories or fixes are released.

You can review this vulnerability in the Vulert Vulnerability Database: CVE-2026-20182 Vulnerability Details.

Conclusion

CVE-2026-20182 is a maximum-severity authentication bypass vulnerability affecting Cisco Catalyst SD-WAN Controller and Manager. With a CVSS score of 10.0, active exploitation, and CISA KEV inclusion, this vulnerability should be treated as an emergency patching priority.

Cisco has stated that there are no workarounds, so affected organizations should upgrade to fixed releases immediately. Security teams should also investigate for signs of compromise, including unauthorized SSH keys, NETCONF configuration changes, unexpected peering events, web shells, credential theft activity, and post-exploitation tooling.

SD-WAN infrastructure is a high-value target because it controls enterprise connectivity and policy. Fast patching, exposure reduction, log review, credential rotation, and continuous monitoring are essential to reducing risk from CVE-2026-20182 and related Cisco SD-WAN exploitation activity.

FAQs

What is CVE-2026-20182?

CVE-2026-20182 is a critical authentication bypass vulnerability in Cisco Catalyst SD-WAN Controller and Manager that can allow an unauthenticated remote attacker to obtain administrative privileges.

What is the CISA KEV deadline?

CISA listed a remediation due date of May 17, 2026, for Federal Civilian Executive Branch agencies.

How can Vulert help?

Vulert helps teams monitor vulnerabilities, track affected components, and receive alerts using manifest files and SBOMs without requiring access to source code.

On-Prem Microsoft Exchange Server CVE-2026-42897 Exploited via Crafted Email

Vulert — Mon, 18 May 2026 06:54:32 +0000

CVE-2026-42897 is a newly disclosed Microsoft Exchange Server vulnerability that has already been marked as exploited in the wild. The flaw affects on-premises Microsoft Exchange Server environments and can be triggered through a specially crafted email when opened in Outlook Web Access, also known as OWA.

Microsoft describes CVE-2026-42897 as a spoofing vulnerability caused by improper neutralization of input during web page generation, commonly known as cross-site scripting or XSS. The vulnerability has a CVSS score of 8.1, making it a high-severity issue that Exchange administrators should treat as urgent.

The good news is that Exchange Online is not impacted. The risk applies to on-premises Exchange Server installations, including Exchange Server 2016, Exchange Server 2019, and Exchange Server Subscription Edition.

What is CVE-2026-42897?

CVE-2026-42897 is a Microsoft Exchange Server spoofing vulnerability tied to a cross-site scripting weakness in Outlook Web Access. An unauthenticated attacker may exploit the issue by sending a crafted email to a target user.

If the victim opens the malicious email in OWA and certain interaction conditions are met, arbitrary JavaScript may execute in the user’s browser context. This could allow attackers to perform spoofing actions, manipulate what the user sees, or potentially abuse the user’s authenticated web session depending on the environment and attack chain.

Microsoft has tagged this vulnerability with an “Exploitation Detected” assessment, which means defenders should not treat this as a theoretical issue. Even though public details about the attacks remain limited, active exploitation raises the urgency for mitigation.

Why This Exchange Server Vulnerability Matters

Microsoft Exchange Server is a high-value target for attackers because it handles email, authentication flows, sensitive communications, business records, attachments, and user access. Even vulnerabilities that appear to target the browser layer can create serious enterprise risk when they affect OWA.

OWA is commonly exposed to the internet so users can access email through a browser. If an attacker can trigger script execution through a crafted email, the attack path becomes especially concerning because email is already a trusted communication channel inside most organizations.

CVE-2026-42897 is not described as remote code execution on the Exchange server itself. However, browser-context JavaScript execution inside OWA can still be dangerous. It may support spoofing, session abuse, phishing-like actions, user deception, or follow-on attacks against sensitive mailbox content.

Affected Microsoft Exchange Server Versions

The following on-premises Exchange Server versions are affected:

Microsoft Exchange Server 2016 — any update level
Microsoft Exchange Server 2019 — any update level
Microsoft Exchange Server Subscription Edition — any update levelMicrosoft has confirmed that Exchange Online is not affected by this vulnerability. Organizations using hybrid Exchange should carefully determine whether any on-premises OWA endpoints remain exposed and whether any mailboxes or workflows still rely on them.

How the Attack Works at a High Level

The attack begins with a crafted email sent to a target user. If the user opens that message in Outlook Web Access and certain interaction conditions are met, the vulnerability can allow JavaScript execution in the browser context.

From a defender’s perspective, the important point is that exploitation depends on OWA handling of email content and browser-side execution. This makes user interaction and OWA exposure important factors in risk assessment.

Microsoft has not publicly shared full details about the threat actor, targets, scale of exploitation, or whether attacks have been successful. Until more information is available, administrators should assume that internet-facing OWA systems may be targeted.

Microsoft Emergency Mitigation for CVE-2026-42897

Microsoft is providing a temporary mitigation through the Exchange Emergency Mitigation Service, also known as EEMS. This mitigation is delivered using a URL Rewrite configuration and is enabled by default in supported Exchange environments.

Administrators should verify that EEMS is enabled and that the mitigation has been applied. Microsoft is also preparing a permanent fix, but until then, the mitigation should be applied immediately.

To check whether mitigations are enabled at the organization level, administrators can use:

Get-OrganizationConfig | Format-Table MitigationsEnabled

To check Exchange servers individually, use:

Get-ExchangeServer | Format-Table Name,MitigationsEnabled,MitigationsApplied

If the mitigation is applied successfully, administrators may see mitigation details such as M2.1.0 depending on the server state and configuration.

Manual Mitigation Using EOMT

If Exchange Emergency Mitigation Service cannot be used, such as in air-gapped environments, Microsoft recommends using the latest version of the Exchange On-premises Mitigation Tool, also known as EOMT.

Download the latest EOMT from Microsoft’s official short link:

https://aka.ms/UnifiedEOMT

To apply the mitigation on a single server, run the following command from an elevated Exchange Management Shell:

.\EOMT.ps1 -CVE "CVE-2026-42897"

To apply the mitigation across all non-Edge Exchange servers, run:

Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897"

Administrators should apply the mitigation on every affected on-premises Exchange server and then verify the mitigation status.

Known Mitigation Message Issue

Microsoft has noted a cosmetic issue where the mitigation may show “Mitigation invalid for this exchange version” in the Description field. According to Microsoft, the mitigation still applies successfully if the status shows “Applied”.

This means administrators should not rely only on the description text. They should confirm the actual mitigation status and review Microsoft’s latest Exchange Team guidance for updates.

Recommended Actions for Exchange Administrators

Organizations running on-premises Exchange Server should take the following actions immediately:

Confirm whether Exchange Server 2016, Exchange Server 2019, or Exchange Server SE is deployed.
Identify whether Outlook Web Access is exposed to the internet.
Verify that Exchange Emergency Mitigation Service is enabled.
Confirm that the CVE-2026-42897 mitigation has been applied.
If EEMS is not available, apply the mitigation manually using EOMT.
Monitor Microsoft’s official advisory for the permanent security update.
Review OWA access logs for suspicious activity.
Restrict external OWA access where it is not required.
Educate users to be cautious with unexpected emails opened in webmail.
Review hybrid Exchange deployments and remove unnecessary public exposure.If your organization has migrated mailboxes to Exchange Online but still keeps on-premises Exchange for hybrid management, review whether public OWA access is still necessary. Reducing unnecessary exposure can significantly lower risk.

Why Exchange Vulnerabilities Are High-Value Targets

Exchange Server vulnerabilities have historically attracted rapid attention from threat actors. Email servers are valuable because they contain sensitive business communications, credentials, attachments, internal documents, financial data, legal records, and operational workflows.

Attackers often use Exchange vulnerabilities for espionage, mailbox access, credential theft, persistence, lateral movement, and phishing from trusted internal accounts. Even when a vulnerability does not directly provide server-side code execution, it may still support broader attack chains.

That is why CVE-2026-42897 should be handled quickly. Active exploitation means attackers are already aware of the issue and may be testing exposed environments.

Exchange Online Is Not Impacted

Microsoft has stated that Exchange Online is not impacted by CVE-2026-42897. This is important for organizations that have fully moved their mailboxes to Microsoft 365.

However, hybrid environments should still be reviewed carefully. Some organizations keep on-premises Exchange servers for management, relay, legacy workflows, or partial mailbox migration. If OWA is still publicly reachable, the organization should verify whether it is needed and whether mitigations are applied.

How Vulert Can Help

Vulert helps developers and security teams stay ahead of vulnerabilities by continuously monitoring software components and open-source dependencies without requiring access to source code.

For fast-moving advisories like CVE-2026-42897, timely visibility is essential. Vulert helps teams track vulnerability intelligence, understand affected components, and respond faster when new threats, mitigations, or patches are released.

You can review this vulnerability in the Vulert Vulnerability Database:
CVE-2026-42897 Vulnerability Details.

Conclusion

CVE-2026-42897 is an actively exploited Microsoft Exchange Server vulnerability affecting on-premises OWA deployments. The flaw is caused by cross-site scripting and can be triggered through a crafted email when opened in Outlook Web Access under certain conditions.

Exchange Server 2016, Exchange Server 2019, and Exchange Server Subscription Edition are affected at any update level. Exchange Online is not impacted.

Until Microsoft releases a permanent fix, administrators should ensure that the Exchange Emergency Mitigation Service mitigation is applied or use EOMT to apply it manually. Exchange environments are high-value targets, so reducing exposure, monitoring logs, and applying mitigations quickly are critical steps.

FAQs

What is CVE-2026-42897?

CVE-2026-42897 is a Microsoft Exchange Server spoofing vulnerability caused by cross-site scripting in Outlook Web Access.

How can administrators mitigate CVE-2026-42897?

Administrators should use Exchange Emergency Mitigation Service or apply the mitigation manually with the Exchange On-premises Mitigation Tool.

How can Vulert help?

Vulert helps teams monitor vulnerabilities, identify affected components, and receive timely alerts using manifest files and SBOMs without requiring source code access.

Windows Zero-Days Expose BitLocker Bypass and CTFMON Privilege Escalation

Vulert — Mon, 18 May 2026 06:50:47 +0000

Windows zero-days are back in the spotlight after a cybersecurity researcher publicly disclosed two new flaws affecting Microsoft Windows environments. The vulnerabilities, named YellowKey and GreenPlasma, involve a BitLocker bypass and a privilege escalation issue tied to the Windows Collaborative Translation Framework, commonly associated with CTFMON.

The disclosure is concerning because BitLocker is widely used to protect encrypted drives, while privilege escalation vulnerabilities can help attackers gain higher access once they already have a foothold on a system. Although the full real-world impact is still being analyzed, security teams should treat these disclosures seriously and review their Windows hardening, endpoint protection, and physical security posture.

At the time of public reporting, these issues were described as zero-days, meaning dedicated patches or official CVE assignments may not yet be available. Organizations should monitor Microsoft advisories closely and apply mitigations where possible.

What Are YellowKey and GreenPlasma?

YellowKey is a reported BitLocker bypass involving the Windows Recovery Environment, also known as WinRE. WinRE is designed to help repair unbootable Windows systems, troubleshoot startup issues, and recover devices. Because WinRE operates close to the boot and recovery process, weaknesses in this area can create serious security concerns.

Public reporting says YellowKey affects Windows 11 and Windows Server 2022/2025. The flaw reportedly allows access to a command shell in a recovery context where BitLocker-protected data may already be unlocked. This makes the issue especially important for laptops, servers, and sensitive endpoints that rely on BitLocker to protect data if a device is stolen or accessed physically.

GreenPlasma is a separate Windows privilege escalation issue involving CTFMON behavior and arbitrary section object creation. In its current publicly released form, the proof-of-concept is reportedly incomplete, but the vulnerability may still allow an unprivileged user to create memory section objects in places that could be trusted by privileged services or drivers.

In simple terms, YellowKey is mainly a BitLocker bypass risk, while GreenPlasma is a local privilege escalation risk. Together, they show how boot security, recovery environments, and local Windows internals remain high-value targets for researchers and attackers.

Why These Windows Zero-Days Matter

These Windows zero-days matter because they target areas that many organizations depend on for baseline security: disk encryption and privilege separation.

BitLocker is commonly used to protect corporate laptops, developer machines, executive devices, and servers from offline data theft. If an attacker can bypass BitLocker protections through recovery or boot-level weaknesses, a stolen or physically accessed device may become much easier to compromise.

Privilege escalation vulnerabilities are also dangerous because they can turn limited access into full control. An attacker who starts with a standard user account may use a local privilege escalation flaw to gain SYSTEM-level permissions, disable protections, dump credentials, tamper with services, or move laterally inside an environment.

Even if these flaws require specific conditions, they should not be ignored. Modern attacks often combine several weaknesses: stolen credentials, physical access, misconfigured recovery settings, old boot components, unpatched endpoints, and weak monitoring.

YellowKey: BitLocker Bypass Risk in Windows Recovery Environment

YellowKey is the more attention-grabbing vulnerability because it targets BitLocker protections through the Windows Recovery Environment. BitLocker is designed to protect encrypted drives, especially when a device is lost, stolen, or accessed outside normal login controls.

The reported issue involves crafted recovery-related behavior that can lead to command execution in WinRE. Security researcher Will Dormann reportedly reproduced the issue with a USB drive attached and noted that Transactional NTFS-related behavior appeared capable of affecting files on another volume during recovery processing.

For defenders, the key concern is not the exploit mechanics but the security outcome: an attacker with the right access may be able to reach a command prompt in a context where protected data is exposed. This could weaken the trust many organizations place in default BitLocker configurations.

Organizations should pay close attention to devices that rely only on TPM-based BitLocker protection. In many enterprise environments, TPM-only BitLocker is common because it is user-friendly and does not require a startup PIN. However, recent BitLocker bypass research continues to show that physical-access attacks can become more practical when pre-boot authentication is not enforced.

GreenPlasma: CTFMON Privilege Escalation Risk

GreenPlasma is a reported privilege escalation vulnerability involving the Windows Collaborative Translation Framework and CTFMON-related behavior. CTFMON is associated with text input, language, keyboard, and input method functionality in Windows.

Public reporting describes GreenPlasma as an arbitrary section creation issue. The released proof-of-concept reportedly does not include a complete path to a full SYSTEM shell, but the primitive may still be useful for attackers in the right conditions.

Privilege escalation flaws are often used after initial access. For example, an attacker may first compromise a low-privileged account through phishing, malware, weak passwords, or another vulnerability. A local privilege escalation flaw can then help the attacker gain administrative or SYSTEM-level control.

Because GreenPlasma appears to involve low-level Windows object handling and trust boundaries, organizations should wait for official Microsoft guidance and avoid assuming the risk is low simply because the current public proof-of-concept is incomplete.

Connection to Earlier Defender Zero-Days

These disclosures follow earlier Microsoft Defender zero-days published by the same researcher, including flaws named BlueHammer, RedSun, and UnDefend. One of those issues, BlueHammer, was assigned CVE-2026-33825 and patched by Microsoft, while reporting suggests another issue may have been addressed without a dedicated public advisory.

This pattern highlights a broader challenge in vulnerability disclosure. When coordination between researchers and vendors breaks down, technical details can become public before patches are ready. That creates pressure for defenders because attackers may begin testing and weaponizing the information quickly.

For security teams, the practical lesson is clear: zero-day response cannot depend only on waiting for patches. Organizations also need hardening, monitoring, least privilege, endpoint detection, and incident response processes that reduce the damage of unpatched vulnerabilities.

BitLocker Downgrade Attack Adds More Concern

Separate from YellowKey, researchers also detailed a BitLocker downgrade attack involving CVE-2025-48804. This previously patched BitLocker issue involved acceptance of extraneous untrusted data with trusted data, allowing an unauthorized attacker to bypass a security feature through a physical attack.

The newer downgrade research shows that even after a vulnerability is patched, old signed boot components may continue to create risk if systems still trust outdated Secure Boot certificates. In simple terms, if a vulnerable old boot manager is still trusted by firmware, an attacker with physical access may be able to use it as part of an attack chain.

This is why Microsoft’s Secure Boot certificate transition is important. Microsoft has warned that older Secure Boot certificates issued in 2011 begin expiring in 2026, and devices need updated 2023 certificates to continue receiving early boot protections, revocation updates, and boot-level mitigations.

Affected Systems and Exposure

Based on public reporting, YellowKey is said to affect:

Windows 11
Windows Server 2022
Windows Server 2025

GreenPlasma affects Windows CTFMON-related behavior, but full affected-version details may remain unclear until Microsoft publishes official guidance or assigns identifiers.

The risk is highest for organizations with sensitive Windows endpoints, unmanaged physical access exposure, shared workstations, developer laptops, executive devices, domain-connected systems, and servers with weak hardening controls.

Recommended Mitigation Steps

Until official fixes or detailed Microsoft guidance are available, organizations should focus on practical risk reduction:

Monitor Microsoft Security Response Center updates for YellowKey, GreenPlasma, and related CVE assignments.
Keep Windows 11, Windows Server 2022, and Windows Server 2025 fully updated.
Enable BitLocker startup PINs for high-risk devices where operationally feasible.
Review WinRE configuration and disable unnecessary recovery exposure on sensitive systems where appropriate.
Restrict physical access to laptops, servers, workstations, and recovery media.
Update Secure Boot certificates to the 2023 trust anchors where required.
Review Secure Boot DB, DBX, and KEK update status across enterprise devices.
Apply least privilege to user accounts and avoid giving local admin access unnecessarily.
Monitor for suspicious local privilege escalation behavior, unusual process creation, and unexpected SYSTEM-level activity.
Use endpoint detection and response tools to identify abnormal boot, recovery, and privilege escalation patterns.

For organizations managing large fleets, prioritize high-risk assets first. Laptops used by executives, developers, administrators, and employees with access to sensitive data should receive the strongest controls.

Why BitLocker PINs Still Matter

Many organizations use BitLocker in TPM-only mode because it provides transparent encryption without requiring users to enter a PIN before Windows starts. This improves usability but can reduce protection against certain physical-access attacks.

A BitLocker startup PIN adds a pre-boot authentication layer. Even if an attacker has physical access to a device, the PIN makes it harder to access encrypted data or abuse recovery behavior. While no single control is perfect, startup PINs can significantly improve protection for high-value systems.

Security teams should evaluate where TPM-only BitLocker is acceptable and where stronger pre-boot authentication is needed. The answer may differ between ordinary workstations, executive laptops, developer machines, and servers.

How Vulert Can Help

Vulert helps developers and security teams stay ahead of vulnerabilities by continuously monitoring open-source dependencies and software components without requiring access to source code.

Teams can use Vulert with manifest files and SBOMs such as package-lock.json, yarn.lock, composer.lock, requirements.txt, pom.xml, go.sum, Gemfile.lock, Cargo.lock, SPDX SBOMs, and CycloneDX SBOMs.

For fast-moving threats like Windows zero-days, visibility is essential. Vulert helps teams track vulnerability intelligence, identify affected components, and respond faster when new disclosures, patches, or advisories are released.

You can review related vulnerability intelligence in the Vulert Vulnerability Database:
CVE-2025-48804 BitLocker Security Feature Bypass.

Conclusion

The disclosure of YellowKey and GreenPlasma shows that Windows security risks continue to evolve beyond traditional application vulnerabilities. Boot security, recovery environments, encryption workflows, and local privilege boundaries are all attractive targets.

YellowKey raises concern because it may weaken BitLocker protections through WinRE behavior, while GreenPlasma highlights local privilege escalation risk through CTFMON-related internals. At the same time, BitLocker downgrade research involving older boot components and Secure Boot certificates shows why patching alone is not always enough.

Organizations should keep systems updated, monitor Microsoft advisories, strengthen BitLocker configurations, update Secure Boot certificates, restrict physical access, and improve endpoint monitoring. The best defense is a layered approach that combines patch management, configuration hardening, identity controls, and continuous vulnerability monitoring.

FAQs

Are YellowKey and GreenPlasma patched?

At the time of public reporting, both issues were described as zero-days. Organizations should monitor Microsoft advisories for official patch status and CVE assignments.

Does BitLocker still protect Windows devices?

Yes, BitLocker remains an important security control. However, high-risk devices should consider stronger configurations such as startup PINs, Secure Boot certificate updates, and strict physical access controls.

How can Vulert help?

Vulert helps teams monitor vulnerabilities, track affected components, and receive alerts using manifest files and SBOMs without requiring source code access.

Microsoft Patches 138 Vulnerabilities Including DNS and Netlogon RCE Flaws

Vulert — Mon, 18 May 2026 06:47:56 +0000

Microsoft Patch Tuesday May 2026 is a major security release that addresses 138 vulnerabilities across Microsoft products, including several critical flaws that could allow remote code execution, privilege escalation, information disclosure, spoofing, and denial-of-service attacks.

While Microsoft has not listed any of these vulnerabilities as publicly known or actively exploited at the time of release, the update still deserves urgent attention. Several flaws have very high CVSS scores, including critical vulnerabilities in Windows DNS Client, Windows Netlogon, Azure services, Microsoft Dynamics 365, Windows Hyper-V, and Microsoft authentication-related components.

For administrators, security teams, and enterprise IT teams, the most important takeaway is simple: patch quickly, prioritize internet-facing and domain-critical systems, and review exposure based on business impact rather than only vulnerability count.

Microsoft Patch Tuesday May 2026: What Was Fixed?

Microsoft released fixes for a large set of vulnerabilities across its product portfolio. The update includes vulnerabilities rated Critical, Important, Moderate, and Low. The flaws cover multiple vulnerability classes, including privilege escalation, remote code execution, information disclosure, spoofing, denial-of-service, security feature bypass, and tampering.

Severity	Number of Vulnerabilities
Critical	30
Important	104
Moderate	3
Low	1

The largest category of vulnerabilities in this release is privilege escalation, followed by remote code execution. This combination is important because attackers often chain these two classes together. A remote code execution vulnerability may provide initial access, while a privilege escalation vulnerability can help attackers gain higher permissions and move deeper into the environment.

Most Important Vulnerabilities to Prioritize

Among the vulnerabilities fixed in Microsoft Patch Tuesday May 2026, two Windows flaws stand out because of their potential enterprise impact: CVE-2026-41096 in Windows DNS Client and CVE-2026-41089 in Windows Netlogon.

CVE	Component	CVSS	Impact
CVE-2026-41096	Windows DNS Client	9.8	Remote Code Execution
CVE-2026-41089	Windows Netlogon	9.8	Remote Code Execution
CVE-2026-42898	Microsoft Dynamics 365 On-Premises	9.9	Remote Code Execution
CVE-2026-33109	Azure Managed Instance for Apache Cassandra	9.9	Remote Code Execution
CVE-2026-41103	Microsoft SSO Plugin for Jira & Confluence	9.1	Elevation of Privilege
CVE-2026-40402	Windows Hyper-V	9.3	Elevation of Privilege

CVE-2026-41096: Critical Windows DNS Client RCE

CVE-2026-41096 is one of the most severe vulnerabilities in this update. It is a heap-based buffer overflow vulnerability in Windows DNS Client that could allow an unauthorized attacker to execute code over a network.

Microsoft said an attacker could exploit the flaw by sending a specially crafted DNS response to a vulnerable Windows system. If the DNS Client processes the response incorrectly and memory becomes corrupted, remote code execution may be possible in certain configurations.

This vulnerability matters because DNS is a core part of almost every Windows environment. Workstations, servers, and enterprise applications rely on DNS resolution constantly. Even if exploitation is not currently observed in the wild, a critical DNS-related RCE should be treated as a high-priority patching item.

CVE-2026-41089: Critical Windows Netlogon RCE

CVE-2026-41089 is another critical vulnerability that should be prioritized, especially by organizations running on-premises Active Directory. The flaw is a stack-based buffer overflow in Windows Netlogon.

According to public reporting, an unauthorized attacker may exploit this vulnerability by sending a specially crafted network request to a Windows server acting as a domain controller. Successful exploitation could allow remote code execution without requiring the attacker to sign in or have prior access.

Netlogon is a sensitive Windows service because of its role in domain authentication and domain controller communication. Any unauthenticated RCE affecting domain controllers deserves immediate attention from enterprise defenders.

Other Critical Microsoft Vulnerabilities Patched

In addition to DNS and Netlogon, Microsoft also fixed several serious vulnerabilities across Azure, Dynamics 365, Hyper-V, Microsoft Teams, Office, SharePoint, and authentication-related components.

CVE-2026-42898: A Microsoft Dynamics 365 on-premises code injection vulnerability that may allow an authorized attacker to execute code over a network.
CVE-2026-33109: An improper access control issue in Azure Managed Instance for Apache Cassandra that may allow remote code execution. Microsoft noted this requires no customer action.
CVE-2026-42823: An improper access control vulnerability in Azure Logic Apps that may allow privilege escalation over a network.
CVE-2026-40402: A Windows Hyper-V use-after-free vulnerability that may allow an attacker to gain SYSTEM privileges and access the Hyper-V host environment.
CVE-2026-41103: A Microsoft SSO Plugin for Jira and Confluence vulnerability that may allow an unauthorized attacker to gain unauthorized access as a valid user.
CVE-2026-33844: An Azure Managed Instance for Apache Cassandra vulnerability involving improper input validation that may allow remote code execution.

Some Azure and cloud-service issues may require no direct customer action because Microsoft patches the affected cloud infrastructure. However, organizations should still review advisory notes, tenant exposure, identity configurations, and any related logs where applicable.

No Active Exploitation Reported, But Patch Urgency Remains High

At the time of release, none of the vulnerabilities in Microsoft Patch Tuesday May 2026 were listed as publicly known or under active attack. This is positive news for defenders, but it should not create a false sense of security.

Attackers frequently analyze Patch Tuesday releases to reverse-engineer fixes and develop working exploits. Once patches are public, unpatched systems can become easier targets because attackers can compare vulnerable and fixed code paths.

Critical vulnerabilities affecting DNS, Netlogon, domain controllers, identity systems, and business applications should be handled quickly because they may provide attackers with high-value access.

Secure Boot Certificate Update Also Needs Attention

Microsoft also reminded organizations to update Windows Secure Boot certificates to newer 2023 counterparts. Older 2011-issued Secure Boot certificates are approaching expiration, and organizations need to ensure that endpoints, servers, and specialized devices are ready before the deadline.

Secure Boot helps ensure that only trusted software loads during the boot process. If Secure Boot trust anchors are outdated, devices may enter a degraded security state or face boot-level security issues in the future. This is especially important for enterprises with older hardware, servers, embedded devices, and specialized operational technology environments.

AI-Assisted Vulnerability Discovery Is Changing Patch Tuesday

Another important theme in this release is the growing role of artificial intelligence in vulnerability discovery. Microsoft noted that AI-assisted vulnerability discovery is expected to increase the scale of Patch Tuesday releases in the coming months.

Several flaws fixed this month across Windows networking and authentication were reportedly identified through Microsoft’s multi-model AI-driven vulnerability discovery system, known as MDASH. This suggests defenders may need to prepare for larger and more frequent patch cycles as AI tools help researchers and vendors discover vulnerabilities faster.

The security lesson is clear: organizations need a disciplined patching process. The number of vulnerabilities may continue to grow, but patch teams should prioritize based on exposure, exploitability, critical business assets, and potential impact.

Recommended Actions for Security Teams

Organizations should take the following actions after the Microsoft Patch Tuesday May 2026 release:

Apply Microsoft security updates as soon as possible, especially on internet-facing systems and domain controllers.
Prioritize CVE-2026-41096 and CVE-2026-41089 because of their remote code execution impact.
Patch Windows servers, Windows clients, Hyper-V hosts, Office products, SharePoint servers, and Dynamics 365 on-premises deployments.
Review Azure advisories and confirm whether customer action is required for your environment.
Audit domain controllers and monitor for unusual authentication or Netlogon-related activity.
Review DNS logs, endpoint telemetry, and network traffic for suspicious behavior.
Update Secure Boot certificates and verify device readiness before the expiration deadline.
Reduce unnecessary internet exposure for Windows services and management interfaces.
Enforce multi-factor authentication, remove legacy authentication, and apply least-privilege access controls.
Segment critical environments to limit attacker movement if one system is compromised.

How Vulert Can Help

Vulert helps developers and security teams monitor vulnerabilities across open-source dependencies and software components without requiring access to source code. Teams can use manifest files and SBOMs to identify vulnerable dependencies, receive alerts, and prioritize fixes.

Vulert supports many ecosystems and file formats, including package-lock.json, yarn.lock, composer.lock, requirements.txt, pom.xml, go.sum, Gemfile.lock, Cargo.lock, SPDX SBOMs, and CycloneDX SBOMs.

For fast-moving security updates like Microsoft Patch Tuesday May 2026, vulnerability visibility is critical. Vulert helps teams understand which applications are affected, receive timely alerts, and reduce the time between disclosure and remediation.

You can check vulnerability details in the Vulert Vulnerability Database:

Conclusion

Microsoft Patch Tuesday May 2026 is a high-volume security release with critical vulnerabilities affecting Windows DNS Client, Windows Netlogon, Azure services, Microsoft Dynamics 365, Hyper-V, Office, SharePoint, and authentication-related components.

Even though Microsoft has not reported active exploitation for these vulnerabilities, organizations should not delay patching. Critical RCE flaws in DNS and Netlogon can have serious consequences if attackers develop reliable exploits.

Security teams should prioritize patching based on exposure and business impact, starting with domain controllers, internet-facing systems, identity infrastructure, and high-value servers. Combined with strong access controls, MFA, segmentation, monitoring, and continuous vulnerability management, timely patching remains one of the most effective ways to reduce cyber risk.

FAQs

What is Microsoft Patch Tuesday May 2026?

Microsoft Patch Tuesday May 2026 is Microsoft’s monthly security update release for May 2026. It includes fixes for vulnerabilities across Windows, Azure, Office, Dynamics 365, Hyper-V, SharePoint, and other Microsoft products.

Which vulnerabilities should be prioritized?

CVE-2026-41096 in Windows DNS Client and CVE-2026-41089 in Windows Netlogon should be prioritized because both are critical remote code execution vulnerabilities with CVSS scores of 9.8.

How can Vulert help?

Vulert helps teams monitor vulnerabilities, detect affected components, and receive alerts using manifest files and SBOMs without requiring source code access. This helps teams respond faster to new security disclosures and reduce remediation delays.

cPanel and WHM Patch Three New Vulnerabilities — Update Now

Vulert — Mon, 18 May 2026 06:43:36 +0000

cPanel and WHM have released security updates for three newly disclosed vulnerabilities that could expose web hosting environments to arbitrary file read, code execution, denial-of-service, and possible privilege escalation risks. The vulnerabilities are tracked as CVE-2026-29201, CVE-2026-29202, and CVE-2026-29203.

These cPanel WHM vulnerabilities are important because cPanel and Web Host Manager are widely used by hosting providers, agencies, developers, resellers, and businesses to manage websites, email accounts, domains, databases, DNS, SSL certificates, and server-level hosting operations. A weakness in this layer can create serious risk because the control panel often sits close to sensitive server functionality.

According to cPanel, the vulnerabilities have been patched across supported cPanel & WHM branches, with a separate fix also released for WP Squared. Administrators should update affected servers as soon as possible and verify that the patched version is running.

Overview of the Three cPanel WHM Vulnerabilities

The latest cPanel security update addresses three separate issues. Two of them carry a CVSS score of 8.8, making them high-severity vulnerabilities that should be prioritized quickly.

CVE ID	CVSS Score	Vulnerability Type	Potential Impact
CVE-2026-29201	4.3	Insufficient input validation	Arbitrary file read
CVE-2026-29202	8.8	Perl code injection	Arbitrary Perl code execution
CVE-2026-29203	8.8	Unsafe symlink handling	Denial-of-service or possible privilege escalation

CVE-2026-29201: Arbitrary File Read Through feature::LOADFEATUREFILE

CVE-2026-29201 is caused by insufficient input validation in the feature::LOADFEATUREFILE adminbin call. The issue relates to how the feature file name is handled. If a relative path is passed as an argument, it may cause an arbitrary file to become world-readable.

This vulnerability has a CVSS score of 4.3, which makes it lower severity than the other two vulnerabilities in this update. However, arbitrary file read issues should not be ignored. In hosting environments, file exposure can reveal configuration details, application secrets, server paths, user data, or other information that helps attackers plan further attacks.

Even when a vulnerability does not directly provide code execution, information disclosure can still become part of a larger attack chain. Attackers often use readable files to discover credentials, tokens, configuration weaknesses, or application structure.

CVE-2026-29202: Perl Code Execution Through create_user API

CVE-2026-29202 is one of the most serious vulnerabilities in this release. It is related to insufficient input validation of the plugin parameter in the create_user API call.

The vulnerability could allow arbitrary Perl code execution on behalf of the already authenticated account’s system user. This means an attacker would need access to an authenticated account, but if that access exists, the flaw may allow the attacker to execute code in the context of that account.

Authenticated code execution vulnerabilities are especially dangerous in shared hosting environments. A compromised hosting account, weak password, reused credentials, or abused plugin workflow may become a path to deeper server impact. This is why cPanel WHM vulnerabilities involving APIs and account-level actions should be handled urgently.

CVE-2026-29203: Unsafe Symlink Handling Could Lead to DoS or Privilege Escalation

CVE-2026-29203 is an unsafe symlink handling vulnerability. According to cPanel, the issue allows a user to modify access permissions of an arbitrary file using chmod.

This can result in denial-of-service or possible privilege escalation. In a web hosting environment, file permissions are extremely important. If a user can modify permissions on files they should not control, the impact can range from service disruption to unauthorized access paths.

Unsafe symlink handling bugs are often dangerous because symbolic links can point to files outside the intended directory. If software follows those links incorrectly, users may affect files that should be protected by isolation boundaries.

Patched cPanel and WHM Versions

cPanel has pushed patches for the following cPanel & WHM versions:

11.136.0.9 and higher
11.134.0.25 and higher
11.132.0.31 and higher
11.130.0.22 and higher
11.126.0.58 and higher
11.124.0.37 and higher
11.118.0.66 and higher
11.110.0.116 and higher
11.110.0.117 and higher
11.102.0.41 and higher
11.94.0.30 and higher
11.86.0.43 and higher

For WP Squared, the patched version is:

11.136.1.10 and higher

cPanel also released 110.0.114 as a direct update for customers still running CentOS 6 or CloudLinux 6. Administrators using legacy environments should review cPanel’s official instructions carefully before updating.

How to Update cPanel and WHM

cPanel recommends updating the server to one of the patched versions. Administrators can force an update by running:

/scripts/upcp --force

After the update completes, verify the installed cPanel version with:

/usr/local/cpanel/cpanel -V

If your server is still on CentOS 6 or CloudLinux 6, cPanel provides a direct update path. The upgrade tier can be set with:

sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.conf

After setting the tier, run the update process and verify the installed version. Because legacy operating systems may have additional compatibility and security concerns, hosting providers should also evaluate whether continued use of these systems is acceptable.

Why Hosting Providers Should Treat This as Urgent

These cPanel WHM vulnerabilities affect the management layer of hosting infrastructure. That makes them important even when exploitation requires authentication or specific conditions.

In real-world attacks, threat actors often do not rely on one vulnerability alone. They may combine stolen credentials, weak passwords, exposed panels, malicious plugins, symlink tricks, unsafe file permissions, and API weaknesses to escalate access. A vulnerability that looks limited on paper can become dangerous when chained with other issues.

Hosting environments also have a high blast radius. One vulnerable server may host dozens, hundreds, or even thousands of websites. A successful attack could affect multiple customers, databases, email accounts, backups, and configuration files.

No Active Exploitation Reported for These Three Flaws — But Risk Remains

At the time of public reporting, there was no evidence that CVE-2026-29201, CVE-2026-29202, or CVE-2026-29203 had been exploited in the wild. However, administrators should not delay patching.

The disclosure follows shortly after another serious cPanel issue, CVE-2026-41940, was reportedly weaponized as a zero-day. That earlier vulnerability was an authentication bypass affecting cPanel & WHM and WP Squared, and it increased urgency around cPanel patch management.

Attackers often monitor vendor advisories and quickly scan for unpatched internet-facing systems after vulnerability details become public. Even if exploitation has not been observed yet, the safest approach is to patch before attackers build reliable exploitation paths.

Recommended Security Actions

Organizations using cPanel, WHM, or WP Squared should take the following steps immediately:

Update cPanel & WHM to a patched version listed by cPanel.
Update WP Squared to 11.136.1.10 or higher if applicable.
Verify the installed version after updating.
Review authenticated user access, especially reseller and privileged accounts.
Audit recent API activity, especially account creation and plugin-related calls.
Review file permission changes and suspicious chmod activity.
Check for abnormal symlink behavior in user directories.
Review logs for unexpected user creation, permission changes, or file exposure.
Enforce strong passwords and multi-factor authentication for WHM and cPanel users.
Restrict administrative access to trusted IP addresses where possible.

Patching should be the first priority. Monitoring and access reviews are important follow-up steps, especially if the server was exposed for some time before the update was applied.

Why Authenticated Vulnerabilities Still Matter

Some teams may treat authenticated vulnerabilities as lower priority because an attacker needs a valid account first. This can be a mistake, especially in hosting environments.

Hosting platforms commonly have many users, multiple account types, API integrations, plugins, automation scripts, and reseller workflows. If any user account is compromised, an authenticated vulnerability may allow the attacker to increase impact beyond the original account.

CVE-2026-29202, for example, involves code execution on behalf of an authenticated account’s system user. CVE-2026-29203 involves file permission manipulation through unsafe symlink handling. Both issues show why authenticated attack surfaces must be included in vulnerability management programs.

How Vulert Can Help

Vulert helps developers and security teams detect and monitor vulnerabilities in open-source dependencies and software components without requiring access to source code. Teams can use manifest files and SBOMs to identify vulnerable components, receive alerts, and prioritize fixes faster.

For hosting providers and DevOps teams, timely vulnerability intelligence is essential. Whether the issue affects a package, server component, control panel, or application dependency, fast visibility helps reduce the window between disclosure and remediation.

Check vulnerability details in the Vulert Vulnerability Database:

Conclusion

The latest cPanel WHM vulnerabilities should be treated as an urgent patching priority. The three flaws, tracked as CVE-2026-29201, CVE-2026-29202, and CVE-2026-29203, can lead to arbitrary file read, Perl code execution, denial-of-service, and possible privilege escalation.

cPanel has released fixed versions across multiple supported branches, and administrators should update immediately using the official update process. After patching, teams should verify the installed version, review logs, audit user access, and monitor for suspicious API or file permission activity.

Web hosting infrastructure is a high-value target. Keeping cPanel, WHM, WP Squared, plugins, operating systems, and server packages updated is essential for reducing risk and protecting hosted websites.

FAQs

What are the latest cPanel WHM vulnerabilities?

The latest cPanel WHM vulnerabilities are CVE-2026-29201, CVE-2026-29202, and CVE-2026-29203. They affect file handling, API input validation, and symlink handling.

Has exploitation been reported?

Public reporting stated that there was no evidence of active exploitation for these three specific vulnerabilities at the time of disclosure. However, patching should still be done immediately.

How can Vulert help?

Vulert helps teams monitor vulnerabilities, identify affected components, and receive timely alerts using manifest files and SBOMs without requiring source code access.

Critical Apache HTTP/2 Flaw CVE-2026-23918 Enables DoS and Potential RCE

Vulert — Mon, 18 May 2026 06:37:50 +0000

CVE-2026-23918 is a serious vulnerability in Apache HTTP Server that affects the HTTP/2 protocol handling in Apache HTTP Server version 2.4.66. The flaw has been described as a double-free vulnerability that can cause denial-of-service and may potentially lead to remote code execution in certain environments.

Apache HTTP Server is one of the most widely used web servers in the world, powering public websites, enterprise applications, APIs, internal portals, and reverse proxy deployments. Because of this large deployment base, any severe Apache vulnerability deserves immediate attention from system administrators, DevOps teams, hosting providers, and security teams.

The Apache Software Foundation has addressed CVE-2026-23918 in Apache HTTP Server 2.4.67. Organizations running Apache HTTP Server 2.4.66 with HTTP/2 enabled should upgrade as soon as possible to reduce exposure.

What is CVE-2026-23918?

CVE-2026-23918 is a double-free vulnerability in Apache HTTP Server’s HTTP/2 implementation. A double-free occurs when software attempts to free the same memory location more than once. This can corrupt memory and may result in application crashes, denial-of-service, or in some cases, remote code execution.

In the case of CVE-2026-23918, the issue exists in Apache HTTP Server version 2.4.66. The vulnerability is related to how HTTP/2 stream cleanup is handled. Under certain conditions, a specially crafted HTTP/2 interaction may cause Apache to mishandle memory during stream cleanup, resulting in a crash or potential memory corruption.

The official description states that this vulnerability may lead to double free and possible remote code execution. While denial-of-service appears to be the more direct and easier impact, remote code execution may be possible depending on the server environment, memory allocator behavior, and exploitation conditions.

Why This Apache HTTP/2 Vulnerability Matters

The risk of CVE-2026-23918 is significant because Apache HTTP Server is commonly exposed directly to the internet. If a vulnerable server is running Apache HTTP Server 2.4.66 with HTTP/2 enabled, attackers may be able to trigger crashes remotely without authentication.

A denial-of-service attack against a web server can disrupt business operations, take customer-facing services offline, interrupt APIs, and affect downstream applications. Even if remote code execution is not achieved, repeated worker crashes can still create serious availability issues.

The potential remote code execution risk makes the issue even more concerning. RCE vulnerabilities allow attackers to run code on a vulnerable server. If successfully exploited, an attacker could potentially gain deeper access, deploy malware, modify files, steal sensitive information, or use the compromised server as a pivot point into internal systems.

Affected Apache HTTP Server Version

The affected version is:

Apache HTTP Server 2.4.66

The fixed version is:

Apache HTTP Server 2.4.67

If your environment is running Apache HTTP Server 2.4.66, you should treat this as a high-priority patching task. Security teams should inventory all Apache instances, especially internet-facing servers, load balancers, reverse proxies, and containerized deployments.

Impact of CVE-2026-23918

The main impacts of CVE-2026-23918 include:

Denial of Service: Attackers may cause Apache worker processes to crash, disrupting active requests and service availability.
Potential Remote Code Execution: In certain environments, memory corruption may be exploitable for code execution.
Service Instability: Repeated crashes may affect production uptime and customer-facing services.
Increased Attack Surface: HTTP/2 is widely enabled in modern Apache deployments, increasing the number of potentially exposed systems.

The vulnerability is especially important for organizations using Apache HTTP Server as a front-facing web server, API gateway, reverse proxy, or application entry point. Publicly exposed web infrastructure is often scanned quickly after vulnerability disclosure, making fast patching essential.

Technical Overview

CVE-2026-23918 is associated with a memory management error in Apache HTTP Server’s HTTP/2 handling. The vulnerability is described as a double-free condition, which means the server may attempt to release the same memory object more than once during HTTP/2 stream cleanup.

Double-free vulnerabilities are dangerous because they can destabilize the application and corrupt heap memory. In many cases, the immediate result is a crash. In more advanced exploitation scenarios, attackers may attempt to manipulate memory layout to influence program execution.

For defenders, the most important takeaway is simple: this is not just a theoretical bug. Apache has released a fixed version, and affected systems should be upgraded immediately.

Why HTTP/2 Increases the Risk

HTTP/2 is widely used because it improves web performance through multiplexing, header compression, and better connection management. Many production environments enable HTTP/2 by default for faster website and API performance.

However, protocol-level vulnerabilities in HTTP/2 can be highly impactful because they may be reachable before application-level authentication or business logic is involved. Attackers do not necessarily need access to a valid user account if the vulnerable protocol handling occurs at the web server layer.

This makes CVE-2026-23918 particularly important for DevOps and infrastructure teams. Even if the hosted application itself is secure, the underlying web server may still expose risk if it is running a vulnerable Apache version.

Recommended Mitigation Steps

Organizations should take the following actions to protect against CVE-2026-23918:

Upgrade Apache HTTP Server to 2.4.67 immediately.
Identify all servers running Apache HTTP Server 2.4.66.
Prioritize internet-facing servers and reverse proxy deployments.
Check whether HTTP/2 is enabled in Apache configuration.
If immediate patching is not possible, consider temporarily disabling HTTP/2 as a risk-reduction measure.
Monitor Apache logs for repeated worker crashes or unusual HTTP/2 traffic patterns.
Restart Apache after applying updates to ensure the patched version is running.
Review container images and base images that may include Apache HTTP Server 2.4.66.

Patching should be the preferred solution. Temporary workarounds such as disabling HTTP/2 may reduce exposure but should not replace upgrading to the fixed Apache release.

How to Check Your Apache Version

Administrators can check the installed Apache version using common commands such as:

apache2 -v

or:

httpd -v

The exact command depends on the operating system and Apache package naming. Debian and Ubuntu-based systems commonly use apache2, while Red Hat-based systems often use httpd.

If the output shows Apache HTTP Server 2.4.66, the server should be upgraded to 2.4.67 or later.

How to Check Whether HTTP/2 is Enabled

Because CVE-2026-23918 affects Apache HTTP/2 handling, teams should also check whether HTTP/2 is enabled in their Apache configuration.

Look for configuration directives such as:

Protocols h2 http/1.1

If HTTP/2 is enabled and the server is running Apache 2.4.66, the server should be considered exposed until patched. Disabling HTTP/2 may reduce immediate risk, but upgrading remains the recommended fix.

Detection and Monitoring Guidance

Security teams should monitor for signs of exploitation attempts or service instability. Useful signals may include:

Unexpected Apache worker crashes
Repeated segmentation faults or memory errors
Unusual spikes in HTTP/2 traffic
Frequent short-lived connections from unknown sources
Increased 5xx errors or dropped requests
Abnormal process restarts

Logs alone may not confirm exploitation, but they can help identify suspicious behavior or operational impact. Organizations should combine log review with patch verification, endpoint monitoring, and network-level visibility.

Why Fast Patching is Important

Vulnerabilities in popular internet-facing software are often weaponized quickly. Apache HTTP Server is widely deployed, and attackers frequently scan the internet for vulnerable versions after public disclosure.

Delaying patches increases the risk that vulnerable servers will be identified and targeted. Even if exploitation only causes denial-of-service in your environment, service disruption can still damage customer trust, business operations, and security posture.

For organizations with compliance obligations, patching high-severity server vulnerabilities should be part of standard vulnerability management and incident response processes.

How Vulert Can Help

Vulert helps developers and security teams detect vulnerable open-source components before attackers can exploit them. With Vulert, teams can monitor dependencies using manifest files and SBOMs without giving access to their source code.

Vulert supports many ecosystems and file types, including package-lock.json, yarn.lock, composer.lock, requirements.txt, pom.xml, go.sum, Cargo.lock, Gemfile.lock, SPDX SBOMs, and CycloneDX SBOMs.

For vulnerabilities like CVE-2026-23918, Vulert helps teams stay informed by providing vulnerability intelligence, affected version details, and fix guidance. This makes it easier to prioritize remediation and reduce the time between disclosure and patching.

You can review this vulnerability in the Vulert Vulnerability Database:
CVE-2026-23918 Vulnerability Details.

Conclusion

CVE-2026-23918 is a critical Apache HTTP Server vulnerability affecting HTTP/2 handling in version 2.4.66. The flaw is caused by a double-free memory error and can lead to denial-of-service, with potential remote code execution in certain environments.

Organizations using Apache HTTP Server should immediately check whether they are running version 2.4.66, confirm whether HTTP/2 is enabled, and upgrade to Apache HTTP Server 2.4.67. Temporary mitigations may reduce risk, but patching is the safest and most reliable solution.

Since Apache is commonly deployed on public-facing infrastructure, security teams should treat this vulnerability as urgent. Fast detection, quick patching, and continuous monitoring are essential to protecting web servers and the applications behind them.

FAQs

What is CVE-2026-23918?

CVE-2026-23918 is a double-free vulnerability in Apache HTTP Server’s HTTP/2 handling that can cause denial-of-service and may potentially lead to remote code execution.

Is CVE-2026-23918 remotely exploitable?

The vulnerability exists in HTTP/2 protocol handling, which may be reachable remotely on servers with HTTP/2 enabled. The main confirmed risk is denial-of-service, while remote code execution may be possible in certain environments.

How can Vulert help with CVE-2026-23918?

Vulert helps teams monitor vulnerabilities, identify affected components, and receive fix guidance using manifest files and SBOMs without requiring source code access.

Ivanti EPMM CVE-2026-6973 RCE Under Active Exploitation

Vulert — Mon, 18 May 2026 06:32:49 +0000

Ivanti EPMM CVE-2026-6973 has become an urgent security concern after Ivanti confirmed that the vulnerability has been exploited in a limited number of customer environments. The flaw affects Ivanti Endpoint Manager Mobile, commonly known as EPMM, and can allow a remotely authenticated administrative user to achieve remote code execution on affected on-premise systems.

Although exploitation requires administrative authentication, the risk remains serious. If attackers already have stolen, reused, or compromised admin credentials, this vulnerability may give them a direct path to execute code on vulnerable Ivanti EPMM appliances. For organizations that use Ivanti EPMM to manage mobile devices, certificates, policies, and enterprise access, this type of vulnerability can create a major security exposure.

Ivanti has released fixes for the issue in versions 12.6.1.1, 12.7.0.1, and 12.8.0.1. Organizations running affected on-premise EPMM versions should patch immediately, review administrative access, rotate credentials where needed, and check for signs of compromise.

What is Ivanti EPMM CVE-2026-6973?

Ivanti EPMM CVE-2026-6973 is a high-severity vulnerability caused by improper input validation in Ivanti Endpoint Manager Mobile. The vulnerability affects EPMM versions before 12.6.1.1, 12.7.0.1, and 12.8.0.1. According to Ivanti, successful exploitation allows a remotely authenticated user with administrative access to achieve remote code execution.

Remote code execution, or RCE, is one of the most dangerous vulnerability classes because it can allow attackers to run commands or malicious code on a target system. In this case, the vulnerability is not unauthenticated. The attacker needs admin-level authentication first. However, this does not make the issue safe to ignore. In real-world attacks, threat actors often combine vulnerabilities with stolen credentials, credential reuse, phishing, exposed admin panels, or previously compromised accounts.

Ivanti also stated that the issue affects only the on-premise EPMM product. It does not affect Ivanti Neurons for MDM, Ivanti EPM, Ivanti Sentry, or other Ivanti products.

Why CVE-2026-6973 is Dangerous

The danger of Ivanti EPMM CVE-2026-6973 comes from the combination of three important factors: remote code execution, administrative access, and active exploitation. Even though the attacker needs admin authentication, successful exploitation can still have serious consequences for enterprise environments.

Ivanti EPMM is used to manage mobile devices, security policies, enterprise access, certificates, and device enrollment. If attackers gain control of an EPMM server, they may be able to move deeper into the organization, access sensitive configuration data, disrupt device management, or use the compromised system as a foothold for further attacks.

This vulnerability is especially concerning because CISA has added it to the Known Exploited Vulnerabilities catalog. CISA KEV inclusion means the flaw is not only theoretical; it has evidence of exploitation in the wild. For U.S. Federal Civilian Executive Branch agencies, remediation is required by the listed deadline. For private organizations, KEV inclusion should be treated as a strong signal to prioritize patching.

Affected Ivanti EPMM Versions

The following Ivanti EPMM versions are affected:

Ivanti EPMM versions before 12.6.1.1
Ivanti EPMM versions before 12.7.0.1
Ivanti EPMM versions before 12.8.0.1

Organizations should upgrade to one of the fixed releases depending on their current version branch:

12.6.1.1
12.7.0.1
12.8.0.1

Security teams should confirm the exact version running in their environment and apply Ivanti’s recommended fix as soon as possible. If immediate patching is not possible, the affected system should be isolated, monitored closely, and protected with strict access controls until the update can be applied.

Active Exploitation Confirmed

Ivanti confirmed that it is aware of a very limited number of customers exploited through CVE-2026-6973. The company also noted that exploitation requires administrative authentication. This means attackers must already have admin-level credentials or access before they can abuse the vulnerability.

However, this requirement should not reduce urgency. Many enterprise breaches begin with compromised credentials. Admin credentials can be obtained through phishing, password reuse, infostealer malware, exposed backups, weak passwords, previous vulnerabilities, or poor credential rotation practices.

Ivanti also advised that customers who followed its earlier recommendation in January to rotate credentials after exploitation involving earlier EPMM vulnerabilities have a significantly reduced risk. This highlights an important lesson: patching alone is not always enough. Credential hygiene, access reviews, and post-incident hardening are also essential.

CISA Adds CVE-2026-6973 to KEV Catalog

The U.S. Cybersecurity and Infrastructure Security Agency has added Ivanti EPMM CVE-2026-6973 to its Known Exploited Vulnerabilities catalog. The KEV catalog tracks vulnerabilities that are known to be exploited in real-world attacks and require urgent remediation.

For Federal Civilian Executive Branch agencies, the required remediation due date is May 10, 2026. Even if your organization is not a federal agency, CISA KEV inclusion is a strong indicator that the vulnerability should be treated as high priority.

Security teams should not wait for public proof-of-concept exploit code before acting. Once a vulnerability is actively exploited, attackers may move quickly to find exposed systems and abuse weak administrative access.

Other Ivanti EPMM Vulnerabilities Patched

Along with CVE-2026-6973, Ivanti also patched four other EPMM vulnerabilities. These issues include improper access control, improper certificate validation, and device enrollment-related risks.

CVE-2026-5786: Improper access control vulnerability that may allow a remote authenticated attacker to gain administrative access.
CVE-2026-5787: Improper certificate validation vulnerability that may allow a remote unauthenticated attacker to impersonate registered Sentry hosts and obtain valid CA-signed client certificates.
CVE-2026-5788: Improper access control vulnerability that may allow a remote unauthenticated attacker to invoke arbitrary methods.
CVE-2026-7821: Improper certificate validation vulnerability that may allow a remote unauthenticated attacker to enroll a restricted device, potentially exposing information about the EPMM appliance and affecting device identity integrity.

While CVE-2026-6973 is the vulnerability currently reported as exploited, organizations should treat the full update as important. Attackers often chain multiple weaknesses together, especially when targeting enterprise management systems.

Recommended Mitigation Steps

Organizations using Ivanti EPMM should take the following actions immediately:

Upgrade Ivanti EPMM to 12.6.1.1, 12.7.0.1, or 12.8.0.1.
Review all administrative accounts and remove unused or unnecessary admin access.
Rotate EPMM admin credentials, especially if the system was exposed or previously impacted by earlier vulnerabilities.
Check authentication logs for unusual admin activity.
Restrict admin panel access to trusted IP addresses or VPN-only access.
Monitor for unexpected commands, new users, configuration changes, or suspicious device enrollment activity.
Review any integrations, certificates, and Sentry-related configurations.
Follow Ivanti’s official advisory and incident response guidance.

If your EPMM instance is internet-facing, the urgency is even higher. Publicly exposed management interfaces are attractive targets for attackers, especially after a vulnerability is added to the CISA KEV catalog.

Why Admin-Authenticated RCE Still Matters

Some teams may mistakenly assume that an authenticated vulnerability is less important than an unauthenticated one. While unauthenticated RCE is usually more severe, authenticated RCE can still be highly dangerous in enterprise environments.

Attackers do not always begin with a software exploit. They may first gain access through stolen credentials, phishing, session theft, or credential stuffing. Once they have admin access, a vulnerability like Ivanti EPMM CVE-2026-6973 can turn that access into code execution. That can increase the attacker’s control over the system and potentially support lateral movement.

This is why patching must be combined with credential rotation, access control, and monitoring. A patched system with weak admin security is still risky, while an unpatched system with exposed admin access is a serious target.

How Vulert Can Help

Vulert helps developers and security teams stay ahead of vulnerabilities by continuously monitoring open-source dependencies and security issues using manifest files and SBOMs. Instead of requiring access to your source code, Vulert can analyze files such as package-lock.json, composer.lock, requirements.txt, pom.xml, go.sum, and SBOM formats like SPDX and CycloneDX.

With Vulert, teams can receive timely alerts, understand which applications are affected, and get clear fix guidance. This makes it easier to respond quickly when vulnerabilities are disclosed or added to high-priority sources such as vulnerability databases and exploited vulnerability catalogs.

Conclusion

Ivanti EPMM CVE-2026-6973 is a serious authenticated remote code execution vulnerability affecting on-premise Ivanti Endpoint Manager Mobile systems. Although exploitation requires admin authentication, active exploitation and CISA KEV inclusion make this a high-priority issue.

Organizations should upgrade to the fixed Ivanti EPMM versions immediately, rotate administrative credentials where appropriate, review logs for suspicious activity, and restrict access to administrative interfaces. Security teams should also treat this incident as a reminder that patch management, credential hygiene, and continuous vulnerability monitoring must work together.

Enterprise management systems are high-value targets. Once attackers gain access to them, the impact can extend far beyond a single server. Acting quickly on CVE-2026-6973 is the best way to reduce exposure and prevent further compromise.

FAQs

What is CVE-2026-6973?

CVE-2026-6973 is an improper input validation vulnerability in Ivanti Endpoint Manager Mobile that can allow a remotely authenticated admin user to achieve remote code execution.

How can organizations fix CVE-2026-6973?

Organizations should upgrade to Ivanti EPMM 12.6.1.1, 12.7.0.1, or 12.8.0.1 and follow Ivanti’s official mitigation guidance.

How does Vulert help with vulnerabilities like this?

Vulert helps teams monitor vulnerabilities, check affected components, and receive alerts without requiring access to source code. It supports manifest files and SBOMs, making vulnerability tracking easier for developers and security teams.

What is SBOM (Software Bill of Materials) and Why Does Your Engineering Team Need One in 2026?

Vulert — Tue, 05 May 2026 14:44:31 +0000

If a food manufacturer sells a packaged product, the label lists the ingredients. Buyers can see what is inside, check for allergens, and make risk-based decisions. A Software Bill of Materials, or SBOM, works the same way for software. It lists the components inside an application: open-source libraries, commercial packages, direct dependencies, transitive dependencies, versions, suppliers, and relationships.

Many engineering teams are now asking what is SBOM because customers, regulators, federal buyers, and enterprise security teams increasingly expect software transparency. The question what is SBOM is no longer only for compliance teams; it now matters to CTOs, engineering leads, DevOps teams, and software vendors selling into regulated markets.

This what is SBOM guide explains the meaning of a Software Bill of Materials, why SBOM requirements are increasing in 2026, which format to choose, how to generate an SBOM, and how to use it for vulnerability scanning.

What is SBOM and What Does It Include?

An SBOM is a structured inventory of the software components used to build an application, library, service, device, container, or product. It helps teams answer a simple but critical question: what exactly is inside this software?

If someone asks what is SBOM in plain language, the answer is: it is an ingredient list for software. Instead of listing flour, sugar, and preservatives, an SBOM lists components such as log4j-core, lodash, django, guzzlehttp/guzzle, openssl, or spring-core, along with versions and package metadata.

When someone searches for what is SBOM, they usually want to know whether it is just a compliance document or something engineering teams can actually use. In practice, an SBOM is both: it supports regulatory and customer requirements, but it also helps engineers quickly identify vulnerable software components.

A useful SBOM normally includes:

Component name: The package, library, module, or software component included in the application.
Version: The exact version of the component, which is essential for vulnerability matching.
Supplier or publisher: The organization, maintainer, or source associated with the component.
Dependency relationship: Whether the package is direct or transitive and how it connects to other components.
Package identifiers: Metadata such as Package URL, hashes, CPEs, or other identifiers that help scanners match components accurately.
Format metadata: Information about the SBOM format, generation tool, timestamp, and target application.

The core purpose is visibility. You cannot secure what you cannot see. An SBOM gives engineering, security, compliance, and customer-facing teams a shared inventory of what exists inside the software they build or buy.

Why Understanding What is SBOM Matters in 2026

SBOMs became more urgent after major software supply chain incidents. When Log4Shell appeared, organizations needed to know which products contained vulnerable Log4j versions. Many teams did not know. They had to search repositories, containers, old builds, vendor products, and transitive dependency trees under emergency pressure.

An SBOM reduces that uncertainty. When a new CVE appears, teams can scan their SBOMs and quickly identify affected products, versions, and customers. This is why SBOMs now appear in federal software procurement, medical device submissions, enterprise security reviews, and customer questionnaires.

EO 14028 defines an SBOM as a formal record of software components and their supply chain relationships, similar to an ingredient list on food packaging.

For CTOs and engineering leads, the practical value is clear: an SBOM turns software supply chain risk from a guessing exercise into a searchable inventory.

Why Governments and Regulated Buyers Are Mandating SBOMs

SBOM requirements are no longer limited to security-forward enterprises. Governments and regulated sectors are pushing software transparency into procurement, product safety, and cybersecurity requirements.

US Executive Order 14028: The US government pushed federal agencies and software suppliers toward stronger software supply chain transparency, secure development practices, and SBOM-related expectations.
EU Cyber Resilience Act: The EU Cyber Resilience Act creates cybersecurity obligations for products with digital elements and increases pressure on manufacturers to understand and document software components and vulnerabilities.
FDA medical device guidance: Medical device manufacturers must provide software component transparency for cyber devices, including commercial, open-source, and off-the-shelf components.
DoD and defense supply chain: Defense supply chain expectations increasingly connect SBOMs with software supply chain risk management, vulnerability management, and customer assurance.

This does not mean every startup must produce SBOMs for every customer tomorrow. It does mean that if you sell to government, healthcare, defense, critical infrastructure, or large enterprises, SBOM requests are becoming normal.

Who Needs SBOMs Now, Soon, and Eventually?

Not every team faces the same urgency. Use this table to understand where your company likely sits.

Urgency	Who It Applies To	Why It Matters	Action to Take
Need SBOMs Now	Federal contractors, defense suppliers, medical device companies, critical infrastructure vendors, and companies selling into regulated government environments.	Contracts, procurement rules, safety guidance, or customer security requirements may already ask for SBOMs.	Generate SBOMs for key products, standardize on a format, and build vulnerability scanning around the SBOM workflow.
Need SBOMs Soon	Financial services vendors, healthcare software providers, enterprise SaaS companies, security vendors, and B2B companies selling to large customers.	Enterprise security teams increasingly request SBOMs during vendor reviews and renewals.	Start generating SBOMs during releases and prepare a process for secure sharing with customers.
Need SBOMs Eventually	Most software companies, including SMB SaaS, agencies, internal platforms, and product teams with open-source dependencies.	SBOMs are becoming a standard software transparency artifact, similar to security questionnaires and SOC2 reports.	Begin with one product, one SBOM format, and one scanning workflow before customers force the timeline.

SPDX vs CycloneDX: The Two Main SBOM Formats

After understanding what is SBOM, the next decision is format. Most teams will choose between SPDX and CycloneDX depending on whether their primary goal is compliance documentation, vulnerability scanning, customer sharing, or software supply chain visibility.

The two most common SBOM formats are SPDX and CycloneDX. Both are widely used, machine-readable, and supported by security tooling. The best choice depends on your workflow.

Format	Maintainer / Origin	Strengths	Common File Types	Best Use Case
SPDX	Linux Foundation project; ISO-recognized standard.	Mature, established, strong for software component identification, licensing, provenance, and broad supply chain documentation.	JSON, YAML, RDF/XML, tag-value, XML depending on tooling and version.	Organizations that need broad legal, licensing, compliance, and software inventory workflows.
CycloneDX	OWASP project focused on software supply chain transparency and cyber risk.	Security-focused, strong for vulnerability analysis, dependency relationships, services, VEX workflows, and application security use cases.	JSON, XML, Protocol Buffers depending on specification and tooling.	Engineering and security teams that want SBOMs for vulnerability scanning and risk management.

Practical advice: if your main goal is vulnerability analysis, CycloneDX is often easier to adopt because the ecosystem is strongly security-focused. If your customers ask for SPDX, produce SPDX. Many teams eventually support both.

How to Generate an SBOM

Once your team understands what is SBOM, the next step is generating one from your real project files, build output, container image, or CI/CD pipeline.

You can generate SBOMs from source directories, package manager files, container images, build outputs, or CI/CD pipelines. The exact command depends on your stack and tooling.

Here are common commands:

# Generate a CycloneDX SBOM from the current directory using Syft
syft dir:. -o cyclonedx-json > sbom.json

# Generate an SPDX SBOM from the current directory using Syft
syft dir:. -o spdx-json > sbom.spdx.json

# Generate a CycloneDX SBOM for a Maven project
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

# Generate a CycloneDX SBOM with Trivy for a filesystem/project directory
trivy fs --format cyclonedx --output sbom.json ./

# Generate an SPDX JSON SBOM with Trivy for a filesystem/project directory
trivy fs --format spdx-json --output sbom.spdx.json ./

For CI/CD, generate the SBOM as part of the release pipeline. Store it with the build artifact, container image, release version, or customer delivery package. An SBOM generated randomly on a developer laptop is less useful than one tied to the exact production release.

What an SBOM File Actually Looks Like

If you are asking what is SBOM because the file itself feels abstract, here is a simplified CycloneDX JSON example. Real files include more metadata, hashes, licenses, suppliers, and relationships.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "component": {
      "type": "application",
      "name": "example-api",
      "version": "1.4.2"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "group": "org.apache.logging.log4j",
      "version": "2.14.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"
    },
    {
      "type": "library",
      "name": "spring-core",
      "group": "org.springframework",
      "version": "5.3.18",
      "purl": "pkg:maven/org.springframework/spring-core@5.3.18"
    }
  ]
}

The important parts are the component names, versions, and package identifiers. Those fields allow vulnerability scanners to match components against CVE databases and advisory feeds.

How to Use an SBOM for Vulnerability Scanning

An SBOM by itself is an inventory. The real value appears when you analyze it. When a new vulnerability is disclosed, you can scan the SBOM and answer: do we use the affected component, which version do we use, where does it appear, and what should we upgrade?

A strong SBOM vulnerability workflow looks like this:

Generate the SBOM: Create an SPDX or CycloneDX file during build or release.
Store it with the release: Keep the SBOM tied to the exact application version or container image.
Scan for vulnerabilities: Compare SBOM components against vulnerability databases and advisories.
Create remediation work: Convert high-risk findings into Jira tickets or engineering tasks.
Monitor continuously: Re-check the same SBOM when new CVEs are disclosed after release.

Vulert SBOM support: Vulert accepts SPDX and CycloneDX SBOM uploads directly at vulert.com/abom. Teams with existing SBOMs can upload them immediately without reconnecting repositories or sharing source code. This is useful for enterprise teams transitioning from tools like Sonatype, Black Duck, Mend, or internal SBOM pipelines.

SBOM Sharing With Clients and Customers

SBOMs also help with customer trust. Enterprise buyers increasingly want to know whether vendors understand their software supply chain. A well-managed SBOM process gives sales, security, and engineering teams better answers during vendor reviews.

When sharing SBOMs, treat them as sensitive operational artifacts. They can reveal software components and versions, which may help attackers if shared carelessly. Use a controlled process:

Share only with approved customers: Do not publish detailed SBOMs openly unless your security and legal teams approve.
Provide the right format: Ask whether the customer prefers SPDX or CycloneDX.
Attach vulnerability status: A raw SBOM is less useful than an SBOM with current vulnerability analysis and remediation notes.
Version the artifact: Tie each SBOM to a release version, date, and product name.
Control access: Use customer portals, secure file transfer, or contractual controls for sensitive SBOM sharing.

Common SBOM Mistakes

Generating an SBOM is not enough. Teams need a repeatable process around it. Avoid these mistakes:

Generating SBOMs only once: SBOMs should be generated for each meaningful release, not only during a one-time compliance project.
Not scanning the SBOM: An inventory without vulnerability analysis does not reduce risk.
Ignoring transitive dependencies: SBOMs should include indirect dependencies because many vulnerabilities hide there.
Not storing SBOMs with releases: If you cannot tie the SBOM to a product version, it becomes much less useful during incidents.
Using the wrong format for the buyer: Some customers ask for SPDX, others ask for CycloneDX. Know what your market expects.

How Vulert Helps With SBOM Vulnerability Analysis

If your team already generates SBOMs, Vulert can help turn those files into actionable vulnerability reports. Upload an SPDX or CycloneDX SBOM and Vulert checks the components against a large vulnerability database, then shows affected packages, severity, CVSS scores, fix guidance, and remediation details.

This matters for teams asking what is SBOM because the file itself is only the beginning. The business value comes from using that SBOM to answer security questions quickly. Which components are vulnerable? Which package should be upgraded first? What version fixes the issue? Which applications need attention?

Vulert also supports manifest files such as package-lock.json, pom.xml, requirements.txt, composer.lock, go.sum, Gemfile.lock, and more. That means teams can scan both SBOMs and dependency files without giving access to the full source codebase.

Key Takeaways

An SBOM is an ingredient list for software: It identifies the components, versions, suppliers, and relationships inside your application.
SBOM requirements are expanding: Federal buyers, EU regulations, medical device rules, defense supply chain expectations, and enterprise customers are pushing SBOM adoption.
SPDX and CycloneDX are the main formats: SPDX is mature and broad; CycloneDX is strongly aligned with security and vulnerability workflows.
SBOMs should be generated during release: The file should match the exact version of the product you ship.
An SBOM needs vulnerability analysis: The inventory becomes valuable when you scan it for CVEs and fix affected packages.
Vulert accepts existing SBOMs: Teams can upload SPDX or CycloneDX files directly and receive vulnerability results quickly.

Frequently Asked Questions

What is SBOM in simple terms?

What is SBOM? It is a Software Bill of Materials: a structured list of the components inside your software. Think of it like an ingredient label for an application, showing which packages, libraries, and versions are included.

Why are companies searching for what is SBOM in 2026?

Companies are searching for what is SBOM because governments, enterprise customers, medical device regulators, defense buyers, and security teams increasingly require software component transparency. SBOMs help teams prove what is inside their software and scan those components for known vulnerabilities.

Is my company required to produce SBOMs?

It depends on your industry, customers, and contracts. Federal contractors, medical device manufacturers, defense suppliers, critical infrastructure vendors, and enterprise software vendors face the strongest pressure. Even if you are not legally required today, large customers may still request SBOMs during security reviews.

The Real Cost of Ignoring Open Source Vulnerabilities — And Why Automated Monitoring Pays for Itself

Vulert — Tue, 05 May 2026 14:00:07 +0000

Equifax did not suffer a $1.4 billion security disaster because attackers used an unknown zero-day. The 2017 breach happened after attackers exploited CVE-2017-5638, a known Apache Struts vulnerability that had already been disclosed. The patch existed. The alert existed. The vulnerable open source component remained exposed. Around 147 million people were affected, and the total cost reached roughly $1.4 billion.

That is the cost of open source vulnerabilities in real business terms. It is not only a CVE score on a dashboard. It is legal exposure, emergency engineering work, lost trust, regulatory attention, audit disruption, cyber insurance pressure, and sales deals that never close.

For CTOs and engineering managers, the business case is direct: automated vulnerability monitoring is cheaper than manual tracking, cheaper than emergency patching, and dramatically cheaper than a breach. A tool that costs hundreds or thousands of dollars per year can prevent weeks of developer waste and reduce the likelihood that a known vulnerability turns into a business-level incident.

Known Vulnerabilities Have Already Created Billion-Dollar Damage

The most expensive security incidents are not always caused by the most sophisticated attacks. Many start with known vulnerabilities, old packages, unpatched dependencies, misconfigured controls, or missing monitoring. Open source risk is especially dangerous because one vulnerable library can appear across dozens of applications, microservices, internal tools, and customer-facing systems.

Incident	Root Issue	Impact	Estimated / Reported Cost	Business Lesson
Equifax 2017	Unpatched Apache Struts vulnerability, CVE-2017-5638.	About 147 million people affected.	Roughly $1.4 billion in total breach-related costs.	Known open source vulnerabilities become catastrophic when patching and monitoring fail.
Log4Shell 2021-ongoing	Apache Log4j remote code execution, CVE-2021-44228.	Global emergency remediation across Java applications and vendor products.	Estimated global economic impact in the billions; still exploited years later.	Deep transitive dependencies make manual discovery unreliable.
Capital One 2019	Cloud control failure involving SSRF and a misconfigured web application firewall.	More than 100 million individuals affected.	$80 million OCC penalty plus a $190 million class-action settlement.	Known weaknesses and weak monitoring create direct regulatory and legal exposure.
Heartbleed 2014	OpenSSL vulnerability, CVE-2014-0160.	Widespread certificate rotation, password resets, infrastructure reviews, and emergency cleanup.	Estimated global cleanup cost started around $500 million.	One open source component can create internet-scale remediation cost.

The Average Breach Already Costs More Than Most Security Budgets

IBM’s 2024 Cost of a Data Breach Report found that the global average cost of a data breach reached $4.88 million. The average time to identify and contain a breach was 258 days.

A $4.88 million breach is not an abstract enterprise number. For a mid-sized SaaS company, that can mean a year of runway, a major hiring plan, a delayed product roadmap, or an enterprise customer segment permanently lost. Breach cost includes investigation, legal support, customer notification, lost business, downtime, remediation, support burden, and regulatory response.

Organizations using extensive security automation reduce breach costs significantly. Automation helps teams detect vulnerabilities earlier, respond faster, and avoid relying on manual tracking. The business conclusion is simple: prevention and automation reduce financial damage. Manual CVE tracking does not scale.

The Hidden Cost of Manual Vulnerability Tracking

The visible cost of open source vulnerabilities is the breach. The hidden cost starts much earlier: developer hours wasted on manual checks, noisy alerts, emergency patching, and repeated audit preparation.

Assume a 5-person engineering team spends 3-5 hours per week manually checking CVEs, reading advisories, running scans, and figuring out which package versions need upgrades.

Low estimate: 3 hours/week × 52 weeks = 156 hours/year.
High estimate: 5 hours/week × 52 weeks = 260 hours/year.
Senior developer cost: 156 hours × $150/hour = $23,400/year.
High-end time cost: 260 hours × $150/hour = $39,000/year.

That does not include context switching, sprint disruption, management review, customer security questionnaires, or emergency patch windows. If the team spends one unplanned sprint fixing vulnerabilities before a SOC2 audit or enterprise customer review, the cost increases again.

Emergency Patching Destroys Sprint Planning

Ignoring vulnerabilities does not make them disappear. It moves them from planned work into emergency work. Emergency patches are expensive because they interrupt everything else.

Roadmap disruption: Product work gets paused while engineers investigate old dependencies and breaking upgrades.
Testing pressure: Security fixes must move fast, but dependency upgrades can break APIs, authentication, serialization, payment flows, or build systems.
Release risk: A rushed patch can introduce production bugs that create a second incident.
Leadership escalation: Critical CVEs quickly become executive issues when customers ask whether your product is affected.

Automated monitoring does not remove all emergency work, but it changes the timing. Finding a vulnerability early gives the team time to triage, test, and deploy safely. Finding it after exploitation starts forces a much more expensive response.

Audit Failure and Lost Enterprise Deals

SOC2, ISO 27001, enterprise security reviews, and vendor questionnaires all ask the same basic question: how do you monitor and remediate vulnerable open source dependencies?

A weak answer can cost real revenue. Enterprise contracts often exceed $100,000 per year. If a buyer asks for evidence of vulnerability monitoring, remediation timelines, SBOM handling, or historical reports, a spreadsheet and a one-time scan may not be enough.

Delayed sales: Enterprise buyers may pause procurement until security evidence is complete.
Extra audit work: Engineering and compliance teams spend weeks reconstructing evidence.
Higher customer scrutiny: Missing vulnerability processes make security reviews harder every year.
Lost trust: If a buyer sees weak dependency security, they may choose a competitor with stronger controls.

The cost of open source vulnerabilities includes the deals you never win because the security process looks immature.

Regulatory exposure is not theoretical. If a breach involves personal data and investigators find that a known vulnerability was ignored, the company may face GDPR, CCPA, contractual, insurance, and customer-notification consequences. The technical issue becomes a governance issue.

Cyber Insurance Is Raising the Bar

Cyber insurers increasingly ask whether companies have vulnerability scanning, patch management, endpoint controls, MFA, incident response procedures, and monitoring. A company that cannot show automated vulnerability monitoring may face higher premiums, lower coverage limits, exclusions, or tougher renewal questions.

Insurance does not replace prevention. It only transfers part of the financial damage after an incident. If a known open source vulnerability is ignored, the insurer may ask whether reasonable controls existed and whether the company followed its own remediation process.

The ROI Calculation for Automated Monitoring

The numbers make the case quickly. Vulert Pro costs $45/month, or $540/year. Compare that with developer time, breach exposure, audit pressure, and emergency patching.

Cost / Benefit Item	Estimated Amount	Business Meaning
Vulert Pro annual cost	$540/year	Hourly scans, Jira integration, Slack alerts, fix commands, and up to 5 team members.
Manual CVE tracking time	156 hours/year	Based on 3 hours/week for one team.
Developer time saved	$23,400/year	156 hours × $150/hour senior developer cost.
High-end manual tracking time	260 hours/year	Based on 5 hours/week for one team.
High-end developer time cost	$39,000/year	260 hours × $150/hour.
Average breach cost	$4.88 million	Global average breach cost reported in 2024.
Risk-adjusted ROI	Overwhelming	A $540/year tool can save more than its cost in developer time alone.

Even if automated monitoring prevents only a small amount of manual effort, the tool pays for itself. If it helps avoid one missed critical vulnerability, one failed audit, one emergency patch cycle, or one delayed enterprise deal, the ROI becomes obvious.

Why Automated Monitoring Works Better Than Manual CVE Tracking

Manual tracking fails because vulnerability disclosure never stops. New CVEs are published daily. Packages are updated constantly. Transitive dependencies change silently. Developers move between teams. Old services remain deployed. A manual process cannot reliably track all of that.

Continuous scanning: Manifest files and SBOMs are monitored after deployment, not only before release.
Fast alerts: Teams receive notifications when new vulnerabilities affect their dependencies.
Fix guidance: Developers see which version to upgrade to and which command to run.
Jira workflow: Findings become trackable remediation tickets instead of forgotten dashboard items.
Trend reporting: Leadership can see whether vulnerability exposure is improving or getting worse.

Where Vulert Fits Into the Business Case

Vulert is a Software Composition Analysis tool focused on open source dependency vulnerability monitoring. It analyzes manifest files and SBOMs, checks dependencies against a database of 458,000+ known vulnerabilities, and alerts teams when new CVEs affect their applications.

For teams calculating the cost of open source vulnerabilities, Vulert helps reduce both direct and hidden costs. It provides exact fix guidance, shows affected versions, supports SBOM uploads in SPDX and CycloneDX formats, groups vulnerabilities by package through Dependency Health views, and integrates with Jira for remediation tracking.

The financial value is not only breach avoidance. It is also saved developer time, better audit evidence, fewer emergency patch cycles, and faster customer security responses.

Key Takeaways

Known vulnerabilities can become billion-dollar incidents: Equifax shows what happens when an open source vulnerability remains unpatched.
The average breach is already a multimillion-dollar event: A single breach can cost more than most annual security tooling budgets.
Manual tracking wastes expensive engineering time: A small team can lose 156-260 hours per year manually tracking CVEs.
Audit and sales impact can exceed tooling cost: Failed SOC2 or enterprise security reviews can delay or kill $100K+ deals.
Automation pays for itself quickly: Vulert Pro costs $540/year, far less than the annual cost of manual tracking.
Continuous monitoring is the real control: A one-time scan does not protect you from tomorrow’s CVE disclosure.

Frequently Asked Questions

What is the real cost of open source vulnerabilities?

The real cost includes breach response, legal fees, regulatory exposure, lost customers, emergency engineering work, failed audits, delayed enterprise deals, and higher insurance pressure. The breach cost can reach millions, while the hidden operational cost begins much earlier.

How much developer time does manual CVE tracking waste?

A 5-person team spending 3-5 hours per week manually tracking CVEs loses 156-260 hours per year. At $150/hour for senior engineering time, that equals $23,400-$39,000 per year before considering emergency work or audit preparation.

Why not just run a vulnerability scan before audits?

A one-time scan before an audit is weak evidence. Auditors and enterprise buyers want to see continuous monitoring, remediation history, alert handling, ticket records, and trend reports. Continuous monitoring creates a stronger evidence trail.