FOCUS FRIDAY: TPRM Insights on Critical Vulnerabilities in TeamCity, Cisco FMC, SolarWinds Web Help Desk, N-central, Langflow, Apache Tomcat, and Gitea

Introduction

This week's Focus Friday covers seven FocusTags spanning CI/CD infrastructure, network security management, remote monitoring and management platforms, AI workflow orchestration, web help desk software, application servers, and self-hosted developer tooling. Four of the seven tags carry CISA Known Exploited Vulnerability status with confirmed active exploitation in the wild. The most operationally significant event this week is the N-central authentication bypass, where threat actors have been observed exploiting the vulnerability to gain access to managed service provider environments and deploy Cloudflare tunnels for persistence. Because N-central is an RMM platform used by MSPs to manage client endpoints, a single compromised instance can affect every downstream organization under its management — making this a supply chain risk event as much as a product vulnerability. Cisco Firewall Management Center, Langflow, and Apache Tomcat round out the active exploitation picture, while TeamCity, SolarWinds Web Help Desk, and Gitea bring critical unauthenticated vulnerabilities with significant third-party risk implications.

Filtered view of vendors with TeamCity - Jul2026 FocusTag® on the Black Kite platform.

TeamCity - Jul2026 (CVE-2026-63077)

What is this vulnerability?

CVE-2026-63077 (CVSS 9.8) is a critical unauthenticated authentication bypass vulnerability in JetBrains TeamCity On-Premises. If exploited, an unauthenticated attacker with HTTP(S) access to a TeamCity server can bypass authentication checks via the TeamCity agent polling protocol and execute arbitrary operating system commands with the privileges of the TeamCity server process. All versions of TeamCity On-Premises are affected. TeamCity Cloud customers are not required to take any action, as the necessary measures have already been applied and no evidence of TeamCity Cloud exploitation was found.

The vulnerability was reported to JetBrains on July 10, 2026 by Antoni Tremblay under coordinated disclosure. Fixed versions are TeamCity 2025.11.7 and 2026.1.3, released July 27, 2026. For installations that cannot be upgraded immediately, JetBrains has released a security patch plugin covering TeamCity 2017.1 and later. The patch plugin for TeamCity 2024.03 and newer is automatically downloaded and presented for administrator review in Administration | Updates. For versions 2017.1 through 2018.1 a server restart is required after plugin installation; from 2018.2 onward the plugin can be enabled without a restart. At the time of advisory publication, JetBrains was not aware of active in-the-wild exploitation. Depending on the privileges granted to the TeamCity server process, successful exploitation could expose configurations and stored credentials, modify server state, and compromise the integrity of build artifacts and downstream CI/CD pipelines.

Why should TPRM professionals care?

TeamCity is a widely deployed CI/CD platform whose server process holds the keys to the software build pipeline: stored version control credentials, artifact signing certificates, deployment tokens, and access to downstream infrastructure. An unauthenticated RCE on a TeamCity server therefore reaches far beyond the build platform itself — into every system and credential the pipeline touches. This exploitation pattern is not theoretical: CVE-2023-42793, a prior unauthenticated authentication bypass in TeamCity On-Premises, was actively exploited by North Korean threat actor groups (Lazarus Group / DPRK-linked actors) in supply chain attacks targeting vendor software build infrastructure. CVE-2026-63077 follows the same structural pattern and should be treated with corresponding urgency. Internet-facing TeamCity servers — particularly those accessible from untrusted networks without VPN gating — represent the highest-risk exposure profile. TPRM professionals should confirm that vendors operating TeamCity On-Premises have patched or applied the security patch plugin, and should inquire about internet-accessibility and credential rotation for CI/CD pipeline secrets.

What questions should TPRM professionals ask vendors?

1. Has TeamCity On-Premises been upgraded to version 2025.11.7 or 2026.1.3 — the releases addressing CVE-2026-63077? If the full upgrade is not yet applied, has the JetBrains security patch plugin been installed on all TeamCity instances running version 2017.1 or later?
2. Is the TeamCity server internet-accessible — reachable over HTTP(S) by untrusted external parties without VPN gating or IP allowlisting? JetBrains specifically recommends requiring VPN connections or implementing an additional security layer for any internet-facing TeamCity instance, even after patching.
3. What credentials, secrets, and API tokens are stored in TeamCity build configurations and agent environments? Given that successful exploitation enables OS command execution under the TeamCity server process, any credentials accessible to that process should be considered potentially compromised and rotated.
4. Have TeamCity server logs been reviewed for anomalous agent polling traffic or unexpected administrative actions during the window when unpatched instances were internet-accessible? The exploitation vector is the agent polling protocol, and log review should focus on unexpected authentication events and REST API calls.
5. Is TeamCity Cloud in use instead of, or alongside, TeamCity On-Premises? TeamCity Cloud is not affected by CVE-2026-63077 and requires no action; confirming which deployment model is in use is a prerequisite for accurate exposure assessment.

Remediation recommendations

• Upgrade TeamCity On-Premises to version 2025.11.7 or 2026.1.3 immediately. Download the latest patched version from jetbrains.com or use the automatic update option within TeamCity. These are the only releases that include the complete fix for CVE-2026-63077.
• If immediate upgrade is not feasible, install the JetBrains security patch plugin for TeamCity 2017.1 and later. Review Administration | Updates in TeamCity 2024.03+ for automatically downloaded security patches. Note that the plugin only addresses CVE-2026-63077 specifically; full upgrade is still recommended for all other security updates.
• Restrict internet access to the TeamCity server. Place internet-facing TeamCity instances behind a VPN gateway or implement IP allowlisting to prevent untrusted external access to the TeamCity login screen and REST API. Even the login screen provides an attack surface for newly disclosed vulnerabilities.
• Rotate all credentials, tokens, and secrets stored in TeamCity build configurations, agent environments, and parameter sets — particularly for any instance that was internet-accessible and unpatched after July 27, 2026. This includes VCS credentials, deployment tokens, cloud provider keys, and signing certificates.
• Review TeamCity server and agent logs for evidence of unauthorized access or unexpected command execution during the pre-patch exposure window. Focus on anomalous agent polling events, unexpected project or build configuration modifications, and unauthenticated API access.

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

