Focus Friday: TPRM Insights On Critical Vulnerabilities In Exchange Server, nginx-poolslip, OpenClaw, Flowise, PostgreSQL, Mongodb, PgAdmin, FreePBX, and n8n

Introduction

Welcome to another edition of Focus Friday. This week brings one of the broadest threat landscapes of the year, with nine FocusTags® spanning email infrastructure, web servers, AI agent platforms, generative AI development tools, relational and NoSQL databases, database administration interfaces, telephony systems, and workflow automation engines.

CVE-2026-42897 in Microsoft Exchange Server represents an actively exploited zero-day stored XSS in Outlook Web Access that requires no authentication to trigger — attackers simply send a crafted email and harvest session tokens when the victim reads it through OWA. The "nginx-poolslip" zero-day targets Nginx 1.31.0 with a multi-stage ASLR bypass and Remote Code Execution chain already demonstrated publicly, with no vendor patch yet available. The "Claw Chain" in OpenClaw chains four vulnerabilities to achieve host-level persistence from inside a sandbox. CVE-2026-46442 in Flowise allows authenticated users to escape the backend sandbox entirely and execute arbitrary commands on the host server. Five vulnerabilities across PostgreSQL 14–18 introduce stack overflows, client memory corruption, integer wraparounds, filesystem hijacking, and network denial-of-service vectors. CVE-2026-8053 in MongoDB creates an out-of-bounds memory write in the time-series collection engine that can escalate to full Arbitrary Code Execution. Multiple critical flaws in pgAdmin 4 expose PostgreSQL administrators to OS command execution, privilege escalation, and authentication bypass. CVE-2026-46376 in FreePBX exposes hard-coded UCP credentials to unauthenticated access. Finally, three new critical flaws in n8n — targeting the Git, XML, and HTTP Request nodes — expand on prior prototype pollution discoveries with file read and full RCE capabilities.

For Third-Party Risk Management (TPRM) professionals, this week's disclosures confirm that no layer of the modern vendor technology stack is immune: from the email servers processing executive communications to the web servers handling public traffic, the databases persisting sensitive data, and the automation engines orchestrating it all.

Filtered view of vendors with Exchange Server - May2026 FocusTag® on the Black Kite platform.

Exchange Server - May2026 (CVE-2026-42897)

What Is the Exchange Server OWA Spoofing Vulnerability?

CVE-2026-42897 is a High-severity Cross-Site Scripting (XSS) vulnerability with a CVSS score of 8.1, affecting all on-premises versions of Microsoft Exchange Server, including Exchange 2016 (all CU23 build levels), Exchange 2019 (all CU14 and CU15 build levels), and Exchange Server Subscription Edition (SE). Exchange Online is not affected. The flaw resides in the Outlook Web Access (OWA) rendering engine's failure to properly neutralize specific HTML or script elements within message body content before generating the web page for the authenticated user — a classic CWE-79 improper neutralization of input during web page generation.

The attack requires no authentication whatsoever from the perspective of the attacker. A threat actor constructs a weaponized email containing obfuscated HTML or script components and delivers it to the target mailbox. When the victim opens the email in the OWA interface, the browser interprets the unneutralized content as executable JavaScript running under the full security context of the authenticated session. This allows the attacker to silently intercept anti-CSRF tokens, extract authentication cookies, manipulate the DOM, or forward session data directly to a command-and-control server — all without the victim performing any action beyond reading the email. Functional exploit code is available. CVE-2026-42897 was added to CISA's Known Exploited Vulnerabilities (KEV) Catalog on May 15, 2026, and is listed in the EU Vulnerability Database as EUVD-2026-30343. Approximately 55,062 Exchange Server instances are discoverable on Shodan.

Why Should TPRM Professionals Care About the Exchange Server Vulnerability?

Microsoft Exchange Server remains the backbone of corporate email communications for thousands of organizations. OWA access is routinely granted to executives, finance teams, legal counsel, and IT administrators — precisely the users whose session tokens hold the highest value. A successful exploitation of CVE-2026-42897 does not require any user interaction beyond the normal act of reading email, making it a highly effective vector for targeted compromise of high-privilege accounts.

For TPRM professionals, a vendor operating unpatched on-premises Exchange Server represents a systemic communication security risk. Session hijacking via this flaw can give attackers persistent, authenticated access to the victim's mailbox — including emails, calendar invitations, shared documents, and any sensitive correspondence processed through that account. If the compromised session belongs to an IT administrator, the impact extends to the entire Exchange environment. The CISA KEV listing confirms active exploitation is ongoing, making this a time-critical assessment for any vendor still operating on-premises Exchange.

What Questions Should TPRM Professionals Ask Vendors About the Exchange Server Vulnerability?

To assess your third-party partners' exposure to this actively exploited vulnerability, consider asking the following technical questions:

1.     Have you verified that the Exchange Emergency Mitigation Service (EEMS) has automatically applied mitigation ID M2.1.x across all on-premises Exchange servers? Can you provide confirmation from the Exchange Management Shell output?

2.     For air-gapped or disconnected Exchange environments not connected to the Microsoft cloud mitigation feed, have you manually downloaded and executed the Exchange On-Premises Mitigation Tool (EOMT) script across the full server fleet?

3.     Have you reviewed OWA and Exchange transport logs for any evidence of malicious email delivery containing suspicious HTML or script elements that may indicate active exploitation attempts against your environment?

4.     If you are running Exchange Server 2016 or 2019, have you enrolled in the Period 2 Extended Security Update (ESU) program, given that the Period 1 ESU program ended in April 2026 and permanent updates now require Period 2 enrollment?

5.     Have you assessed the feasibility of migrating remaining on-premises Exchange workloads to Exchange Online, which is not affected by CVE-2026-42897, as a long-term architectural remediation for recurring OWA-related exposure?

Remediation Recommendations for Vendors Subject to This Risk

The following recommendations are drawn directly from the Microsoft Security Response Center advisory for CVE-2026-42897 and the Microsoft Exchange Team blog post addressing the May 2026 security update.

•  Verify EEMS Mitigation Application: Immediately log into the Exchange Management Shell and confirm that mitigation ID M2.1.x is listed as 'Applied'. Note that a cosmetic error message stating 'Mitigation invalid for this exchange version' may appear but does not indicate a failed application — verify the status field specifically.
• Apply the May 2026 Security Update: Install the official May 2026 Cumulative Update or Security Update provided by Microsoft for your Exchange version. This is the definitive remediation and supersedes the EEMS mitigation.
• Manually Patch Disconnected Environments: For air-gapped servers that cannot reach the Microsoft cloud mitigation feed, manually download and run the latest EOMT script to apply the temporary mitigation until the full patch can be deployed.
• Audit Session and Access Logs: Review OWA access logs and email transport logs for anomalous script-bearing messages delivered before the mitigation was applied. Investigate any unexplained session activity from high-privilege accounts.
•  ESU Enrollment for Legacy Versions: Ensure Exchange 2016 and 2019 deployments are enrolled in the Period 2 ESU program to remain eligible for security patches.

