blog

FOCUS FRIDAY: TPRM Insights On Critical Vulnerabilities In MariaDB, Jenkins, Roundcube, Zimbra, Langflow, And jsPDF

Published

Mar 27, 2026

Introduction

Welcome to another edition of Focus Friday. As digital supply chains grow increasingly complex, a single compromised database engine or a hidden authentication flaw within a third-party application can rapidly escalate into a direct threat to your own operations. This week, we are analyzing a diverse set of high-severity vulnerabilities that require immediate attention from Third-Party Risk Management (TPRM) professionals.

Our analysis spans the entire modern infrastructure stack: from active, state-sponsored exploitation of Zimbra mail servers and critical remote code execution (RCE) flaws in Jenkins and Langflow AI pipelines, to memory corruptionrisks in MariaDB and session-hijacking vulnerabilities in foundational libraries like jsPDF. Whether it is a pre-authentication file write in Roundcube or a DNS rebinding attack on CI/CD systems, these threats demonstrate that an attacker only needs one weak link to compromise a vendor’s environment. In this blog, we will break down the technical implications of these incidents and provide the actionable intelligence needed to safeguard your vendor ecosystem against today's most sophisticated attack vectors.

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

MariaDB (CVE-2026-32710)

What is the MariaDB JSON Schema Validation Buffer Overflow?

CVE-2026-32710 is a high-severity heap-based buffer overflow vulnerability affecting the JSON schema validation component of MariaDB. Carrying a CVSS score of 8.5 and an EPSS score of 0.26%, the flaw resides within the JSON_SCHEMA_VALID() function. This vulnerability allows an authenticated attacker with low privileges to trigger a memory corruption event by providing specifically crafted or malformed JSON inputs.

First published on March 24, 2026, the vulnerability primarily leads to a server crash, resulting in a Denial of Service (DoS). However, security researchers have noted that under specific laboratory conditions—where an attacker can maintain precise control over the server's memory layout—the flaw could potentially be escalated to achieve Remote Code Execution (RCE). As of this writing, there are no reports of active exploitation in the wild or public Proof-of-Concept (PoC) exploits. Furthermore, CVE-2026-32710 is not currently listed in CISA’s Known Exploited Vulnerabilities (KEV) Catalog, though it has been documented in the European Union’s Vulnerability Database under the identifier EUVD-2026-13764.

Why should TPRM Professionals care about the MariaDB vulnerability?

MariaDB is a foundational component of many modern web applications and enterprise data architectures. Because this vulnerability affects the database's ability to validate JSON data—a format widely used for configuration and data exchange—it poses a significant risk to the integrity and availability of a vendor's data environment.

For Third-Party Risk Management professionals, a vulnerability in a core database engine means that any vendor utilizing vulnerable versions of MariaDB could face prolonged service outages if an attacker triggers a crash. Furthermore, the theoretical possibility of RCE implies that a compromised database could serve as a gateway for attackers to exfiltrate sensitive customer records, manipulate financial data, or move laterally into the broader corporate network. Given that an attacker only needs low-level authentication to trigger the overflow, the barrier for an internal threat or a compromised user account to cause damage is notably low.

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

To assess the specific exposure of your third-party ecosystem to this database flaw, consider asking the following questions:

Can you confirm if you have updated all instances of MariaDB to the officially patched releases (11.4.10, 11.8.6, or 12.2.2) to mitigate the risk of CVE-2026-32710?
Have you implemented strict validation and sanitization for all user-supplied JSON data processed by the database to prevent malformed or manipulated inputs from triggering the memory corruption associated with CVE-2026-32710?
Are you closely monitoring the execution of the JSON_SCHEMA_VALID() function, as it is the specific component targeted by this heap-based buffer overflow vulnerability (CVE-2026-32710)?
Are you continuously reviewing official MariaDB security advisories and release notes for any further updates or supplementary mitigation strategies regarding this specific threat (CVE-2026-32710)?

