blog

Focus Friday: FTPRM Insights on Critical Vulnerabilities in FreeScout, pac4j, MongoDB, Django, Langflow, RustFS, and Apache Superset

Published

Mar 6, 2026

Updated

Mar 5, 2026

Introduction

Welcome to another edition of Focus Friday, our dedicated series where we analyze the week's most critical cybersecurity incidents through the lens of Third-Party Risk Management (TPRM). As digital supply chains grow increasingly complex, a single software flaw in a vendor's environment can rapidly escalate into a direct threat to your organization's data and operational continuity. This week, we are breaking down a highly diverse set of vulnerabilities impacting essential business infrastructure. We will examine a critical Remote Code Execution (RCE) flaw in FreeScout help desks (Mail2Shell), a highly efficient Denial-of-Service (DoS) vulnerability in MongoDB, framework-level DoS and race conditions in Django, a severe prompt injection RCE in Langflow AI agents, an administrative account takeover via XSS in RustFS storage, major access control bypasses in Apache Superset, and a critical authentication bypass via forged tokens in pac4j libraries. Let's explore how these specific threats impact your vendor ecosystem and the actionable steps you can take to secure your supply chain.

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

By utilizing Black Kite’s FocusTags®, organizations can move beyond manual, broad-spectrum vendor surveys and instead apply a data-driven approach to identify and mitigate these specific risks within their vendor ecosystem.

Mail2Shell (CVE-2026-28289, FreeScout)

What is the FreeScout Mail2Shell Vulnerability?

CVE-2026-28289 is a critical unauthenticated Remote Code Execution (RCE) vulnerability affecting FreeScout, a popular open-source help desk and shared mailbox application. Carrying a maximum CVSS score of 10.0 and an EPSS score of 0.04%, this flaw allows a remote attacker to gain complete administrative control over the underlying server.

Published in early March 2026, this vulnerability acts as a patch bypass for a previously addressed flaw (CVE-2026-27636). The root cause is a Time-of-Check to Time-of-Use (TOCTOU) and logic error within the application's filename sanitization process. Specifically, the software checks for restricted file prefixes before it removes invisible formatting characters. An attacker can exploit this by uploading a malicious file using a Zero-Width Space (U+200B) prefix, such as \u200B.htaccess. This invisible character bypasses the initial security check, which only looks for a literal dot. During the subsequent sanitization step, the Zero-Width Space is stripped out, resulting in a perfectly valid .htaccess file being saved to the disk. If the application is hosted on an Apache server with AllowOverride All enabled, the attacker can use this file to alter server configurations and execute arbitrary PHP web shells.

While public Proof-of-Concept (PoC) exploits are currently available, there are no confirmed reports of active exploitation in the wild or specific threat actor campaigns leveraging this flaw at this time. Consequently, as of early March 2026, the vulnerability is not listed in CISA’s Known Exploited Vulnerabilities (KEV) Catalog, nor has CISA published a specific advisory regarding it.

Why Should TPRM Professionals Care About the FreeScout Vulnerability?

FreeScout functions as a central hub for managing customer support tickets, shared inboxes, and internal team communications. Due to its core purpose, the application inherently processes and stores highly sensitive information, including customer Personally Identifiable Information (PII), proprietary business discussions, and potentially sensitive authentication tokens shared during support requests.

From a TPRM perspective, a vendor relying on a vulnerable FreeScout instance introduces severe risks to data confidentiality and supply chain integrity. Because this is an unauthenticated RCE, a threat actor does not even need a valid account to compromise the system; they simply need to send a malicious email containing the payload to the configured mailbox. Once the server is compromised, attackers can exfiltrate sensitive communications, intercept support processes, or abuse the vendor’s trusted domain to send fraudulent, malicious emails directly to your organization or other clients. A breach of a help desk system fundamentally breaks the trust and security of the communication channel between you and your third-party vendor, making rapid remediation essential.

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

To accurately assess the risk exposure of your third-party ecosystem, consider asking your vendors the following targeted questions regarding this incident:

Have you updated all instances of FreeScout to version 1.8.207 or later to mitigate the risk of CVE-2026-27636 and CVE-2026-28289?
Can you confirm if you have implemented a Web Application Firewall (WAF) rule to block requests containing the Zero-Width Space character (%E2%80%8B) in multi-part form data as a temporary measure if an immediate update was not possible?
Have you conducted a file system audit on the storage/attachment/ directory for any unexpected .htaccess files or text files containing PHP code (e.g., php, shell_exec)?
Can you confirm if you have reviewed your Apache configuration and disabled AllowOverride All in the storage/attachment/ directory to prevent [.]htaccess files from altering script execution permissions?