Cisco FMC - Jul2026 (CVE-2026-20316, CVE-2026-20079)

What is this vulnerability?

CVE-2026-20316 (CVSS 5.3, Cisco Security Impact Rating: High) is a static credential vulnerability in the web interface of Cisco Secure Firewall Management Center (FMC) Software. The vulnerability exists due to the presence of static, hardcoded user credentials for a low-privileged account in FMC. An unauthenticated remote attacker can exploit this flaw by authenticating to an affected system using the static credentials, gaining low-privileged access to sensitive data within the FMC. Cisco assigned a Security Impact Rating of High — rather than Medium as the CVSS score indicates — because CVE-2026-20316 can be chained with other Cisco Secure FMC Software vulnerabilities to elevate privileges. The critical chaining target is CVE-2026-20079 (CVSS 10.0): a separate authentication bypass flaw in Cisco Secure FMC that, when combined with the static credential access from CVE-2026-20316, enables execution of arbitrary script files and obtains root access on the FMC appliance.

CVE-2026-20316 has been added to CISA's Known Exploited Vulnerabilities catalog as of July 29, 2026, confirming active in-the-wild exploitation. Federal Civilian Executive Branch agencies were required to apply fixes by August 1, 2026. Active exploitation was confirmed as occurring at least as early as July 23, 2026. The attack surface is reduced if the FMC management interface does not have public internet access. Approximately 823 FMC management interfaces are detectable on Shodan. Cisco released hotfixes for FMC versions 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0. To detect potential exploitation, Cisco advises running the CLI command zgrep "package_info.*license" messages* in expert mode and checking whether output includes /var/tmp/license.tmp — a confirmed indicator of compromise.

Why should TPRM professionals care?

Cisco Secure Firewall Management Center is the centralized management plane for Cisco Secure Firewall deployments — governing firewall policy, intrusion detection, network visibility, and security event management across an organization's network perimeter. A compromise of FMC is not an application-layer breach: it is a security control plane compromise that grants an attacker visibility into and administrative control over the network security infrastructure it manages. The CVE-2026-20316 and CVE-2026-20079 chain — static credentials to low-privileged access, escalated to root via a CVSS 10.0 authentication bypass — represents a complete FMC takeover with potential to modify firewall rules, exfiltrate network security configurations, and create persistent access paths through the managed firewall infrastructure. For TPRM professionals, any vendor running internet-accessible FMC without the July 2026 hotfix applied should be treated as a priority engagement target given confirmed active exploitation.

What questions should TPRM professionals ask vendors?

1. Have the Cisco Secure FMC hotfixes been applied across all FMC Software versions in use? The specific hotfix releases are version-dependent: 7.0 (Hotfix_GB-7.0.9.1-3), 7.2 (Hotfix_HL-7.2.11.1-4), 7.4 (Hotfix_HG-7.4.7.1-3), 7.6 (Hotfix_CY-7.6.5.1-2), 7.7 (Hotfix_AM-7.7.12.1-2), and 10.0 (Hotfix_P-10.0.1.1-2). What FMC versions are deployed and have the correct hotfixes been confirmed?
2. Has the Cisco-recommended IoC check been performed — running zgrep "package_info.*license" messages* in expert mode on each FMC device and verifying whether /var/tmp/license.tmp appears in the output? If this indicator is present, Cisco advises immediate contact with the Cisco Technical Assistance Center, as hotfixes alone may not address existing compromise.
3. Is the FMC management interface accessible from the public internet, or restricted to internal trusted networks? Public internet exposure of the FMC management interface is the primary risk amplifier for CVE-2026-20316, as the static credential vulnerability requires no prior access beyond network reachability.
4. Has CVE-2026-20079 (CVSS 10.0) also been addressed — including the updated hotfix entries (second bug ID CSCwt95974) added by Cisco to the CVE-2026-20079 advisory? Both CVEs share the same /var/tmp/license.tmp indicator of compromise, and both should be remediated as part of the same patching action.
5. Given that exploitation was confirmed as early as July 23, 2026: have firewall policy configurations, access rules, and administrative account audit logs been reviewed for unauthorized changes on all affected FMC instances? A compromised FMC may have been used to silently modify network security policy.

Remediation recommendations

• Apply the Cisco Secure FMC hotfix for your deployed version immediately. Download the correct hotfix from the Cisco Software Center at cisco.com. Do not rely on the hotfix to address existing compromise if the /var/tmp/license.tmp IoC is present — contact Cisco TAC for recovery guidance in that scenario.
• Immediately restrict FMC management interface access to trusted internal networks and IP ranges as a compensating control for any FMC instance where the hotfix has not yet been applied. Public internet access to the FMC management interface should be considered an unacceptable risk given active exploitation of CVE-2026-20316.
• Perform the Cisco IoC detection procedure on all FMC instances: run zgrep "package_info.*license" messages* in expert mode and check for /var/tmp/license.tmp in the output. Any positive IoC result requires immediate incident response engagement, not just patching.
• Rotate all administrative credentials and session tokens on FMC instances that were internet-accessible and unpatched during the active exploitation window (from at least July 23 through hotfix application). Review and audit all firewall policy changes made during this window for unauthorized modifications.
• Address CVE-2026-20079 (CVSS 10.0) concurrently with CVE-2026-20316. Both vulnerabilities are addressed by the same hotfix batch, and both share confirmed IoC indicators. Treating only CVE-2026-20316 while leaving CVE-2026-20079 unaddressed is insufficient remediation for the active exploitation scenario.

Black Kite’s Cisco FMC - Jul2026 FocusTag® details critical insights on the event for TPRM professionals.