Black Kite's Exchange Server - May2026 FocusTag® details critical insights on the event for TPRM professionals.

nginx-poolslip (Zero-Day)

What Is the nginx-poolslip Zero-Day Vulnerability?

"nginx-poolslip" is a critical, unpatched zero-day vulnerability discovered in Nginx mainline release version 1.31.0, uncovered by Nebula Security's autonomous research agent (Vega). No CVE identifier has been assigned and no CVSS score is available at the time of publication — as no vendor patch exists. The flaw targets Nginx's core memory pooling logic, enabling remote attackers to reliably bypass Address Space Layout Randomization (ASLR) and achieve full Remote Code Execution (RCE) on the affected server. A public video demonstration confirming successful exploitation against a fully hardened, modern Linux server environment has been released on X (formerly Twitter), showing an interactive root-level terminal session being spawned. Weaponized binaries and full technical documentation remain under embargo and will be published 30 days after an official patch is released. Approximately 36,555 Nginx 1.31.0 instances are discoverable on Shodan.

The exploit operates as a multi-stage attack. The first stage — "Remote Heap Probing" — involves approximately 300 targeted, high-frequency HTTP requests that dynamically map the server's memory layout in real time. The second stage, described by Nebula Security as "Crazy Heap Feng Shui," manipulates the allocation and deallocation of Nginx's internal data structures to leak the exact cryptographic memory offsets of the codebase. With ASLR completely neutralized, the attacker triggers a tailored memory corruption primitive in the pooling subsystem, redirecting the legitimate instruction execution path to an embedded payload — resulting in root-level code execution. The attack requires no authentication and leaves no standard application-level log entries during the heap probing phase.

Why Should TPRM Professionals Care About the nginx-poolslip Vulnerability?

Nginx powers approximately one-third of all active websites globally. It is deployed as the primary web server, reverse proxy, and TLS termination point in the majority of modern enterprise and cloud-native vendor architectures. A full RCE exploit against Nginx does not target a single application — it compromises the gateway through which all of a vendor's web traffic and API calls are routed, providing immediate access to backend services, internal network segments, and all data passing through the proxy layer.

For TPRM professionals, the absence of a vendor patch creates an unprecedented risk window. Vendors running Nginx 1.31.0 have no official remediation available and must rely entirely on compensating controls until a patch is released. The public demonstration of a working exploit means that sophisticated threat actors do not need to develop this capability independently — they only need to acquire the embargoed details or independently replicate the demonstrated technique. With tens of thousands of discoverable instances, the potential for automated, large-scale exploitation is significant.

What Questions Should TPRM Professionals Ask Vendors About the nginx-poolslip Vulnerability?

To assess your third-party partners' exposure to this unpatched zero-day, consider asking the following technical questions:

1.  Have you confirmed whether any of your internet-facing infrastructure is running Nginx version 1.31.0, the only version currently confirmed as vulnerable to the nginx-poolslip zero-day?
2. Have you deployed a Web Application Firewall (WAF) configured to detect and block anomalous high-frequency request clustering — the signature pattern of the remote heap probing stage of this exploit — against all Nginx-fronted endpoints?
3. Have you configured endpoint detection and response (EDR) tooling to alert on or block any Nginx worker process spawning unexpected shell processes such as /bin/sh or /bin/bash, which would indicate successful exploitation?
4. Do you have an emergency patch deployment procedure in place so that the official Nginx security patch can be applied within hours of its release, given that the 30-day full public disclosure clock begins immediately upon patch availability?

Remediation Recommendations for Vendors Subject to This Risk

As no official patch exists, all current recommendations are compensating controls based on the technical disclosure published by Nebula Security at securityonline.info and the public vulnerability description.

• Enforce Strict Network Segmentation: Restrict public internet exposure to Nginx administrative and monitoring endpoints wherever possible. Place frontend web proxies behind strict WAFs configured to flag and block anomalous, high-frequency request clustering associated with the heap probing stage of the exploit.
• Monitor Process Anomalies: Configure EDR tooling to watch Nginx worker processes closely. Any instance of Nginx spawning unexpected shell processes (/bin/sh, /bin/bash) should trigger immediate automated host isolation and full forensic logging.
• Prepare for Emergency Patching: Monitor the official Nginx security announcement boards continuously. Once the official patch is released, the 30-day public disclosure clock begins — making immediate regression testing and deployment a mandatory priority.
• Assess Version Rollback: If operationally feasible, evaluate whether downgrading from Nginx 1.31.0 to a prior stable release would eliminate exposure while awaiting the official patch.

Black Kite's nginx-poolslip FocusTag® details critical insights on the nginx-poolslip zero-day for TPRM professionals.

OpenClaw - May2026 (CVE-2026-44112, CVE-2026-44113, CVE-2026-44115, CVE-2026-44118)

What Are the OpenClaw "Claw Chain" Vulnerabilities?

A critical set of four vulnerabilities, collectively dubbed the "Claw Chain," has been disclosed in OpenClaw (formerly known as Clawdbot/Moltbot), an autonomous agent control platform. When chained together, these flaws allow an attacker who has achieved initial code execution inside the OpenShell managed sandbox to bypass restrictions, exfiltrate sensitive data, escalate privileges to owner-level, and plant persistent backdoors on the underlying host. All OpenClaw versions prior to v2026.4.22 are vulnerable. Public PoC methodologies have been reported, and these vulnerabilities are not listed in CISA's KEV Catalog. Approximately 20,740 OpenClaw instances are discoverable on Shodan.

The exploitation sequence begins with initial code execution inside the OpenShell sandbox — typically achieved via a malicious plugin, prompt injection, or a compromised external input feed. Once inside, the attacker leverages CVE-2026-44113 (TOCTOU race condition allowing file reads outside the mount root) and CVE-2026-44115 (CVSS 8.8, incomplete input validation that processes shell expansion tokens within a heredoc body) to execute unauthorized commands and expose internal credentials, secrets, and system files. Next, CVE-2026-44118 (CVSS 7.8, improper access control) is exploited to obtain owner-level control of the agent runtime by manipulating a client-controlled loopback flag called senderIsOwner that the application blindly trusts without verifying against an authenticated session. Finally, CVE-2026-44112 (CVSS 9.6, TOCTOU sandbox write-bypass) allows writes to be redirected completely outside the intended mount root — enabling modification of configuration files, establishment of cron-based persistence, and planting of persistent backdoors on the host.

Why Should TPRM Professionals Care About the OpenClaw Vulnerabilities?

OpenClaw operates as an autonomous agent control plane — a system purpose-built to execute actions on behalf of users with elevated system privileges. Unlike application-layer vulnerabilities that require multiple privilege escalation steps, the Claw Chain exploits the inherent trust model of agent platforms: because OpenClaw is designed to take autonomous actions, a successful compromise allows an adversary to mask malicious activity as legitimate agent behavior, making detection significantly more difficult.

