blog

FOCUS FRIDAY: TPRM Insights on SonicWall SMA1000, FortiGate SSL-VPN, n8n, Exim Mail, Zimbra, MongoDB, M-Files, Elastic Kibana, and FreeBSD Vulnerabilities

Published

Dec 26, 2025

Updated

Dec 26, 2025

Introduction

As we approach the end of the year, this edition of Focus Friday offers an opportunity to reflect on a period marked by an unusually high volume of critical vulnerabilities and impactful security incidents. Over the past year, Third-Party Risk Management (TPRM) teams have faced sustained pressure as zero-day vulnerabilities, actively exploited flaws, and large-scale data exposures continued to emerge across a wide range of technologies. Heading into the new year, maintaining visibility into vendor risk and strengthening response readiness remains a top priority for organizations aiming to stay secure in an increasingly complex threat landscape.

This week’s Focus Friday examines a diverse set of high-impact vulnerabilities affecting technologies that underpin vendor operations, ranging from secure remote access gateways and workflow automation platforms to email servers, databases, analytics tools, and operating systems. Several of these issues involve perimeter-facing systems and authentication controls, where exploitation can result in immediate unauthorized access rather than gradual compromise. While these vulnerabilities vary in exploitability and scope, they share a common challenge for TPRM teams: identifying which vendors are genuinely exposed and determining where response efforts should be focused.

In this edition, we analyze vulnerabilities affecting SonicWall SMA1000, FortiGate SSL-VPN, n8n, Exim Mail, Zimbra, MongoDB, M-Files Server, Elastic Kibana, and FreeBSD through a TPRM lens. Rather than viewing each issue as a standalone technical flaw, this blog highlights how such weaknesses can translate into tangible third-party risk, including unauthorized access, data exposure, operational disruption, and erosion of trust. By pairing technical context with risk-focused insights, this Focus Friday aims to help TPRM professionals close out the year with clarity—and enter the next one better equipped to make timely, confident decisions in response to emerging threats across their vendor ecosystem.

Filtered view of companies with SonicWall SMA1000 FocusTag™ on the Black Kite platform.

CVE-2025-40602 & CVE-2025-23006 (SonicWall SMA1000 Vulnerabilities)

What are the SonicWall SMA1000 vulnerabilities?

The SonicWall SMA1000 FocusTag^TM centers on two linked security flaws in the SonicWall Secure Mobile Access (SMA) 1000 series remote access appliances:

CVE-2025-40602 – A local privilege escalation vulnerability in the Appliance Management Console (AMC) caused by insufficient authorization controls. On its own, this vulnerability has a CVSS score of 6.6 and an EPSS score of 1.42%, indicating a measurable likelihood of real-world exploitation.
CVE-2025-23006 – A critical pre-authentication deserialization of untrusted data vulnerability that allows attackers to execute arbitrary operating system commands without authentication. This vulnerability carries a CVSS score of 9.8 and a notably high EPSS score of 56.66%, reflecting strong exploitation signals.

Individually, these vulnerabilities pose serious risk. When chained together, they enable unauthenticated remote code execution with root privileges, allowing attackers to fully compromise affected SMA1000 appliances without valid credentials.

Discovery and disclosure timeline:
CVE-2025-23006 was disclosed and confirmed as actively exploited in early 2025. CVE-2025-40602 was disclosed later and identified as a privilege escalation flaw that significantly amplifies the impact of the original issue when used in combination.
Exploitation status:
Both vulnerabilities have been observed in active exploitation scenarios, with public proof-of-concept exploits reported. The exploitation chain has been confirmed to work against internet-exposed SMA1000 appliances.
CISA KEV inclusion:
CVE-2025-23006 was added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog on January 24, 2025.
CVE-2025-40602 was added to the KEV Catalog on December 17, 2025.

The presence of both vulnerabilities in the KEV Catalog confirms that exploitation is not theoretical and represents an ongoing operational threat.

Why should TPRM professionals care about these vulnerabilities?

These vulnerabilities affect secure remote access infrastructure, a critical component in many vendor environments:

Gateway compromise risk: SonicWall SMA1000 appliances are commonly deployed as externally accessible gateways for VPN and remote access. A successful compromise provides attackers with a foothold directly into internal networks.
Impact amplification through chaining: While CVE-2025-40602 is classified as medium severity in isolation, its ability to escalate privileges turns CVE-2025-23006 into a full system takeover vector, resulting in root-level access.
Downstream risk to customers: A compromised remote access appliance can be leveraged to intercept credentials, pivot laterally, access sensitive internal systems, and potentially impact customer data or service availability.

From a TPRM perspective, vendors operating affected SMA1000 appliances may unintentionally expose customer environments to unauthorized access, data compromise, or service disruption, making this vulnerability chain highly relevant in third-party risk evaluations.

What questions should TPRM professionals ask vendors about these vulnerabilities?

To assess vendor exposure and response maturity, TPRM professionals should consider asking:

Have you updated your SonicWall SMA1000 series firmware to the patched versions (12.4.3-03245 or 12.5.0-02283) to mitigate the risk of CVE-2025-40602 and CVE-2025-23006?
Can you confirm if you have implemented the recommended workarounds, such as restricting access to the management interface and disabling the SSL VPN management interface (AMC) and SSH access from the public internet, if immediate patching was not possible?
Have you reviewed your network segmentation and access controls around SMA1000 appliances to limit potential lateral movement in case of compromise, as suggested by SonicWall?
Are you actively monitoring network traffic and system logs for any signs of exploitation, unauthorized access attempts, or unusual activity on SMA1000 devices and connected networks, as recommended by SonicWall?

These questions are intended to confirm both technical exposure and the vendor’s ability to detect and respond to exploitation attempts.

Remediation recommendations for vendors subject to this risk

Vendors operating SonicWall SMA1000 appliances should take the following actions:

Apply official security updates immediately:
Upgrade affected appliances to the patched platform-hotfix builds 12.4.3-03245 or 12.5.0-02283, depending on the deployed firmware branch.
Break the exploit chain:
Ensure both vulnerabilities are fully remediated, as patching only one issue does not eliminate the overall risk.
Restrict management access:
If immediate patching is not possible, disable public access to the Appliance Management Console (AMC) and restrict management access to trusted internal networks or VPN connections only.
Harden network segmentation:
Limit the ability of compromised appliances to move laterally by enforcing strict segmentation and access controls.
Increase monitoring and logging:
Review authentication logs, command execution events, and system behavior for indicators of compromise related to these vulnerabilities.

Black Kite’s SonicWall SMA1000 FocusTags™ details critical insights on the event for TPRM professionals.

CVE-2020-12812 (FortiGate SSL-VPN - Dec2025)

What is the FortiGate SSL-VPN 2FA Bypass Vulnerability?

CVE-2020-12812 is a critical improper authentication vulnerability affecting Fortinet FortiGate SSL-VPN deployments. The issue arises from a mismatch in username case-sensitivity handling between FortiGate appliances and LDAP directories. While FortiGate treats usernames as case-sensitive by default, most LDAP implementations treat them as case-insensitive.

Under specific but common configurations, this discrepancy allows an attacker to bypass two-factor authentication (2FA) entirely by authenticating with a case-altered version of a valid username (for example, “JSmith” instead of “jsmith”). When FortiGate fails to match the username to the local 2FA-protected account, it may fall back to LDAP group authentication without enforcing 2FA.

The vulnerability is classified as critical, with a CVSS score of 9.8 and an EPSS score of 45.02%, indicating a significant likelihood of real-world exploitation. CVE-2020-12812 was originally disclosed in 2020, but Fortinet has confirmed active exploitation in the wild, including renewed abuse observed in late 2025. Public proof-of-concept exploits are available.

CVE-2020-12812 was added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog on November 3, 2021, confirming that exploitation is not theoretical and represents a sustained operational risk. No recent standalone CISA advisory has been issued beyond KEV inclusion.

The vulnerability has been actively exploited in the wild by threat actors including LAPSUS, APT35, and Cobalt, and has been associated with the deployment of malware families such as Cring, PLAY, and Hive variants targeting both Windows and Linux environments.

Why should TPRM professionals care about this vulnerability?

FortiGate appliances are frequently deployed as internet-facing secure access gateways, providing SSL-VPN connectivity and administrative access to vendor environments. A successful 2FA bypass undermines a core security control relied upon to protect remote access.

From a TPRM perspective, this vulnerability introduces several material risks:

Unauthorized network access: Attackers with valid credentials can access VPN or administrative interfaces without 2FA, gaining direct entry into internal networks.
Control plane exposure: FortiGate devices often sit at the network perimeter. Compromise can enable lateral movement, traffic inspection, or policy manipulation.
Persistent third-party risk: Although the CVE is several years old, continued exploitation indicates that legacy configurations and incomplete mitigations remain common across vendor environments.

Vendors affected by this issue may unintentionally expose customer systems, sensitive data, or service availability due to weakened authentication controls on a critical access layer.

What questions should TPRM professionals ask vendors about this vulnerability?

To assess exposure and response maturity, TPRM professionals may consider asking:

Have you updated all instances of FortiGate appliances to FortiOS versions 6.0.10, 6.2.4, 6.4.1, or later versions (e.g., 6.0.13, 6.2.10, 6.4.7, 7.0.1 and above) to mitigate the risk of CVE-2020-12812?
Have you implemented the recommended mitigation measures such as setting 'username-case-sensitivity disable' or 'username-sensitivity disable' on all local accounts to prevent the bypass of 2FA?
Have you reviewed and removed any unnecessary secondary LDAP Groups that could be used as fallback authentication methods, especially in light of the CVE-2020-12812 vulnerability?
Are you monitoring authentication logs for case variations in usernames or unexpected authentication paths, as recommended in the advisory, to detect potential exploitation attempts related to CVE-2020-12812?

Remediation recommendations for vendors subject to this risk

Vendors operating FortiGate SSL-VPN infrastructure should take the following actions:

Apply official FortiOS updates: Upgrade to supported FortiOS versions that introduce and enforce username sensitivity controls.
Enforce username case-insensitivity: Configure set username-sensitivity disable (or equivalent) to ensure consistent username matching across local and LDAP authentication.
Review LDAP group usage: Remove unnecessary or overlapping LDAP groups used for authentication, especially those that may act as fallback mechanisms.
Reset credentials if compromise is suspected: Treat affected systems as potentially compromised and rotate all relevant credentials, including LDAP and administrative accounts.
Strengthen monitoring: Log and alert on anomalous authentication behavior, including repeated case-variant login attempts or unexpected group-based authentication success.

Black Kite’s FortiGate SSL-VPN - Dec2025 FocusTagTM details critical insights on the event for TPRM professionals.

CVE-2025-68613 (n8n Remote Code Execution Vulnerability)

What is the n8n Remote Code Execution vulnerability?

CVE-2025-68613 is a critical remote code execution (RCE) vulnerability affecting the n8n workflow automation platform, a tool commonly used to orchestrate integrations, data flows, and automated business processes.

Vulnerability type: Remote Code Execution due to improper isolation of user-supplied expressions
Severity: Critical
CVSS score: 10.0
EPSS score: 0.22%

The vulnerability originates from insufficient sandboxing of expressions defined by authenticated users during workflow creation or modification. These expressions are evaluated in a context that is not properly isolated from the underlying runtime. As a result, an authenticated attacker can craft malicious expressions that are executed with the same privileges as the n8n process itself.

CVE-2025-68613 was publicly disclosed in December 2025, making it a recent issue at the time of publication. Public proof-of-concept exploits have been released, demonstrating reliable exploitation paths. However, based on currently available information, there is no confirmed evidence of active exploitation in the wild, and the vulnerability has not been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog. CISA has not published a specific advisory related to this CVE.