SolarWinds WHD - Aug2026 (CVE-2026-28323, CVE-2026-28299)

What is this vulnerability?

SolarWinds Web Help Desk 2026.2.1, released July 30, 2026, addresses two vulnerabilities: CVE-2026-28323 (CVSS 9.8, CWE-287, EPSS 0.64%) is a critical SAML 2.0 authentication bypass affecting Web Help Desk deployments where SAML authentication is enabled. The flaw allows an attacker to bypass identity checks in the SAML sign-in path and access the Web Help Desk application without valid credentials. CVE-2026-28299 (CVSS 8.2, CWE-770) is a denial of service vulnerability where insufficient memory controls can cause the Web Help Desk server to crash. Both vulnerabilities are fixed exclusively in WHD 2026.2.1. SolarWinds reports no confirmed exploitation in the wild for either issue at time of publication. The [Suspected] designation on this FocusTag indicates product-based detection methodology, meaning Black Kite identifies the presence of Web Help Desk based on external signals with medium confidence.

The SAML authentication bypass (CVE-2026-28323) is only exploitable where SAML 2.0 authentication has been enabled in Web Help Desk configuration. Deployments using other authentication methods are not exposed to the CVE-2026-28323 attack vector, though patching to WHD 2026.2.1 is recommended regardless. SolarWinds Web Help Desk manages IT help desk tickets and asset inventory data for enterprise organizations — data that typically includes IT asset details, service account information, and internal ticketing records. The WHD 2026.2.1 release also rolls up the 2026.2 patches, including third-party pgAdmin4 security fixes. Approximately 763 Web Help Desk instances are detectable on Shodan. The product has a notable prior exploitation history: CVE-2024-28986, a deserialization RCE in SolarWinds Web Help Desk, was added to CISA's KEV catalog in 2024.

Why should TPRM professionals care?

SolarWinds Web Help Desk occupies a sensitive position in enterprise IT infrastructure as the system handling IT service requests, asset data, access requests, and internal ticketing workflows — often including records of privileged access grants and service account management. A SAML authentication bypass at CVSS 9.8 eliminates the login barrier entirely for deployments using SAML 2.0, granting an unauthenticated attacker full access to the WHD interface and all data it contains. SolarWinds products carry elevated threat actor attention following multiple high-profile exploitation campaigns, and CVE-2024-28986's KEV addition confirms that SolarWinds Web Help Desk specifically has been targeted. The [Suspected] tag designation means TPRM professionals should confirm with vendors whether WHD is deployed before initiating a detailed engagement, but the CVSS 9.8 severity and product history justify proactive outreach to potentially affected vendors.

What questions should TPRM professionals ask vendors?

1. Has SolarWinds Web Help Desk been upgraded to version 2026.2.1 — the release addressing CVE-2026-28323 (SAML bypass) and CVE-2026-28299 (DoS)? This is the only release that fixes both vulnerabilities.
2. Is SAML 2.0 authentication enabled in the Web Help Desk deployment? CVE-2026-28323 specifically requires the SAML 2.0 authentication method to be enabled to be exploitable. Confirming whether SAML is in use clarifies the actual exposure for deployments pending upgrade.
3. Is the Web Help Desk interface accessible from the public internet, or restricted to internal networks and VPN-gated access? As with all IT management platforms, restricting WHD to internal access significantly reduces the exploitable attack surface for an authentication bypass vulnerability.
4. Have WHD access logs been reviewed for anomalous authentication events or unusual data access patterns — particularly any unauthenticated or abnormal SAML-based session activity — during the pre-patch exposure window?
5. Given the [Suspected] detection confidence for this FocusTag: can the vendor confirm whether SolarWinds Web Help Desk is deployed in their environment, and if so, which version and authentication configuration is in use?

Remediation recommendations

• Upgrade SolarWinds Web Help Desk to version 2026.2.1 immediately. This is the only release addressing CVE-2026-28323 and CVE-2026-28299. The release notes are available at the SolarWinds Success Center.
• If immediate patching is not possible and SAML 2.0 is enabled: evaluate temporarily disabling SAML authentication and switching to an alternative authentication method as a compensating control. This removes the CVE-2026-28323 attack vector until the patch can be applied.
• Restrict Web Help Desk access to internal networks and trusted IP ranges. Remove any public internet exposure of the WHD interface pending patch confirmation, given the CVSS 9.8 severity of the SAML bypass.
• Review WHD access logs for any anomalous activity during the exposure window. Given no active exploitation confirmed at publication, this is a precautionary measure rather than incident response, but should be performed as part of normal patch verification practice.
• Confirm and document the WHD deployment status — version, authentication method, and network exposure — across all environments. The [Suspected] detection confidence requires vendor confirmation of whether WHD is actually in use.

Black Kite’s SolarWinds WHD - Aug2026 FocusTag® details critical insights on the event for TPRM professionals.

N-central - Aug2026 (CVE-2026-18577, CVE-2026-18556)

What is this vulnerability?

CVE-2026-18577 (CVSS 8.2, CWE-288, EPSS 1.48%) is an authentication bypass via an alternate path or channel in N-able N-central — and is itself an incomplete fix for CVE-2026-18556 (CVSS 8.2), an earlier authentication bypass in the same platform. Both vulnerabilities, whether individually or in combination, allow an attacker to bypass authentication and achieve full account takeover on the N-central management server. CVE-2026-18577 was added to CISA's Known Exploited Vulnerabilities catalog on August 3, 2026, confirming active in-the-wild exploitation. Active exploitation was confirmed and documented by Huntress security. The fix for both vulnerabilities is N-central hotfix 2026.3.1.7, released August 2, 2026, built on top of N-central 2026.3.0 (released July 30, 2026).