Remediation Recommendations for Vendors subject to this risk

Vendors identified as running vulnerable MariaDB versions should prioritize the following technical steps to secure their environments:

Immediate Patching: Update MariaDB installations to the latest stable releases (11.4.10, 11.8.6, or 12.2.2). This is the only definitive way to remediate the heap-based buffer overflow.
Function Restriction: If immediate patching is not feasible, restrict the execution permissions for the JSON_SCHEMA_VALID() function to only the most essential service accounts.
Enhanced Input Validation: Implement robust sanitization layers at the application level to filter out malformed JSON strings before they are processed by the database.
Privilege Audit: Review database user permissions to ensure that only authorized users have the ability to execute schema validation functions, adhering to the principle of least privilege.

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

Jenkins - Mar2026 (CVE-2026-33001, CVE-2026-33002, CVE-2026-33003, CVE-2026-33004)

What are the Jenkins Core and LoadNinja Plugin Vulnerabilities?

The Jenkins automation server and its LoadNinja plugin are currently affected by four distinct security flaws ranging from medium to high severity. The most critical, CVE-2026-33001, is a high-severity arbitrary file write vulnerability (CVSS 8.8, EPSS 0.12%) stemming from improper validation of symbolic links during the extraction of .tar and .tar.gz archives. An attacker with "Item/Configure" permissions can exploit this to write malicious scripts to the Jenkins initialization directory, leading to Remote Code Execution (RCE) upon server restart.

CVE-2026-33002 is a high-severity DNS rebinding vulnerability (CVSS 7.5, EPSS 0.05%) that targets the Jenkins WebSocket Command Line Interface (CLI). By manipulating HTTP headers, an attacker can bypass origin checks and establish a malicious connection. In environments where the "anonymous user" is granted even minimal permissions, this flaw can be leveraged to execute unauthorized CLI commands. Finally, CVE-2026-33003 and CVE-2026-33004 (both CVSS 4.3, EPSS 0.04% and 0.03% respectively) involve the LoadNinja plugin storing and displaying sensitive API keys in plaintext, exposing them to any user with job configuration access.

These vulnerabilities were officially disclosed by the Jenkins project on March 18, 2026. At present, there are no confirmed reports of active exploitation in the wild or public Proof-of-Concept (PoC) exploits. None of these vulnerabilities have been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog as of late March 2026.

Why should TPRM Professionals care about the Jenkins vulnerabilities?

Jenkins serves as the central orchestration engine for Continuous Integration and Continuous Deployment (CI/CD) pipelines, making it one of the most high-value targets in a vendor's infrastructure. If a vendor's Jenkins controller is compromised via an arbitrary file write or a CLI hijack, the impact radiates across their entire software supply chain. An attacker gaining RCE could inject malicious code directly into the vendor’s software builds before they are delivered to your organization, effectively turning a trusted partner into a vector for malware distribution.

Furthermore, the exposure of LoadNinja API keys highlights a significant risk to cloud-based testing environments. If a vendor’s API keys are harvested from plaintext configuration files, an attacker can hijack their LoadNinja accounts to disrupt testing phases or exfiltrate sensitive performance data. For TPRM professionals, these flaws represent more than just individual server risks; they indicate potential systemic weaknesses in how a vendor manages their development environment and handles sensitive credentials.

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

To gauge the security of your vendors' development pipelines, consider the following specific inquiries:

Have you updated Jenkins to version 2.555 or Jenkins LTS to 2.541.3 to mitigate the risk of CVE-2026-33001 and CVE-2026-33002, which enforce strict path validation for archive extraction and use the configured "Jenkins URL" for WebSocket origin validation instead of request headers?
Have you updated the LoadNinja Plugin to version 2.2 to address the issues of CVE-2026-33003 and CVE-2026-33004, ensuring that LoadNinja API keys are encrypted at rest and masked in the web interface?
Have you audited the "Global Security" configuration to ensure the anonymous user has no permissions, specifically disabling "Anyone can do anything" and switching to "Matrix-based security" or "Role-based strategy" to prevent potential WebSocket CLI DNS Rebinding attacks?
Have you rotated all LoadNinja API keys considering they were stored in plain text, and can you confirm that these keys are now compromised and have been replaced with new ones after updating the plugin?

