blog

FOCUS FRIDAY: TPRM Insights on Escalating n8n Risks and Emerging Infrastructure Vulnerabilities (Ni8mare, D-Link DSL Routers, aiohttp, SmarterMail, Coolify)

Published

Jan 9, 2026

Updated

Jan 9, 2026

Introduction

This week’s Focus Friday highlights a pattern that Third-Party Risk Management (TPRM) professionals cannot afford to ignore: the rapid concentration of critical vulnerabilities within the n8n ecosystem, alongside high-impact weaknesses across infrastructure, email, and application platforms. With back-to-back disclosures such as Ni8mare and n8n – Jan2026, n8n has moved from an isolated concern to a recurring risk signal, underscoring how quickly automation platforms can become high-value targets when widely deployed and deeply integrated into business workflows.

Beyond n8n, this edition also examines actively exploited and high-severity issues affecting legacy network devices, asynchronous web frameworks, email servers, and deployment orchestration platforms. Together, these incidents reinforce a core TPRM challenge: critical vulnerabilities increasingly span diverse technologies, and not all vendors are equally exposed. This Focus Friday approaches these incidents through a TPRM lens, emphasizing how security teams can identify which vendors truly matter, prioritize response efforts, and reduce risk without overwhelming vendor ecosystems with broad, unfocused outreach.

Filtered view of companies with Ni8mare FocusTag® on the Black Kite platform.

Ni8mare (CVE-2026-21858)

What is the Ni8mare vulnerability in n8n?

CVE-2026-21858, tagged as Ni8mare, is a critical security vulnerability in the n8n workflow automation platform that enables unauthenticated remote code execution. The vulnerability stems from Improper Input Validation in the webhook request body parser logic, allowing attackers to craft a request that causes arbitrary file reads and subsequent authentication bypass. Attackers can retrieve sensitive files (including database and config files), derive authentication secrets, forge valid session tokens, and ultimately achieve remote code execution by creating workflows that leverage command execution nodes. According to the available intelligence, public proof-of-concept exploits have been published, indicating real exploitability beyond theoretical risk. The vulnerability bears a CVSS score of 10.0 and an EPSS score of 0.02, reflecting both its critical severity and emerging exploitation potential. All n8n versions prior to 1.121.0 are vulnerable, and the fix is available in 1.121.0 or later. Despite active PoCs, CVE-2026-21858 has not been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog at this time, suggesting confirmed widespread exploitation may not yet meet the catalog’s criteria for inclusion.

Why should TPRM professionals care about this vulnerability?

TPRM professionals must view Ni8mare through a risk lens that incorporates both the critical severity of the flaw and the strategic role n8n plays in vendor environments. n8n is frequently deployed to automate cross-system workflows, often processing sensitive data and integrating with business-critical services. A vulnerability that allows unauthenticated attackers to take complete control of an n8n instance exposes not just the vulnerable application but potentially every system connected via its workflows. From a third-party risk standpoint, this can mean unauthorized data access, lateral movement into internal resources, misuse of automated actions, disruption of business processes, and compromise of credentials or secrets stored or referenced by n8n. Because the vulnerability is exploitable without authentication and has documented exploit code circulating publicly, vendors with unpatched instances pose a significant risk to customer environments. Even if Ni8mare is not (yet) in CISA’s KEV catalog, its exploitability and impact profile should elevate it within vendor risk questionnaires and remediation prioritization frameworks.

What questions should TPRM professionals ask vendors about this vulnerability?

Below are focused questions to help TPRM teams evaluate vendors’ exposure and risk management posture relative to Ni8mare:

Have you updated all instances of n8n to version 1.121.0 or later to mitigate the risk of CVE-2026-21858?
Can you confirm if you have implemented strict monitoring for any unusual activity, especially related to webhook endpoints or unexpected process execution from the n8n user, as recommended in the advisory?
Have you enforced authentication for all created Forms to limit the unauthenticated attack surface as a measure against the Unauthenticated Remote Code Execution vulnerability?
Can you confirm if you have isolated n8n instances from untrusted networks and placed them behind a firewall or VPN if direct internet exposure is not necessary for operation?

Remediation recommendations for vendors subject to this risk

To reduce operational and security risk from Ni8mare, vendors should:

Upgrade immediately to n8n version 1.121.0 or later, which contains the official fix for CVE-2026-21858.
Enforce strong authentication on all public-facing n8n endpoints, especially webhook and form handling nodes, to prevent unauthenticated access.
Isolate unpatched n8n instances from untrusted networks and restrict access to trusted networks only until patching is complete.
Implement stringent monitoring for anomalous requests and workflow creations, with alerts for known indicators of exploitation activity.
Review network exposure for all n8n installations and place them behind protective infrastructure (firewalls, VPNs, application gateways) where possible.

How TPRM professionals can leverage Black Kite for this vulnerability

Black Kite published the Ni8mare FocusTag® shortly after the vulnerability’s disclosure, providing TPRM teams with early visibility of vendor exposures to CVE-2026-21858. Black Kite’s platform identifies which vendors in a customer’s risk ecosystem host n8n instances that match the vulnerability footprint and surfaces associated assets (IP addresses, subdomains) at risk. This operational intelligence enables security and risk teams to focus remediation efforts on vendors genuinely impacted rather than broadly asking all third parties. If this FocusTag® is updated with new information (for example, KEV inclusion or evidence of widespread exploitation), Black Kite will revise the tag accordingly and notify customers, further refining prioritization. By combining the Ni8mare tag with continuous asset monitoring, TPRM professionals can correlate n8n exposures with vendor risk scores and automate follow-up workflows to drive more efficient risk reduction.

Black Kite’s Ni8mare FocusTag® details critical insights on the event for TPRM professionals.

n8n - Jan2026 (CVE-2026-21877)

What is the n8n Jan 2026 RCE Vulnerability?

CVE-2026-21877 is a critical Remote Code Execution (RCE) vulnerability in the n8n workflow automation platform that allows an authenticated user to achieve total compromise of an affected instance through an arbitrary file write mechanism. According to the official security advisory, under certain conditions an authenticated actor may write untrusted files on the server, which the n8n service can then execute, resulting in full instance compromise including unauthorized code execution. The flaw appears to be related to components such as the Git node and its handling of file operations, giving attackers a vector to plant and execute malicious code. This vulnerability carries a CVSS score of 9.9and an EPSS score of 0.02, indicating it is both highly severe and showing early exploitation potential. The issue affects all n8n versions prior to 1.121.3, with a patch available in n8n 1.121.3 and later. Public proof-of-concept exploit code has not been reported, and as of the latest verification, CVE-2026-21877 has not been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, suggesting there is no evidence of widespread exploitation in the wild at this time.

Why should TPRM professionals care about this vulnerability?

From a third-party risk management perspective, this vulnerability presents a notable risk because n8n is often deployed to automate critical business processes and integrate with a broad set of internal and external systems. An RCE vulnerability that requires only an authenticated user means that compromise of even low-privilege vendor accounts can lead to a full takeover of the n8n instance and any downstream systems that are integrated via automated workflows. These workflows often touch sensitive data, internal applications, and external services, so a compromise can cascade into data exposure, process manipulation, or unauthorized access to additional systems. Even though exploitation demands authentication, many vendors expose their automation nodes to internal teams or partners, and authentication controls may be weaker or inconsistent across vendors. This increases the likelihood that a compromised account, misconfiguration, or insufficient access control could lead to exploitation, making it a meaningful concern for TPRM professionals evaluating vendor security posture.

What questions should TPRM professionals ask vendors about this vulnerability?

To assess vendor exposure and risk management practices relative to CVE-2026-21877, TPRM teams should consider asking:

Can you confirm if you have upgraded all instances of n8n to version 1.121.3 or later to mitigate the risk of CVE-2026-21877?
Have you implemented the recommended action of strictly limiting user access to enforce the principle of least privilege for all n8n users, especially given that the attack requires an authenticated user?
If you were unable to patch immediately, did you disable the Git node within n8n as a workaround to reduce exposure to the vulnerability?
Can you confirm if you have taken measures to prevent an authenticated user from overwriting critical files and executing untrusted code on the server, specifically in relation to the Arbitrary File Write mechanism in n8n's version control capabilities?

Remediation recommendations for vendors subject to this risk

Vendors with n8n deployments should take the following steps to mitigate risk:

Upgrade all n8n instances immediately to version 1.121.3 or later to obtain the patch that resolves the arbitrary file write and RCE flaw.
Temporarily disable the Git node or equivalent components that could facilitate arbitrary file writes if patching cannot occur immediately, reducing the potential attack surface.
Enforce strict access controls and the principle of least privilege for all authenticated n8n users, ensuring that only trusted and necessary accounts have capabilities that could lead to exploitation.
Implement enhanced monitoring of workflow changes, file system operations, and API calls within n8n to detect unexpected behavior that could signal exploitation attempts.

How TPRM professionals can leverage Black Kite for this vulnerability

Black Kite published the n8n - Jan2026 FocusTag® promptly following the disclosure of CVE-2026-21877, providing TPRM teams with early visibility into which vendors in their third-party ecosystem may be hosting vulnerable n8n instances. By associating the FocusTag® with actual assets (such as IP addresses and subdomains linked to vulnerable n8n instances), Black Kite enables security and risk professionals to prioritize outreach and remediation efforts only to vendors who are genuinely at risk rather than issuing broad assessments to the entire vendor base. Black Kite’s continuous monitoring further ensures that if this tag is updated — for example, with emerging exploit evidence or integration into the CISA KEV catalog — TPRM professionals will receive relevant updates to adjust risk assessments and action plans accordingly.

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

D-Link DSL Routers (CVE-2026-0625)

What is the D-Link DSL Router RCE vulnerability?

CVE-2026-0625 is a critical Remote Code Execution (RCE) vulnerability affecting multiple legacy D-Link DSL router models. The issue is caused by command injection in the dnscfg.cgi DNS configuration endpoint due to improper input sanitization. An unauthenticated remote attacker can exploit this flaw via the router’s web interface to inject and execute arbitrary shell commands without valid credentials. The vulnerability has a CVSS score of 9.3 and an EPSS score of 1.35 %, reflecting both high impact and meaningful exploitation likelihood. Active exploitation in the wild has been observed since November 27, 2025, indicating that threat actors are already abusing this weakness. While specific campaigns or actors have not been publicly attributed, exploitation activity suggests use cases such as botnet enrollment and DNS manipulation. The affected router models were declared End-of-Life (EOL) in early 2020, meaning no vendor patches or official remediation are available. As of the latest verification, CVE-2026-0625 is not listed in CISA’s Known Exploited Vulnerabilities (KEV) Catalog, and no dedicated CISA advisory has been issued.

Why should TPRM professionals care about this vulnerability?

From a third-party risk management perspective, this vulnerability represents a persistent and unmitigable infrastructure risk. DSL routers sit at the core of network connectivity and DNS resolution, and compromise at this layer enables attackers to intercept traffic, redirect users to malicious destinations, manipulate network behavior, or establish a foothold for further intrusion. Because the affected D-Link devices are EOL and permanently unpatchable, vendors using them cannot remediate the risk through standard patching practices. This creates long-term exposure that can directly impact the confidentiality, integrity, and availability of vendor environments and, by extension, customer data and services. Vendors that continue operating these routers effectively maintain a known, actively exploited weakness in their network perimeter, which elevates their overall risk profile and increases the likelihood of downstream impact.

What questions should TPRM professionals ask vendors about the vulnerability?

To properly assess vendor exposure and response maturity, TPRM professionals should ask targeted questions such as:

Have you upgraded all instances of aiohttp to version 3.13.3 to mitigate the risk of CVE-2025-69228, CVE-2025-69227, CVE-2025-69229, CVE-2025-69230, CVE-2025-69224, CVE-2025-69225, and CVE-2025-69226?
Can you confirm if you have implemented robust input validation and rate limiting for applications using `Request.post()` method to prevent memory exhaustion attacks as per the advisory for CVE-2025-69228?
Have you configured log rotation and monitoring to prevent excessive log file growth from invalid cookie warnings and to ensure important security alerts are not masked, as recommended for CVE-2025-69230?
For the mitigation of CVE-2025-69226, have you reviewed configurations and implemented mechanisms to prevent brute-force path enumeration attempts if `web.static()` is used in your aiohttp setup?

Remediation recommendations for vendors subject to this risk

Vendors impacted by CVE-2026-0625 should take decisive action to reduce exposure:

Replace affected D-Link DSL routers immediately with supported hardware that receives regular security updates. Replacement is the only complete remediation.
Isolate or decommission vulnerable devices if immediate replacement is not possible, ensuring they are not internet-facing or connected to sensitive network segments.
Continuously monitor network traffic and DNS behavior associated with legacy devices to detect exploitation or misuse.
Regularly review DNS configurations to identify unauthorized changes that could enable traffic interception or redirection.

How TPRM professionals can leverage Black Kite for this vulnerability

Black Kite published the D-Link DSL Routers FocusTag® shortly after active exploitation of CVE-2026-0625 was identified. This tag enables TPRM teams to determine which vendors in their ecosystem are operating affected D-Link DSL routers and to associate the risk with specific exposed assets such as IP addresses and subdomains. By narrowing visibility to vendors with confirmed exposure, Black Kite allows organizations to prioritize outreach, validate hardware replacement plans, and track compensating controls instead of issuing broad, unfocused assessments. Continuous monitoring ensures that any changes in exploitation status or risk context are reflected in the FocusTag®, allowing TPRM professionals to maintain accurate and actionable risk assessments over time.

Black Kite’s D-Link DSL Routers FocusTag® details critical insights on the event for TPRM professionals.

aiohttp (CVE-2025-69228, CVE-2025-69230)

What are the recent aiohttp vulnerabilities?

In early January 2026, the aiohttp project disclosed and patched seven distinct vulnerabilities affecting the widely used asynchronous HTTP client/server framework for Python. These issues span multiple vulnerability classes, most notably Denial of Service (DoS), request smuggling, and information disclosure.

The most impactful issues are CVE-2025-69228, CVE-2025-69227, and CVE-2025-69229, all rated Medium severitywith CVSS scores of 6.6 and EPSS scores ranging from 0.02 to 0.04. These vulnerabilities allow attackers to exhaust server memory or CPU resources through crafted POST requests, infinite loops triggered under Python optimization flags, or abuse of chunked transfer encoding. Together, they enable reliable denial-of-service conditions against exposed aiohttp endpoints.

Additional vulnerabilities include request smuggling flaws (CVE-2025-69224 and CVE-2025-69225) caused by improper parsing of non-ASCII characters in headers, potentially allowing attackers to bypass upstream security controls. CVE-2025-69226 introduces an information disclosure and path traversal risk, enabling attackers to infer absolute path components when static file serving is enabled. CVE-2025-69230, while rated Low, can generate excessive warning-level logs via invalid cookie submissions, potentially leading to disk exhaustion or reduced visibility of other security events.

All vulnerabilities were publicly disclosed in January 2026 and affect aiohttp versions 3.13.2 and earlier. The issues are fully addressed in aiohttp 3.13.3. As of the latest verification, no public proof-of-concept exploits have been reported, no active exploitation has been observed, and none of the vulnerabilities are listed in CISA’s Known Exploited Vulnerabilities (KEV) Catalog. No standalone CISA advisory has been issued for these flaws.

Why should TPRM professionals care about these vulnerabilities?

From a third-party risk management perspective, these vulnerabilities are significant due to aiohttp’s role as a foundational component in many modern web services, APIs, and internal platforms. aiohttp is frequently embedded deep within vendor applications rather than deployed as a standalone service, which makes its presence less visible during traditional asset inventory processes. A denial-of-service condition in aiohttp can directly affect availability of customer-facing services, APIs, or backend integrations, potentially causing outages or degraded performance.

Request smuggling and information disclosure vulnerabilities further elevate risk by enabling attackers to bypass security controls, leak internal path structures, or interfere with request handling in ways that are difficult to detect. Because these flaws can be triggered remotely and may not require authentication, vendors that have not promptly updated embedded dependencies may unknowingly expose customers to service disruption or indirect security impact. For TPRM teams, this highlights the importance of understanding not just products vendors deploy, but also the open-source components those products rely on.

What questions should TPRM professionals ask vendors about these vulnerabilities?

To assess vendor exposure and remediation readiness, TPRM professionals should consider asking:

Have you identified whether aiohttp is used directly or indirectly within your applications, services, or APIs, and if so, which versions are deployed?
Have all affected aiohttp components been upgraded to version 3.13.3 or later across production and non-production environments?
What controls are in place to mitigate denial-of-service risks on aiohttp-based endpoints, such as rate limiting, request size limits, or resource monitoring?
If web.static() or similar static file serving features are used, how are configurations reviewed to prevent information disclosure or path enumeration risks?