Remediation Recommendations for Vendors subject to this risk

Vendors running affected FreeScout installations should take immediate technical actions to secure their help desk environments:

Immediate Software Upgrade: Update FreeScout to version 1.8.207 or later. This patched version corrects the logic flaw, ensuring that the removal of invisible characters occurs before any security pattern validation takes place.
Web Server Hardening: Modify your Apache configuration to disable AllowOverride All specifically within the storage/attachment/ directory. This ensures that even if an .htaccess file is successfully uploaded, it cannot alter script execution permissions.
File System Audit: Actively search the storage/attachment/ directory for any unauthorized .htaccess files or text files containing PHP execution functions (e.g., php, shell_exec).
Restrict Uploads: If patching must be delayed, consider temporarily disabling file attachments or implementing WAF rules to block incoming requests that contain the Zero-Width Space character in filenames.

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

pac4j (CVE-2026-29000)

What is the pac4j Authentication Bypass Vulnerability?

CVE-2026-29000 is a Critical-severity authentication bypass vulnerability impacting pac4j-jwt, a module within the widely used pac4j Java security engine. Carrying a maximum CVSS score of 10.0 and an EPSS score of 0.24%, this flaw permits unauthenticated threat actors to forge administrative tokens and completely bypass application security controls.

Published in early March 2026, the vulnerability resides within the JwtAuthenticator component of the library. When developers utilize this component without explicitly enforcing the setExpectedJti method for JSON Web Token (JWT) validation, the application fails to verify the presence and validity of the jti (JWT ID) claim. An attacker can exploit this oversight by crafting and submitting malformed JWTs that intentionally lack a jti claim. Because the application logic does not reject the missing claim, the forged token is accepted as valid. This allows the attacker to bypass the intended authentication sequence, granting them unauthorized access and the ability to seamlessly escalate privileges to administrative roles.

While a public Proof-of-Concept (PoC) exploit has been reported detailing how to forge these tokens, there are no confirmed reports of active exploitation in the wild or specific threat actor campaigns currently abusing the flaw. As of early March 2026, this vulnerability has not been added to CISA's Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not published a specific advisory regarding it.

Why Should TPRM Professionals Care About the pac4j Vulnerability?

The pac4j framework is a foundational building block for Java developers, utilized to implement authentication and authorization across countless enterprise web applications, customer portals, and internal APIs. Because it operates at the core of an application's identity management, a flaw in this library compromises the entire security architecture.

From a Third-Party Risk Management perspective, this authentication bypass represents a critical supply chain risk. If a vendor builds their SaaS platform or internal data dashboards using a vulnerable version of pac4j-jwt, the front door to their environment is left entirely unguarded. An attacker does not need to phish employees or guess passwords; they simply forge a token to log in as an administrator. Once inside, they have unfettered access to modify user accounts, alter application logic, or exfiltrate sensitive data shared by your organization. Ensuring that your vendors are utilizing secure authentication libraries and configuring them correctly is vital to preventing unauthorized access to your shared digital ecosystem.

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

To accurately assess your vendors' exposure to this critical authentication flaw, consider asking the following technical questions:

can you confirm if you have upgraded the `pac4j-core` library to version 5.7.2 or a subsequent secure version to mitigate the risk of CVE-2026-29000?
Have you implemented robust logging and monitoring to detect unusual authentication attempts, token validation failures, or unexpected privilege escalations that could indicate potential exploitation of CVE-2026-29000?
Have you ensured that the `setExpectedJti` method is correctly configured and used with the `JwtAuthenticator` to validate the `jti` claim in all processed JWTs, as recommended in the advisory for CVE-2026-29000?
Given the public proof-of-concept exploits reported for CVE-2026-29000, have you taken any additional measures to prevent the forgery of administrative JWT tokens and subsequent authentication bypass?

Remediation Recommendations for Vendors subject to this risk

Vendors relying on the affected pac4j libraries should execute the following technical remediations to secure their authentication pipelines:

Upgrade Dependencies Immediately: The primary and most effective remediation is to update the underlying pac4j-core library to version 5.7.2 or a subsequent secure release. This patched version contains the necessary fixes to handle JWT validation correctly.
Enforce setExpectedJti Configuration: Developers must explicitly ensure that the setExpectedJti method is configured and applied within the JwtAuthenticator. This step acts as a failsafe, guaranteeing that any JWT lacking a valid jti claim is immediately rejected by the application.
Implement Robust Monitoring: Security teams should enhance application logging to monitor specifically for unusual authentication patterns, rapid token validation failures, or unexpected privilege escalations that could signal an active exploitation attempt.

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

MongoDB - Mar2026 (CVE-2026-25611)

What is the MongoDB DoS Vulnerability?

CVE-2026-25611 is a High-severity Denial of Service (DoS) vulnerability impacting MongoDB servers. Carrying a CVSS score of 8.7 and an EPSS score of 0.05%, this flaw enables an unauthenticated attacker to crash an exposed database server with minimal effort.

Published in early March 2026, the issue originates within MongoDB's OP_COMPRESSED wire protocol compression mechanism. When a compressed message arrives, the server allocates memory based on an attacker-controlled uncompressedSize value before actually validating the decompressed payload's true size. An attacker exploits this by sending a tiny zlib-compressed packet (e.g., 47KB) that falsely claims a massive uncompressed size (e.g., 48MB). This creates an extreme memory amplification ratio of up to 1,027:1. By opening just a handful of concurrent connections and sending these malformed packets, the attacker rapidly exhausts the server's RAM. This triggers an Out-of-Memory (OOM) kernel kill, immediately crashing the mongod process. Tests show that an attacker can crash a 512MB server in roughly two seconds using only ten connections.

Currently, there are no public Proof-of-Concept (PoC) exploits available, and there are no reports of active exploitation in the wild or specific threat actor campaigns. As a result, the vulnerability has not been added to CISA's Known Exploited Vulnerabilities (KEV) Catalog, and no specific CISA advisory has been issued as of March 5, 2026.

Why Should TPRM Professionals Care About the MongoDB Vulnerability?

MongoDB is a foundational NoSQL database widely used by vendors to power critical web applications, store vast amounts of customer data, and maintain essential backend services. When evaluating supply chain risk, the availability of a vendor's primary database is just as critical as its confidentiality.

From a TPRM perspective, this vulnerability represents a severe threat to business continuity. Because the attack requires no authentication and minimal resources, a single bad actor can easily cause extensive downtime. If a critical third party relies on a vulnerable, internet-facing MongoDB or Atlas instance, a successful DoS attack will immediately break their application. This downtime cascades directly to your organization, leading to SLA breaches, disrupted services, and blocked access to the tools or data you rely on that vendor to provide.

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

To evaluate the resilience of your third-party partners against this DoS threat, ask the following specific technical questions:

Have you updated all instances of MongoDB to versions 8.2.4, 8.0.18, or 7.0.29 to mitigate the risk of CVE-2026-25611?
Have you implemented connection limits by configuring `maxIncomingConnections` to limit the number of concurrent connections a MongoDB server can accept, as recommended in the advisory?
Are you monitoring network and system logs for signs of a DoS attack, including high volumes of TCP connections to port 27017 from a single source, rapid connection establishment that remains idle, rapid MongoDB memory spikes, and OOM killer events targeting the `mongod` process?
Have you disabled compression entirely by configuring MongoDB with `--networkMessageCompressors=disabled` if an immediate upgrade was not possible?

Remediation Recommendations for Vendors subject to this risk

Vendors operating affected MongoDB instances should implement the following technical measures to restore stability and secure their database infrastructure:

Apply Official Security Updates Immediately: The most definitive fix is to update MongoDB deployments to versions 8.2.4, 8.0.18, or 7.0.29. These releases correct the memory allocation logic within the compression mechanism.
Disable Compression as a Workaround: If upgrading is not immediately feasible, administrators must disable compression entirely by configuring the database with --networkMessageCompressors=disabled.
Restrict Database Network Access: Implement strict firewalls to ensure MongoDB servers and Atlas clusters are never exposed to the public internet. Limit incoming connections to verified, trusted internal networks.
Implement Connection Limits and Monitoring: Set maxIncomingConnections to restrict the concurrent connections a server accepts, limiting the efficiency of a DoS attempt. Continuously monitor network traffic for rapid connection spikes to port 27017 and unexpected memory surges.

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