For TPRM professionals, vendors deploying OpenClaw as part of their AI automation or DevOps pipelines expose an attack surface that goes far beyond the agent itself. A compromised OpenClaw instance with host-level access can pivot into the vendor's broader infrastructure, access secrets and credentials managed by the agent, and establish persistence that survives container restarts or redeployments via cron manipulation. Given that agent platforms routinely hold API keys, SSH credentials, and access tokens for every system they interact with, a single exploitation can cascade into a full environment compromise.

What Questions Should TPRM Professionals Ask Vendors About the OpenClaw Vulnerabilities?

To evaluate your third-party partners' exposure to the Claw Chain, consider asking the following technical questions:

1. Have you upgraded all OpenClaw (Clawdbot/Moltbot) deployments to version v2026.4.22 or higher, which patches the TOCTOU sandbox issues and changes the MCP loopback runtime to derive ownership from separate bearer tokens rather than the spoofable senderIsOwner header?
2. Have you audited all third-party plugins and external integrations running within the OpenShell sandbox, and implemented strict input sanitization patterns for dynamic prompt inputs to prevent the prompt injection vectors that enable initial sandbox access?
3. Are all OpenClaw gateway infrastructure and control endpoints properly segmented behind firewalls and strict ACLs to prevent direct public internet exposure?
4. Have you reviewed cron jobs, gateway configurations, and file operations for indicators of host-level compromise, including file writes attempting to span outside the intended sandbox mount roots?

Remediation Recommendations for Vendors Subject to This Risk

The following recommendations are drawn directly from the OpenClaw security advisory GHSA-wppj-c6mr-83jj published on GitHub and the technical disclosure via The Hacker News.

• Upgrade Immediately: Update all OpenClaw instances to version v2026.4.22 or higher. This patched release directly addresses the sandbox TOCTOU race conditions and replaces the spoofable senderIsOwner trust model with proper bearer token authentication.
• Restrict and Audit Plugin Inputs: Tightly restrict external plugins and integrations running within the OpenShell sandbox. Implement strict sanitization patterns for dynamic prompt inputs to defend against prompt injection vectors that serve as the initial access stage of the Claw Chain.
• Review and Segment Public Exposure: Ensure all OpenClaw gateway infrastructure and control endpoints are behind firewalls and ACLs. No OpenClaw management or execution interface should be directly reachable from the public internet.
• Monitor Agent Behavior for Compromise Indicators: Actively monitor network logs, system runtime activity, and execution environments for unexpected cron scheduling updates, changes to gateway configurations, or file operations targeting paths outside the intended sandbox mount roots.

Black Kite's OpenClaw - May2026 FocusTag® details critical insights on the Claw Chain for TPRM professionals.

Flowise - May2026 (CVE-2026-46442)

What Is the Flowise Sandbox Escape Vulnerability?

CVE-2026-46442 is a Critical-severity sandbox escape and Remote Code Execution vulnerability with a CVSS score of 9.4 and an EPSS score of 0.02%, affecting all currently known versions of Flowise, the popular open-source generative AI development platform. The flaw enables authenticated users — or those with a low-privileged API key — to fully escape the backend sandbox and execute arbitrary commands on the underlying host server. A Proof-of-Concept exploit has been published. The vulnerability is not listed in CISA's KEV Catalog.

The exploit operates as a two-stage chain. The first stage exploits a Missing Route-Level Authorization flaw: the endpoint processing custom JavaScript functions (router.post('/', nodesRouter.executeCustomFunction)) lacks the necessary authentication middleware, allowing any valid authenticated user to interact with this execution endpoint regardless of their privilege level. The second stage triggers when an E2B API key for external sandboxing is not configured, causing Flowise to fall back silently to a basic NodeVM sandbox. A specially crafted error-handling payload forces the runtime to leak components of the host architecture. By traversing the leaked prototype chain (e.constructor.constructor), the attacker captures the host's Function constructor and gains direct access to Node.js system libraries such as child_process, enabling arbitrary OS command execution on the server hosting the Flowise instance.

Why Should TPRM Professionals Care About the Flowise Vulnerability?

Flowise has become a cornerstone platform for organizations building generative AI applications — used to construct RAG pipelines, chatbot backends, LLM agent frameworks, and custom AI-powered workflows. These deployments routinely handle sensitive datasets, proprietary knowledge bases, and API credentials for connected AI services. Unlike a typical application vulnerability, a sandbox escape in an AI development platform means that the very tool designed to build AI products becomes an unrestricted gateway to the host server.

For TPRM professionals, a vendor running an unpatched Flowise deployment represents a direct threat to any data processed or stored within that AI development environment. The fact that exploitation requires only a low-privileged API key — not administrative credentials — substantially lowers the barrier. A single compromised API key, leaked through any means, is sufficient to achieve full host compromise. The silent fallback to the vulnerable NodeVM sandbox when E2B is not configured means that most default Flowise deployments are vulnerable without administrators being aware of the exposure.

What Questions Should TPRM Professionals Ask Vendors About the Flowise Vulnerability?

To evaluate your third-party partners' exposure to CVE-2026-46442, consider asking the following technical questions:

1. Has the vendor applied the official Flowise security patch addressing CVE-2026-46442 once released? If a patch is not yet deployed, what compensating controls are in place?
2.  Is the E2B API key actively configured on all Flowise deployments to prevent the silent fallback to the vulnerable local NodeVM sandbox that serves as the sandbox escape mechanism in this exploit?
3. Have all Flowise user accounts and API keys been reviewed and restricted to the minimum necessary permissions, eliminating any shared or unused credentials that could serve as the low-privilege access point for this exploit?
4. Are Flowise deployments isolated within secure network segments with direct external access restricted, so that even a compromised deployment limits the attacker's pivot capability into broader infrastructure?
5. Have Flowise server logs been reviewed for unusual activity, suspicious command execution events, or attempts to access prototype chain properties consistent with the CVE-2026-46442 exploit technique?

Remediation Recommendations for Vendors Subject to This Risk

The following recommendations are drawn from the Flowise security disclosure published at securityonline.info and the vulnerability details for CVE-2026-46442.

• Apply Vendor Patches Immediately: Monitor Flowise's official release channels and apply the security patch addressing CVE-2026-46442 as soon as it becomes available.
• Configure the E2B API Key: Actively configure the E2B API key in all Flowise deployments to prevent the silent fallback to the vulnerable NodeVM sandbox. This is the most direct compensating control available prior to patching.
• Enforce Least Privilege for All API Keys and User Accounts: Restrict all Flowise user accounts and API keys to the minimum permissions required. Revoke unused, shared, or overly broad credentials immediately.
• Network Isolation: Isolate all Flowise deployments within secure network segments and restrict direct external internet access to minimize the attacker's ability to reach the execution endpoint and exfiltrate data after exploitation.
• Active Log Monitoring: Monitor Flowise server logs continuously for suspicious command execution patterns, unusual prototype chain traversal activity, or unauthorized access to the custom JavaScript function execution endpoint.