Huntress documented the active exploitation chain: following authentication bypass, threat actors achieved full account takeover on N-central, then leveraged the platform's remote monitoring and management capabilities to gain god-mode access across all managed service provider client endpoints under that N-central instance's management. For persistence, attackers deployed Cloudflare tunnels — registering a service named 'Cloudflared' and dropping a file named 'svchost.exe' in device users' Documents folders as indicators of compromise. N-able confirmed that N-central hosted instances (NCOD) would be upgraded on a managed schedule and notified directly; on-premises N-central instances require manual hotfix application. N-central is built on AlmaLinux 9. No exploited instances require agent-level upgrades for the server-side protection, though agent upgrades are still recommended.

Why should TPRM professionals care?

N-central is an RMM (Remote Monitoring and Management) platform used by managed service providers to manage and administer their clients' IT environments. This creates a qualitatively different risk profile compared to typical single-vendor vulnerability events: a single compromised N-central instance gives an attacker administrative access to every endpoint, server, and device managed under that instance across all MSP clients. The authentication bypass chain — from zero credentials to full account takeover to RMM-level god-mode across all client endpoints — is among the most consequential exploitation paths in the TPRM context. For organizations that rely on MSP partners for IT management, a compromised MSP N-central instance represents a direct threat to the organization's own endpoints. TPRM professionals should identify vendors and partners who operate N-central and confirm hotfix application with particular urgency given CISA KEV status and confirmed active exploitation.

What questions should TPRM professionals ask vendors?

1. Has N-central hotfix 2026.3.1.7 been applied — the release addressing both CVE-2026-18577 and its predecessor CVE-2026-18556? The hotfix requires first being on N-central 2026.3.0. For N-central hosted (NCOD) instances, N-able handles the upgrade directly; for on-premises instances, manual hotfix application is required and should be confirmed as complete.
2. Has the Huntress-documented IoC check been performed across managed devices? Indicators of compromise include a file named 'svchost.exe' in device users' Documents folders, and a registered Windows service named 'Cloudflared'. If either indicator is present on managed endpoints, immediate incident response engagement is required.
3. If the vendor operates as an MSP using N-central: what is the scope of client environments under the affected N-central instance's management? Given that N-central account takeover grants access across all managed client endpoints, the downstream breach scope may extend to the vendor's entire managed client base.
4. Has the N-central administrative account audit log been reviewed for unexpected login events, account creation, privilege escalation, or bulk script/command deployment — the types of activity consistent with post-compromise use of RMM capabilities?
5. For older N-central versions: what is the upgrade path to 2026.3.0 and then to hotfix 2026.3.1.7? N-able provides upgrade path documentation; vendors on legacy versions must upgrade in sequence and should confirm the full path and timeline.

Remediation recommendations

• Apply N-central hotfix 2026.3.1.7 immediately. On-premises N-central instances require manual download and installation following N-able's upgrade documentation at documentation.n-able.com. N-central hosted (NCOD) instances are updated by N-able directly; partners on NCOD should confirm their upgrade schedule with N-able support.
• Perform the IoC check on all managed endpoints: search for 'svchost.exe' in users' Documents folders, and check for a registered service named 'Cloudflared'. Consult the N-able status page (status.n-able.com) for the most current IoC list, as it is being updated with additional indicators. Any positive IoC result requires immediate incident response.
• If IoC is detected: contact N-able support immediately and engage your own security incident response team. Given that the exploitation chain enables RMM-level access across all managed client endpoints, the scope of potential compromise may be broad and requires forensic investigation.
• Rotate all N-central administrative credentials and review account access policies following hotfix application. Implement MFA on all N-central administrative accounts if not already enforced.
• Restrict N-central management interface access to trusted networks and implement IP allowlisting where possible. Audit all remote script and command deployment actions executed from N-central during the exposure window for unauthorized activity across managed endpoints.

Black Kite’s N-central - Aug2026 FocusTag® details critical insights on the event for TPRM professionals.

Langflow - Aug2026 (CVE-2026-9198)

What is this vulnerability?

CVE-2026-9198 (CVSS 9.8, EPSS 1.89%) is a critical unauthenticated remote code execution vulnerability in Langflow, an open-source low-code AI workflow orchestration platform. The exploitation chain is: an unauthenticated attacker calls /api/v1/auto_login, which mints a SUPERUSER-level authentication token without requiring any credentials. That token is then used to call /api/v1/validate/code, which invokes Python's exec() on attacker-supplied code — enabling arbitrary OS command execution on the Langflow server. No workarounds exist for this vulnerability. The fixed version is Langflow 1.10.1. All versions from 1.0.0 through 1.10.0 are affected. CVE-2026-9198 has been added to CISA's Known Exploited Vulnerabilities catalog as of August 4, 2026.

This is the third critical Langflow vulnerability in this FocusTag cycle — following CVE-2026-55255 (CISA KEV July 7, 2026) and CVE-2026-0770 (CISA KEV, actively exploited, covered in the July 24 Focus Friday). The pattern of recurring critical RCE vulnerabilities in Langflow reflects structural challenges in securing AI workflow platforms that execute user-supplied code as a core platform function. The /api/v1/auto_login endpoint that enables unauthenticated superuser token minting represents a fundamental authentication design flaw: it provides a privileged access path that bypasses the platform's authentication layer entirely, rather than simply weakening it.

Why should TPRM professionals care?

Langflow AI workflow instances are typically connected to LLM APIs (OpenAI, Anthropic, Google Vertex, Azure OpenAI), vector databases, cloud storage, and enterprise data pipelines — making the Langflow server process a credential aggregation point for the AI infrastructure stack. Unauthenticated RCE on a Langflow instance reaches every connected service and credential the instance can access. The CISA KEV listing on August 4, 2026 is the definitive signal of real-world exploitation. With three Langflow critical vulnerabilities CISA KEV listed in a single disclosure cycle, TPRM professionals should treat any internet-accessible Langflow deployment running a version below 1.10.1 as a priority engagement target. The absence of any workaround makes patching the only available defensive action; compensating controls are limited to network-level access restriction pending upgrade.

What questions should TPRM professionals ask vendors?

