blog

FOCUS FRIDAY: TPRM Insights on the March Supply Chain Surge, F5 BIG-IP, TrueChaos, Cisco IMC, Perl, Grafana, n8n, Squid Proxy, and Harbor

Published

Apr 3, 2026

Introduction

Welcome to another edition of Focus Friday. As threat actors continuously refine their tactics, the window between vulnerability disclosure and active exploitation is shrinking rapidly, placing immense pressure on digital supply chains. A single unpatched gateway or an overlooked default credential within your vendor ecosystem can instantly become a critical entry point for adversaries. This week, we are analyzing a diverse and highly critical set of incidents that demand immediate attention from Third-Party Risk Management (TPRM) professionals.

Not only will we examine the active, zero-day "TrueChaos" exploitation targeting TrueConf servers, critical remote code execution (RCE) flaws in F5 BIG-IP, Grafana, and n8n, a severe authentication bypass in Cisco IMC, memory bleed issues in Squid Proxy, and a catastrophic default credential risk in Harbor registries, but we are also unpacking the devastating wave of supply chain compromises that defined March. We will dive deep into the sophisticated Axios NPM bait-and-switch, TeamPCP’s cross-platform hijacking of AI gateways and developer ecosystems (LiteLLM, Telnyx, Rust), and the Trivy-linked development environment breach. In this blog, we break down the technical realities of these combined threats and provide the actionable intelligence you need to secure your third-party network against them.

Filtered view of companies with F5 BIG-IP - Mar2026 FocusTag® on the Black Kite platform.

The March Surge: Unpacking the Devastating Wave of Supply Chain and AI Compromises

While critical vulnerabilities in standalone products demand immediate attention, March 2026 was truly defined by a highly sophisticated, multi-vector assault on the software supply chain. Threat actors bypassed traditional perimeters by poisoning the foundational libraries, AI proxy gateways, and development tools that your third-party vendors rely upon daily. For TPRM professionals, these incidents represent the ultimate cascading risk: a breach at the dependency level instantly compromises every vendor downstream.

1. The Axios NPM Bait-and-Switch & RAT Deployment: In a meticulously timed and highly deceptive attack, threat actors compromised the widely used Axios HTTP client (targeting versions 1.14.1 and 0.30.4). The attackers utilized a complex dependency confusion tactic.

The Deception: They created a fraudulent dependency named plain-crypto-js to mimic the legitimate crypto-js library. To bypass automated zero-day security scanners, they first published version 4.2.0 as an exact, clean copy of the real library.
The Weaponization: Immediately after, utilizing a ProtonMail account, they published version 4.2.1. This version introduced a malicious setup.js post-install script designed to silently download a Remote Access Trojan (RAT).
The Execution: This poisoned package was uploaded just minutes before the compromised Axios versions, forcing developer environments to pull the RAT as an automated sub-dependency.
Detection & IOCs: Traditional scanning via tools like Shodan is highly ineffective for this specific attack structure. TPRM teams must advise vendors to rely on Netflow and network-level indicators. Key IOCs include:
- Outbound Traffic: Destination IP 142.11.206.73 via TCP port 8000 to the domain sfrclak[.]com.
- HTTP POST Payloads: Traffic directed to packages[.]npm[.]org/product0 (macOS), product1 (Windows), or product2 (Linux).
- Suspicious User-Agent: Look for the specific string mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0).

2. TeamPCP’s Cross-Platform Assault (LiteLLM, Telnyx, and Rust): The threat actor known as TeamPCP executed a highly disruptive, multi-ecosystem campaign that targeted AI infrastructure, communications APIs, and developer environments.