Black Kite's Flowise - May2026 FocusTag® details critical insights on the event for TPRM professionals.

PostgreSQL - May2026 (CVE-2026-6637, CVE-2026-6477, CVE-2026-6473, CVE-2026-6475, CVE-2026-6479)

What Are the PostgreSQL May 2026 Vulnerabilities?

The PostgreSQL Global Development Group has released a coordinated security update addressing five vulnerabilities across all actively supported branches (PostgreSQL 14 through 18). The highest CVSS score is 8.8 (CVE-2026-6637). No public PoC is available, and none of these vulnerabilities appear in CISA's KEV Catalog. Approximately 199,841 PostgreSQL instances are discoverable on Shodan. An End-of-Life warning has also been issued for PostgreSQL 14, which will cease receiving security updates on November 12, 2026.

CVE-2026-6637 (CVSS 8.8) is a stack buffer overflow in the legacy refint module. An unprivileged database user can exploit this to break out of the database context and execute arbitrary commands with OS-level privileges of the running engine process. It also acts as a secondary SQL injection vector if an application uses a user-controlled column as a refint cascade primary key. CVE-2026-6477 (CVSS 8.8) is a client-side memory corruption flaw in the internal PQfn() function within libpq, where failure to validate size limits during data copy allows a compromised or malicious superuser to overflow the stack memory of the client machine — affecting utilities like psql and pg_dump that depend on these functions.

CVE-2026-6473 involves integer wraparound vulnerabilities across multiple server components, where carefully crafted input can force the server to undersize memory allocations and trigger an out-of-bounds write causing a segmentation fault and server crash. CVE-2026-6475 is a symlink validation flaw in pg_basebackup and pg_rewind that allows an origin superuser to step outside intended directories and overwrite arbitrary files on the host system. CVE-2026-6479 is a network Denial of Service vulnerability in the SSL and GSS authentication negotiation phases, where an attacker with access to a PostgreSQL AF_UNIX socket can trigger an infinite loop and sustained denial of service. Patched versions are: PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23.

Why Should TPRM Professionals Care About the PostgreSQL Vulnerabilities?

PostgreSQL is one of the most widely deployed relational databases in enterprise environments, serving as the persistence layer for SaaS applications, internal business systems, analytics platforms, and AI backends. These five vulnerabilities collectively span the full stack of PostgreSQL's architecture — from the server engine and its modules to client libraries and backup utilities — meaning that patching the database server alone is insufficient if client tools and auxiliary components remain unpatched.

For TPRM professionals, the CVE-2026-6637 stack overflow is particularly significant because it allows an unprivileged database user to break out of database boundaries entirely. If vendors grant broad database access to application service accounts — a common configuration anti-pattern — this flaw becomes exploitable without requiring superuser privileges. The CVE-2026-6475 symlink flaw is equally concerning from a data integrity perspective: an attacker with superuser access can overwrite arbitrary host files, including SSH authorized keys or shell configuration files, establishing host-level persistence.

What Questions Should TPRM Professionals Ask Vendors About the PostgreSQL Vulnerabilities?

To assess your third-party partners' database security posture against these vulnerabilities, consider asking the following technical questions:

1. Have all PostgreSQL instances been upgraded to patched versions — 18.4, 17.10, 16.14, 15.18, or 14.23 — and have client-side tools including psql, pg_dump, pg_basebackup, and pg_rewind been updated to eliminate the CVE-2026-6477 and CVE-2026-6475 exposures in those utilities?
2.  Are all database user accounts operating under the principle of least privilege? Specifically, are application service accounts restricted from using the refint module functionality targeted by CVE-2026-6637?
3. Is PostgreSQL access restricted to trusted internal network segments only, with PostgreSQL AF_UNIX sockets and TCP endpoints not directly accessible from untrusted networks, to limit the CVE-2026-6479 denial-of-service attack surface?
4. For PostgreSQL 14 deployments, has the vendor assessed the November 12, 2026 EOL deadline and developed a migration plan to a supported version that will continue receiving security updates?

Remediation Recommendations for Vendors Subject to This Risk

The following recommendations are drawn from the official PostgreSQL security advisories published at postgresql.org/support/security for each of the five CVEs.

• Apply Binary Updates Immediately: Update PostgreSQL binaries to the patched versions — 18.4, 17.10, 16.14, 15.18, or 14.23 — and restart the database service. As PostgreSQL minor updates do not alter structural disk data, this process is straightforward and low-risk for production environments.
• Update All Client Tools: Ensure psql, pg_dump, pg_basebackup, and pg_rewind are also updated to the patched versions to eliminate the client-side CVE-2026-6477 and CVE-2026-6475 exposures.
• Enforce Least Privilege: Review and restrict database user account permissions. Ensure application service accounts cannot use the refint module unless explicitly required.
• Restrict Network Access: Bind PostgreSQL listeners to trusted internal interfaces only and apply firewall rules to prevent untrusted network access to PostgreSQL ports and AF_UNIX sockets.
• Plan PostgreSQL 14 Migration: Begin planning migration from PostgreSQL 14 to a supported version ahead of the November 12, 2026 EOL date to ensure continued access to security updates.

Black Kite's PostgreSQL - May2026 FocusTag® details critical insights on the event for TPRM professionals.

MongoDB - May2026 / TimeSeriesACE (CVE-2026-8053)

What Is the MongoDB TimeSeriesACE Vulnerability?

CVE-2026-8053 is a Critical-severity Arbitrary Code Execution vulnerability with a CVSS score of 8.7 and an EPSS score of 0.06%, affecting MongoDB Server's time-series collection implementation across multiple release trains. A public Proof-of-Concept has been reported. The vulnerability is not listed in CISA's KEV Catalog and is tracked in the EU Vulnerability Database as EUVD-2026-29888.

The flaw stems from a dangerous inconsistency in how MongoDB handles internal field-name-to-index mapping inside the time-series bucket catalog. An authenticated user with basic database write privileges can exploit this inconsistency to trigger an out-of-bounds memory write directly within the core mongod process. Under the right conditions, this memory corruption escalates to Arbitrary Code Execution (ACE), allowing the attacker to execute malicious code with the privileges of the MongoDB server process and gain complete control over the database environment. Affected version ranges span: MongoDB 5.0.0–5.0.32, 6.0.0–6.0.27, 7.0.0–7.0.33, 8.0.0–8.0.22, 8.2.0–8.2.8, and 8.3.0–8.3.1. Patched versions are: 5.0.33, 6.0.28, 7.0.34, 8.0.23, 8.2.9, and 8.3.2. Redis Cloud customers are automatically protected; self-managed instances require immediate action.

Why Should TPRM Professionals Care About the MongoDB Vulnerability?

MongoDB is deployed as the primary data store for document-oriented applications across a vast range of enterprise systems — from user profile databases and product catalogs to IoT data platforms and real-time analytics engines. The time-series collection feature targeted by this vulnerability is specifically designed for high-volume, time-stamped data workloads, making it widely used in monitoring systems, financial data pipelines, and operational telemetry platforms.