Despite the absence of confirmed exploitation campaigns, the technical impact remains severe due to the level of access granted upon successful exploitation.

Why should TPRM professionals care about this vulnerability?

n8n is often deployed as a central automation and integration layer, connecting internal systems, cloud services, APIs, and sensitive data sources. From a third-party risk management perspective, this role significantly amplifies the impact of a compromise:

Automation abuse risk: An attacker who gains code execution can modify or create workflows that exfiltrate data, alter business logic, or trigger unauthorized downstream actions.
Data exposure: n8n instances frequently handle credentials, API tokens, and sensitive operational data, all of which may be accessible once the platform is compromised.
Privilege concentration: Because the vulnerability executes code with the privileges of the n8n process, the blast radius depends heavily on how the service is deployed and isolated within the vendor’s environment.

For TPRM professionals, a vendor operating a vulnerable n8n instance may unintentionally expose internal systems or customer-related workflows, even if n8n is not customer-facing. This makes the vulnerability particularly relevant when assessing vendors that rely on automation platforms to support core business operations.

What questions should TPRM professionals ask vendors about this vulnerability?

To assess exposure and mitigation status, TPRM professionals may consider asking vendors:

Can you confirm if you have upgraded all instances of n8n to version 1.120.4, 1.121.1, or 1.122.0 to mitigate the risk of CVE-2025-68613?
Have you implemented runtime container hardening measures such as AppArmor or Seccomp to restrict the n8n process's ability to execute system calls that are not required for normal operation?
Post-patching, have you audited all active workflows for suspicious JavaScript expressions and rotated all credentials/API keys stored within n8n?
If immediate patching was not feasible, did you restrict workflow creation and editing permissions within n8n to only trusted users to minimize the attack surface?

These questions help determine both technical exposure and whether access controls meaningfully reduce exploitation risk.

Remediation recommendations for vendors subject to this risk

Vendors operating n8n should take the following actions to reduce risk:

Apply official patches immediately:
Upgrade to one of the fixed versions (1.120.4, 1.121.1, 1.122.0, or later) to fully remediate the vulnerability.
Restrict workflow authoring permissions:
Limit workflow creation and editing capabilities to a minimal set of trusted users to reduce the likelihood of malicious expression abuse.
Harden the runtime environment:
Run n8n with restricted operating system privileges, avoid running it as a highly privileged user, and enforce least-privilege access to the host system.
Constrain network access:
Limit inbound and outbound network connectivity for the n8n instance to only required services, reducing post-exploitation impact.

Black Kite’s n8n FocusTags™ details critical insights on the event for TPRM professionals.

CVE-2025-26794 & CVE-2025-67896 (Exim Mail Vulnerabilities)

What are the Exim Mail vulnerabilities?

The Exim Mail FocusTag^TM covers a critical vulnerability chain involving a SQL Injection flaw and a heap buffer overflow, both affecting specific Exim configurations that use SQLite-based rate limiting.

CVE-2025-26794
- Type: SQL Injection
- Severity: Critical
- CVSS score: 9.8
- EPSS score: 72.09%
This vulnerability exists in the xtextencode() function, which is intended to sanitize database keys. The function fails to properly escape single quote characters, allowing attacker-controlled input to be injected into the SQLite hints db. Exploitation is possible through Ratelimit Access Control Lists (ACLs) that rely on attacker-controlled values, such as the email sender address. The issue represents an incomplete fix of a previously identified weakness and has been successfully demonstrated as part of a chained exploit.
CVE-2025-67896
- Type: Remote heap corruption (heap buffer overflow)
- Severity: Critical
- CVSS score: 9.8
- EPSS score: 0.06%
This vulnerability occurs when Exim processes the bloom_size field from database records without sufficient validation. By abusing the SQL injection flaw, an attacker can inject a crafted database record containing a maliciously large bloom_size value. When Exim processes this record, it writes far beyond the allocated heap buffer, resulting in memory corruption. Demonstrations confirmed overwrites of up to 1.5 MB of heap memory. While full remote code execution was not achieved due to modern mitigations such as ASLR, a reliable crash condition was demonstrated, and further exploitation may be feasible.

Both vulnerabilities were publicly disclosed in December 2025, making them recently published issues. Public proof-of-concept exploits are available. At the time of writing, neither CVE has been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, and there is no indication that CISA has issued a standalone advisory for this vulnerability chain. Exploitation has been demonstrated in controlled scenarios, but there is no confirmed evidence of active exploitation campaigns in the wild.

Why should TPRM professionals care about these vulnerabilities?

Exim is a widely deployed Mail Transfer Agent (MTA) and often serves as a core component of email infrastructure for vendors, service providers, and managed hosting environments. From a TPRM perspective, these vulnerabilities raise several concerns:

Email infrastructure compromise: A successful exploit could allow attackers to crash mail servers, disrupt email delivery, or potentially gain deeper control over the system hosting Exim.
Chained attack risk: The combination of SQL injection and heap corruption significantly increases impact compared to either issue in isolation, particularly in environments using SQLite-backed ratelimits.
Trust and abuse implications: A compromised mail server can be abused to send fraudulent emails, impersonate the vendor, bypass email-based security controls, or access sensitive message content.

For TPRM professionals, vendors operating vulnerable Exim configurations may pose a heightened risk to business communications, data confidentiality, and operational continuity, even if email services are considered internal-only.

What questions should TPRM professionals ask vendors about these vulnerabilities?

To assess exposure and configuration risk, TPRM professionals may ask vendors:

Have you upgraded all instances of Exim to the latest version to mitigate the risk of SQL Injection (CVE-2025-26794) and Heap Buffer Overflow (CVE-2025-67896)?
Have you implemented strict validation checks for database records, especially fields like `bloom_size`, to prevent the exploitation of memory corruption vulnerabilities in Exim?
Can you confirm if you have discontinued the use of Exim versions 4.98, 4.98.1, and 4.99 with SQLite integrations that are vulnerable to the SQL Injection (CVE-2025-26794) and Heap Buffer Overflow (CVE-2025-67896)?
Have you reviewed your Exim configurations, specifically those involving ratelimits, to ensure that they do not rely on attacker-controlled data (like `$sender_address`) as keys, especially if SQLite support is enabled?

Remediation recommendations for vendors subject to this risk

Vendors using Exim should take the following steps to mitigate risk:

Upgrade Exim immediately:
Systems running Exim versions 4.98, 4.98.1, or 4.99 with SQLite integrations should be upgraded to the latest patched release to address both vulnerabilities.
Review ratelimit configurations:
Ensure ratelimits do not rely on attacker-controlled values such as $sender_address. Default configurations that rely on client IP addresses are not vulnerable.
Address SQL injection root cause:
Fix or avoid the flawed string escaping behavior in xtextencode() by correcting escaping logic or adopting parameterized query mechanisms where possible.
Harden database record handling:
Enforce strict validation on database fields such as bloom_size to prevent memory corruption conditions.
Increase operational monitoring:
Monitor for repeated crashes, abnormal memory behavior, or unexpected mail processing failures that could indicate exploitation attempts.

Black Kite’s Exim Mail - Dec2025 FocusTags™ details critical insights on the event for TPRM professionals.

CVE-2025-68645 & CVE-2025-67809 (Zimbra Collaboration Suite Vulnerabilities)

What are the Zimbra Collaboration Suite vulnerabilities?

The Zimbra – Dec2025 Focus Tag addresses two distinct vulnerabilities affecting the Zimbra Collaboration Suite, combining an unauthenticated Local File Inclusion (LFI) flaw with a hardcoded credentials exposure in a bundled integration component.

CVE-2025-68645
- Type: Local File Inclusion (LFI)
- Severity: High
- CVSS score: 8.8
- EPSS score: 0.08%
CVE-2025-68645 resides in the Webmail Classic UI, specifically within the RestFilter servlet handling requests to the /h/rest endpoint. Due to improper input sanitization, an unauthenticated remote attacker can manipulate internal request dispatching and force the server to include arbitrary files from the WebRoot directory. This can lead to the disclosure of internal application files and configuration data. The vulnerability was publicly disclosed in December 2025, placing it among recently published issues.
CVE-2025-67809
- Type: Hardcoded credentials exposure
- Severity: Medium
- CVSS score: 4.7
- EPSS score: 0.03%
CVE-2025-67809 affects the Flickr Zimlet, where an API key and secret were embedded directly in the code. These credentials were publicly accessible and could be reused by unauthorized parties to impersonate the Zimbra application during OAuth authorization flows. While exploitation requires user interaction, a successful attack could result in unauthorized access to private Flickr data. The vendor has since revoked the exposed credentials and removed them from the codebase.

Public proof-of-concept exploits have been reported for these issues. At the time of publication, neither CVE has been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not issued a dedicated advisoryrelated to these vulnerabilities.

Why should TPRM professionals care about these vulnerabilities?

Zimbra Collaboration Suite functions as a core enterprise email and collaboration platform, often handling sensitive communications, attachments, calendars, and contact data. From a TPRM perspective, these vulnerabilities introduce several material risks:

Unauthenticated data exposure: The LFI vulnerability can allow external attackers to access internal files without credentials, increasing the likelihood of reconnaissance, configuration leakage, or follow-on attacks.
Trust and identity risks: Hardcoded credentials in bundled integrations create downstream identity risks, particularly when third-party services are involved in authentication flows.
Email platform abuse: Compromise or partial visibility into a mail server environment can enable phishing, impersonation, or unauthorized access to sensitive communications.

For TPRM professionals, vendors operating vulnerable Zimbra deployments may present elevated confidentiality and integrity risks, especially if email services are internet-facing or used to support customer communications.

What questions should TPRM professionals ask vendors about these vulnerabilities?

To assess exposure and remediation maturity, TPRM professionals may consider asking:

Have you updated all instances of Zimbra Collaboration Suite to versions 10.1.13 or 10.0.18 to mitigate the risk of CVE-2025-68645 and CVE-2025-67809?
Can you confirm if the Webmail Classic interface of your Zimbra Collaboration Suite, which is the attack vector for the LFI vulnerability, is exposed to the internet? If so, what additional security controls have you implemented to restrict access?
Have you observed any unusual access patterns, attempts to read internal files, or unauthorized activities in your Zimbra server logs that could indicate exploitation or reconnaissance attempts related to CVE-2025-68645 and CVE-2025-67809?
Can you confirm that the hardcoded Flickr API key and secret in the Flickr Zimlet have been removed from the codebase to mitigate the risk of CVE-2025-67809?

Remediation recommendations for vendors subject to this risk

Vendors operating Zimbra Collaboration Suite should take the following actions:

Apply official security updates immediately:
Upgrade to Zimbra Collaboration 10.1.13 or 10.0.18, which address both the LFI and hardcoded credential issues.
Prioritize remediation of the LFI flaw:
Given its unauthenticated nature, CVE-2025-68645 should be treated as the highest priority to reduce the risk of reconnaissance or data leakage.
Review Webmail Classic exposure:
Assess whether the Classic UI is required and publicly accessible. Restrict access or apply additional controls where possible.
Audit integrations and secrets:
Ensure no hardcoded credentials remain in deployed Zimlets or custom extensions, and rotate any secrets that may have been exposed historically.
Increase monitoring:
Monitor server logs for abnormal file access patterns, REST endpoint misuse, or other indicators of probing activity.

Black Kite’s Zimbra - Dec2025 FocusTags™ details critical insights on the event for TPRM professionals.

CVE-2025-14847 (MongoDB Server Vulnerability)

What is the MongoDB Server vulnerability?