Remediation recommendations for vendors subject to this risk

Vendors should take the following actions to mitigate the identified aiohttp vulnerabilities:

Upgrade all aiohttp deployments to version 3.13.3 or later, which resolves all seven disclosed vulnerabilities.
Review application code that uses Request.post(), ensuring proper input validation, request size limits, and rate limiting are enforced to reduce DoS risk.
Evaluate the use of Python optimization flags and confirm that production environments are not exposed to logic flaws present in unpatched versions.
Implement log management and rotation controls to prevent excessive logging from masking security events or consuming disk resources.
Audit static file serving configurations, particularly where web.static() is enabled, to reduce the risk of information leakage.

How TPRM professionals can leverage Black Kite for this vulnerability

Black Kite published the aiohttp FocusTag® following the January 2026 disclosure, enabling TPRM teams to identify vendors potentially exposed to these vulnerabilities through direct or embedded aiohttp usage. By correlating vulnerability intelligence with observable assets such as IP addresses and application endpoints, Black Kite helps organizations narrow their focus to vendors most likely affected rather than issuing broad, dependency-agnostic questionnaires. This asset-level visibility allows TPRM professionals to prioritize outreach, validate patching efforts, and track remediation progress with higher confidence. Continuous monitoring ensures that any future updates — such as changes in exploitation status or severity — are reflected in the FocusTag™, supporting ongoing risk assessment and decision-making.

Black Kite’s aiohttp FocusTag® details critical insights on the event for TPRM professionals.

SmarterMail (CVE-2025-52691)

What is the SmarterMail unauthenticated RCE vulnerability?

CVE-2025-52691 is a critical unauthenticated Remote Code Execution (RCE) vulnerability in SmarterMail caused by unrestricted file upload of dangerous file types. Due to improper validation and handling of uploaded files, an attacker can upload arbitrary files to attacker-controlled locations on the mail server without authentication. Once a malicious file is uploaded, it can be executed by the server, resulting in full system compromise.

This vulnerability has a CVSS score of 10.0, reflecting maximum severity, and an EPSS score of 0.23%, indicating a non-trivial likelihood of exploitation at scale. The issue was publicly disclosed in late December 2025, making it a recent and highly relevant threat. Public proof-of-concept exploits are available, significantly lowering the barrier to exploitation. While exploitation activity has been reported by researchers, no specific threat actor groups or coordinated campaigns have been publicly attributed at this time. As of the latest verification, CVE-2025-52691 has not been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, and no CISA advisory has been published specifically for this issue.

Why should TPRM professionals care about this vulnerability?

From a third-party risk management perspective, this vulnerability is particularly concerning because SmarterMail is an email server platform, which typically processes sensitive communications, credentials, attachments, and personally identifiable information. An unauthenticated RCE in an email server enables attackers to read, modify, or exfiltrate email content, impersonate users, distribute fraudulent emails that appear to originate from a trusted vendor domain, and potentially pivot deeper into internal networks.

Because exploitation does not require authentication, any internet-exposed SmarterMail instance running vulnerable versions becomes an immediate and high-value target. A compromised email server can undermine trust, enable business email compromise scenarios, disrupt operations, and expose regulated data. For TPRM professionals, vendors operating vulnerable SmarterMail versions represent a direct downstream risk, especially if email services are used for customer communications, support, billing, or identity verification workflows.

What questions should TPRM professionals ask vendors about the vulnerability?

To assess vendor exposure and response readiness, TPRM professionals should ask targeted questions such as:

Have you updated all instances of SmarterMail to version Build 9413 or later to mitigate the risk of CVE-2025-52691?
Can you confirm that you have conducted a thorough scan of your network to identify all running instances of SmarterMail and verified their version numbers to determine which systems are vulnerable to CVE-2025-52691?
Have you reviewed your network exposure and ensured that SmarterMail instances are not unnecessarily exposed to the internet, especially considering the attack requires no authentication?
Are you actively monitoring server logs for any unusual file uploads, unauthorized access attempts, or suspicious activity that could indicate prior compromise attempts related to CVE-2025-52691?