1. Has Langflow been upgraded to version 1.10.1 — the only release addressing CVE-2026-9198? All versions from 1.0.0 through 1.10.0 are vulnerable. No workaround exists for this vulnerability; upgrading to 1.10.1 is the only remediation path.
2. Given CISA KEV listing (August 4, 2026) and confirmed active exploitation: has a forensic review of Langflow server access logs been conducted for evidence of exploitation? Specifically, look for unauthenticated calls to /api/v1/auto_login followed by calls to /api/v1/validate/code with attacker-supplied code payloads.
3. Is the Langflow instance internet-accessible, or restricted to internal networks and VPN-gated access? Internet-accessible Langflow instances on any version below 1.10.1 should be considered the highest-urgency exposure given the trivial unauthenticated exploitation path.
4. What cloud credentials, LLM API keys, vector database API keys, and other secrets are accessible from the Langflow server environment? If a Langflow instance was internet-accessible and unpatched after August 4, all credentials accessible to the Langflow process should be considered potentially compromised and rotated.
5. This is the third critical Langflow CVE with KEV listing in one cycle: has the vendor evaluated whether Langflow continues to be an appropriate AI workflow platform given its ongoing critical vulnerability record, and are processes in place for rapid patch application for future Langflow critical disclosures?

Remediation recommendations

• Upgrade Langflow to version 1.10.1 immediately. There is no workaround for CVE-2026-9198; the patch is the only available remediation. This is a CISA KEV-listed vulnerability with confirmed active exploitation, justifying emergency upgrade priority.
• Immediately restrict internet access to all Langflow instances pending upgrade confirmation. Block external access to all Langflow API endpoints — particularly /api/v1/auto_login and /api/v1/validate/code — at the network perimeter or reverse proxy layer for any instance still running a version below 1.10.1.
• Rotate all credentials accessible from Langflow server environments: LLM API keys, cloud provider credentials (AWS, GCP, Azure), vector database API keys, and any other secrets configured in Langflow workflows or environment variables on the Langflow host. Do this for any instance that was internet-accessible and running a vulnerable version.
• Conduct a forensic review of Langflow server access logs for exploitation indicators: unexpected calls to /api/v1/auto_login and /api/v1/validate/code, unusual process spawns from the Langflow service, and anomalous outbound network connections from the Langflow host.
• Establish a rapid patch response procedure for Langflow given its recurring critical vulnerability pattern. This includes monitoring Langflow GitHub releases and CISA KEV additions for new Langflow entries, and treating any new Langflow critical disclosure as an emergency patching event.

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

Apache Tomcat - Aug2026 (CVE-2026-34486, CVE-2026-29146)

What is this vulnerability?

CVE-2026-34486 (CVSS 7.5, EPSS 42.63%) is an incomplete fix for CVE-2026-29146 in Apache Tomcat, tracked as a missing encryption of sensitive data vulnerability (CWE-311). The vulnerability affects Apache Tomcat's clustering feature, which uses the Tribes framework to synchronize session data between cluster nodes, listening on TCP port 4000 by default. When the EncryptInterceptor (AES/CBC) is enabled for cluster communication, a logic flaw causes the code to continue forwarding messages to the deserialization pipeline even when decryption fails. Specifically, the super.messageReceived(msg) call that triggers ObjectInputStream.readObject() was placed outside the try-catch block handling decryption failure — meaning decryption failure only logs an error while raw unencrypted bytes are still forwarded to deserialization. An unauthenticated attacker on port 4000 can send a crafted Java deserialization payload to trigger Remote Code Execution without authentication.

A public proof-of-concept exploit was published to GitHub (404-src/CVE-2026-34486). CVE-2026-34486 was added to CISA's Known Exploited Vulnerabilities catalog on August 4, 2026. The vulnerability affects exactly three Tomcat versions: 11.0.20, 10.1.53, and 9.0.116 — the versions that included the incomplete CVE-2026-29146 fix. Fixed versions are 11.0.21, 10.1.54, and 9.0.117. Tomcat versions prior to those that implemented the CVE-2026-29146 fix are not affected by CVE-2026-34486 specifically, but may carry other vulnerabilities. The vulnerability only applies to Tomcat deployments with clustering enabled and the EncryptInterceptor configured.

Why should TPRM professionals care?

CVE-2026-34486's EPSS score of 42.63% is exceptional — it places this vulnerability in the extreme upper tier of exploitation probability, indicating a very high likelihood of active exploitation attempts against vulnerable instances. Combined with a public PoC, CISA KEV listing, and the straightforward exploitation mechanism — send a crafted payload to port 4000, receive RCE — the practical exploitation barrier is low. Apache Tomcat is one of the most widely deployed Java application servers globally, used across enterprise web applications, microservice architectures, and backend processing systems. While the vulnerability requires Tomcat clustering to be enabled, clustering is a common configuration in high-availability enterprise Tomcat deployments. The three-version specificity of the affected range (exactly 11.0.20, 10.1.53, 9.0.116) means TPRM professionals need precise version confirmation from vendors — a difference of one minor version determines exposure.

What questions should TPRM professionals ask vendors?

1. What Apache Tomcat version is deployed? CVE-2026-34486 affects exactly versions 11.0.20, 10.1.53, and 9.0.116. Has the vendor confirmed whether their deployed version falls within this specific affected range, and has the upgrade to 11.0.21, 10.1.54, or 9.0.117 been applied?
2. Is Apache Tomcat clustering enabled in the deployment, with EncryptInterceptor configured? CVE-2026-34486 requires both clustering and EncryptInterceptor to be active. If clustering is not enabled, the vulnerability is not exploitable. Confirming the clustering configuration resolves the actual exposure.
3. Is port 4000 (the default Tribes cluster communication port) accessible from untrusted networks or the public internet? The CVE-2026-34486 exploitation requires network access to this port; restricting port 4000 to internal cluster networks is a critical compensating control for any instance pending the patch.
4. Given the CISA KEV listing (August 4, 2026) and EPSS 42.63%: has a forensic review of Tomcat access logs and OS process activity been performed on instances running the affected versions (11.0.20, 10.1.53, 9.0.116) for evidence of exploitation via the cluster port?
5. Is CVE-2026-29146 (the predecessor vulnerability that CVE-2026-34486 incompletely addressed) also patched? Organizations that were tracking CVE-2026-29146 remediation and applied the partial fix that introduced 11.0.20 / 10.1.53 / 9.0.116 are specifically the affected population for CVE-2026-34486.