LiteLLM AI Traffic Hijacking: TeamPCP targeted high-risk versions (1.82.7 and 1.82.8) of the LiteLLM API Gateway. By identifying exposed /openapi.json endpoints, attackers mapped out the /config routes. If the proxy was running without a strictly enforced LITELLM_MASTER_KEY, attackers exploited unauthenticated access to the /config/pass_through_endpoint. This allowed them to inject a Man-in-the-Middle (MitM) backdoor, silently rerouting corporate AI traffic to exfiltrate high-value provider API keys (OpenAI, Vertex AI) and intercept sensitive prompts containing PII or intellectual property.
Telnyx Python Compromise: The actor poisoned the Telnyx ecosystem with malicious packages (telnyx==4.87.1 and telnyx==4.87.2, containing the Trojan.Python.TPCPSTEAL.A/B malware). The payload delivery was disguised within .wavfiles (hangup[.]wav, ringtone[.]wav), which decoded into a Windows payload dropped at %APPDATA%\Microsoft\Windows\StartMenu\Programs\Startup\msbuild.exe. Data was subsequently exfiltrated to hxxps[://]83[.]142[.]209[.]203:8080.

3. The Trivy-Linked Dev Environment Breach: Proving that even the security tools designed to protect the supply chain are prime targets, a breach within a development environment linked to the Trivy vulnerability scanner led directly to the theft of Cisco source code. This incident highlights an extreme vendor risk: the very CI/CD and scanning tools vendors use to secure their infrastructure can become the conduits for massive intellectual property theft if their own environments are not heavily fortified.

If your vendors utilize any of these compromised libraries, gateways, or scanning environments, your shared data, corporate AI API keys, and intellectual property are actively at risk. Identifying these deeply embedded supply chain threats requires continuous, granular visibility that traditional, static vendor assessments simply cannot provide.

You can find detailed technical information and IOC details about this topic from the links shared in the references section.

F5 BIG-IP - Mar2026 (CVE-2025-53521)

What is the F5 BIG-IP APM RCE Vulnerability?

CVE-2025-53521 is a critical, unauthenticated Remote Code Execution (RCE) vulnerability residing in the apmd process of the F5 BIG-IP Access Policy Manager (APM). The flaw carries a CVSS v4.0 score of 9.3 (CVSS v3.1: 9.8) and an EPSS score of 19.92%. Initially disclosed and patched in October 2025 as a Denial-of-Service (DoS) issue, new threat intelligence obtained in March 2026 revealed that threat actors could leverage specific malicious traffic to achieve unauthenticated code execution directly on the data plane. Consequently, F5 upgraded the severity to critical.

The vendor has explicitly confirmed that this vulnerability is being actively exploited in the wild against vulnerable BIG-IP versions configured with an active access policy on a virtual server. While public Proof-of-Concept (PoC) exploits have not yet been reported, the confirmed exploitation activity prompted the Cybersecurity and Infrastructure Security Agency (CISA) to add CVE-2025-53521 to its Known Exploited Vulnerabilities (KEV) catalog on March 27, 2026, mandating immediate patching protocols for affected agencies.

Why should TPRM Professionals care about the F5 BIG-IP vulnerability?

F5 BIG-IP APM acts as a secure identity proxy and access gateway, explicitly designed to control user authentication and authorization to an organization’s most critical applications and APIs. Because this vulnerability exists on the data plane and requires no authentication to exploit, it presents an extreme risk to any vendor's network perimeter.

For Third-Party Risk Management professionals, a compromised BIG-IP appliance in a vendor's environment is a worst-case scenario. If a threat actor exploits this RCE, they can bypass all established access controls, essentially turning the secure gateway into a malicious beachhead. From there, attackers can intercept sensitive proprietary data flowing through the proxy, harvest authentication tokens, or pivot directly into the vendor's internal network to deploy ransomware or establish persistent backdoors. Since APM handles core identity enforcement, an attacker controlling it holds the keys to downstream applications, making this a highly critical single point of failure within your supply chain operations.

What questions should TPRM professionals ask vendors about the F5 BIG-IP vulnerability?

To properly evaluate your third parties' exposure to this critical flaw, consider asking the following technical questions:

Have you upgraded all instances of BIG-IP APM to the fixed versions 17.5.1.3, 17.1.3, 16.1.6.1, or 15.1.10.8 to mitigate the risk of CVE-2025-53521?
Can you confirm that you have conducted a meticulous review of your systems against the Indicators of Compromise (IoCs) detailed in F5's advisory (K000160486) to detect any signs of active exploitation of CVE-2025-53521?
If a security compromise was suspected based on the IoC hunt, did you rebuild the system configuration entirely from scratch as recommended by F5, instead of relying on UCS backups created during or after the potential compromise window?
Can you confirm that you have no active APM configurations on BIG-IP Next, BIG-IQ, F5OS, NGINX, and BIG-IP LTM, as these are not vulnerable to CVE-2025-53521?

Remediation Recommendations for Vendors subject to this risk

Vendors operating vulnerable F5 BIG-IP APM systems must take the following immediate actions to secure their environments:

Apply Patches Immediately: Upgrade to the fixed versions provided by F5 (17.5.1.3, 17.1.3, 16.1.6.1, or 15.1.10.8) without delay. Be aware that F5 has stated there are no mitigations or workarounds for this vulnerability; applying the official software fix is the only valid remediation.
Hunt for Indicators of Compromise (IoCs): Meticulously review systems against the IoCs detailed in F5 advisory K000160486. This deep forensic review must be conducted for systems currently running vulnerable versions, as well as those recently upgraded from a vulnerable state to a patched state.
Complete System Rebuild on Suspicion: If a security compromise is suspected based on the IoC hunt, rebuild the system configuration entirely from scratch. Do not rely on UCS backups created during or after the potential compromise window, as these files may contain persistent malware.

Black Kite's F5 BIG-IP - Mar2026 FocusTag® details critical insights on the event for TPRM professionals.

TrueChaos (CVE-2026-3502)

What is the TrueConf TrueChaos Vulnerability?

CVE-2026-3502 is a High-severity vulnerability affecting the TrueConf client application, rooted in a complete failure of the protection mechanism and insufficient firmware update validation. The flaw carries a CVSS score of 7.8 and an EPSS score of 0.01%.

Initially discovered and publicly detailed by security researchers in late March 2026, the vulnerability exists because the TrueConf client fails to verify the digital signature or cryptographic hash of update packages downloaded from its server. If an attacker compromises the on-premises TrueConf server, they can replace the legitimate trueconf_client.exe installer with a weaponized version. When the client automatically checks for updates, it blindly executes this malicious package.

This vulnerability was exploited in the wild as a zero-day prior to public disclosure. Threat actors leveraged it in a campaign dubbed "Operation TrueChaos," specifically targeting government entities in Southeast Asia. The attack chain utilizes DLL side-loading to drop a malicious library alongside a benign executable, ultimately deploying the Havoc C2 implant and bypassing User Account Control (UAC) for privilege escalation. A public Proof-of-Concept (PoC) exploit is available. As of March 31, 2026, CVE-2026-3502 was added to CISA's Known Exploited Vulnerabilities (KEV) Catalog on April 2, 2026. It is tracked in the European Union's Vulnerability Database under EUVD-2026-17162.

Why should TPRM Professionals care about the TrueConf vulnerability?

TrueConf is an enterprise video conferencing and collaboration platform designed to connect distributed teams, meaning it is deeply embedded in a vendor's daily communication infrastructure. For Third-Party Risk Management professionals, a vulnerability in this type of software represents a critical supply chain risk because it weaponizes the vendor's own trusted update mechanism.

If a vendor's on-premises TrueConf server is compromised, that centralized server essentially becomes a malware distribution hub for every connected client machine. The "TrueChaos" infection chain demonstrates that attackers can use this flaw to deploy advanced command-and-control (C2) frameworks like Havoc across a vendor's entire workforce. This grants threat actors hands-on-keyboard access, allowing them to monitor sensitive meetings, exfiltrate proprietary data, or establish persistent backdoors into the vendor's internal network. Given the targeted nature of these attacks against high-value entities, a compromised vendor could easily serve as a stepping stone for adversaries aiming to breach your own organization.

What questions should TPRM professionals ask vendors about the TrueConf vulnerability?

To accurately evaluate your third-party ecosystem's exposure to this zero-day exploit, consider asking vendors the following technical questions:

Can you confirm if you have updated all instances of TrueConf Client to version 8.5.3 or later to mitigate the risk of CVE-2026-3502?
Have you implemented measures to monitor network communication for connections to known Havoc C2 infrastructure, specifically IP addresses 43.134.90[.]60, 43.134.52[.]221, and 47.237.15[.]197?
Have you conducted a server integrity audit to verify that the trueconf_client.exe stored in the ClientInstFiles directory is digitally signed by TrueConf and matches known good hashes?
Have you restricted server access and limited administrative access to the TrueConf server host to a minimum number of highly trusted personnel, and are you monitoring for unauthorized file modifications in the installation directories?

Remediation Recommendations for Vendors subject to this risk

Vendors utilizing on-premises TrueConf environments must implement the following technical actions to halt the infection chain and secure their systems:

Immediate Client Upgrade: Update all Windows endpoints to TrueConf version 8.5.3 or newer. This release introduces the required cryptographic validation checks to confirm update packages are authentic.
Server Integrity Audit: Inspect the on-premises server directory at C:\Program Files\TrueConf Server\ClientInstFiles\. Confirm that the executable stored there is the legitimate, properly signed TrueConf installer.
Hunting for Indicators (IoCs): Scan client machines for the presence of the side-loading files poweriso.exe and 7z-x64.dll to detect existing infections.
Monitor Network Communication: Audit network and firewall logs for any outbound connections to the Havoc C2 IP addresses identified in the threat intelligence reports.
Restrict Server Access: Harden the on-premises TrueConf server by limiting administrative privileges to a strictly controlled group of personnel and monitoring the installation directories for unauthorized file modifications.

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

Cisco IMC (CVE-2026-20093)

What is the Cisco IMC Authentication Bypass Vulnerability?

CVE-2026-20093 is a Critical-severity vulnerability (CVSS: 9.8, EPSS: 0.02%) impacting the Cisco Integrated Management Controller (IMC). The flaw, rooted in incorrect handling of password change requests (CWE-20), allows an unauthenticated, remote attacker to bypass authentication completely. By sending a specifically crafted HTTP request to the affected management interface, an attacker can alter any user's password and subsequently gain unauthorized access to the system with the privileges of that user, including full Admin rights.

This vulnerability affects a massive swath of Cisco infrastructure, including 5000 Series ENCS, Catalyst 8300 Series Edge, UCS C-Series and E-Series servers, and numerous specialized appliances based on preconfigured UCS C-Series hardware (such as APIC Servers, Catalyst Center, Nexus Dashboard, and Secure Firewall Management Center). While currently, there are no public Proof-of-Concept (PoC) exploits available and no confirmed reports of active exploitation in the wild, the severity of the flaw is immense. As of April 2026, CVE-2026-20093 has not yet been listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog. It is tracked in the European Union's Vulnerability Database under EUVD-2026-17947.

Why should TPRM Professionals care about the Cisco IMC vulnerability?

The Cisco Integrated Management Controller (IMC) is the foundational baseboard management controller (BMC) providing out-of-band management, monitoring, and deployment capabilities for Cisco UCS servers and specialized appliances. For Third-Party Risk Management professionals, a critical authentication bypass in a vendor's out-of-band management interface is equivalent to leaving the master key to the data center completely exposed.

Because the IMC operates below the primary operating system, compromising it grants an attacker ultimate control over the physical server and everything hosted on it. If a threat actor exploits CVE-2026-20093 to gain Admin access on a vendor's Cisco appliance, they can silently reboot servers, alter low-level firmware, intercept network traffic (in the case of compromised Catalyst or Secure Firewall appliances), and completely bypass any OS-level security controls or logging mechanisms. A breach at this hardware management layer within a vendor's environment could lead to deep, persistent compromise, putting any shared data or dependent network services at extreme risk.

What questions should TPRM professionals ask vendors about the Cisco IMC vulnerability?

To effectively evaluate your third-party ecosystem's exposure to this critical baseboard management flaw, consider asking vendors the following technical questions:

Have you upgraded the affected versions of Cisco IMC to the fixed releases as recommended in the advisory to mitigate the risk of CVE-2026-20093?
Have you applied the relevant Hotfixes, ISO patches, or used the Host Upgrade Utility (HUU) for specialized appliances like Secure Firewall Management Center to address the authentication bypass vulnerability?
Can you confirm if you have restricted access to IMC management interfaces to trusted internal networks only, as there are no workarounds for this vulnerability?
For the Catalyst 8300 Series Edge, have you prepared to upgrade to NFVIS 4.18.3, which is slated for release in April 2026, to mitigate the risk of CVE-2026-20093?

Remediation Recommendations for Vendors subject to this risk

Cisco has stated that there are NO workarounds available for this vulnerability. Vendors must take immediate architectural and patching actions to secure their environments:

Restrict Management Access: Ensure that all IMC interfaces are strictly isolated from production networks and the public internet. Access should be permitted only from dedicated, highly secured management jump hosts or VPNs.
Migrate to Fixed Releases: Apply the necessary firmware updates immediately. For example: upgrade 5000 Series ENCS to NFVIS 4.15.5, UCS C-Series M5 to 4.3(2.260007), and UCS C-Series M6 to 4.3(6.260017) or 6.0(1.250174).
Apply Appliance-Specific Patches: For specialized appliances (like the Secure Firewall Management Center or Catalyst Center), apply the designated Hotfixes, ISO patches, or use the Host Upgrade Utility (HUU) as outlined in Cisco's advisory.

Black Kite's Cisco IMC FocusTag® details critical insights on the event for TPRM professionals.

Perl (CVE-2026-4176, CVE-2026-3381, CVE-2026-27171)

What are the Perl Compress::Raw::Zlib Vulnerabilities?

CVE-2026-4176 is a critical-severity supply chain vulnerability (CWE-1395) impacting multiple versions of the Perl programming language. Carrying a CVSS score of 9.8 and an EPSS score of 0.02%, this flaw stems from Perl shipping with a compromised version of the Compress::Raw::Zlib module, which contains a vulnerable internal copy of the zlib library. This primary supply chain flaw directly exposes affected systems to two additional vulnerabilities: CVE-2026-3381, a critical Remote Code Execution (RCE) flaw (CVSS 9.8, EPSS 0.03%), and CVE-2026-27171, a medium-severity Denial of Service (DoS) vulnerability triggered via uncontrolled right shifts (CVSS 5.5, EPSS 0.01%).

Discovered and documented in early April 2026, these flaws impact a wide range of Perl branches, spanning from version 5.9.4 through 5.43.9. Currently, there are no public Proof-of-Concept (PoC) exploits available, nor are there any confirmed reports of active exploitation or specific threat actor campaigns leveraging these flaws in the wild. Consequently, none of these vulnerabilities have been added to CISA's Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not issued a dedicated advisory for them. They are, however, tracked within the European Union's Vulnerability Database under identifiers EUVD-2026-17044, EUVD-2026-9520, and EUVD-2026-8063.

Why should TPRM Professionals care about the Perl vulnerabilities?

Perl remains a foundational scripting language deeply embedded in legacy enterprise architectures, backend web services, log processing pipelines, and system administration automation. For Third-Party Risk Management professionals, a critical supply chain flaw within a core data compression module like Compress::Raw::Zlib poses a substantial, hidden risk across a vendor's infrastructure.

Any third-party application or service that utilizes Perl to decompress untrusted data—such as web traffic payloads, file uploads, or archived logs—could inadvertently trigger the RCE or DoS conditions. If an attacker successfully exploits the RCE vulnerability (CVE-2026-3381), they could gain complete control over the host server without requiring initial authentication. This level of access allows adversaries to exfiltrate sensitive databases, disrupt mission-critical vendor operations, or pivot laterally to compromise connected client networks. The widespread, often overlooked presence of Perl in background services makes this a pervasive threat to supply chain resilience.

What questions should TPRM professionals ask vendors about the Perl vulnerabilities?

To accurately evaluate your third-party ecosystem's exposure to these compression library flaws, consider asking vendors the following specific technical questions:

Have you updated your Perl deployments to versions 5.40.4, 5.42.2, or later to ensure the patched Compress::Raw::Zlib (version 2.222) module is properly implemented?
For legacy environments where a full Perl language update is currently unfeasible, have you manually installed Compress::Raw::Zlib version 2.220 or higher directly into your @INC include path as a workaround?
Are your servers configured to utilize OS-level zlib libraries instead of the vendored Perl version, and if so, have you verified that the system zlib is updated to version 1.3.2 or later?
Have you audited your backend automated scripts and web services to identify applications that process compressed, user-supplied data using vulnerable Perl instances?

Remediation Recommendations for Vendors subject to this risk

Vendors relying on Perl for their operational infrastructure must take the following technical actions to secure their environments against these chained vulnerabilities:

Apply Official Language Updates: The most comprehensive mitigation is a full language upgrade. Transition to Perl versions 5.40.4, 5.42.2, or later, which securely bundle the patched Compress::Raw::Zlib 2.222 module.
Implement Manual Workarounds: If immediate full-version patching is impossible, manually install Compress::Raw::Zlib version 2.220 or newer directly into the @INC include path. This ensures the secure module version takes precedence during execution.
Validate OS-Level Mitigations: For operating system distributions configured to patch Perl to utilize the system's native zlib, administrators must verify that the OS-level zlib package is updated to version 1.3.2 or higher to neutralize the underlying flaws.

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

Grafana - Mar2026 (CVE-2026-27876, CVE-2026-27880)

What are the Grafana SQL Expressions and Resource Allocation Vulnerabilities?

CVE-2026-27876 is a Critical-severity vulnerability encompassing Remote Code Execution (RCE), Arbitrary File Write, and SQL Injection flaws stemming from improper handling of SQL expressions within Grafana. It carries a CVSS score of 9.1 and an EPSS score of 0.08%. The second flaw, CVE-2026-27880, is a High-severity Denial of Service (DoS) vulnerability caused by the allocation of resources without limits or throttling, holding a CVSS score of 7.5 and an EPSS score of 0.01%.

Discovered and published in late March 2026, security researchers have already published a Proof-of-Concept (PoC) exploit for the critical RCE flaw (CVE-2026-27876) on GitHub. Despite the availability of this public PoC, there are currently no confirmed reports of active exploitation in the wild or coordinated attack campaigns targeting these issues. Neither vulnerability has been added to CISA's Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not released a specific advisory for them. They are, however, tracked in the European Union's Vulnerability Database under identifiers EUVD-2026-16634 and EUVD-2026-16598.

Why should TPRM Professionals care about the Grafana vulnerabilities?

Grafana is an industry-standard analytics and interactive visualization web application widely used to monitor IT infrastructure, application performance, and operational health metrics. For Third-Party Risk Management professionals, an RCE vulnerability in an operational monitoring tool represents a severe risk to an organization's extended network perimeter.

Because Grafana often integrates directly with highly sensitive backend databases, time-series data stores, and cloud environments to build its dashboards, an attacker exploiting CVE-2026-27876 could execute arbitrary code to gain unauthorized access to this connected infrastructure. A compromised Grafana instance could allow cybercriminals to extract proprietary telemetry data, manipulate monitoring alerts to blind security teams to other malicious activities, or execute arbitrary file writes to gain a persistent foothold within the vendor's network. Additionally, the DoS vulnerability (CVE-2026-27880) could be weaponized to deliberately crash a vendor's monitoring capabilities during a broader, coordinated attack.

What questions should TPRM professionals ask vendors about the Grafana vulnerabilities?

To effectively assess your third-party ecosystem's exposure to these critical visualization platform flaws, consider asking the following technical questions:

Can you confirm if you have updated all instances of Grafana to versions 11.6.14, 12.1.10, 12.2.8, 12.3.6, or 12.4.2 to mitigate the risk of CVE-2026-27876 and CVE-2026-27880?
Have you implemented the recommended actions from Grafana's official security advisories for CVE-2026-27876 and CVE-2026-27880, including applying security patches and restricting access?
Are you monitoring for potential exploitation of the SQL expressions feature in Grafana, specifically in relation to the Remote Code Execution vulnerability CVE-2026-27876?
Can you confirm if the sqlExpressions feature toggle, which is linked to the RCE vulnerability, is enabled in your Grafana instances? If so, what measures have you taken to mitigate the associated risks?

Remediation Recommendations for Vendors subject to this risk

Vendors running affected versions of Grafana must implement the following technical measures to secure their monitoring environments:

Deploy Patches Immediately: Upgrade all Grafana instances to the secure versions (11.6.14, 12.1.10, 12.2.8, 12.3.6, or 12.4.2) as soon as they are officially released to remediate the root causes of both CVEs.
Restrict Network Exposure: Limit access to Grafana dashboards strictly to internal, trusted networks or require authenticated VPN connections to minimize the attack surface against the RCE vulnerability.
Enforce Least Privilege: Review and strictly limit the permissions of database service accounts used by Grafana to query backend data sources, ensuring they only have read access to the necessary metrics and cannot execute write commands.
Monitor Advisory Updates: Continuously track the official Grafana security advisories for any new workarounds, mitigation steps, or indicators of compromise related to these specific flaws.

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

Squid Proxy - Mar2026 (CVE-2026-33526, CVE-2026-32748, CVE-2026-33515)

What are the Squid Proxy ICP Protocol Vulnerabilities?

This cluster of vulnerabilities impacts the Internet Cache Protocol (ICP) message processing engine within the Squid caching proxy. The two most severe flaws, CVE-2026-33526 (Critical, CVSS: 9.2, EPSS: 1.30%) and CVE-2026-32748 (High, CVSS: 8.7, EPSS: 0.98%), are heap-based Use-After-Free (UAF) vulnerabilities. They occur when Squid improperly manages memory pointers while parsing malformed ICP UDP packets. An attacker can deliberately send crafted packets to trigger premature memory deallocation, resulting in a fatal crash and a Denial of Service (DoS) when the service attempts to access the freed memory.

The third vulnerability, CVE-2026-33515 (Medium, CVSS: 6.9, EPSS: 0.12%), is an information disclosure flaw caused by an out-of-bounds read. Due to improper input validation, when Squid processes an invalid ICP request, it inadvertently includes fragments of its own internal heap memory in the response packet. This "memory bleed" exposes sensitive data currently held in the proxy's memory to the attacker.

Published in late March 2026, these vulnerabilities affect all Squid deployments from version 3.0 through 7.4 where ICP support is explicitly enabled (i.e., icp_port > 0). Currently, there are no public Proof-of-Concept (PoC) exploits available, nor is there evidence of active exploitation in the wild. As such, these vulnerabilities are not listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not issued an advisory. They are tracked in the European Union's Vulnerability Database under EUVD-2026-16068, EUVD-2026-16056, and EUVD-2026-16067.

Why should TPRM Professionals care about the Squid vulnerabilities?

Squid is a widely deployed, high-performance caching proxy designed to optimize web delivery, filter traffic, and manage bandwidth across enterprise networks. For Third-Party Risk Management professionals, vulnerabilities within a vendor's core proxy infrastructure present a dual threat to availability and confidentiality.

Because Squid often sits at the edge of a network or acts as a crucial intermediary between internal services, a successful DoS attack leveraging the UAF vulnerabilities (CVE-2026-33526 and CVE-2026-32748) can cripple a vendor's web operations. This could lead to significant downtime for SaaS platforms or APIs that your organization relies upon. More concerning from a data security perspective is the "memory bleed" flaw (CVE-2026-33515). Because Squid caches web content and manages active sessions, the leaked heap memory could contain sensitive session tokens, authentication credentials, or fragments of confidential data belonging to your organization that were simply passing through the vendor's proxy.

What questions should TPRM professionals ask vendors about the Squid vulnerabilities?

To accurately determine the risk posture of your third parties regarding these proxy flaws, consider asking the following technical questions:

Can you confirm if you have upgraded all instances of Squid Proxy to version 7.5 or later to mitigate the risk of CVE-2026-33526, CVE-2026-32748, and CVE-2026-33515?
Have you applied the individual patches from commits 8a7d42f, 703e07d, and 8138e90 to your Squid 7 branch to address the vulnerabilities if a full upgrade was not possible?
Can you confirm if you have disabled the ICP protocol by setting icp_port to 0 in your squid.conf file to prevent exploitation of these vulnerabilities if an upgrade was not immediately possible?
Have you run the command 'squid -k parse 2>&1 | grep -E \"(icp|udp)_port\" | tail -n1' to verify if your instance is currently listening for ICP traffic and if the output shows a port other than 0, have you taken steps to address the vulnerability?

Remediation Recommendations for Vendors subject to this risk

Vendors utilizing Squid proxy servers must take the following actions to secure their infrastructure against these ICP vulnerabilities:

Immediate Software Upgrade: Update all vulnerable Squid instances to version 7.5 or higher, which contains the official code corrections for the ICP message processing engine.
Disable ICP Protocol: If patching is delayed, the only effective workaround is to disable the protocol entirely. Edit the squid.conf file and set icp_port 0. Note that configuring icp_access rules will not prevent exploitation of these specific flaws.
Validate Configuration: Administrators should actively verify their configuration status by running the diagnostic command: squid -k parse 2>&1 | grep -E "(icp|udp)_port" | tail -n1. An output showing a port other than 0 indicates the system remains vulnerable.
Network-Level Filtering: As an interim defense-in-depth measure, configure network firewalls to block UDP traffic destined for the configured ICP port to shield the service from external probing.

Black Kite’s Squid Proxy - Mar2026 FocusTag® details critical insights on the event for TPRM professionals.

n8n - Mar2026 (CVE-2026-33660)

What is the n8n Merge Node RCE Vulnerability?

CVE-2026-33660 is a Critical-severity Remote Code Execution (RCE) vulnerability impacting the n8n workflow automation platform. Carrying a CVSS score of 9.4 and an EPSS score of 0.07%, this flaw originates from insufficient sandboxing within the AlaSQL library used by the platform's Merge node.

The vulnerability, detailed in late March 2026, specifically affects the "Combine by SQL" functionality of the Merge node. Because the AlaSQL sandbox fails to adequately restrict high-risk SQL statements, an authenticated attacker with the permissions to create or edit workflows can craft malicious queries. These queries can bypass intended restrictions to invoke underlying JavaScript functions or interface directly with the host's file system. This allows the attacker to read sensitive local files, such as .env files containing database credentials, or achieve full Remote Code Execution with the same privileges as the n8n process itself.

Currently, there are no public Proof-of-Concept (PoC) exploits available, nor are there any confirmed reports of active exploitation in the wild. As a result, CVE-2026-33660 has not been added to CISA's Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not issued a dedicated advisory for it. The vulnerability is tracked in the European Union's Vulnerability Database under EUVD-2026-15942.

Why should TPRM Professionals care about the n8n vulnerability?

n8n is a powerful, node-based workflow automation tool, , often used to connect disparate APIs, databases, and SaaS applications. It acts as the central nervous system for many operational processes, meaning it holds extensive integration tokens, API keys, and credentials for various third-party services.

For Third-Party Risk Management professionals, an RCE vulnerability in an automation platform like n8n presents a severe, cascading risk to data security. If a threat actor compromises a vendor's n8n instance by exploiting the Merge node flaw, they gain the ability to execute arbitrary code and read local configuration files. This means the attacker can easily extract the integration tokens stored within the platform. With those tokens in hand, the attacker can pivot from the compromised n8n server directly into any connected service—including CRMs, cloud storage, or financial databases—potentially exposing sensitive data belonging to your organization that the vendor processes.

What questions should TPRM professionals ask vendors about the n8n vulnerability?

To accurately evaluate the security posture of your third parties concerning this automation platform flaw, consider asking the following technical questions:

Have you verified if your n8n deployments fall within the affected versions (prior to 2.14.1, 2.13.3, or 1.123.27) and prioritized an immediate upgrade to a patched release?
Are you enforcing strict Role-Based Access Control (RBAC) to limit "Workflow Editor" and "Workflow Creator" permissions to only the most essential and trusted personnel?
If an immediate upgrade is unfeasible, have you utilized the NODES_EXCLUDE environment variable (NODES_EXCLUDE=["n8n-nodes-base.merge"]) to disable the vulnerable Merge node, acknowledging the impact on existing workflows?
Have you audited existing workflows utilizing the "Combine by SQL" feature for any suspicious or unauthorized SQL statements?

Remediation Recommendations for Vendors subject to this risk

Vendors utilizing n8n must take immediate action to secure their automation infrastructure against this critical RCE flaw:

Immediate Software Upgrade: Update the n8n instance to the officially patched versions (2.14.1, 2.13.3, or 1.123.27). These releases incorporate the necessary updates to the AlaSQL sandboxing logic.
Restrict Workflow Permissions: Because exploitation requires authentication, heavily restrict access. Ensure only highly trusted users hold the "Workflow Editor" or "Workflow Creator" roles.
Disable Vulnerable Nodes: As a temporary workaround if patching is delayed, disable the Merge node entirely by setting the environment variable: NODES_EXCLUDE=["n8n-nodes-base.merge"]. Note that this will break any active workflows reliant on that specific node.
Audit Existing Workflows: Conduct a thorough review of all workflows currently using the Merge node in "Combine by SQL" mode, looking for anomalous logic or attempts to access system resources.
Environment Hardening: Ensure the n8n application process runs as a low-privileged user, rather than root, to contain the potential blast radius of a successful RCE exploit.

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

Harbor (CVE-2026-4404)

What is the Harbor Registry Default Credentials Vulnerability?

CVE-2026-4404 is a Critical-severity vulnerability (CVSS: 9.4, EPSS: 0.06%) stemming from the use of hard-coded, default credentials within GoHarbor's Harbor container registry. Detailed in late March 2026, the flaw exists because Harbor versions 2.15.0 and earlier initialize with a default administrative account (admin) and a publicly documented password (Harbor12345). Crucially, the system design does not enforce a mandatory password change during the initial setup phase or upon the first login.

Because these credentials are fixed within the application's configuration (harbor.yml) and widely known, a remote attacker can effortlessly authenticate to the Harbor web UI without needing to bypass complex security measures or execute code.As of late March 2026, there are no public Proof-of-Concept (PoC) exploits reported, nor are there confirmed incidents of active exploitation in the wild. Consequently, this vulnerability has not been added to CISA's Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not published a specific advisory for it. It is currently tracked in the European Union's Vulnerability Database under the identifier EUVD-2026-14455.

Why should TPRM Professionals care about the Harbor Registry vulnerability?

Harbor is an open-source, OCI-compliant container registry that serves as the central repository for a vendor's software images, making it a critical hub in the modern continuous integration and continuous development (CI/CD) pipeline. For Third-Party Risk Management professionals, an unmitigated default credentials vulnerability at this layer introduces a catastrophic supply chain risk.

If a vendor leaves the default credentials unchanged, an attacker gaining administrative access can completely compromise the registry. The attacker can silently overwrite legitimate, trusted container images with malicious variants.When the vendor's downstream systems—such as Kubernetes clusters or customer-facing applications—pull these compromised images, the attacker achieves remote code execution within those live environments. Furthermore, attackers can establish persistent access by generating new API tokens or robot accounts, exfiltrate proprietary source code embedded in the images, and disable built-in security features like vulnerability scanning and signature enforcement. A compromised registry essentially poisons the well for all software deployed by that vendor.

What questions should TPRM professionals ask vendors about the Harbor vulnerability?

To properly evaluate how your third parties are securing their container registries against this fundamental flaw, consider asking the following technical questions:

Have you upgraded all Harbor instances to version 2.15.1 or later to natively eliminate the default credential risk introduced during deployment?
If running an older version, have you explicitly replaced the default admin and Harbor12345 credentials with a strong,unique password by modifying the harbor_admin_password parameter in the harbor.yml file?
Have you conducted an immediate audit of your Harbor environment to identify and remove any unauthorized users, suspicious robot accounts, or unrecognized API tokens that may indicate prior compromise?
Is your container registry strictly segmented from the public internet, utilizing IP allowlisting or firewall rules to limit access exclusively to trusted internal CI/CD networks?

Remediation Recommendations for Vendors subject to this risk

Vendors hosting GoHarbor container registries must take immediate administrative and architectural actions to secure their artifacts:

Upgrade Harbor Immediately: Update the registry to version 2.15.1 or later. This is the most effective way to remediate the vulnerability and remove the systemic default credential risk.
Change the Default Admin Credentials: If an immediate upgrade is impossible, replace the default admin / Harbor12345 credentials via the web interface or by updating the harbor_admin_password parameter in harbor.yml prior to the next deployment.
Verify the Password Change: Actively test the login portal using the default credentials. If access is granted, the system is still vulnerable and must be reconfigured immediately.
Review Accounts and API Tokens: Inspect the user management console for unauthorized administrators,unexpected robot accounts, or newly generated API tokens, removing any suspicious entries.
Restrict Access to Harbor: Implement strict network controls, ensuring the registry is only accessible from trusted network segments and enforcing multi-factor authentication (MFA) for all administrative logins.

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

How TPRM Professionals Can Leverage Black Kite for These Vulnerabilities

Managing third-party risk across such a diverse spectrum of threats—from active zero-day exploitation in TrueConf, critical RCEs in F5 BIG-IP, Grafana, and n8n, and severe authentication bypasses in Cisco IMC, to foundational supply chain flaws in Perl, memory leaks in Squid Proxy, and default credential risks in Harbor—requires precise, actionable intelligence.

Black Kite addresses the challenge of identifying affected vendors by continuously releasing and updating specialized FocusTags®. Over the past week, Black Kite's threat intelligence team published a comprehensive suite of tags to help TPRM professionals track these specific incidents: the "Squid Proxy - Mar2026" and "Harbor" tags were published on March 26, 2026; the "F5 BIG-IP - Mar2026", "Grafana - Mar2026", and "n8n - Mar2026" tags followed on March 30, 2026; and the "TrueChaos" tag was released on March 31, 2026. Furthermore, on April 1, 2026, Black Kite published an updated version of the "Perl" tag to incorporate the latest supply chain risk data, followed immediately by the release of the "Cisco IMC" tag on April 2, 2026.

TPRM teams can operationalize these tags to instantly filter their vendor portfolios, isolating the exact organizations running compromised software versions. Instead of relying on slow, labor-intensive questionnaire cycles that contribute to severe vendor fatigue, analysts can use Black Kite's platform to drive an evidence-based incident response strategy.

A massive differentiator of Black Kite’s intelligence is the provision of granular, technical asset information. When a FocusTag® identifies a vulnerable vendor, the platform explicitly details the specific IP addresses and subdomains hosting the at-risk applications—whether it is an exposed Harbor registry, an unpatched Grafana dashboard, a targeted F5 BIG-IP gateway, or an exposed Cisco IMC management interface. Armed with this exact infrastructure data, risk professionals can bypass broad assessments and directly present vendors with undeniable proof of their exposure. This empowers organizations to demand targeted, verified fixes for the specific assets threatening the supply chain, drastically reducing the time to remediation.

Strengthening TPRM Outcomes with Black Kite’s FocusTags®

Managing third-party risk across such a broad spectrum of threats—ranging from active zero-day campaigns like TrueChaos and hardware-level authentication bypasses in Cisco IMC, to deep architectural flaws in Perl and Harbor—requires a highly dynamic and intelligent approach. Black Kite’s FocusTags® are designed to transform overwhelming vulnerability data into a prioritized, actionable defense strategy. Here is how Black Kite’s FocusTags® elevate your TPRM practices when facing these complex incidents:

Immediate Threat Visibility: Instantly spotlight which vendors in your ecosystem are running vulnerable software versions, enabling a rapid response to fast-moving threats like the actively exploited F5 BIG-IP RCE or the critical n8n automation flaw.
Granular Asset Identification: Move beyond generalized risk scores. FocusTags provides the exact IP addresses and subdomains associated with exposed assets, such as a vulnerable Harbor container registry, a leaking Squid Proxy server, or an exposed Cisco IMC management interface.
Evidence-Based Vendor Outreach: Facilitate highly targeted discussions with vendors. Armed with specific infrastructure data, TPRM teams can bypass generic questionnaires and demand verified proof of remediation for specific nodes, drastically reducing questionnaire fatigue.
Streamlined Supply Chain Defense: Provide a comprehensive view of complex dependencies, allowing risk teams to efficiently manage and track deep-seated vulnerabilities like the Perl Compress::Raw::Zlib supply chain flaw across their entire vendor portfolio.

The true value of Black Kite’s FocusTags® lies in their ability to translate intricate cyber threat intelligence into a streamlined, proactive operational workflow. By pinpointing exact exposures, these tags empower TPRM professionals to act decisively, ensuring that vendor ecosystems remain resilient against today’s most sophisticated attack vectors.

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:

F5 BIG-IP - Mar2026 : CVE-2025-53521, Critical Unauthenticated Remote Code Execution (RCE) vulnerability in the BIG-IP APM actively exploited in the wild.
TrueChaos : CVE-2026-3502, High-Severity Insufficient Firmware Update Validation allowing compromised on-premises servers to distribute malware (Zero-Day Exploited).
Cisco IMC : CVE-2026-20093, Critical Authentication Bypass Vulnerability allowing unauthenticated, remote attackers to alter passwords and gain full Admin access.
Perl : CVE-2026-4176, CVE-2026-3381, CVE-2026-27171, Critical Supply Chain Vulnerability leading to Remote Code Execution and Denial of Service.
Grafana - Mar2026 : CVE-2026-27876, CVE-2026-27880, Critical Remote Code Execution, Arbitrary File Write, SQL Injection, and Denial of Service Vulnerabilities.
Squid Proxy - Mar2026 : CVE-2026-33526, CVE-2026-32748, CVE-2026-33515, Critical Use-After-Free and Denial of Service Vulnerabilities in the Internet Cache Protocol (ICP) causing remote service crashes and information disclosure.
n8n - Mar2026 : CVE-2026-33660, Critical Remote Code Execution Vulnerability in the Merge node due to insufficient sandboxing.
Harbor : CVE-2026-4404, Critical Use of Default Credentials allowing full administrative access and potential supply chain attacks.
MariaDB : CVE-2026-32710, High-Severity JSON Schema Validation Buffer Overflow Vulnerability.
Jenkins - Mar2026 : CVE-2026-33001, CVE-2026-33002, CVE-2026-33003, CVE-2026-33004, Critical File Creation, DNS Rebinding, and Sensitive API Key Exposure in Jenkins Core and LoadNinja Plugin.
Roundcube - Mar2026 : Pre-Auth Arbitrary File Write, Critical Session Handler Vulnerability allowing Remote Code Execution and Account Takeover.
Zimbra - Mar2026 : CVE-2025-66376, Actively Exploited Stored XSS Vulnerability targeted by APT28 for Email Exfiltration.
Langflow - Mar2026 : CVE-2026-33017, CVE-2026-33309, Critical Unauthenticated Remote Code Execution and Arbitrary File Write in AI Orchestration Frameworks.
jsPDF - Mar2026 : CVE-2026-31938, Medium-Severity Cross-Site Scripting (XSS) Vulnerability in Client-Side PDF Generation Library.
Wing FTP Server : CVE-2025-47813, Information Disclosure Vulnerability in Wing FTP Server.
ScreenConnect - Mar2026 : CVE-2026-3564, Critical Improper Verification of Cryptographic Signature Vulnerability in ConnectWise ScreenConnect.
LiteSpeed - Mar2026 : CVE-2026-31386, High-Severity OS Command Injection and Privilege Escalation Vulnerabilities in LiteSpeed Web Server.
Authlib : CVE-2026-28490, CVE-2026-28498, CVE-2026-27962, Critical Cryptographic, Authentication Bypass, and Server-Side Request Forgery (SSRF) Vulnerabilities in Authlib.
File Browser : CVE-2026-32760, Critical Broken Access Control and Privilege Escalation Vulnerability in FileBrowser.
Hikvision IP Cameras : CVE-2021-36260, CVE-2017-7921, Critical Remote Code Execution (RCE) and Authentication Bypass Vulnerabilities in Hikvision Systems.
MSSQL - Mar2026 : CVE-2026-21262, CVE-2026-26115, CVE-2026-26116, Multiple Elevation of Privilege Vulnerabilities in Microsoft SQL Server.
SharePoint - Mar2026 : CVE-2026-26105, CVE-2026-26114, CVE-2026-26106, Remote Code Execution (RCE) and Spoofing Vulnerabilities in Microsoft SharePoint Server.
Cloudflare Pingora : CVE-2026-2835, CVE-2026-2833, CVE-2026-2836, Critical Request Smuggling and Cache Flaws in Cloudflare Pingora.
Gogs - Mar2026 : CVE-2025-64111, CVE-2025-64175, CVE-2026-24135, Critical Remote Code Execution, 2FA Bypass, and Path Traversal Vulnerabilities in Gogs.
SAP NetWeaver for ABAP [Suspected] : CVE-2026-24316, CVE-2026-24309, CVE-2026-27688, CVE-2026-27684, Server-Side Request Forgery (SSRF), Missing Authorization Checks, and SQL Injection Vulnerabilities in SAP NetWeaver.
Vaultwarden : CVE-2026-27803, CVE-2026-27802, CVE-2026-27898, High-Severity Privilege Escalation, Improper Authorization, and Broken Access Control Vulnerabilities in Vaultwarden.
Apache ZooKeeper : CVE-2026-24281, CVE-2026-24308, Authentication Bypass and Sensitive Information Disclosure Vulnerabilities in Apache ZooKeeper.
Mail2Shell : CVE-2026-28289, Critical Unauthenticated Remote Code Execution and Time-of-Check to Time-of-Use (TOCTOU) Vulnerabilities in FreeScout.
pac4j : CVE-2026-29000, Critical Authentication Bypass and JWT Token Forging Vulnerability in pac4j-jwt.
MongoDB - Mar2026 : CVE-2026-25611, High-Severity Denial of Service (DoS) Vulnerability in MongoDB.
Django - Mar2026 : CVE-2026-25673, CVE-2026-25674, High-Severity Denial of Service (DoS) and Race Condition Vulnerabilities in Django Web Framework.
Langflow : CVE-2026-27966, Critical Remote Code Execution (RCE) Vulnerability in Langflow AI Data Workflows.
RustFS : CVE-2026-27822, Medium-Severity Cross-Site Scripting (XSS) Vulnerability in RustFS S3 Storage Management Console.
Apache Superset - Mar2026 : CVE-2026-23984, CVE-2026-23982, CVE-2026-23980, High-Severity Data Access Control Bypass and SQL Injection Vulnerabilities in Apache Superset.