Remediation recommendations for vendors subject to this risk

Vendors affected by CVE-2025-52691 should take immediate and decisive action:

Upgrade SmarterMail to Build 9413 or later to fully remediate the unrestricted file upload vulnerability.
Conduct a forensic review of SmarterMail servers that were exposed prior to patching to identify malicious files or persistence mechanisms.
Restrict internet exposure of mail server management and upload interfaces through network controls and segmentation.
Increase monitoring and logging around file uploads, execution paths, and mail flow to detect post-exploitation activity.

How TPRM professionals can leverage Black Kite for this vulnerability

Black Kite published the SmarterMail FocusTag® shortly after the disclosure of CVE-2025-52691, enabling TPRM teams to identify vendors operating vulnerable SmarterMail instances within their third-party ecosystem. By mapping the vulnerability to observable assets such as IP addresses and mail-related subdomains, Black Kite allows organizations to quickly determine which vendors pose a direct exposure risk. This asset-level intelligence enables focused vendor outreach, validation of patching efforts, and prioritization of remediation activities. Continuous monitoring ensures that changes in exposure or remediation status are reflected promptly, helping TPRM professionals maintain accurate, up-to-date risk assessments for vendors relying on SmarterMail.

Black Kite’s SmarterMail FocusTag® details critical insights on the event for TPRM professionals.

Coolify (CVE-2025-64419, CVE-2025-64424, and CVE-2025-64420)

What are the critical Coolify root access vulnerabilities?

In early January 2026, three critical vulnerabilities were disclosed in the open-source Coolify platform that collectively allow authenticated attackers to achieve root-level compromise of affected systems. These issues include two command injection vulnerabilities and one information disclosure vulnerability involving insufficiently protected credentials.

CVE-2025-64419 is a critical command injection vulnerability with a CVSS score of 9.7 and an EPSS score of 0.05%. The flaw resides in the Docker Compose build pack parameters. An attacker can exploit it by persuading a user to deploy an application from a malicious repository. Due to improper sanitization, injected shell commands are executed during the deployment process with elevated privileges.

CVE-2025-64424, also a command injection vulnerability, carries a CVSS score of 9.4 and a notably higher EPSS score of 0.5%. This issue affects Git source input fields in Coolify resource configurations. Low-privileged users with “member” access can inject arbitrary commands directly into these fields, which are executed without proper validation, resulting in privilege escalation and arbitrary command execution.

CVE-2025-64420 is an information disclosure vulnerability with a CVSS score of 10.0 and an EPSS score of 0.04%. It allows low-privileged users to access Coolify’s private SSH key. Possession of this key enables attackers to bypass normal authentication controls and gain direct SSH access to the underlying server, providing persistent and elevated access.

All three vulnerabilities were publicly disclosed in early January 2026. Public proof-of-concept exploits have been reported for each, significantly lowering the barrier to exploitation. While there is no confirmed evidence of large-scale exploitation campaigns or named threat actors at this time, the presence of PoCs increases the likelihood of opportunistic abuse. None of these vulnerabilities are currently listed in CISA’s Known Exploited Vulnerabilities (KEV) Catalog, and no CISA advisory has been published.

Why should TPRM professionals care about these vulnerabilities?

From a TPRM perspective, these vulnerabilities represent a high-impact risk due to Coolify’s role as an infrastructure and deployment management platform. Coolify is often used to orchestrate application deployments, manage containers, and interact directly with host systems and repositories. A successful exploit does not merely affect an application layer; it enables root-level access to the underlying server, which can lead to full infrastructure compromise.

The fact that two of the vulnerabilities can be exploited by low-privileged authenticated users makes insider threat scenarios and account compromise especially concerning. A single compromised user account can be leveraged to gain complete control of the platform and host, deploy malicious workloads, steal secrets, or tamper with deployed applications. For organizations relying on vendors that use Coolify to host or manage customer-facing services, this creates a direct downstream risk affecting availability, integrity, and confidentiality.

What questions should TPRM professionals ask vendors about these vulnerabilities?

To understand vendor exposure and mitigation readiness, TPRM professionals should ask questions such as:

Have you upgraded all instances of Coolify to version v4.0.0-beta.445 or later to mitigate the risk of CVE-2025-64419, and to version v4.0.0-beta.434 or later to mitigate the risk of CVE-2025-64424 and CVE-2025-64420?
Can you confirm if you have implemented measures to sanitize the "docker compose build pack" parameters and "git source input fields" to prevent command injection flaws like CVE-2025-64419 and CVE-2025-64424?
Have you taken steps to secure the "private SSH key" to prevent unauthorized access and information disclosure as highlighted in CVE-2025-64420?
Are you actively monitoring Coolify instance logs and host system logs for any signs of unusual or unauthorized activity, particularly attempts at privilege escalation, unauthorized SSH access, or command execution from unexpected sources?

Remediation recommendations for vendors subject to this risk

Vendors operating Coolify should take immediate steps to reduce exposure:

Upgrade all Coolify instances to at least v4.0.0-beta.445 to remediate CVE-2025-64419 and v4.0.0-beta.434 or later to remediate CVE-2025-64424 and CVE-2025-64420.
Review and restrict user privileges, enforcing least-privilege access and carefully evaluating permissions granted to non-administrative users.
Avoid deploying applications from untrusted repositories and implement validation or approval processes for repository sources used in deployments.

Monitor system and application logs for signs of command execution abuse, unexpected SSH access, or other indicators of compromise.

How TPRM professionals can leverage Black Kite for this vulnerability

Black Kite published the Coolify [Suspected] FocusTag® following the January 2026 disclosure to help TPRM teams identify vendors potentially exposed to these critical root-level vulnerabilities. Because Coolify is often self-hosted and embedded within vendor infrastructure, Black Kite’s ability to associate risk with observable assets such as IP addresses and subdomains is a key differentiator. This enables TPRM professionals to move beyond questionnaire-based assessments and focus outreach on vendors with confirmed exposure. As new information becomes available or remediation status changes, continuous monitoring allows the FocusTag® to remain current, supporting timely risk prioritization and follow-up actions.

Black Kite’s Coolify FocusTag® details critical insights on the event for TPRM professionals.

Strengthening TPRM Outcomes with Black Kite’s FocusTags®

As vulnerability disclosures accelerate and exploitation timelines continue to shrink, TPRM teams need more than awareness—they need precision. Black Kite’s FocusTags® are designed to bridge the gap between raw vulnerability intelligence and operational risk management, particularly in scenarios like this week’s where risks range from unauthenticated RCE in automation platforms to unpatchable, actively exploited network devices.

Rather than treating every high-profile vulnerability as universally applicable, FocusTags® enable organizations to:

Pinpoint True Vendor Exposure: Identify which vendors actually operate affected technologies such as n8n, SmarterMail, or Coolify, and correlate risk to observable assets like IP addresses and subdomains.
Prioritize Action Where Impact Is Highest: Focus remediation and follow-up on vendors whose exposure aligns with critical business dependencies and severe exploitation potential.
Reduce Vendor Fatigue: Replace broad, generic questionnaires with targeted outreach informed by concrete exposure data and technical context.
Maintain Continuous Risk Awareness: Track changes in exposure and remediation status over time as vulnerabilities evolve, patches are released, or exploitation patterns shift.

In an environment where platforms like n8n are experiencing repeated critical disclosures in short succession, and where legacy infrastructure vulnerabilities remain permanently unpatchable, Black Kite’s FocusTags® provide TPRM professionals with actionable clarity. By transforming complex vulnerability data into vendor-specific intelligence, FocusTags® help organizations respond faster, communicate more effectively, and manage third-party risk with greater confidence and efficiency.

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:

Ni8mare : CVE-2026-21858, Improper Input Validation, Arbitrary File Read, Authentication Bypass, and Unauthenticated Remote Code Execution Vulnerabilities Leading to Full Administrative Takeover in n8n Workflow Automation Platform.
n8n – Jan2026 : CVE-2026-21877, Authenticated Arbitrary File Write Vulnerability Leading to Remote Code Execution and Total Compromise of n8n Instances.
D-Link DSL Routers : CVE-2026-0625, Unauthenticated Command Injection Vulnerability Leading to Actively Exploited Remote Code Execution in End-of-Life D-Link DSL Routers.
aiohttp : CVE-2025-69228, CVE-2025-69227, CVE-2025-69229, CVE-2025-69230, CVE-2025-69224, CVE-2025-69225, CVE-2025-69226, Multiple Denial of Service, Request Smuggling, Information Disclosure, and Path Traversal Vulnerabilities Affecting aiohttp Asynchronous HTTP Framework.
SmarterMail : CVE-2025-52691, Unauthenticated Arbitrary File Upload Vulnerability Leading to Remote Code Execution and Complete Email Server Compromise in SmarterMail.
Coolify : CVE-2025-64419, CVE-2025-64424, CVE-2025-64420, Multiple Command Injection and Credential Exposure Vulnerabilities Allowing Root-Level Code Execution and Persistent Access in the Coolify Platform.
SonicWall SMA1000 : CVE-2025-40602, CVE-2025-23006, Privilege Escalation and Pre-authentication Deserialization of Untrusted Data Vulnerabilities Leading to Unauthenticated Remote Code Execution in SonicWall SMA1000.
FortiGate SSL-VPN – Dec2025 : CVE-2020-12812, Improper Authentication Vulnerability Allowing Two-Factor Authentication (2FA) Bypass via Case-Sensitivity Mismatch in LDAP-Backed FortiGate SSL-VPN Deployments.
n8n : CVE-2025-68613, Arbitrary Code Execution via Improper Isolation of User-Supplied Expressions in n8n Workflow Automation Platform.
Exim Mail – Dec2025 : CVE-2025-26794, CVE-2025-67896, SQL Injection and Heap Buffer Overflow Vulnerabilities Leading to Memory Corruption and Potential Remote Code Execution in Exim Mail Transfer Agent.
Zimbra – Dec2025 : CVE-2025-68645, CVE-2025-67809, Local File Inclusion and Hardcoded Credentials Vulnerabilities Leading to Sensitive Data Exposure and Unauthorized Access in Zimbra Collaboration Suite.
MongoDB – Dec2025 : CVE-2025-14847, Out-of-bounds Read and Information Disclosure Vulnerability via zlib Compression Handling in MongoDB Server.
M-Files Server : CVE-2025-13008, CVE-2025-14267, Session Token Disclosure and Improper Removal of Sensitive Information Vulnerabilities Leading to Identity Impersonation and Information Disclosure in M-Files Server.
Elastic Kibana – Dec2025 : CVE-2025-68385, Cross-Site Scripting Vulnerability via Vega Visualizations Leading to Session Hijacking and Unauthorized Actions in Elastic Kibana.
FreeBSD : CVE-2025-14558, rtsold DNSSL Command Injection Vulnerability Leading to Local Network Remote Code Execution in FreeBSD.
ScreenConnect – Dec2025 : CVE-2025-14265, Exposure of Sensitive Information and Download of Code Without Integrity Check Vulnerability in ConnectWise ScreenConnect.
CentreStack & Triofox – Dec2025 : CVE-2025-14611, Insecure Cryptography and Arbitrary File Read Vulnerability Leading to Remote Code Execution in Gladinet CentreStack and Triofox.
Jenkins – Dec2025 : CVE-2025-67635, CVE-2025-67637, CVE-2025-67636, Denial of Service, Information Disclosure, and Missing Authorization Vulnerabilities in Jenkins Core.
FreePBX – Dec2025 : CVE-2025-66039, CVE-2025-61675, CVE-2025-61678, Authentication Bypass, SQL Injection, and Arbitrary File Upload Vulnerabilities Leading to Remote Code Execution in FreePBX.
Gogs – Dec2025 : CVE-2025-8110, Path Traversal Vulnerability via Symlink Bypass Leading to Remote Code Execution in Gogs.
Fortinet [Suspected] – Dec2025 : CVE-2025-59718, CVE-2025-59719, Administrative Authentication Bypass via SAML Forgery in Fortinet FortiCloud SSO.
Exchange Server – Dec2025 : CVE-2025-64666, CVE-2025-64667, Elevation of Privilege and Email Spoofing Vulnerabilities in Microsoft Exchange Server.
Cacti – Dec2025 : CVE-2025-66399, Remote Code Execution Vulnerability via SNMP Community String Injection in Cacti.
React Server Components (RSC) [Suspected] : CVE-2025-55182, Remote Code Execution Vulnerability in React Server Components.
Mixpanel Clients : Assessing the Potential Impact of Client Data Exposure in Mixpanel.