For TPRM professionals, the critical concern is that exploitation requires only authenticated write access — not superuser or DBA-level privileges. In environments where application service accounts are granted broad write permissions to MongoDB collections (a common pattern), a compromised service account is sufficient to trigger ACE with MongoDB server process privileges. This gives an attacker not just database access but operating system-level execution capability, opening paths to lateral movement into any system accessible from the MongoDB server.

What Questions Should TPRM Professionals Ask Vendors About the MongoDB Vulnerability?

To assess your third-party partners' exposure to CVE-2026-8053, consider asking the following technical questions:

1. Have all MongoDB Server instances been upgraded to the patched versions — 5.0.33, 6.0.28, 7.0.34, 8.0.23, 8.2.9, or 8.3.2 — across all deployment environments including development, staging, and production?
2. Have all operational and application accounts been audited, with write privileges restricted to only the collections and operations explicitly required for their function?
3.  Is MongoDB completely unreachable from untrusted networks, with access restricted strictly to trusted application paths, bastion hosts, or explicitly approved administrative IP ranges?
4. Have all database user credentials been reviewed for password reuse, shared credentials, or credentials that have not been rotated in the last 90 days, given that a compromised write-privileged account is sufficient to trigger this vulnerability?

Remediation Recommendations for Vendors Subject to This Risk

The following recommendations are drawn from the MongoDB security advisory for CVE-2026-8053 published at jira.mongodb.org (SERVER-126021) and the securityonline.info technical analysis.

• Immediate Software Upgrade: Update all self-managed MongoDB instances to the patched versions for the relevant release train. MongoDB Atlas (cloud) instances have been automatically protected.
• Lock Down Network Access: Ensure MongoDB is completely unreachable from untrusted networks. Restrict all access strictly to trusted application paths, bastion hosts, and explicitly approved administrative IP ranges.
• Audit and Restrict Write Privileges: Conduct an immediate review of all accounts with write access to MongoDB. Strip unnecessary write privileges and flag shared or reused credentials for immediate rotation.
• Enforce Strict Credential Hygiene: Ensure all authentication credentials are unique per account and environment, using strong passphrases of at least 15 characters. Rotate any credentials not changed within the past 90 days.

Black Kite's MongoDB - May2026 FocusTag® details critical insights on the TimeSeriesACE vulnerability for TPRM professionals.

pgAdmin - May2026 (CVE-2026-7813, CVE-2026-7816, CVE-2026-7815, CVE-2026-7820, CVE-2026-7818, CVE-2026-7817, and CVE-2026-7819)

What Are the pgAdmin May 2026 Vulnerabilities?

A cluster of seven high and critical-severity vulnerabilities has been disclosed in pgAdmin 4, the leading open-source administration platform for PostgreSQL. All versions of pgAdmin 4 prior to v9.15 are affected. The most severe flaw, CVE-2026-7813 (CVSS 9.4), involves improper access control in server mode, allowing authenticated users to guess object IDs and access private servers and debugger arguments belonging to other users, with a privilege escalation path through the Shared Servers feature enabling modification of the passexec_cmd field to execute arbitrary shell commands during connection establishment. No public PoC is available, and these vulnerabilities are not listed in CISA's KEV Catalog. They are tracked in the EU Vulnerability Database as EUVD-2026-29081 through EUVD-2026-29087.

Two critical Remote Code Execution paths are provided through SQL tool abuse: CVE-2026-7816 (CVSS 9.1) involves the Export Tool performing raw interpolation of user input into a psql \copy template, enabling OS command injection via the TO PROGRAM primitive. CVE-2026-7815 (CVSS 9.1) similarly allows OS command execution through the Maintenance Tool by concatenating JSON fields directly into VACUUM and ANALYZE commands. Additional flaws include CVE-2026-7818 (unsafe deserialization of session files enabling RCE via a crafted file in the sessions directory), CVE-2026-7817 (SSRF and arbitrary file reads via unvalidated LLM API settings), CVE-2026-7820 (CVSS 6.9, account lockout bypass on a hidden /login endpoint enabling unbounded brute-force attacks), and CVE-2026-7819 (file manipulation outside designated directories via symbolic link path traversal). The fixed version is pgAdmin 4 v9.15.

Why Should TPRM Professionals Care About the pgAdmin Vulnerabilities?

pgAdmin is the primary administrative gateway to PostgreSQL databases — the tool through which database administrators configure, query, and manage the data stores holding an organization's most sensitive information. In server mode, pgAdmin deployments are frequently accessible to multiple administrators simultaneously, meaning that a single exploited account can escalate to control the entire pgAdmin infrastructure.

For TPRM professionals, the convergence of OS command execution paths (CVE-2026-7816 and CVE-2026-7815), session hijacking via deserialization (CVE-2026-7818), and brute-force enablement (CVE-2026-7820) in a single pgAdmin version creates a compounding risk profile. An attacker who gains access to any pgAdmin user account — even a low-privileged one — has multiple independent pathways to escalate to full OS command execution. Because pgAdmin sits directly in front of the PostgreSQL databases processing customer data, supply chain partners' data, and internal business records, its compromise is equivalent to full database environment compromise.

What Questions Should TPRM Professionals Ask Vendors About the pgAdmin Vulnerabilities?

To evaluate your third-party partners' PostgreSQL administration security posture, consider asking the following technical questions:

1. Have all pgAdmin 4 installations been upgraded to version 9.15 or higher, the fixed release that implements centralized access control and strict allow-listing for SQL commands to remediate CVE-2026-7813 through CVE-2026-7820?
2.  Is pgAdmin 4 in server mode accessible only through a VPN or SSH tunnel, with no direct public internet exposure, to prevent external attackers from reaching the authentication and execution endpoints targeted by these vulnerabilities?
3. Have unused or non-essential features — specifically the LLM API and File Manager features — been disabled or strictly restricted to administrative users to eliminate the CVE-2026-7817 SSRF and arbitrary file read attack surface?
4. Have pgAdmin session files and application logs been audited for suspicious entries, unauthorized command executions, or crafted session files consistent with the CVE-2026-7818 deserialization exploit?

Remediation Recommendations for Vendors Subject to This Risk

The following recommendations are drawn from the pgAdmin security advisory published at github.com/advisories/GHSA-h2x2-q2mc-24gw and the technical analysis at securityonline.info.

• Immediate Software Upgrade: Update to pgAdmin 4 v9.15 or higher. This release centralizes access controls and introduces strict allow-listing for SQL commands, directly addressing the root causes of the RCE and privilege escalation vulnerabilities.
• Restrict Network Access: Ensure pgAdmin 4 in server mode is not exposed to the public internet. Use a VPN or SSH tunnel exclusively for remote administrative access.
• Disable Unused Features: Disable the LLM API and File Manager features if not required, or restrict them strictly to administrative users to eliminate the SSRF and file read attack surface from CVE-2026-7817.
• Audit Session and Log Files: Review the pgAdmin sessions directory and application logs for suspicious entries, crafted files, or unauthorized command execution events.
• Harden Database Permissions: Restrict the PostgreSQL service account used by pgAdmin to the minimum privilege level necessary, specifically limiting its ability to execute COPY ... TO PROGRAM where not operationally required.