Django - Mar2026 (CVE-2026-25673, CVE-2026-25674)

What are the Django DoS and Race Condition Vulnerabilities?

On March 3, 2026, the Django Software Foundation released security patches addressing two vulnerabilities in the popular Python web framework: CVE-2026-25673 and CVE-2026-25674.

CVE-2026-25673 (High Severity, CVSS: 7.5, EPSS: 0.10%): This is a Denial of Service (DoS) and resource allocation vulnerability affecting the URLField.to_python() method. On Windows systems, urlsplit() performs NFKC normalization, which processes specific Unicode characters very slowly. An attacker can exploit this by submitting excessively large, crafted inputs to URL fields, forcing the server to consume massive CPU cycles and leading to a DoS condition.
CVE-2026-25674 (Low Severity, CVSS: 3.7, EPSS: 0.03%): This is a race condition resulting in improper access control and potential sensitive information exposure. In multi-threaded environments, Django previously relied on the process umask for file-system storage and cache backends. If one thread alters the temporary umask, it impacts file creation across all other threads simultaneously. This race condition can cause directories or files to be generated with unintended, overly permissive access rights.

Currently, there are no public Proof-of-Concept (PoC) exploits available, and researchers have not observed active exploitation in the wild or specific threat actor campaigns targeting these flaws. Consequently, these vulnerabilities have not been added to CISA's Known Exploited Vulnerabilities (KEV) Catalog, nor has CISA published a specific advisory for them as of early March 2026.

Why Should TPRM Professionals Care About the Django Vulnerabilities?

Django is a foundational web framework that powers everything from basic vendor portals to highly complex backend APIs and data management platforms. Because it sits at the core of a vendor's web infrastructure, vulnerabilities in Django directly threaten the availability and confidentiality of the services they provide.

From a TPRM perspective, the DoS vulnerability (CVE-2026-25673) represents a clear risk to business continuity. If a critical vendor's application goes offline because an attacker overwhelms their Windows-based servers, your organization could experience service outages, delayed deliverables, or broken integrations. Furthermore, the race condition flaw (CVE-2026-25674) poses a subtle but serious data privacy risk. If a vendor uses multi-threaded servers to handle sensitive media uploads or caches confidential application data, this bug could inadvertently expose those files to unauthorized local users or processes on the server. Ensuring your vendors patch these flaws protects the data you share with them and maintains the reliability of your supply chain.

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

To accurately gauge a vendor's exposure and response to these framework vulnerabilities, consider asking the following technical questions:

Have you updated all instances of Django to versions 6.0.3, 5.2.12, or 4.2.29 to mitigate the risk of CVE-2026-25673 and CVE-2026-25674?
Have you audited the permissions of existing media and cache directories to ensure no sensitive files were created with overly permissive access during the period of vulnerability?
Have you reviewed and updated any custom validation logic that relies on URLField.to_python() to strip control characters, in light of the changes made to address CVE-2026-25673?
In the context of CVE-2026-25674, have you implemented measures to monitor and control file and directory creation in multi-threaded environments to prevent unintended permissions?

Remediation Recommendations for Vendors subject to this risk

Vendors operating affected Django versions should apply the following technical remediation steps to secure their applications:

Immediate Framework Upgrade: The primary defense is to update the Django framework to versions 6.0.3, 5.2.12, or 4.2.29 immediately. These patches resolve the DoS vector on Windows and correct the umask handling logic for multi-threaded file creation.
Audit File Permissions: For deployments utilizing multi-threaded web servers, conduct a thorough audit of the permissions on all existing media storage and cache directories. Ensure no sensitive files were inadvertently assigned overly permissive read/write access during the vulnerable period.
Review Custom URL Validators: If your application relies on URLField.to_python() to strip control characters (such as tabs or newlines), update your custom validation logic, as the patched scheme detection no longer handles these automatically.
Windows Environment Monitoring: Organizations hosting Django on Windows environments should proactively monitor system metrics for abnormal CPU usage spikes that correlate with form submissions containing massive text blocks in URL fields.

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

Langflow (CVE-2026-27966)

What is the Langflow RCE Vulnerability?