Remediation Recommendations for Vendors subject to this risk

Vendors utilizing Jenkins and the LoadNinja plugin should take immediate technical action to secure their controllers:

Apply Core Updates: Immediately update Jenkins Weekly to version 2.555 or Jenkins LTS to version 2.541.3. These releases introduce strict path validation for archives and hardened origin checks for WebSockets.
Secure Plugin Configurations: Update the LoadNinja Plugin to version 2.2 to enable credential encryption at rest and masking in the user interface.
Rotate Secrets: Because LoadNinja API keys were previously stored in plaintext config.xml files, they must be considered compromised and rotated immediately after the plugin update.
Harden Access Controls: Move away from permissive authorization strategies. Disable "Anyone can do anything" and ensure that only authenticated, authorized users have "Item/Configure" or "Item/Extended Read" permissions.

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

Roundcube - Mar2026

What is the Roundcube Pre-Auth Arbitrary File Write Vulnerability?

Roundcube Webmail version 1.6.14 addresses a critical pre-authentication arbitrary file write vulnerability that stems from unsafe deserialization within the Redis and Memcache session handlers. Discovered by security researcher y0us and disclosed on March 18, 2026, this flaw allows a remote, unauthenticated attacker to write files to arbitrary locations on the server. Although no specific CVE ID has been publicly assigned to this particular issue yet, its impact is categorized as high-severity due to the potential for remote code execution (RCE) if an attacker manages to overwrite critical application or configuration files.

While older vulnerabilities like CVE-2025-49113 (CVSS 9.9) and CVE-2025-68461 (CVSS 7.2) were added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog on February 20, 2026, this new session handler flaw is not yet listed in the KEV as of late March 2026. The version 1.6.14 update also resolves several other security concerns, including a password change logic bug, IMAP injection, and multiple cross-site scripting (XSS) and server-side request forgery (SSRF) bypasses.

Why should TPRM Professionals care about the Roundcube vulnerability?

Webmail servers like Roundcube are prime targets for threat actors because they act as gateways to sensitive corporate communications, intellectual property, and personal data. A pre-authentication vulnerability is particularly dangerous because it removes the requirement for valid credentials, allowing any internet-based actor to target the server. If a vendor's webmail interface is compromised, attackers can intercept confidential emails, exfiltrate user credentials, and utilize the server to send authentic-looking phishing emails to your employees or customers.

From a Third-Party Risk Management perspective, this vulnerability represents a total loss of trust in the vendor’s communication infrastructure. An arbitrary file write flaw can lead to full system compromise, allowing an attacker to establish a persistent presence within the vendor’s network. This could facilitate lateral movement, potentially leading to a broader breach of the vendor’s internal databases or service platforms that host your organization's data.

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

To identify exposure to this specific webmail threat, consider asking vendors the following technical questions:

Have you upgraded all instances of Roundcube Webmail to version 1.6.14 or later to mitigate the risk of the arbitrary file write vulnerability?
Can you confirm if you have implemented logging and monitoring for any unusual file write operations, especially in critical system or web-accessible directories, to detect potential exploitation attempts?
Have you reviewed file system permissions for the Roundcube installation directory and ensured that the web server user only has the minimum necessary write permissions?
Can you provide details on how you are managing the Principle of Least Privilege for the Roundcube installation directory to prevent unauthorized access or arbitrary code execution?

Remediation Recommendations for Vendors subject to this risk

Vendors running Roundcube must take immediate action to secure their mail infrastructure:

Upgrade to Version 1.6.14: Apply the security update to version 1.6.14 (or 1.5.14 for LTS users) immediately. This patch addresses the unsafe deserialization in the session handlers.
Review File Permissions: Implement the principle of least privilege for the web server user (e.g., www-data). Ensure it cannot write to directories outside of the intended temporary or upload folders.
Conduct a Security Audit: Monitor server logs for unusual activity, specifically looking for attempts to manipulate session data or unexpected file creations in the application root.
Enable Multi-Factor Authentication (MFA): To mitigate the risk of account takeovers resulting from the other logic flaws patched in this release, enforce MFA for all webmail users.

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

Zimbra - Mar2026 (CVE-2025-66376)

What is the Zimbra Collaboration Suite Stored XSS Vulnerability?

CVE-2025-66376 is a medium-severity stored Cross-Site Scripting (XSS) vulnerability impacting the Synacor Zimbra Collaboration Suite (ZCS). Carrying a CVSS score of 6.1 and an EPSS score of 10.01%, the flaw exists within the "Classic UI" rendering engine's handling of Cascading Style Sheets (CSS). Specifically, the application fails to sanitize @import directives when processing HTML-formatted email messages. This allows an attacker to bypass standard filters and inject malicious JavaScript that executes automatically when a victim views a specially crafted email.

Although first published in early January 2026, the vulnerability saw a significant escalation in risk following reports of active exploitation in the wild. Security researchers identified campaigns—notably by the Russia-linked threat actor APT28 (also known as Fancy Bear or Operation GhostMail)—targeting government and critical infrastructure entities. In these attacks, malicious scripts were used to silently exfiltrate session tokens, login credentials, and up to 90 days of mailbox data. Due to this verified threat activity, the Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-66376 to its Known Exploited Vulnerabilities (KEV) catalog on March 18, 2026, mandating federal agencies to apply patches by early April.

Why should TPRM Professionals care about the Zimbra XSS vulnerability?

Email servers are the communication backbone of any organization, housing immense amounts of sensitive corporate data, intellectual property, and internal strategy. Because this vulnerability is a "stored" XSS flaw, the malicious payload resides within the mailbox itself, meaning it can be triggered repeatedly and silently. For Third-Party Risk Management (TPRM) professionals, a compromised vendor email server represents a catastrophic breakdown in the secure supply chain.

If a vendor's ZCS environment is exploited, attackers can hijack legitimate sessions to impersonate vendor employees. This allows them to send fraudulent invoices, request unauthorized wire transfers, or conduct highly convincing spear-phishing attacks against your own staff from a trusted domain. Furthermore, the ability for threat actors like APT28 to exfiltrate months of historical email data means that your organization’s past projects, shared credentials, or confidential agreements with that vendor may now be in the hands of a state-sponsored adversary.

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

To assess the resilience of your third-party ecosystem against this active threat, consider asking the following targeted questions:

Have you updated all instances of Synacor Zimbra Collaboration Suite to version 10.0.18 or 10.1.13 to mitigate the risk of the XSS vulnerability (CVE-2025-66376)?
Have you implemented or tightened the Content Security Policy (CSP) headers on your Zimbra web server to restrict the execution of unauthorized inline scripts and the loading of styles from untrusted external domains, as recommended?
Have you configured your Email Security Gateway to strip or block incoming HTML emails containing suspicious <style> blocks or @import directives until all internal servers are patched?
Have you audited account activity for Indicators of Compromise (IoC), such as unauthorized email forwarding rules or unusual login locations, especially for high-profile accounts that may have been targeted by this campaign?

Remediation Recommendations for Vendors subject to this risk

Vendors identified as running vulnerable versions of Zimbra should implement these technical safeguards immediately:

Immediate Upgrade: Apply the latest security patches (ZCS 10.0.18 or 10.1.13) which contain the logic necessary to neutralize malicious CSS imports.
Transition to Modern UI: Shift user populations from the "Classic UI" to the "Modern UI" to mitigate risks associated with the legacy rendering engine.
Tighten Content Security Policy (CSP): Implement strict CSP headers on the web server to block the loading of styles from untrusted external domains and prevent the execution of inline scripts.
Monitor and Audit: Actively monitor for unusual exfiltration patterns, especially DNS or HTTPS-based exfiltration channels associated with the Operation GhostMail campaign.

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

Langflow - Mar2026 (CVE-2026-33017, CVE-2026-33309)

What are the Langflow Remote Code Execution Vulnerabilities?

Langflow, a prominent visual framework for building AI agents and RAG pipelines, is affected by two critical vulnerabilities that allow for full system takeover. CVE-2026-33017 is an unauthenticated Remote Code Execution (RCE) flaw with a CVSS score of 9.3 and an EPSS score of 0.36%. It resides in the /api/v1/build_public_tmp endpoint, where the application incorrectly processes attacker-supplied flow definitions using Python’s exec() function without sandboxing. This allows an unauthenticated actor to run arbitrary code with a single HTTP request.

CVE-2026-33309 is a critical path traversal and arbitrary file write vulnerability (CVSS 9.9) located in the /api/v2/files/ endpoint. This flaw allows attackers to write files to any location on the host filesystem, which can be leveraged to achieve RCE. Both issues were disclosed in mid-March 2026 and impact all versions prior to 1.9.0.

Active exploitation for CVE-2026-33017 was detected by security researchers within just 20 hours of its public disclosure on March 17, 2026. Automated scanning campaigns have been observed targeting exposed instances to harvest environment variables, including OpenAI API keys and database connection strings. While these vulnerabilities are documented in the European Union's Vulnerability Database (EUVD-2026-13556), and the vulnerability has been added to CISA's Known Exploited Vulnerabilities (KEV) Catalog on March 25, 2026.

Why should TPRM Professionals care about the Langflow vulnerabilities?

Langflow is frequently deployed by data science and AI development teams to orchestrate complex workflows involving highly sensitive assets. Because these platforms often require access to core corporate data, large language model (LLM) API keys, and internal databases, a compromise of a Langflow instance is essentially a compromise of the organization’s AI supply chain.

TPRM professionals should prioritize this risk because many AI tools are deployed in "shadow IT" environments—outside the typical security oversight of production infrastructure. If a vendor uses Langflow to build the AI features they provide to your organization, an unauthenticated attacker could steal the credentials used to access your data or inject malicious logic into the AI’s decision-making process. The speed at which these flaws are being weaponized means that any delay in vendor patching creates a wide window for data exfiltration and persistent lateral movement within the vendor's network.

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

To evaluate the security posture of vendors utilizing AI orchestration tools, consider asking the following specific questions:

Have you upgraded all instances of Langflow to version 1.9.0 or later to mitigate the risk of CVE-2026-33017 and CVE-2026-33309?
Can you confirm that you have implemented network segmentation and least privilege principles to all Langflow deployments to prevent potential exploitation of the /api/v1/build_public_tmp/{flow_id}/flow and /api/v2/files/ endpoints?
Have you rotated all potentially exposed credentials including API keys, database credentials, and tokens in response to the active exploitation observed for CVE-2026-33017?
Are you monitoring logs for suspicious requests targeting build and file upload endpoints to detect potential exploitation of the critical path traversal and arbitrary file write vulnerability (CVE-2026-33309)?

Remediation Recommendations for Vendors subject to this risk

Vendors running Langflow must take immediate technical steps to neutralize these critical threats:

Update Immediately: Upgrade all Langflow installations to version 1.9.0 or newer to patch the logic flaws in the build and file API endpoints.
Eliminate Public Exposure: Place Langflow instances behind a reverse proxy with strong authentication or require a VPN for access. Langflow should never be directly accessible from the public internet.
Rotate Exposed Secrets: Because attackers are actively harvesting credentials, assume all environment variables and stored secrets in vulnerable instances are compromised and rotate them immediately.
Implement Network Segmentation: Isolate Langflow deployments from critical internal systems and restrict the outbound network permissions of the host server to prevent data exfiltration.

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

jsPDF - Mar2026 (CVE-2026-31938)

What is the jsPDF Cross-Site Scripting Vulnerability?

CVE-2026-31938 is a recently disclosed Cross-Site Scripting (XSS) vulnerability affecting jsPDF, a widely utilized JavaScript library for generating PDF documents. The vulnerability, which carries a CVSS score of 6.1 and an EPSS score of 0.04%, is rooted in the library's output() function. Specifically, certain method overloads—such as pdfobjectnewwindow and dataurlnewwindow—fail to properly sanitize user-controlled strings before they are embedded into the HTML used to display the generated PDF.

First published on March 18, 2026, the flaw allows an attacker to inject arbitrary HTML and malicious scripts into the browser context. Although there are no confirmed reports of active exploitation in the wild at this time, public Proof-of-Concept (PoC) exploits have already surfaced, demonstrating how an attacker can break out of the intended HTML structure to execute JavaScript. As of late March 2026, this vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog. However, it is documented in the European Union's Vulnerability Database under the identifier EUVD-2026-12755. Note that while some technical discussions may conflate this with other recent disclosures, CVE-2026-31938 specifically addresses this HTML injection path in the jsPDF core.

Why should TPRM Professionals care about the jsPDF vulnerability?

jsPDF is a standard component in modern web applications, often used in client-side portals to allow users to download invoices, reports, or sensitive account statements. Because the vulnerability is an XSS flaw, the malicious script executes within the origin of the web application itself. For Third-Party Risk Management (TPRM) professionals, this means a vulnerability in a vendor's "Export to PDF" feature could be weaponized to compromise your organization's user sessions.

If a vendor utilizes a vulnerable version of jsPDF, an attacker could potentially steal session cookies, capture login credentials, or exfiltrate sensitive data displayed on the page. Since the script runs with the full permissions of the logged-in user, the impact is not limited to the PDF itself but extends to the entire web application session. This makes the vulnerability a significant risk for any third-party service that handles authenticated user data or sensitive business records.

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

To assess the exposure of your third-party ecosystem to this XSS risk, consider asking the following technical questions:

Can you confirm if you have updated the jsPDF library in your project to version 4.2.1 or higher to mitigate the risk of CVE-2026-31938 and CVE-2026-20963?
Have you implemented a Content Security Policy (CSP) to disallow the execution of inline scripts ('unsafe-inline') and restrict the origins from which scripts can be loaded as a secondary defense against XSS exploitation?
Have you identified and audited all instances in your codebase where user-provided input is passed into the jsPDF output() function, particularly for filename or url options, to prevent arbitrary script execution?
If an immediate upgrade to jsPDF version 4.2.1 or higher was not feasible, have you implemented strict manual sanitization using a library like DOMPurify to clean all strings before passing them to jsPDF, or manually escape double quotes, angle brackets, and backslashes?

Remediation Recommendations for Vendors subject to this risk

Vendors identified as using vulnerable versions of the library should prioritize the following actions to protect their users:

Immediate Upgrade: Update the jsPDF library to version 4.2.1 or higher. This version introduces the necessary escaping to prevent HTML injection via the options argument.
Input Sanitization: Regardless of the library version, always validate and sanitize user-controlled data (such as filenames or metadata) before passing it to document generation functions.
Harden Content Security Policy (CSP): Implement a robust CSP that disallows 'unsafe-inline' and 'unsafe-eval'. This provides a critical layer of defense that can prevent injected scripts from executing even if a sanitization bypass is found.
Code Review: Conduct a targeted review of all code paths where user input flows into the jsPDF output() method, particularly focusing on the pdfjsnewwindow and dataurlnewwindow overloads.

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