Black Kite's pgAdmin - May2026 FocusTag® details critical insights on the event for TPRM professionals.

FreePBX - May2026 (CVE-2026-46376)

What Is the FreePBX Hard-Coded Credentials Vulnerability?

CVE-2026-46376 (GHSA-m55x-h47x-v3gx) is a Critical-severity Unauthenticated Use of Hard-Coded Credentials vulnerability in the FreePBX User Control Panel (UCP) interface. No CVSS score or EPSS value is currently available in NIST NVD. No public PoC has been reported, and the vulnerability is not listed in CISA's KEV Catalog. The flaw affects the userman module in FreePBX versions prior to 16.0.45 and prior to 17.0.7.

When UCP generic templates are enabled in FreePBX, the system initializes accounts using hard-coded sample credentials baked into the template configuration. If an administrator activates these templates without immediately changing the default credentials, unauthenticated attackers can use these known, hard-coded values to log into the UCP interface without any prior knowledge of the target environment. The vulnerability is configuration-dependent — it requires an administrator to have enabled UCP templates and neglected to change the defaults — but given the breadth of FreePBX deployments across managed telephony environments, this configuration oversight is common in practice. The remediation in userman 16.0.45 and 17.0.7 randomizes the default password, eliminating the predictable credential exposure.

Why Should TPRM Professionals Care About the FreePBX Vulnerability?

FreePBX is the dominant open-source telephony administration platform, used by businesses and managed service providers to control VoIP PBX infrastructure. The User Control Panel provides users with access to their extension settings, voicemail, call recordings, and in some configurations, broader system administration capabilities. Unauthorized access to the UCP is not merely a cosmetic risk — it provides an attacker with access to voicemail recordings, call history, and potentially the ability to reconfigure extensions or intercept calls.

For TPRM professionals, vendors operating FreePBX as part of their unified communications infrastructure may inadvertently expose call recordings containing sensitive business discussions, customer interactions, or internal communications through this flaw. Managed service providers administering FreePBX deployments on behalf of multiple customers face an even broader exposure: a single UCP compromise in a multi-tenant deployment can provide access across multiple customers' telephony environments if tenant isolation is insufficient.

What Questions Should TPRM Professionals Ask Vendors About the FreePBX Vulnerability?

To evaluate your third-party partners' telephony infrastructure security posture, consider asking the following technical questions:

1. Has the userman module been updated to version 16.0.45 or higher (FreePBX 16) or 17.0.7 or higher (FreePBX 17) to implement randomized default passwords and fully remediate CVE-2026-46376?
2. If UCP generic templates are enabled in your FreePBX deployment, have all accounts initialized from those templates been audited and forced to change their credentials from any default values that may have been in place?
3.  Is the FreePBX UCP interface accessible only from trusted internal networks, with direct public internet access blocked at the firewall level to reduce exposure in the event of any future hard-coded credential vulnerabilities?
4. Have UCP access logs been reviewed for any unauthorized login attempts or successful logins using default credential patterns that may indicate exploitation prior to the patch being applied?

Remediation Recommendations for Vendors Subject to This Risk

The following recommendations are drawn from the FreePBX security advisory GHSA-m55x-h47x-v3gx and the technical disclosure at securityonline.info.

• Update the userman Module Immediately: Upgrade the userman module to version 16.0.45 or higher for FreePBX 16, or 17.0.7 or higher for FreePBX 17. This update randomizes the default password, directly mitigating CVE-2026-46376.
• Audit and Reset Template-Based Credentials: If UCP generic templates are or have been enabled, immediately audit all accounts initialized from those templates and require password changes for any account that may have retained default credentials.
• Restrict UCP Network Access: Apply firewall rules to prevent direct public internet access to the FreePBX UCP interface. Limit access to trusted internal network ranges only.
• Review UCP Access Logs: Audit UCP login logs for any successful authentication events from unexpected IP addresses or at unusual times that may indicate prior exploitation.

Black Kite's FreePBX - May2026 FocusTag® details critical insights on the event for TPRM professionals.

n8n - May2026 (CVE-2026-44790, CVE-2026-44791, CVE-2026-44789)

What Are the n8n May 2026 Vulnerabilities?

Three new critical-severity vulnerabilities — CVE-2026-44790, CVE-2026-44791, and CVE-2026-44789 — have been disclosed in the n8n workflow automation platform, each carrying a CVSS score of 9.4. These flaws target core native processing nodes: the Git node, the XML node, and the HTTP Request node respectively. Additionally, CVE-2026-44791 represents a patch bypass for the previously disclosed CVE-2026-42232, demonstrating that prior incomplete security controls in n8n's XML parsing logic remain exploitable. No public PoC is available, and these vulnerabilities are not listed in CISA's KEV Catalog. Approximately 60,833 n8n instances are discoverable on Shodan. Patched versions are 2.22.1, 2.20.7, and 1.123.43 (or later).

CVE-2026-44790 targets the Git node during a Push operation. The application fails to properly sanitize input parameters passed to the underlying CLI, allowing an attacker to craft a workflow that injects malicious CLI flags into backend Git parameters and forces the n8n server to perform arbitrary file reads from the local filesystem — exposing .env files, master API tokens, and hardcoded operational secrets. CVE-2026-44791 is a bypass of the prior prototype pollution fix in the XML node: due to incomplete security controls in the XML parsing logic, a specially structured payload can still manipulate the global JavaScript Object.prototype. When chained with downstream processing nodes, this achieves full Remote Code Execution. CVE-2026-44789 targets the HTTP Request node, where an unvalidated pagination configuration parameter can be exploited to trigger global prototype pollution across the application template — similarly escalating to RCE via auxiliary system behaviors.

Why Should TPRM Professionals Care About the n8n May 2026 Vulnerabilities?

n8n has emerged as the central orchestration hub of modern enterprise IT operations — connecting SaaS platforms, internal databases, communication tools, cloud services, and custom APIs as part of automated workflows that run continuously across business processes. This architectural role means that n8n instances inherently hold credentials for every system they connect to, making them a master key to an organization's integrated technology stack.

For TPRM professionals, the May 2026 n8n disclosures are particularly concerning for two reasons. First, CVE-2026-44791's status as a patch bypass for a previously known vulnerability demonstrates that vendors who believed they had remediated the prior n8n Prototype Pollution issues may remain exposed. Second, the combination of a file read path (CVE-2026-44790) and two independent RCE paths (CVE-2026-44791, CVE-2026-44789) means that even a partially successful exploit chain — one that achieves file read without RCE — can exfiltrate sufficient credentials to enable complete environment compromise through secondary means. With over 60,000 n8n instances discoverable on Shodan, the scale of potential exposure demands immediate prioritization.