CVE-2026-27966 is a Critical-severity Remote Code Execution (RCE) vulnerability impacting Langflow, a highly popular low-code platform used for building AI agents and data workflows. With a maximum CVSS score of 9.8 and an EPSS score of 0.41%, this flaw enables remote attackers to execute arbitrary Python code and operating system commands directly on the host server.

Disclosed in late February 2026, the root cause lies within the application's CSV Agent node. Specifically, the source code hardcodes the allow_dangerous_code: True parameter when initializing the LangChain CSV agent, which automatically activates the python_repl_ast tool. By crafting a malicious prompt and routing it through an exposed workflow (such as connecting ChatInput to the CSVAgent), an attacker can easily instruct the agent to utilize the Python REPL tool. Providing an action input like __import__("os").system("echo pwned > /tmp/pwned") forces the server to execute the command, granting the attacker full root or administrative control over the environment.

Public Proof-of-Concept (PoC) exploits are widely available, and recent security reports indicate that threat actors have begun exploring this prompt injection technique in real-world attacks. Despite these observations of active abuse, as of early March 2026, the vulnerability has not yet been officially added to CISA's Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not released a dedicated advisory for this specific flaw.

Why Should TPRM Professionals Care About the Langflow Vulnerability?

Langflow is increasingly utilized by vendors to integrate Large Language Models (LLMs) and automate complex business processes. Because these AI pipelines require deep integration with proprietary datasets, internal APIs, and core databases to function properly, they represent highly lucrative targets for cybercriminals.

For third-party risk managers, an unauthenticated RCE in an AI workflow tool introduces extreme supply chain peril. If a vendor's Langflow deployment is compromised, attackers can bypass traditional network perimeter defenses by simply "talking" to the exposed AI agent. Once a foothold is established, threat actors can manipulate automated workflows, exfiltrate confidential training data, or pivot laterally into the vendor's deeper internal network. Evaluating this specific exposure is vital because AI infrastructure is frequently deployed rapidly by data science teams, sometimes bypassing the stringent security hardening typically applied to traditional web applications.

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

To evaluate the security posture of your supply chain partners regarding this critical AI flaw, consider raising the following technical inquiries:

Can you confirm if you have updated all instances of Langflow to version 1.8.0 or later to mitigate the risk of CVE-2026-27966?
Have you reviewed existing Langflow projects for any use of the "CSV Agent" node and inspected logs for "Action: python_repl_ast" calls that do not align with standard data analysis tasks, specifically looking for import statements or os.system calls?
Have you restricted the ability to create or edit flows to trusted administrators only, as the vulnerability is triggered through the flow configuration and interaction?
If an immediate update was not possible, have you disabled or removed any flows containing the CSV Agent node and ensured the Langflow service is running in an isolated environment (e.g., a restricted Docker container) with minimal filesystem permissions to limit the "blast radius" of a potential breakout?

Remediation Recommendations for Vendors subject to this risk

Organizations running vulnerable Langflow deployments must execute the following technical mitigations to secure their AI environments:

Immediate Software Upgrade: The primary and most effective fix is updating Langflow to version 1.8.0 or newer. This release permanently removes the hardcoded allow_dangerous_code: True parameter from the CSV Agent node logic.
Audit Active Flows (IoC Hunting): Security personnel should thoroughly inspect all active projects utilizing the CSV Agent. Review system and application logs for anomalous python_repl_ast usage, specifically searching for unauthorized import statements or OS-level commands that do not align with standard data analysis.
Apply Temporary Mitigations: If patching cannot happen immediately, administrators must disable or delete any flows containing the CSV Agent node. Additionally, ensure the application runs in a tightly restricted container with minimal read/write filesystem permissions.
Restrict Access: Tightly limit the ability to create, edit, or publish workflows to a small group of authorized administrators, as the exploit relies heavily on flow interaction and node configuration.

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

RustFS (CVE-2026-27822)

What is the RustFS XSS Vulnerability?

CVE-2026-27822 is a Medium-severity Stored Cross-Site Scripting (XSS) vulnerability affecting the management console of RustFS, a distributed object storage system. Currently, it holds a CVSS score of 5.4 and an EPSS score of 0.03%.

Disclosed and published in late February 2026, this flaw exists due to improper validation of the response content type during the file preview process, combined with a lack of origin separation between the S3 object delivery and the management console. An attacker can upload a maliciously crafted file (such as a fake PDF) containing JavaScript. When a system administrator attempts to preview this file, the JavaScript executes within the context of the management console. Because the console stores highly sensitive credentials in the browser's localStorage, the script can silently steal the administrator's AccessKey, SecretKey, and Session Tokens, ultimately leading to a complete account takeover.