CVE-2025-14847 is a high-severity, unauthenticated information disclosure vulnerability affecting multiple supported and legacy versions of MongoDB Server.

Vulnerability type: Out-of-bounds read leading to memory leak and information disclosure
Severity: High
CVSS score: 8.7
EPSS score: 0.03%

The vulnerability resides in MongoDB Server’s zlib compression handling logic. By manipulating client-side compression behavior, an attacker can cause the server to return uninitialized heap memory as part of its response. This memory may contain sensitive artifacts such as recently processed queries, internal data structures, or residual credential material present in server RAM.

A key aspect of CVE-2025-14847 is that it is unauthenticated. An attacker does not need valid MongoDB credentials to exploit the flaw; network-level access to the MongoDB service port is sufficient. The issue was publicly disclosed in December 2025, making it a newly published vulnerability at the time of this FocusTag^TM.

There is no public proof-of-concept exploit currently available, and no confirmed reports of exploitation in the wild. The vulnerability has not been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not published a dedicated advisory related to this issue.

Why should TPRM professionals care about this vulnerability?

MongoDB is widely used as a backend data store for customer data, application state, and operational workloads. From a third-party risk management perspective, this vulnerability introduces several material concerns:

Unauthenticated exposure risk: If MongoDB instances are reachable from untrusted networks, attackers may extract sensitive data without needing credentials.
Confidentiality impact: Even partial memory disclosure can expose internal queries, metadata, or credentials that facilitate further compromise.
Cloud and managed service implications: MongoDB is frequently deployed in cloud environments where misconfigurations can unintentionally expose database ports beyond intended boundaries.

For TPRM professionals, a vendor running vulnerable MongoDB versions with network exposure may pose a silent but serious data leakage risk. This is especially relevant for vendors handling regulated data, customer records, or proprietary business information.

What questions should TPRM professionals ask vendors about this vulnerability?

To assess real-world exposure, TPRM professionals may consider asking:

Have you upgraded all instances of MongoDB Server to the versions 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30 to mitigate the risk of CVE-2025-14847?
If you have not been able to upgrade immediately, have you disabled zlib compression on the MongoDB Server by starting mongod or mongos with a networkMessageCompressors or a net.compression.compressors option that explicitly omits zlib?
Have you implemented strict firewall rules and network segmentation to limit access to only trusted clients and applications, given the unauthenticated nature of the vulnerability?
Are you continuously monitoring network traffic and MongoDB logs for any unusual connection attempts or signs of information disclosure, especially if zlib compression cannot be immediately disabled or patches applied?

Remediation recommendations for vendors subject to this risk

Vendors operating MongoDB Server should take the following actions:

Upgrade MongoDB Server immediately:
Affected deployments should be upgraded to patched versions, including 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30, depending on the branch in use.
Apply the temporary workaround if needed:
If immediate patching is not feasible, disable zlib compression by explicitly configuring net.compression.compressors to exclude zlib, using alternatives such as snappy or zstd if compression is required.
Restrict network access:
Ensure MongoDB service ports are accessible only from trusted application networks. Enforce firewall rules and segmentation to prevent direct access from untrusted sources.
Increase visibility and logging:
Monitor for unusual connection patterns or unexpected response behavior that could indicate attempted exploitation of compression handling.

Black Kite’s MongoDB - Dec2025 FocusTags™ details critical insights on the event for TPRM professionals.

CVE-2025-13008 & CVE-2025-14267 (M-Files Server Vulnerabilities)

What are the M-Files Server vulnerabilities?

The M-Files Server FocusTag^TM addresses two distinct information disclosure–related vulnerabilities that affect document management environments where sensitive corporate and personal data is routinely stored.

CVE-2025-13008
- Type: Session token disclosure leading to session hijacking
- Severity: High
- CVSS score: 8.6
- EPSS score: 0.04%
CVE-2025-13008 impacts the M-Files Web interface and allows an authenticated attacker to obtain active session tokens belonging to other users. With a stolen session token, an attacker can impersonate the victim without re-authentication, operate under their identity, access document vaults, and view or modify confidential content. Because the attacker leverages a valid session, activity may bypass standard access logging, complicating detection and forensic analysis. This vulnerability was publicly disclosed in December 2025.
CVE-2025-14267
- Type: Improper removal of sensitive information before storage or transfer
- Severity: Medium
- CVSS score: 5.6
- EPSS score: 0.04%
CVE-2025-14267 occurs during the vault copy process when administrators use the “metadata structure only” option. Due to insufficient cleanup of temporary cache data, information from the source vault may unintentionally appear in the copied vault. This leaked data can include file names, usernames, comments, or other metadata that may reveal sensitive or regulated information. This issue was also disclosed in December 2025.

At the time of writing, no public proof-of-concept exploits have been reported for either vulnerability, and neither CVE has been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog. There are no publicly issued CISA advisories associated with these vulnerabilities.

Why should TPRM professionals care about these vulnerabilities?

M-Files Server is commonly used as a centralized document and records management platform, often holding contracts, financial records, intellectual property, and personal data. From a TPRM perspective, these vulnerabilities present meaningful risks:

Identity misuse risk: Session hijacking enables attackers to act as legitimate users, potentially accessing or altering sensitive documents without triggering typical security alerts.
Insider threat amplification: CVE-2025-13008 can be abused by malicious insiders or compromised internal accounts, increasing the impact of credential misuse scenarios.
Data leakage through administrative workflows: CVE-2025-14267 highlights that even routine administrative actions, such as vault duplication, can unintentionally expose sensitive metadata if not properly controlled.

For TPRM professionals, vendors relying on M-Files to manage sensitive documentation may face confidentiality and compliance risks if these vulnerabilities remain unaddressed, particularly in environments subject to regulatory or contractual data protection obligations.

What questions should TPRM professionals ask vendors about these vulnerabilities?

To evaluate exposure and control maturity, TPRM professionals may ask vendors:

Have you upgraded all instances of M-Files Server to version 25.12.15491.7 or later to mitigate the risk of CVE-2025-13008 and CVE-2025-14267?
Can you confirm if you have implemented measures to continuously monitor M-Files server logs for any unusual user activity, unauthorized access attempts, or signs of session hijacking, especially as successful exploitation of CVE-2025-13008 can bypass standard access logs?
Have you reviewed and enforced the principle of least privilege for all M-Files users to minimize the potential impact of session hijacking, as CVE-2025-13008 requires an authenticated attacker?
Can you confirm if you have reviewed vault copy procedures to be aware of the risks associated with creating copies of document vaults using the "metadata structure only" option, and ensure that sensitive data is not inadvertently disclosed through cached information as per the vulnerability CVE-2025-14267?

Remediation recommendations for vendors subject to this risk

Vendors using M-Files Server should consider the following remediation steps:

Upgrade M-Files Server immediately:
Deploy version 25.12.15491.7 or newer to remediate both vulnerabilities. Long-term support branches should be updated to their latest secure service releases.
Apply least-privilege principles:
Limit user permissions to only what is necessary, reducing the potential damage if a session token is compromised.
Review vault copy practices:
Exercise caution when using the “metadata structure only” option and validate that no residual data is transferred during vault duplication.
Increase monitoring and review:
Monitor for anomalous user behavior, unusual access patterns, or unexpected vault interactions that may indicate session hijacking or misuse.

Black Kite’s M-Files Server FocusTags™ details critical insights on the event for TPRM professionals.

CVE-2025-68385 (Elastic Kibana Vulnerability)

What is the Elastic Kibana XSS vulnerability?

CVE-2025-68385 is a high-severity Cross-Site Scripting (XSS) vulnerability affecting Elastic Kibana, specifically within the Vega visualization framework used to create advanced dashboards and charts.

Vulnerability type: Cross-Site Scripting (improper neutralization of input during web page generation)
Severity: High
CVSS score: 7.2
EPSS score: 0.03%

The vulnerability allows an authenticated user with dashboard creation or editing capabilities to bypass existing XSS protections in Vega visualizations. By embedding malicious JavaScript into a crafted visualization, the attacker can persistently inject scripts into Kibana dashboards. When another user views the affected dashboard—often a higher-privileged user such as an administrator—the embedded script executes in their browser context.

Successful exploitation can lead to session hijacking, execution of unauthorized actions through the victim’s session, or exposure of sensitive data accessible via the Kibana interface. The issue was publicly disclosed in December 2025, making it a recently published vulnerability.

At this time, no public proof-of-concept exploit has been released, and there are no confirmed reports of exploitation in the wild. CVE-2025-68385 has not been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not issued a specific advisory related to this vulnerability.

Why should TPRM professionals care about this vulnerability?

Kibana is commonly deployed as a central analytics and visualization layer for logs, security events, and operational telemetry. From a TPRM perspective, this vulnerability presents several notable risks:

Privilege abuse through visualization features: Even low-privileged users can weaponize dashboards to target higher-privileged users who routinely review analytics and security data.
Session compromise risk: If an administrator’s session is hijacked, attackers may gain indirect access to sensitive dashboards, configuration settings, or integrated backend systems.
Data visibility and integrity concerns: Malicious scripts can manipulate displayed data, hide indicators, or exfiltrate sensitive analytics information viewed through Kibana.

For TPRM professionals, vendors that rely on Kibana for monitoring, security analytics, or customer-related telemetry may introduce downstream risk if user access controls and patching practices are not properly enforced.

What questions should TPRM professionals ask vendors about this vulnerability?

To assess exposure and control effectiveness, TPRM professionals may ask vendors:

Can you confirm if you have upgraded all instances of Elastic Kibana to the patched versions (v8.19.9, v9.1.9, v9.2.3) to mitigate the risk of CVE-2025-68385?
Have you implemented strict access controls and the principle of least privilege for all Kibana users, especially those with dashboard creation or editing capabilities, to prevent potential exploitation of the XSS vulnerability in Vega visualizations?
Are you actively monitoring Kibana logs and user activity for any unusual behavior, particularly related to dashboard modifications, script injection attempts, or unauthorized access attempts that could indicate a compromised low-level account?
Have you reinforced the Vega sanitization process as recommended by Elastic's patches to mitigate the XSS loophole in Kibana?

Remediation recommendations for vendors subject to this risk

Vendors operating Elastic Kibana should consider the following actions:

Apply official security updates immediately:
Upgrade Kibana to v8.19.9, v9.1.9, or v9.2.3. Environments running Kibana 7.x should prioritize a major version upgrade, as all 7.x releases are affected.
Limit dashboard creation privileges:
Enforce the principle of least privilege and restrict Vega visualization creation and editing to a small, trusted group of users.
Harden visualization workflows:
Ensure that patched Vega sanitization logic is fully deployed and avoid embedding complex or user-supplied expressions where not strictly necessary.
Monitor user activity:
Review logs and audit trails for unusual dashboard changes, repeated edits, or access patterns that may indicate misuse of visualization features.

Black Kite’s Elastic Kibana - Dec2025 FocusTags™ details critical insights on the event for TPRM professionals.

CVE-2025-14558 (FreeBSD rtsold DNSSL Command Injection (RCE) Vulnerability)

What is the FreeBSD rtsold RCE vulnerability?

CVE-2025-14558 is a critical remote code execution (RCE) vulnerability affecting FreeBSD systems that process IPv6 Router Advertisement (RA) messages.

Vulnerability type: Command injection leading to remote code execution
Severity: Critical
CVSS score: 9.8
EPSS score: 0.02%

The vulnerability exists in the rtsol and rtsold daemons, which handle IPv6 Stateless Address Autoconfiguration (SLAAC). These components fail to properly validate Domain Name Search List (DNSSL) options received via IPv6 router advertisements. Malicious DNSSL values are passed unsanitized to resolvconf(8), a shell script responsible for managing DNS configuration.