Remediation recommendations

• Upgrade Apache Tomcat to version 11.0.21, 10.1.54, or 9.0.117 immediately. These are the only releases that include the complete fix for CVE-2026-34486. The fix moves super.messageReceived(msg) inside the try-catch block, ensuring decryption failure causes the message to be silently dropped rather than forwarded to deserialization.
• Immediately restrict access to port 4000 (Tribes cluster port) to trusted internal cluster IP ranges as a compensating control for any instance still running the affected versions. This port should never be accessible from untrusted networks regardless of patch status.
• If Tomcat clustering is not operationally required: disable the clustering feature to eliminate the EncryptInterceptor vulnerability surface entirely. Disabling clustering on Tomcat instances that do not require session synchronization is the most complete mitigation option.
• Given EPSS 42.63% and a public PoC: conduct a forensic review of Tomcat server logs and OS process activity on any instance that ran version 11.0.20, 10.1.53, or 9.0.116 while clustering was enabled and port 4000 was accessible. Look for unexpected process spawns, anomalous outbound connections, or new files created by the Tomcat service account.
• Maintain version tracking precision for Apache Tomcat deployments. CVE-2026-34486's three-version-specific affected range (11.0.20, 10.1.53, 9.0.116) requires exact version confirmation — a one-version difference determines exposure. Implement automated version detection across Tomcat deployment inventory.

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

Gitea - Aug2026 (CVE-2026-59774)

What is this vulnerability?

CVE-2026-59774 (CVSS 9.8, CWE-22) is a critical path traversal vulnerability in Gitea, the widely deployed self-hosted Git service. The vulnerability resides in Gitea's markup preview route. An anonymous user can POST Org-mode markup content to a public repository's markup endpoint — the route accessible at POST /{owner}/{repo}/markup — and use the Org-mode #+INCLUDE directive with an absolute file path to cause the Gitea server to read and return the contents of any file accessible to the Gitea service account. The underlying Org-mode file reader was left unrestricted, enabling arbitrary file read without any authentication — requiring only that a public repository exists on the Gitea instance. Both Windows and Linux hosting environments are in scope.