What Questions Should TPRM Professionals Ask Vendors About the n8n May 2026 Vulnerabilities?

To evaluate your third-party partners' workflow automation security posture against these flaws, consider asking the following technical questions:

1. Have all n8n deployments been upgraded to the patched versions — 2.22.1, 2.20.7, or 1.123.43 (or later) — which address the underlying CLI escaping, parameter validation, and XML parsing flaws across all three vulnerable nodes?
2. Given that CVE-2026-44791 is a patch bypass for the previously disclosed CVE-2026-42232, have you confirmed that the remediation applied to your n8n deployment addresses the updated exploit technique and not merely the original vulnerability?
3. Are workflow creation and editing permissions restricted exclusively to fully trusted platform administrators, preventing lower-privilege users from constructing the malicious workflows required to trigger these vulnerabilities?
4. Have you reviewed and rotated all API keys, OAuth tokens, database connection strings, and credentials stored within n8n's credential manager, given that CVE-2026-44790 specifically enables arbitrary local file reads targeting .env files and token stores?
5.  If immediate upgrading is blocked by internal testing cycles, have the Git node, XML node, and HTTP Request node been disabled via the NODES_EXCLUDE environment variable as a temporary compensating control?

Remediation Recommendations for Vendors Subject to This Risk

The following recommendations are drawn from the official n8n security advisories published on GitHub: GHSA-c8xv-5998-g76h (CVE-2026-44790), GHSA-57g9-58c2-xjg3 (CVE-2026-44791), and GHSA-wrwr-h859-xh2r (CVE-2026-44789).

• Upgrade Immediately: Update all n8n instances to version 2.22.1, 2.20.7, or 1.123.43 or later. This unified security release addresses CLI escaping in the Git node, prototype pollution in the XML node, and parameter validation in the HTTP Request node.
• Restrict Workflow Permissions: Enforce strict RBAC — limit workflow creation and editing rights exclusively to fully trusted platform administrators. Revoke these permissions from standard or untrusted user accounts immediately.
•  Temporary Node Disablement: If upgrading is delayed, add the affected nodes to the NODES_EXCLUDE environment variable to disable them as a temporary compensating control. Note that this will break workflows dependent on those nodes.
• Rotate Credentials: Immediately audit and rotate all credentials stored in n8n's credential manager — API keys, OAuth tokens, database connection strings, and any .env-stored secrets accessible via the CVE-2026-44790 file read path.
• Run n8n as a Low-Privilege Service Account: Ensure the n8n process runs under a dedicated, low-privilege OS user to contain the blast radius of any successful RCE.

Black Kite's n8n - May2026 FocusTag® details critical insights on the event for TPRM professionals.

How TPRM Professionals Can Leverage Black Kite for These Vulnerabilities