While researchers have published Proof-of-Concept (PoC) exploits demonstrating how to bypass the preview logic to steal credentials, there are currently no confirmed reports of active exploitation in the wild or specific threat actor campaigns. As of early March 2026, this vulnerability has not been added to CISA's Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not issued a specific advisory regarding it.

Why Should TPRM Professionals Care About the RustFS Vulnerability?

RustFS is utilized as an S3-compatible storage backend, meaning it is fundamentally designed to hold massive amounts of data. Organizations use these distributed storage systems to house mission-critical assets, including database backups, sensitive customer records, proprietary intellectual property, and application media.

From a Third-Party Risk Management perspective, a vulnerability that grants an attacker total administrative control over a vendor's storage environment is a worst-case scenario for data confidentiality and integrity. If a vendor's RustFS console is compromised via this XSS flaw, the attacker gains the highest level of access. They could silently exfiltrate terabytes of sensitive data shared by your organization, permanently delete crucial backups to facilitate a ransomware extortion scheme, or tamper with stored application files to distribute malware to end-users. Evaluating whether your vendors have secured their foundational storage infrastructure is essential to preventing catastrophic data breaches.

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

To accurately assess the risk within your supply chain, consider asking your vendors the following targeted, technical questions:

Can you confirm if you have upgraded all deployments of RustFS to version 1.0.0-alpha.83 or later to mitigate the risk of CVE-2026-27822?
Have you implemented origin separation by hosting the Management Console and S3 object endpoint on different domains as recommended to mitigate the risk of CVE-2026-27822?
Have you audited recently uploaded objects for suspicious Content-Type mismatches or embedded scripts as part of your remediation measures for CVE-2026-27822?
Have you enforced strict security headers, including Content-Security-Policy (CSP) and X-Content-Type-Options: nosniff, to prevent potential exploitation of the XSS vulnerability in RustFS?

Remediation Recommendations for Vendors subject to this risk

Vendors operating vulnerable RustFS deployments should immediately execute the following technical actions to secure their storage infrastructure:

Upgrade Immediately: Update all RustFS deployments to version 1.0.0-alpha.83 or later, which contains the official patch for the preview logic and content validation.
Implement Origin Separation: Host the Management Console and the S3 object endpoint on different domains to leverage the Same-Origin Policy (SOP) and isolate scripts.
Enforce Security Headers: Apply strict security headers on the backend, including a robust Content-Security-Policy(CSP) and X-Content-Type-Options: nosniff.
Restrict Upload Permissions: Limit S3 object upload capabilities strictly based on the principle of least privilege.
Audit for Suspicious Objects: Review recently uploaded objects for unexpected Content-Type mismatches or embedded scripts.
Rotate Credentials and Revoke Sessions: If any compromise is suspected, immediately rotate AccessKeys, SecretKeys, and Session Tokens, and revoke all active administrative sessions.
Avoid LocalStorage for Credentials: Where architecturally possible, avoid storing long-lived, sensitive credentials directly in the browser's localStorage.
Restrict Network Access: Consider limiting access to the RustFS Console strictly via a corporate VPN or dedicated IP allowlisting to shrink the administrative attack surface.

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

Apache Superset - Mar2026 (CVE-2026-23984, CVE-2026-23982, CVE-2026-23980)

What are the Apache Superset Vulnerabilities?

Disclosed in early March 2026, Apache Superset, a popular open-source data exploration and visualization platform, received critical patches addressing three distinct vulnerabilities related to improper input validation and authorization.

CVE-2026-23984 (High Severity, CVSS: 7.1, EPSS: 0.05%): This is an Improper Input Validation and SQL Injection vulnerability specific to PostgreSQL connections. Superset is designed to block Data Manipulation Language (DML) statements (like INSERT, UPDATE, DELETE) on read-only connections. However, an authenticated user with SQLLab access can embed these commands within specially crafted SQL statements, bypassing the read-only restrictions and performing unauthorized write operations.
CVE-2026-23982 (High Severity, CVSS: 7.1, EPSS: 0.04%): This Improper Authorization flaw allows a low-privileged attacker (with permissions to write datasets and read charts) to bypass data access controls entirely. By overwriting the SQL query of an existing dataset, the attacker bypasses the permission checks normally enforced during dataset creation, allowing them to query and extract data they are explicitly not authorized to view.
CVE-2026-23980 (Medium Severity, CVSS: 5.3, EPSS: 0.03%): This is an Error-Based SQL Injection vulnerability caused by the improper neutralization of special elements in the sqlExpression or where parameters. An authenticated user with basic read access can leverage this flaw to map the underlying database structure or extract sensitive data through manipulated SQL queries.