The file read escalates to full Remote Code Execution via a multi-step chain: the attacker reads app.ini (Gitea's main configuration file) to extract the INTERNAL_TOKEN. Using the INTERNAL_TOKEN, the attacker injects a Git hook through Gitea's internal logger. The malicious hook then executes during an anonymous git clone operation — delivering RCE under the Gitea OS user's privileges. The full exploitation chain requires no user account. Researchers publicly demonstrated the arbitrary file read reaching /[etc]/[passwd] before the patch was released. The vulnerability affects Gitea versions 1.22.1 through 1.27.0, and is fixed in Gitea 1.27.1. No confirmed in-the-wild exploitation at publication time, though public technical demonstration of the file read step has occurred.

Why should TPRM professionals care?

Gitea is deployed as a self-hosted alternative to GitHub and GitLab by security-conscious enterprises and development teams who require code sovereignty or regulatory compliance constraints on cloud code hosting. CVE-2026-59774 requires no authentication, no account, and no social engineering — only the existence of a single public repository on the Gitea instance. From that minimal starting point, an attacker can read any file accessible to the Gitea service account, including configuration files, secrets stored on the filesystem, and internal tokens — then escalate to full RCE on the server hosting the organization's code repository. The self-hosted nature of Gitea means that compromise reaches not only the source code hosted on the platform but also any CI/CD secrets, deploy keys, and organizational credentials integrated with the Gitea instance. The CVSS 9.8 rating and zero-user-interaction requirement make this a high-priority vulnerability for any organization operating internet-facing Gitea.

What questions should TPRM professionals ask vendors?

1. Has Gitea been upgraded to version 1.27.1 — the release fixing CVE-2026-59774? All versions from 1.22.1 through 1.27.0 are affected. Versions prior to 1.22.1 are not affected by this specific vulnerability.
2. Does the Gitea instance host any public repositories? CVE-2026-59774 requires only the existence of a public repository for exploitation; an instance with all repositories set to private reduces the exploitable attack surface, though patching remains required.
3. Has the Gitea INTERNAL_TOKEN in app.ini been rotated following the patch? The full RCE chain requires reading the INTERNAL_TOKEN from app.ini; rotating this token post-patch eliminates the token-based hook injection step of the chain for any instance that may have been exposed.
4. Is the Gitea instance internet-accessible, or restricted to internal networks? Since exploitation requires no account and no authentication, internet-facing Gitea instances on affected versions (1.22.1 through 1.27.0) represent the highest-risk exposure profile.
5. Have Gitea server logs been reviewed for anomalous POST requests to markup endpoints — specifically requests containing Org-mode #+INCLUDE directives with absolute file paths — that may indicate reconnaissance or exploitation attempts before the patch was applied?

Remediation recommendations

• Upgrade Gitea to version 1.27.1 immediately. This is the only release addressing CVE-2026-59774. The same release includes additional security fixes beyond the path traversal, making it the recommended version for all Gitea deployments on the 1.27.x branch.
• Rotate the INTERNAL_TOKEN value in Gitea's app.ini configuration following the upgrade. The INTERNAL_TOKEN is the key step in the file-read-to-RCE escalation chain; rotating it ensures that any token value extracted by an attacker before the patch is no longer usable for hook injection.
• Review all public repository configurations on the Gitea instance. If any repositories do not require public visibility, set them to private as a defense-in-depth measure — reducing the attack surface while patching is pending or as ongoing access control hygiene.
• Restrict internet exposure of Gitea markup endpoints at the reverse proxy or WAF layer for any instance pending upgrade. If possible, temporarily disable Org-mode markup rendering or add request filtering for #+INCLUDE directives on pre-patch instances that cannot be immediately upgraded.
• Audit Gitea server access logs for POST requests to /{owner}/{repo}/markup endpoints containing Org-mode content with file path references. Correlate with subsequent git clone operations that may indicate the hook injection and RCE phase of the exploitation chain.

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

How TPRM Professionals Can Leverage Black Kite for These Vulnerabilities

This week's seven FocusTags® illustrate a recurring pattern in the current threat landscape: the highest-impact vulnerabilities are concentrated in platforms that function as force multipliers — CI/CD systems, security management consoles, RMM platforms, and AI workflow orchestrators whose compromise reaches far beyond the vulnerable application itself into every system and credential it connects. Four of the seven tags carry CISA KEV status, meaning confirmed active exploitation is the reality for four distinct vendor technology segments this week simultaneously.

The N-central exploitation event is the clearest illustration of why TPRM programs must track infrastructure-layer platforms in vendor technology stacks: an MSP's N-central compromise is not contained to the MSP's own environment — it extends to every client organization the MSP manages. Standard TPRM questionnaires rarely capture RMM platform deployment details, making external signal-based detection the only scalable approach to identifying this exposure class across a vendor portfolio.

•  Continuous External Attack Surface Monitoring: FocusTags® correlate new vulnerability disclosures with vendor technology profiles derived from external signals — identifying internet-facing Gitea and Langflow instances, TeamCity CI/CD servers, and Cisco FMC management interfaces that vendors rarely disclose in formal questionnaire responses.

•  KEV-Integrated Prioritization: CISA KEV listings and EPSS scores feed directly into FocusTag® prioritization. This week, four KEV-listed events across seven tags require simultaneous emergency engagement — FocusTags® surface these as immediate high-priority triggers rather than items buried in routine patch queues.

•  Supply Chain Risk Detection: N-central's RMM platform status means a single vendor compromise propagates to all their managed clients. FocusTags® identify MSP partners operating affected N-central instances, enabling TPRM teams to assess the downstream supply chain risk before it materializes as a client-side incident.

•  Continuous Risk Score Integration: FocusTag® exposure updates vendor risk ratings in real time, ensuring that active exploitation events — particularly across four simultaneous KEV listings — are immediately reflected in vendor risk scores without waiting for scheduled assessment cycles.

Strengthening TPRM Outcomes with Black Kite’s FocusTags®

Black Kite's FocusTag® technology gives TPRM teams the operational intelligence needed to keep pace with an accelerating threat landscape — from CISA KEV-listed active exploitation events affecting CI/CD infrastructure and RMM platforms, to critical unauthenticated vulnerabilities in AI workflow orchestration and self-hosted developer tooling.

•  Automated Vendor Scoring: Each FocusTag® automatically affects the risk scores of vendors detected running the affected technology, enabling portfolio-wide risk visibility without manual assessment effort.

•  Targeted Vendor Engagement: FocusTags® generate specific, structured vendor questions for each vulnerability — enabling TPRM teams to send targeted remediation inquiries rather than generic questionnaires, and to verify patch status against precise version requirements.

•  TPRM-Contextualized Analysis: Every FocusTag® is evaluated through a TPRM lens — assessing not just the technical severity of the vulnerability, but its implications for third-party breach scenarios, supply chain risk, and vendor assessment prioritization.

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

• TeamCity - Jul2026: CVE-2026-63077, Unauthenticated Authentication Bypass via Agent Polling Protocol leading to Remote Code Execution in JetBrains TeamCity On-Premises.
• Cisco FMC - Jul2026: CVE-2026-20316, CVE-2026-20079, Static Credential Authentication Bypass and Critical Authentication Bypass (CVSS 10.0) leading to Root Execution in Cisco Secure Firewall Management Center.
• SolarWinds WHD - Aug2026: CVE-2026-28323, CVE-2026-28299, SAML Authentication Bypass and Denial of Service Vulnerability in SolarWinds Web Help Desk.
• N-central - Aug2026: CVE-2026-18577, CVE-2026-18556, Authentication Bypass via Alternate Path leading to Full Account Takeover and RMM-Level Access in N-able N-central.
• Langflow - Aug2026: CVE-2026-9198, Unauthenticated Superuser Token Minting via /api/v1/auto_login enabling Remote Code Execution in Langflow.
• Apache Tomcat - Aug2026: CVE-2026-34486, CVE-2026-29146, EncryptInterceptor Bypass enabling Unauthenticated Remote Code Execution via Java Deserialization in Apache Tomcat Clustering.
• Gitea - Aug2026: CVE-2026-59774, Org-mode #+INCLUDE Path Traversal enabling Arbitrary File Read and Remote Code Execution in Gitea.
• WordPress - wp2shell : CVE-2026-63030, CVE-2026-60137, REST API Batch-Route Confusion Vulnerability and SQL Injection Vulnerability Leading to Unauthenticated Remote Code Execution in WordPress Core.
• NGINX - Jul2026 : CVE-2026-42533, CVE-2026-60005, CVE-2026-56434, Heap-Based Buffer Overflow Vulnerability, Uninitialized Memory Access Vulnerability, and Use-After-Free Vulnerability in NGINX.
• SolarWinds Serv-U - Jul2026 : CVE-2026-28302, CVE-2026-28304, CVE-2026-28305, CVE-2026-28306, CVE-2026-28307, CVE-2026-28308, CVE-2026-28309, CVE-2026-28310, CVE-2026-28311, CVE-2026-28312, CVE-2026-28313, CVE-2026-28314, CVE-2026-28315, CVE-2026-28316, CVE-2026-28317, CVE-2026-28321, Insecure Direct Object Reference, Privilege Escalation, Remote Code Execution, Broken Access Control, and Stored Cross-Site Scripting Vulnerabilities in SolarWinds Serv-U.
• Oracle WebLogic - Jul2026 : CVE-2026-60206, CVE-2026-60205, CVE-2026-60204, CVE-2026-60202, CVE-2026-60198, CVE-2026-60294, CVE-2026-60200, CVE-2026-60291, CVE-2026-60292, CVE-2026-60199, CVE-2026-60208, Unauthenticated Remote Code Execution and Unauthorized Data Access Vulnerabilities in Oracle WebLogic Server.
• Zimbra - Jul2026 (Latest) : No CVE, Command Injection Vulnerability in SNMP Monitoring Component and Cross-Site Scripting Vulnerabilities in Zimbra Collaboration Suite Classic Web Client.
• Exim Mail - Jul2026 : GCVE-25-2026-07-45-1, Local Directory Traversal Vulnerability Leading to Privilege Escalation in Exim Mail Transfer Agent.
• RabbitMQ : CVE-2026-57219, CVE-2026-57221, TLS Client Authentication Bypass Vulnerability, OAuth2 JWKS Verification Bypass Vulnerability, OAuth Client Secret Exposure Vulnerability, and Cross-Tenant Authorization Bypass Vulnerability in RabbitMQ Server.
• Langflow - Jul2026 (Latest) : CVE-2026-0770, CVE-2026-5027, Unsafe Code Execution Vulnerability Leading to Unauthenticated Remote Code Execution in Langflow.
• Gitea : CVE-2026-58443, Incorrect Authorization Vulnerability Allowing Public-Only API Tokens to Trigger Writes to Private Repository Branches in Gitea.
• Progress ShareFile SZC : CVE Pending, Authenticated Path Traversal Vulnerability Allowing Arbitrary File Read, Arbitrary File Write, and Directory Enumeration in Progress ShareFile Storage Zone Controller.
• SonicWall SMA1000 - Jul2026 : CVE-2026-15409, CVE-2026-15410, Unauthenticated Server-Side Request Forgery Vulnerability and Post-Authentication Code Injection Vulnerability in SonicWall SMA1000.
• MSSQL - Jul2026 : CVE-2026-42990, CVE-2026-54117, CVE-2026-54118, CVE-2026-47295, CVE-2026-54116, CVE-2026-50468, Heap-Based Buffer Overflow Vulnerability, Deserialization of Untrusted Data Vulnerabilities, SQL Injection Vulnerability, and Information Disclosure Vulnerabilities in Microsoft SQL Server.
• Exchange Server - Jul2026 : CVE-2026-55008, CVE-2026-55005, CVE-2026-55009, CVE-2026-55006, Cross-Site Scripting Vulnerability, Heap-Based Buffer Overflow Vulnerability, Deserialization of Untrusted Data Vulnerability, and Privilege Escalation Vulnerability in Microsoft Exchange Server.
• Zimbra - Jul2026 : No CVE, Stored Cross-Site Scripting Vulnerability in Zimbra Collaboration Suite Classic Web Client.
• Roundcube - Jul2026 : CVE-2026-54433, Zero-Click Stored Cross-Site Scripting Vulnerability in Roundcube Webmail.
• FreeBSD - Jul2026 : CVE-2026-49418, CVE-2026-49419, CVE-2026-49415, Use-After-Free Vulnerability, Jail Reference Count Underflow Vulnerability, and Time-of-Check Time-of-Use Race Condition Vulnerability in FreeBSD.
• JoomShaper SP Page Builder : CVE-2026-48908, Critical Unauthenticated Remote Code Execution Vulnerability in JoomShaper SP Page Builder.
• Langflow - Jul2026 : CVE-2026-55255, High-Severity Insecure Direct Object Reference Vulnerability in Langflow.

See Black Kite's full CVE Database and the critical TPRM vulnerabilities that have an applied  FocusTags® at https://blackkite.com/cve-database.

References

https://www.cve.org/CVERecord?id=CVE-2026-63077
https://blog.jetbrains.com/teamcity/2026/07/cve-2026-63077/
https://www.bleepingcomputer.com/news/security/jetbrains-warns-of-critical-teamcity-remote-code-execution-flaw/
https://www.cve.org/CVERecord?id=CVE-2026-20316
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-static-cred-BET3Cjh
https://www.cisa.gov/news-events/alerts/2026/07/29/cisa-adds-one-known-exploited-vulnerability-catalog
https://thehackernews.com/2026/07/cisco-fmc-zero-day-actively-exploited.html
https://www.cve.org/CVERecord?id=CVE-2026-28323
https://www.cve.org/CVERecord?id=CVE-2026-28299
https://documentation.solarwinds.com/en/success_center/whd/content/release_notes/whd_2026-2-1_release_notes.htm
https://securityonline.info/solarwinds-web-help-desk-saml-bypass/
https://www.cve.org/CVERecord?id=CVE-2026-18577
https://www.cve.org/CVERecord?id=CVE-2026-18556
https://www.huntress.com/blog/rapid-response-critical-n-able-n-central-vulnerability-and-active-exploitation
https://status.n-able.com/2026/08/02/n-central-2026-3-hotfix-1-mitigation-for-cve-2026-18577/
https://www.cve.org/CVERecord?id=CVE-2026-9198
https://www.ibm.com/support/pages/node/7273426
https://www.cve.org/CVERecord?id=CVE-2026-34486
https://lists.apache.org/thread/9510k5p5zdvt9pkkgtyp85mvwxo2qrly
https://github.com/404-src/CVE-2026-34486
https://www.cve.org/CVERecord?id=CVE-2026-59774
https://github.com/advisories/GHSA-6v53-hr58-556r
https://securityonline.info/gitea-vulnerability-cve-2026-59774/