This week's nine-tag vulnerability landscape represents one of the most operationally complex weeks of the year for TPRM teams, spanning active zero-day exploitation in enterprise email infrastructure, unpatched RCE in web server software, chained sandbox escapes in AI agent and generative AI platforms, memory corruption in two of the most widely deployed database engines, critical flaws in the database administration tool that manages them, hard-coded credentials in telephony systems, and three new critical nodes compromised in a workflow automation platform. Black Kite's threat intelligence team published these FocusTags® across the week of May 15, 2026 — including the Exchange Server - May2026 FocusTag® (coinciding with CISA's KEV addition on May 15), the NGINX - May2026, OpenClaw - May2026, Flowise - May2026, PostgreSQL - May2026, MongoDB - May2026, pgAdmin - May2026, FreePBX - May2026, and n8n - May2026 FocusTags®.

TPRM teams can deploy these nine FocusTags® in parallel to immediately filter their entire vendor portfolio — identifying in a single pass which vendors are running active exploitation targets like unpatched Exchange Server OWA, which are exposing Nginx 1.31.0 to the internet without compensating WAF controls, which vendors' AI development stacks include unpatched Flowise or OpenClaw deployments, and which database environments carry the PostgreSQL, MongoDB, or pgAdmin exposures catalogued this week. Rather than waiting for vendor self-reporting through questionnaire cycles that can take weeks, analysts can drive evidence-based outreach to the specific vendors whose infrastructure is demonstrably exposed.

Black Kite's platform provides not just tag-level filtering but granular asset-level detail for each identified vendor — specific IP addresses, subdomains, and exposed service versions. For a week with nine simultaneous FocusTags®, this capability is essential: risk teams can triage by vendor criticality and tag severity simultaneously, directing first-priority engagement toward vendors running actively exploited vulnerabilities like Exchange Server CVE-2026-42897, while systematically working through higher-count, lower-criticality exposures across the rest of the portfolio.

Strengthening TPRM Outcomes with Black Kite’s FocusTags®

A week that simultaneously exposes email servers, web servers, AI platforms, relational and NoSQL databases, database administration tools, telephony infrastructure, and automation engines demonstrates that the modern vendor attack surface has no well-defined perimeter. Black Kite's FocusTags® are built precisely for this reality — designed to transform an overwhelming volume of simultaneous vulnerability disclosures into a structured, prioritized action plan that TPRM teams can execute efficiently.

When managing the breadth of this week's disclosures, Black Kite's FocusTags® empower your team through:

• Immediate Threat Visibility: Instantly identify which vendors are exposed to any of this week's nine FocusTags® — from the actively exploited Exchange Server zero-day and the unpatched Nginx RCE to the database and automation vulnerabilities — enabling targeted outreach before exploitation cascades through your supply chain.
• Contextual Risk Triage: Evaluate each vendor's exposure against their role in your ecosystem. A vendor running unpatched Exchange Server OWA that processes your organization's email communications demands different urgency than one with a MongoDB time-series collection vulnerability in an isolated analytics environment.
• Evidence-Based Vendor Collaboration: Replace broad, time-consuming questionnaires with direct, evidence-based conversations. Provide vendors with the specific IP addresses and subdomains identified as running vulnerable Exchange Server builds, exposed Nginx 1.31.0 instances, or unpatched database administration interfaces.
• Resilient Supply Chain Defense: Maintain a continuous, comprehensive view of your extended attack surface across all technology layers — from email and web infrastructure to AI platforms, database engines, and automation systems — so your organization can adapt its security posture in real time as new vulnerabilities emerge.

By transforming raw cyber threat data into precise, actionable intelligence, Black Kite's FocusTags® provide TPRM professionals with the exact tools needed to efficiently and effectively secure the digital supply chain against today's most sophisticated attacks.

About Focus Friday

Every week, we delve into the realms of critical vulnerabilities and their implications from a Third-Party Risk Management (TPRM) perspective. This series is dedicated to shedding light on pressing cybersecurity threats, offering in-depth analyses, and providing actionable insights.

FocusTags® in the Last 30 Days:

• Exchange Server - May2026 : CVE-2026-42897, High-Severity Cross-Site Scripting (XSS) Vulnerability in Outlook Web Access (OWA) actively exploited in the wild, allowing unauthenticated attackers to execute arbitrary JavaScript in authenticated user sessions via a crafted email, enabling session hijacking and account takeover. Added to CISA KEV on May 15, 2026.
• NGINX - May2026 : Unpatched Zero-Day "nginx-poolslip" Memory Corruption Vulnerability in Nginx 1.31.0 allowing remote attackers to bypass ASLR defenses and achieve full Remote Code Execution via multi-stage heap probing and memory corruption. No CVE assigned. No vendor patch available.
• OpenClaw - May2026 : CVE-2026-44112, CVE-2026-44113, CVE-2026-44115, CVE-2026-44118, Critical "Claw Chain" of four chained vulnerabilities enabling sandbox escape, sensitive data exfiltration, owner-level privilege escalation, and host-level persistent backdoor installation in the OpenClaw autonomous agent platform.
• Flowise - May2026 : CVE-2026-46442, Critical Sandbox Escape and Remote Code Execution Vulnerability in the Flowise generative AI platform, allowing authenticated users to escape the backend NodeVM sandbox and execute arbitrary OS commands on the host server via missing route-level authorization combined with prototype chain traversal.
• PostgreSQL - May2026 : CVE-2026-6637, CVE-2026-6477, CVE-2026-6473, CVE-2026-6475, CVE-2026-6479, Multiple High-Severity Vulnerabilities including stack buffer overflow enabling OS command execution, client-side memory corruption, integer wraparounds, filesystem hijacking via symlinks, and network Denial of Service across PostgreSQL versions 14–18.
• MongoDB - May2026 : CVE-2026-8053, Critical Time-Series Arbitrary Code Execution Vulnerability in MongoDB Server's time-series collection implementation allowing authenticated users with write privileges to trigger out-of-bounds memory write and achieve full server compromise.
• pgAdmin - May2026 : CVE-2026-7813, CVE-2026-7816, CVE-2026-7815, CVE-2026-7820, CVE-2026-7818, CVE-2026-7817, CVE-2026-7819, Critical and High-Severity OS Command Injection, Improper Authorization, Unsafe Deserialization, SSRF, and Authentication Bypass Vulnerabilities in pgAdmin 4 prior to v9.15 allowing full host OS command execution and administrative takeover.
• FreePBX - May2026 : CVE-2026-46376, Critical Hard-Coded Credentials Vulnerability in the FreePBX User Control Panel (UCP) interface allowing unauthenticated attackers to gain access using hard-coded default template credentials if not changed by the administrator.
• n8n - May2026 : CVE-2026-44790, CVE-2026-44791, CVE-2026-44789, Critical Git Node Arbitrary File Read, XML Node Prototype Pollution Patch Bypass, and HTTP Request Node Prototype Pollution Vulnerabilities in n8n workflow automation enabling arbitrary local file reads and full Remote Code Execution on the host server.
• Dead.Letter : CVE-2026-45185, Critical Remote Code Execution, Use-After-Free, Memory Corruption, and Improper Input Validation Vulnerabilities in Exim Mail Server.
• SharePoint - May2026 : CVE-2026-35439, CVE-2026-33110, CVE-2026-33112, CVE-2026-40357, CVE-2026-40365, CVE-2026-40368, High-Severity Remote Code Execution Vulnerabilities in Microsoft SharePoint.
• MSSQL - May2026 : CVE-2026-40370, High-Severity Remote Code Execution and Privilege Escalation Vulnerability in Microsoft SQL Server.
• cPanel & WHM : CVE-2026-41940, Critical Authentication Bypass Vulnerability in cPanel & WHM.
• Redis - May2026 : CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, CVE-2026-23479, CVE-2026-23631, High-Severity Invalid Memory Access and Use-After-Free Vulnerabilities in Redis.
• Ivanti EPMM - May2026 : CVE-2026-6973, CVE-2026-7821, Improper Input Validation, Remote Code Execution, Improper Certificate Validation, Authentication Bypass, Information Disclosure, and Data Integrity Failure Vulnerabilities in Ivanti EPMM.
• Ollama : CVE-2026-5757, Critical Information Disclosure, Out-of-Bounds Read, and Memory Corruption Vulnerabilities in Ollama.
• Langflow - Apr2026 : CVE-2026-42048, Critical Path Traversal Vulnerability in Langflow.
• SonicWall SonicOS - Apr2026 : CVE-2026-0204, CVE-2026-0205, CVE-2026-0206, High-Severity Improper Access Control, Path Traversal, and Stack-Based Buffer Overflow Vulnerabilities in SonicWall SonicOS.

See Black Kite's full CVE Database and the critical TPRM vulnerabilities that have an applied  FocusTags® at https://blackkite.com/cve-database/.

References

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42897

https://www.bleepingcomputer.com/news/microsoft/microsoft-warns-of-exchange-zero-day-flaw-exploited-in-attacks/

https://www.cve.org/CVERecord?id=CVE-2026-42897

https://techcommunity.microsoft.com/blog/exchange/addressing-exchange-server-may-2026-vulnerability-cve-2026-42897/4518498

https://securityonline.info/nginx-poolslip-zero-day-aslr-bypass-remote-code-execution/

https://thehackernews.com/2026/05/four-openclaw-flaws-enable-data-theft.html

https://github.com/openclaw/openclaw/security/advisories/GHSA-wppj-c6mr-83jj

https://nvd.nist.gov/vuln/detail/CVE-2026-44112

https://nvd.nist.gov/vuln/detail/CVE-2026-44113

https://nvd.nist.gov/vuln/detail/CVE-2026-44115

https://nvd.nist.gov/vuln/detail/CVE-2026-44118

https://securityonline.info/flowise-sandbox-escape-vulnerability-cve-2026-46442-host-rce/

https://www.postgresql.org/support/security/CVE-2026-6637/

https://www.postgresql.org/support/security/CVE-2026-6477/

https://www.postgresql.org/support/security/CVE-2026-6473/

https://www.postgresql.org/support/security/CVE-2026-6475/

https://www.postgresql.org/support/security/CVE-2026-6479/

https://nvd.nist.gov/vuln/detail/CVE-2026-8053

https://securityonline.info/mongodb-time-series-vulnerability-cve-2026-8053-patch-alert/

https://jira.mongodb.org/browse/SERVER-126021

https://securityonline.info/pgadmin-4-critical-vulnerabilities-rce-authorization-bypass-v9-15/

https://github.com/advisories/GHSA-h2x2-q2mc-24gw

https://github.com/FreePBX/security-reporting/security/advisories/GHSA-m55x-h47x-v3gx

https://securityonline.info/freepbx-ucp-vulnerability-cve-2026-46376-hardcoded-credentials/

https://securityonline.info/n8n-automation-nodes-vulnerabilities-cve-2026-44791-rce/

https://github.com/n8n-io/n8n/security/advisories/GHSA-c8xv-5998-g76h

https://github.com/n8n-io/n8n/security/advisories/GHSA-57g9-58c2-xjg3

https://github.com/n8n-io/n8n/security/advisories/GHSA-wrwr-h859-xh2r