How TPRM Professionals Can Leverage Black Kite for These Vulnerabilities

Black Kite provides a streamlined approach to identifying and managing the vulnerabilities discussed in this week’s blog. To ensure immediate supply chain visibility, the platform published the Zimbra - Mar2026 tag on March 19, 2026, followed by the Jenkins - Mar2026, Langflow - Mar2026, and jsPDF - Mar2026 tags on March 23, 2026. Most recently, the MariaDB and Roundcube - Mar2026 tags were released on March 24 and March 25, 2026, respectively. These tags allow TPRM teams to instantly filter their entire vendor ecosystem to isolate companies running vulnerable versions of these products without the need for manual scanning or generic inquiries.

The primary differentiator of the Black Kite platform is the provision of precise asset intelligence. Rather than simply indicating that a vendor "might" be using a vulnerable application, Black Kite identifies the exact IP addresses and subdomains where the risk is detected. By providing these granular technical details, TPRM professionals can move beyond broad assessments and instead present vendors with actionable evidence of their exposure. This empowers organizations to demand verified remediation for specific, high-risk assets—such as an exposed Langflow instance or a vulnerable Jenkins controller—ensuring that critical supply chain nodes are secured before they can be exploited.

Strengthening TPRM Outcomes with Black Kite’s FocusTags®

In an era where threat actors weaponize zero-day vulnerabilities within hours of disclosure, traditional, static risk assessments are no longer sufficient. Black Kite’s FocusTags® revolutionize Third-Party Risk Management (TPRM) by converting overwhelming vulnerability data into a prioritized, actionable roadmap. Whether addressing the complex RCE risks in Langflow or the targeted exploitation of Zimbra mail servers, these tags empower security teams to move with precision. Here is how Black Kite’s FocusTags® elevate your defensive posture:

Rapid Exposure Identification: Instantly isolate which vendors in your ecosystem are running vulnerable versions of software like Jenkins or MariaDB, allowing for a response that is measured in minutes, not months.
Evidence-Based Vendor Outreach: Move past generic questionnaires. Armed with specific asset details—including the exact IP addresses and subdomains at risk—TPRM teams can demand verified proof of remediation for the specific vulnerabilities identified, such as the jsPDF XSS or Roundcube file write flaws.
Proactive Threat Monitoring: For "reactivated" or high-activity threats like the Zimbra XSS campaign targeted by state-sponsored actors, FocusTags® provide continuous visibility, ensuring that vendor patches remain effective against evolving exploit methods.
Smarter Resource Allocation: By correlating the severity of a vulnerability with the criticality of a vendor, FocusTags® help analysts focus their limited time on the supply chain nodes that present the highest risk to the organization’s data integrity.

Black Kite’s FocusTags® provide the specialized intelligence required to manage the modern digital supply chain, transforming intricate cyber threat data into a streamlined, proactive defense strategy that keeps your organization resilient in a volatile threat environment.

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:

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.
SolarWinds Serv-U - Feb2026 : CVE-2025-40541, CVE-2025-40540, CVE-2025-40539, CVE-2025-40538, Critical Remote Code Execution (RCE) flaws that could allow unauthenticated attackers to gain root-level access.
Jenkins - Feb2026 : CVE-2026-27099, CVE-2026-27100, High-severity stored XSS in node descriptions and information disclosure via Run Parameters.
Cisco Catalyst SD-WAN : CVE-2026-20127, CVE-2022-20775 — Critical 10.0 CVSS authentication bypass exploited in the wild, chained with privilege escalation for full root access.
n8n - Feb2026 (Latest) : CVE-2026-27497, CVE-2026-27577, CVE-2026-27495 — Triple critical RCE vulnerabilities in sandbox and node execution allowing host server takeover.