Currently, there are no public Proof-of-Concept (PoC) exploits available for these flaws, nor have researchers observed active exploitation in the wild. Consequently, as of early March 2026, none of these vulnerabilities are listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not issued a specific advisory regarding them.

Why Should TPRM Professionals Care About the Apache Superset Vulnerabilities?

Apache Superset is typically deployed as a centralized business intelligence (BI) hub, connecting directly to an organization's most critical and sensitive data warehouses (such as PostgreSQL, Snowflake, or BigQuery). It acts as the window into a vendor's core operational, financial, and customer data.

From a TPRM perspective, these vulnerabilities represent a severe breakdown of internal data governance and access control. If a vendor uses an unpatched version of Superset, an internal user or a compromised low-privileged account could bypass established boundaries. They could escalate privileges to alter critical database records (CVE-2026-23984) or access highly confidential datasets—such as your organization's PII or financial metrics—that were supposed to be segmented and protected (CVE-2026-23982). Because BI tools inherently have deep hooks into sensitive databases, ensuring your vendors maintain strict access controls and promptly apply patches to these platforms is essential to preventing data leakage and unauthorized data manipulation.

What questions should TPRM professionals ask vendors about the Apache Superset vulnerabilities?

To evaluate how your vendors are managing the risk to their business intelligence infrastructure, consider asking the following technical questions:

Have you updated all instances of Apache Superset to version 6.0.0 or later to mitigate the risk of CVE-2026-23984, CVE-2026-23982, and CVE-2026-23980?
Can you confirm if you have audited users with permissions to write datasets and ensured that the "Gamma" role or other low-privileged roles do not have unnecessary write access to shared or critical datasets?
Have you reviewed the use of sqlExpression and where parameters in custom charts and dashboards for signs of injection attempts, such as unexpected syntax or error-generating queries?
Are you monitoring PostgreSQL database logs for unexpected DML activity (INSERT, UPDATE, DELETE) originating from the Superset service account, especially on connections intended to be read-only?

Remediation Recommendations for Vendors subject to this risk

Vendors operating affected Apache Superset instances must take the following actions to secure their data exploration environments:

Immediate Software Upgrade: The primary and most critical action is to update all Apache Superset instances to version 6.0.0 or later. This release addresses the core logic flaws in validation, authorization checks, and parameter neutralization.
Audit SQLLab Activity: Security teams should proactively monitor backend database logs (especially PostgreSQL) for unauthorized INSERT, UPDATE, or DELETE commands that bypass Superset's intended read-only connection limits.
Review Dataset Permissions: Conduct a thorough audit of user roles and permissions. Verify that users with the ability to create or modify datasets adhere to the principle of least privilege, preventing unauthorized access to sensitive information.
Sanitize SQL Parameters: If an immediate upgrade is not feasible, implement strict review processes for the use of sqlExpression and where parameters within custom charts and dashboards to detect and block potential injection vectors.

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

How TPRM Professionals Can Leverage Black Kite for These Vulnerabilities

Managing third-party risk effectively requires the ability to instantly correlate global threat data with your specific vendor ecosystem. This week’s vulnerabilities span a wide array of critical infrastructure, from FreeScout help desks and MongoDB databases to Langflow AI workflows, RustFS storage, Django web frameworks, Apache Superset BI platforms, and pac4j authentication libraries.

Instead of relying on broad, manual questionnaires that cause vendor fatigue and delay critical insights, organizations can use Black Kite’s FocusTags® to apply a rapid, data-driven approach. Between March 2 and March 5, 2026, Black Kite published tags for all of these incidents: Langflow and Apache Superset - Mar2026, RustFS, Django - Mar2026, alongside Mail2Shell, MongoDB - Mar2026, and pac4j.

TPRM professionals can operationalize this intelligence by filtering their entire vendor portfolio using these specific tags. This instantly generates a prioritized list of third parties that are actually running the exposed software, allowing risk teams to focus their resources on the most urgent threats.