Because resolvconf(8) does not adequately quote input, an attacker can craft DNSSL entries that contain embedded shell commands. When processed, these commands are executed with system-level privileges. Exploitation is limited to the local network segment, as IPv6 router advertisements are not forwarded beyond the local link.

CVE-2025-14558 was publicly disclosed in December 2025, placing it among recently published vulnerabilities. There is currently no public proof-of-concept exploit, and no evidence of active exploitation in the wild. The vulnerability has not been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, and CISA has not issued a dedicated advisory related to this issue.

Why should TPRM professionals care about this vulnerability?

FreeBSD is widely used as a server operating system, network appliance platform, and foundation for firewalls, storage systems, and embedded infrastructure. From a TPRM perspective, this vulnerability introduces several important considerations:

Local network attack surface: Vendors operating FreeBSD-based systems on shared or untrusted networks may be exposed to lateral attacks originating from compromised internal hosts.
Infrastructure-level impact: Successful exploitation enables execution of arbitrary commands with system privileges, potentially allowing attackers to tamper with core services, network configurations, or security controls.
Hidden exposure: Systems may be vulnerable by default if IPv6 is enabled and router advertisements are accepted, even if administrators are unaware that rtsold is active.

For TPRM professionals, vendors relying on FreeBSD for backend services, network appliances, or security infrastructure may face elevated risk in environments where internal network trust boundaries are weak or where IPv6 is broadly enabled.

What questions should TPRM professionals ask vendors about this vulnerability?

To assess exposure and mitigation readiness, TPRM professionals may ask vendors:

Can you confirm if your FreeBSD system has been updated since December 16, 2025, specifically for versions 15.0-RELEASE, 14.3-RELEASE, and 13.5-RELEASE, to mitigate the risk of CVE-2025-14558?
Have you applied the patch from the official security advisory and recompiled the system using `buildworld` and `installworld` to address the vulnerability in the `rtsol` and `rtsold` programs?
Have you taken steps to disable IPv6 or configure your network interfaces to ignore router advertisements by ensuring the `ACCEPT_RTADV` flag is not set, as a mitigation measure against this specific attack vector?
Can you confirm if your system is configured to process IPv6 Router Advertisements, specifically, does the network interface have the ACCEPT_RTADV flag enabled, and is the rtsold or rtsol daemon active to process incoming packets?

Remediation recommendations for vendors subject to this risk

Vendors operating FreeBSD systems should consider the following actions:

Upgrade to patched FreeBSD releases:
Apply updates from supported FreeBSD branches dated after December 16, 2025, which include fixes for the vulnerable rtsold and resolvconf behavior.
Apply updates using supported mechanisms:
Use freebsd-update where applicable, or rebuild the system from source after applying the official patch if managing custom builds.
Disable unnecessary IPv6 features:
If IPv6 is not required, disable it entirely. Alternatively, ensure network interfaces do not accept router advertisements by disabling the ACCEPT_RTADV flag.
Limit local network trust:
Strengthen internal network controls to reduce the likelihood of malicious router advertisements originating from compromised hosts.

Black Kite’s FreeBSD FocusTags™ details critical insights on the event for TPRM professionals.

How TPRM Professionals Can Leverage Black Kite FocusTags™ Across These Vulnerabilities

When critical vulnerabilities span multiple technology domains—ranging from operating systems and email and collaboration platforms to automation tools, databases, remote access gateways, and analytics systems—TPRM teams face a common challenge: determining which vendors represent actual, actionable risk versus theoretical exposure. Black Kite’s FocusTags™ are designed to address this challenge by transforming vulnerability intelligence into operational insight that scales across diverse vendor ecosystems.

Across the vulnerabilities discussed in this Focus Friday—including SonicWall SMA1000, FortiGate SSL-VPN, n8n, Exim Mail, Zimbra Collaboration Suite, MongoDB, M-Files Server, Elastic Kibana, and FreeBSD—Black Kite enables TPRM professionals to:

Identify truly exposed vendors: FocusTags™ correlate vulnerability intelligence with observable internet-facing assets, allowing teams to pinpoint vendors operating affected technologies—such as externally accessible SSL-VPN gateways or authentication services—rather than relying on broad assumptions.
Prioritize response based on real risk: By combining severity, exploitation context, and asset exposure, FocusTags™ help TPRM teams determine which vendor relationships require immediate attention, particularly where authentication bypass or remote access abuse could lead to full network compromise.
Enable precise vendor outreach: Asset-level visibility, including relevant IP addresses and subdomains, supports evidence-based conversations with vendors and accelerates validation of remediation claims, especially for perimeter technologies like VPNs and secure access gateways.
Reduce assessment fatigue: Narrowing outreach to vendors with demonstrable exposure minimizes unnecessary questionnaires and follow-ups for both risk teams and vendors, even when vulnerabilities affect widely deployed infrastructure products.
Maintain continuity across evolving threats: FocusTags™ remain active over defined time windows, allowing TPRM professionals to track remediation progress and reassess exposure as vulnerabilities evolve, exploitation resurfaces, or new intelligence—such as renewed abuse of legacy flaws—emerges.

Strengthening TPRM Outcomes with Black Kite’s FocusTags™

Managing third-party cyber risk becomes increasingly challenging when critical vulnerabilities affect core infrastructure, email and collaboration platforms, databases, analytics systems, remote access gateways, and automation tools simultaneously. Black Kite’s FocusTags™ are designed to reduce this complexity by converting vulnerability intelligence into actionable, risk-focused insights that TPRM teams can apply across diverse vendor environments.

In the context of this week’s FocusTags™—spanning infrastructure-level risks in FreeBSD, email and collaboration platform exposure in Zimbra and Exim Mail, data disclosure risks in MongoDB and M-Files, and authentication, privilege, or remote access abuse risks in platforms such as FortiGate SSL-VPN, SonicWall, Kibana, and n8n—FocusTags™ enable organizations to move from generalized awareness to targeted, operational action. Key benefits include:

Focused vendor scoping: Identify which vendors are actually operating affected technologies, rather than expending effort across the entire vendor population.
Risk-based prioritization: Combine vulnerability severity, exploitation context, and observable asset exposure to determine which vendor relationships warrant immediate attention—particularly where authentication bypass or perimeter access is involved.
Evidence-driven vendor engagement: Ground outreach in verifiable exposure and technical context, enabling more productive and outcome-oriented conversations with vendors.
Operational efficiency: Reduce unnecessary questionnaires and follow-ups by concentrating resources on vendors with demonstrable risk signals.
Asset-level visibility: Gain insight into specific IP addresses or subdomains associated with vulnerable deployments, supporting faster validation and remediation tracking.

By operationalizing FocusTags™ across the high-profile vulnerabilities discussed in this blog, Black Kite equips TPRM professionals with a scalable, intelligence-driven approach to third-party risk. This approach aligns security urgency with business impact, enabling organizations to manage vendor risk more effectively while maintaining clarity and confidence in their decision-making.

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:

SonicWall SMA1000 : CVE-2025-40602, CVE-2025-23006, Privilege Escalation and Pre-authentication Deserialization of Untrusted Data Vulnerabilities Leading to Unauthenticated Remote Code Execution in SonicWall SMA1000.
FortiGate SSL-VPN – Dec2025 : CVE-2020-12812, Improper Authentication Vulnerability Allowing Two-Factor Authentication (2FA) Bypass via Case-Sensitivity Mismatch in LDAP-Backed FortiGate SSL-VPN Deployments.
n8n : CVE-2025-68613, Arbitrary Code Execution via Improper Isolation of User-Supplied Expressions in n8n Workflow Automation Platform.
Exim Mail – Dec2025 : CVE-2025-26794, CVE-2025-67896, SQL Injection and Heap Buffer Overflow Vulnerabilities Leading to Memory Corruption and Potential Remote Code Execution in Exim Mail Transfer Agent.
Zimbra – Dec2025 : CVE-2025-68645, CVE-2025-67809, Local File Inclusion and Hardcoded Credentials Vulnerabilities Leading to Sensitive Data Exposure and Unauthorized Access in Zimbra Collaboration Suite.
MongoDB – Dec2025 : CVE-2025-14847, Out-of-bounds Read and Information Disclosure Vulnerability via zlib Compression Handling in MongoDB Server.
M-Files Server : CVE-2025-13008, CVE-2025-14267, Session Token Disclosure and Improper Removal of Sensitive Information Vulnerabilities Leading to Identity Impersonation and Information Disclosure in M-Files Server.
Elastic Kibana – Dec2025 : CVE-2025-68385, Cross-Site Scripting Vulnerability via Vega Visualizations Leading to Session Hijacking and Unauthorized Actions in Elastic Kibana.
FreeBSD : CVE-2025-14558, rtsold DNSSL Command Injection Vulnerability Leading to Local Network Remote Code Execution in FreeBSD.
ScreenConnect – Dec2025 : CVE-2025-14265, Exposure of Sensitive Information and Download of Code Without Integrity Check Vulnerability in ConnectWise ScreenConnect.
CentreStack & Triofox – Dec2025 : CVE-2025-14611, Insecure Cryptography and Arbitrary File Read Vulnerability Leading to Remote Code Execution in Gladinet CentreStack and Triofox.
Jenkins – Dec2025 : CVE-2025-67635, CVE-2025-67637, CVE-2025-67636, Denial of Service, Information Disclosure, and Missing Authorization Vulnerabilities in Jenkins Core.
FreePBX – Dec2025 : CVE-2025-66039, CVE-2025-61675, CVE-2025-61678, Authentication Bypass, SQL Injection, and Arbitrary File Upload Vulnerabilities Leading to Remote Code Execution in FreePBX.
Gogs – Dec2025 : CVE-2025-8110, Path Traversal Vulnerability via Symlink Bypass Leading to Remote Code Execution in Gogs.
Fortinet [Suspected] – Dec2025 : CVE-2025-59718, CVE-2025-59719, Administrative Authentication Bypass via SAML Forgery in Fortinet FortiCloud SSO.
Exchange Server – Dec2025 : CVE-2025-64666, CVE-2025-64667, Elevation of Privilege and Email Spoofing Vulnerabilities in Microsoft Exchange Server.
Cacti – Dec2025 : CVE-2025-66399, Remote Code Execution Vulnerability via SNMP Community String Injection in Cacti.
React Server Components (RSC) [Suspected] : CVE-2025-55182, Remote Code Execution Vulnerability in React Server Components.
Mixpanel Clients : Assessing the Potential Impact of Client Data Exposure in Mixpanel.
SonicWall SSL VPN – Nov2025 : CVE-2025-40601, Pre-Authentication Stack-Based Buffer Overflow Vulnerability in SonicWall SonicOS SSLVPN Service Leading to Denial of Service.
Grafana Enterprise – Nov2025 : CVE-2025-41115, Incorrect Privilege Assignment Vulnerability Allowing Privilege Escalation and User Impersonation via SCIM Provisioning in Grafana Enterprise.
Apache SkyWalking : CVE-2025-54057, Stored Cross-Site Scripting (XSS) Vulnerability Allowing Persistent Script Injection in Apache SkyWalking Monitoring Dashboards.
Gainsight Client – Nov2025 : Integration-Token Abuse Incident, Unauthorized Access and Potential Data Exfiltration Through Compromised OAuth Tokens in Gainsight–Salesforce Connected Applications.
FortiWeb [Suspected] : CVE-2025-64446, CVE-2025-58034, Authentication Bypass Vulnerability, Path Traversal Vulnerability, OS Command Injection Vulnerability in Fortinet FortiWeb Web Application Firewall.