A massive differentiator of the Black Kite platform is the provision of precise, asset-level data. Rather than just flagging a vendor as potentially at risk, Black Kite identifies the exact IP addresses and subdomains where the vulnerable products are hosted. By providing this concrete evidence—whether it is an exposed RustFS console, a vulnerable Django application, an unpatched Langflow AI agent, or a misconfigured pac4j authentication implementation—TPRM teams can cut through generic survey responses. Supplying vendors with undeniable proof of their exposure initiates highly targeted conversations and drives a much faster, verifiable remediation process across the supply chain.

Strengthening TPRM Outcomes with Black Kite’s FocusTags®

Managing third-party risk effectively requires more than just tracking the latest vulnerability news; it demands the ability to instantly correlate global threat intelligence with your specific vendor ecosystem. When facing a diverse array of threats—ranging from AI workflow exploits in Langflow and database DoS attacks in MongoDB to severe access bypasses in Apache Superset, FreeScout, and pac4j authentication libraries—Black Kite’s FocusTags® provide the exact precision TPRM teams need.

These tags transform complex technical advisories into actionable supply chain defense mechanisms by delivering:

Immediate Exposure Identification: Instantly pinpoint which vendors in your portfolio are running the specific affected versions of Django, RustFS, pac4j, or other critical systems, eliminating the delay of manual vendor surveying.
Actionable Asset Intelligence: Go beyond generic risk scores by accessing the exact IP addresses and subdomains where vulnerable instances are hosted, allowing for concrete, evidence-based remediation discussions.
Precision-Driven Prioritization: Filter and rank vendor risk based on the severity of the flaw and the criticality of the vendor, ensuring your team tackles high-impact threats like the FreeScout RCE, pac4j authentication bypass, or Langflow exploit first.
Streamlined Vendor Collaboration: Replace tedious, repetitive questionnaires with highly targeted, technical inquiries that drive faster, verifiable patching and configuration changes across your supply chain.

By integrating Black Kite’s FocusTags® into your daily operations, your TPRM program shifts from a reactive compliance exercise to a proactive, intelligence-led defense, securing your organization against the rapidly shifting cyber threat landscape.

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:

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.
BeyondTrust RA & PRA : CVE-2026-1731, Remote Code Execution (RCE) vulnerability in BeyondTrust RA & PRA.
Zimbra - Feb2026 : CVE-2020-7796, Critical Server-Side Request Forgery (SSRF) vulnerability in the Zimbra’s WebEx Zimlet.
PostgreSQL - Feb2026 : CVE-2026-2004, CVE-2026-2005, CVE-2026-2006, Arbitrary Code Execution and Buffer Overflows Vulnerabilities in PostgreSQL.
Exchange Server - Feb2026 : CVE-2026-21527, Spoofing vulnerability in Microsoft Exchange Server involving UI misrepresentation.
SAP NetWeaver - Feb2026 : CVE-2026-0509, Critical Missing Authorization vulnerability in SAP NetWeaver AS ABAP allowing unauthorized RFC execution.
Gogs - Feb2026 : CVE-2025-64111, CVE-2025-64175, CVE-2026-24135, Triple threat involving Critical RCE, 2FA Bypass, and Path Traversal in Gogs Git services.
OpenClaw : CVE-2026-25253, Critical 1-Click Remote Code Execution and Token Exfiltration Vulnerability in OpenClaw (Moltbot).
Ivanti EPMM - Jan2026 : CVE-2026-1281, CVE-2026-1340, Critical Unauthenticated Remote Code Execution and Code Injection Vulnerabilities in Ivanti Endpoint Manager Mobile.
Cisco TelePresence : CVE-2026-20119, High-Severity Denial of Service Vulnerability in Cisco TelePresence Collaboration Endpoint (CE) Software.
Django - Feb2026 : CVE-2026-1207, CVE-2026-1287, CVE-2026-1312, CVE-2025-14550, CVE-2026-1285, CVE-2025-13473, Multiple SQL Injection, Denial of Service (DoS), and Username Enumeration Vulnerabilities in Django Web Framework.
n8n - Feb2026 : CVE-2026-25049, CVE-2026-25056, CVE-2026-25053, Triple Threat of Critical Remote Code Execution Vulnerabilities in n8n Workflow Automation Platform.