CISA Adds Three Known Exploited Vulnerabilities to Catalog

CISA Adds Actively Exploited N-able, Apache Tomcat and Langflow Vulnerabilities to KEV Catalog

The addition of three vulnerabilities affecting N-able N-central, Apache Tomcat and IBM Langflow to CISA’s Known Exploited Vulnerabilities Catalog demonstrates how attackers continue to target systems that provide administrative control, application hosting and artificial-intelligence workflow execution.

The vulnerabilities are tracked as CVE-2026-18556, CVE-2026-34486 and CVE-2026-9198. Their inclusion in the KEV Catalog means that exploitation is no longer merely theoretical. CISA has identified credible evidence that attackers are using the weaknesses against real systems.

Organizations running any of the affected products should therefore move them out of the ordinary vulnerability-management queue and treat them as immediate incident-response priorities. Applying the available updates is essential, but because exploitation has already occurred, affected systems should also be examined for evidence that attackers gained access before remediation.

The three vulnerabilities affect very different technologies, yet they share a common security theme. Each product occupies a trusted position within the environment. N-central manages endpoints, Tomcat hosts business applications and Langflow executes workflows that may contain cloud credentials, model keys and other sensitive information. Compromise of any one of these platforms can therefore provide access extending well beyond the initially vulnerable service.

CVE-2026-18556 affects N-able N-central

CVE-2026-18556 is an authentication-bypass vulnerability affecting N-able N-central through version 2026.1. The weakness allows a remote attacker to bypass normal authentication controls through an alternate access path or channel.

N-central is a remote monitoring and management platform commonly used by managed service providers and internal IT teams to administer large numbers of endpoints. Its capabilities can include remote access, software deployment, command execution, service management, monitoring and configuration changes.

These functions are legitimate and operationally valuable when used by authorised administrators. When an attacker gains control of the platform, however, the same functionality can provide an efficient route into every connected customer or managed device.

The security risk is therefore considerably larger than compromise of one web application. An attacker controlling N-central may inherit the remote administrative relationships already established between the management server and downstream endpoints.

This can allow the attacker to operate through legitimate management software rather than installing an unfamiliar remote-access tool on every system. Endpoint security products may see trusted N-central components performing technically valid actions, making malicious activity harder to distinguish from ordinary support work.

The flaw is closely related to CVE-2026-18577, which CISA added to the KEV Catalog one day earlier. CVE-2026-18577 arose because the original correction for the underlying N-central authentication problem did not block every exploitable path.

The appearance of two related actively exploited vulnerabilities illustrates the danger of incomplete fixes. An organization may believe it has resolved the issue after installing an earlier update, only to discover that attackers can reach the same sensitive functionality through another route.

Administrators must therefore verify the precise N-central build recommended by N-able rather than assuming that any recent 2026 release is sufficient.

N-central compromise can spread across customer environments

Remote monitoring and management platforms concentrate authority. One management server may administer dozens or hundreds of customer networks, making it an attractive target for ransomware operators, espionage groups and financially motivated access brokers.

An attacker compromising an ordinary workstation gains access to one device and the privileges of one user. An attacker compromising an RMM platform may gain remote-control capabilities across many organizations.

This creates supply-chain risk for customers that do not operate N-central themselves but allow an MSP to manage their endpoints through the platform.

A downstream organization may have strong firewalls, restricted VPN access and endpoint protection while still trusting commands delivered through its service provider’s management agent. If the provider’s N-central server becomes compromised, that trusted channel may become the path through which attackers enter the customer environment.

Organizations using managed IT services should therefore ask their providers whether they operate affected N-central versions, when updates were installed and whether remote-session logs have been reviewed for unauthorized activity.

Customers should not depend entirely on the service provider’s visibility. They should maintain their own endpoint and network telemetry so that suspicious RMM sessions, new services and unexpected remote-control activity can be investigated independently.

Patching N-central does not remove downstream persistence

Attackers who gained access before remediation may have used N-central to create alternative access mechanisms on managed endpoints.

They may have installed remote-access software, tunnelling utilities, scheduled tasks, new services, local administrator accounts or scripts that continue operating after the N-central server itself is patched.

The management platform may therefore represent only the initial access path. Once the attacker establishes persistence elsewhere, repairing the original server does not remove them from the environment.

Security teams should review N-central administrative accounts, active sessions, API credentials and authentication settings. Unknown identities, unexpected role changes and recently created tokens should be investigated.

Remote-access histories should be correlated with support tickets and technician schedules. Sessions that cannot be linked to legitimate maintenance should be treated as potentially malicious.

Every downstream endpoint accessed during the suspected compromise period should be examined for new services, startup mechanisms, remote-management agents, tunnelling tools and unusual outbound connections.

CVE-2026-34486 affects Apache Tomcat clustering

CVE-2026-34486 is a high-severity Apache Tomcat vulnerability involving missing encryption of sensitive data. It resulted from the correction for an earlier vulnerability and allows attackers to bypass the EncryptInterceptor under affected conditions.

The flaw affects Apache Tomcat 11.0.20, 10.1.53 and 9.0.116. Users should upgrade to Tomcat 11.0.21, 10.1.54 or 9.0.117, respectively.

Apache Tomcat is one of the most widely deployed Java application servers and servlet containers. It hosts internal applications, customer portals, APIs, middleware and other enterprise services across cloud and on-premises environments.

The affected EncryptInterceptor is associated with Tomcat cluster communication. In clustered deployments, application state and session information may be replicated between multiple Tomcat nodes to support availability and load balancing.

Encryption is intended to protect this communication from unauthorized observation or manipulation. A bypass can undermine the assumption that sensitive information transmitted between cluster members remains confidential.

The immediate consequence may be exposure of application session or replication data rather than direct remote code execution. However, the practical risk depends heavily on what the affected application places into replicated state and who can reach the cluster communication network.

Session information can be highly sensitive

Web applications frequently store information within sessions so users can remain authenticated while navigating the service.

Depending on the application design, replicated session data may include user identifiers, authorization state, account information, workflow details and other sensitive values.

If an attacker can observe unencrypted cluster traffic, this information may support session hijacking, identity impersonation or reconnaissance.

Even when the data does not contain a reusable authentication token directly, it can reveal how the application handles identities and internal state.

The threat becomes more serious when Tomcat cluster traffic crosses shared, cloud or insufficiently segmented networks. An attacker who compromises another system on the same network may be able to observe replication traffic that administrators assumed was encrypted.

Organizations should therefore avoid viewing this as merely a cryptographic configuration issue. The affected communication may carry information trusted by every application node in the cluster.

A successful attack against that trust relationship can potentially affect several servers rather than one isolated instance.

Tomcat cluster networks must be isolated

Cluster communication should be restricted to known Tomcat nodes and protected within a dedicated network segment.

Ordinary user endpoints, public-facing systems and unrelated workloads should not be able to reach the ports used for application-state replication.

Firewall policies should allow communication only between the precise systems participating in the cluster. Broad internal-network trust makes it easier for attackers to reach sensitive infrastructure after compromising another endpoint.

Organizations should also confirm that cluster membership cannot be established merely by reaching the relevant port. Nodes should authenticate one another using strong, deployment-specific credentials and certificates.

Shared default secrets and reusable cryptographic material can weaken otherwise secure encryption.

Security teams should monitor the cluster network for unfamiliar systems, unexpected multicast or replication traffic and changes in node membership.

The appearance of a new cluster participant should be treated as a high-risk event because it may receive trusted data from legitimate application servers.

The Tomcat vulnerability came from a previous fix

CVE-2026-34486 is particularly instructive because it was introduced or exposed through the correction for an earlier vulnerability.

Security updates can occasionally create new weaknesses when a change alters protocol behaviour, encryption handling or assumptions between components.

This does not mean organizations should avoid patching. Delaying known security updates generally creates far greater risk.

It does mean that patch management cannot end with installing one build and closing the ticket. Administrators must continue monitoring vendor advisories for regressions, incomplete corrections and follow-up releases.

Security testing should include the actual production configuration. A fix that works correctly in a simple standalone server may behave differently in clustered, proxied or highly customized deployments.

Organizations using Apache Tomcat should test important application and clustering behaviour after upgrading and confirm that encryption is functioning as expected.

Network captures in an authorized test environment can help verify that sensitive replication data is no longer transmitted in a readable form.

CVE-2026-9198 gives unauthenticated attackers Langflow RCE

CVE-2026-9198 is a critical code-injection vulnerability affecting IBM Langflow OSS versions 1.0.0 through 1.10.0.

The flaw allows an unauthenticated attacker to chain two exposed application endpoints. The first, `/api/v1/auto_login`, can issue superuser tokens to a network caller. The second, `/api/v1/validate/code`, executes user-supplied code through Python’s `exec()` functionality.

By combining these behaviours, an attacker can obtain administrative authority and execute arbitrary code on a default Langflow deployment without possessing valid credentials.

The vulnerability carries a CVSS score of 9.8 and can result in complete compromise of confidentiality, integrity and availability.

Affected users should upgrade to Langflow 1.10.1 or later and should remove public exposure wherever the platform does not need to be accessible from the internet.

Langflow combines automation with powerful code execution

Langflow is used to create visual workflows involving large language models, agents, databases, APIs and other services.

Its ability to connect multiple systems makes it useful for rapidly developing AI applications. The same integrations can place valuable credentials and access tokens within the platform.

A typical Langflow deployment may contain API keys for model providers, cloud credentials, database connection strings, vector-store access, internal service tokens and application secrets.

An attacker obtaining remote code execution may be able to access these values from environment variables, workflow configurations, local files or connected secrets-management systems.

The compromise may therefore extend beyond the Langflow server. Stolen credentials can provide access to cloud platforms, data stores and third-party AI services.

Attackers may also inspect workflows to understand how the organization’s applications operate, which systems they trust and where sensitive information is processed.

AI orchestration platforms are increasingly attractive targets because they combine code execution, valuable data and extensive connectivity inside one convenient interface.

Default deployments should never provide anonymous superuser access

The vulnerability chain is especially severe because it works against default deployments and does not require an authenticated user.

An endpoint capable of creating superuser tokens should never be available to arbitrary network callers.

Likewise, a function that executes supplied Python code must be protected by strong authentication, authorization and isolation.

The presence of both capabilities in one reachable application creates a direct path from anonymous access to operating-system compromise.

Organizations should review the complete attack surface of AI development and orchestration tools rather than assuming they are harmless internal utilities.

Development platforms often receive weaker security controls because teams view them as experimental or temporary. Unfortunately, temporary applications have an uncanny ability to become permanent production dependencies while retaining their original laboratory-grade security.

Langflow services should be placed behind authenticated gateways and restricted to approved users and devices. Administrative interfaces should not be published directly to the internet.

Execution environments should run with minimal operating-system privileges and inside isolated containers or sandboxes wherever possible.

Langflow compromise requires credential rotation

Installing the corrected version addresses the vulnerable endpoints but does not invalidate secrets already accessed by an attacker.

Organizations should identify every credential available to the affected Langflow instance and rotate it after containment.

This may include model-provider API keys, cloud credentials, database passwords, Git tokens, webhook secrets, OAuth credentials and keys used by connected applications.

Active sessions and issued tokens should be revoked. Unknown users, workflows, components and scheduled tasks should be removed.

Security teams should review whether attackers modified workflows to capture prompts, responses or credentials after the initial compromise.

Outbound connections from the Langflow host should be examined for communication with unfamiliar infrastructure, file-transfer services, cryptocurrency-mining pools or command-and-control servers.

Where system integrity cannot be established, rebuilding the Langflow environment from a trusted image is safer than relying only on an in-place upgrade.

KEV inclusion changes vulnerability priority

All three vulnerabilities were added to the KEV Catalog because CISA identified evidence of active exploitation.

This signal should carry more weight than CVSS severity alone.

The Apache Tomcat flaw has a lower score than the Langflow vulnerability, but confirmed exploitation means it may present greater immediate risk than a higher-scoring weakness that attackers have not weaponized.

Vulnerability management should combine severity, exploitation evidence, internet exposure, asset importance and attacker outcomes.

An externally accessible N-central server can provide administrative access to many endpoints. A vulnerable Langflow instance can provide unauthenticated code execution and expose secrets. A Tomcat cluster may leak sensitive application state across the network.

Each vulnerability creates a different attack path and therefore requires a different investigation.

Security teams should avoid treating the CISA alert as one generic patching task. The affected products occupy different layers of the environment and require product-specific containment and hunting.

The short federal deadline reflects urgency

CISA assigned an August 7, 2026 remediation deadline, only three days after the vulnerabilities were added.

The shortened timeline reflects the reality that actively exploited, reachable vulnerabilities can be weaponized faster than conventional patching cycles can respond.

Attackers do not need to wait for an organization’s next monthly maintenance window. They can scan public infrastructure and target vulnerable systems immediately.

Organizations should maintain emergency update procedures for internet-facing and high-privilege systems.

These procedures should define who can approve urgent changes, how backups are created, how updates are tested and what compensating controls are applied when immediate patching is impossible.

Emergency processes should remain controlled, but they must be practical. A procedure requiring several committees and a week of scheduling is not an emergency procedure. It is a detailed explanation of how the attacker received extra time.

Asset inventory is the first requirement

Organizations cannot remediate these vulnerabilities without knowing where N-central, Apache Tomcat and Langflow are deployed.

N-central instances may be operated by MSPs rather than directly by the organization. Tomcat may be embedded inside commercial products or internal Java applications. Langflow may have been deployed by development or data-science teams outside ordinary infrastructure processes.

Security teams should search software inventories, cloud environments, container registries, network telemetry and procurement records.

External attack-surface monitoring should identify exposed administrative interfaces and application services.

Teams should also ask third-party providers whether they operate any of the affected products on the organization’s behalf.

An unknown deployment remains vulnerable regardless of whether it appears in the asset-management dashboard, which is unfortunate news for anyone who believed spreadsheets exercised authority over reality.

Patching must be verified

After remediation, organizations should confirm the complete product version or build number rather than merely recording that an update command was executed.

For N-central, administrators must ensure the corrected hotfix level is installed and that no older server remains active in a failover or testing environment.

For Apache Tomcat, the patched versions must match the appropriate release branch. Packaged Tomcat versions supplied through operating-system vendors may use different package numbering and should be checked against the vendor’s own security update.

For Langflow, deployments should run version 1.10.1 or later, including container images and dormant instances that may later return to service.

Clusters, replicas and autoscaling templates must also be updated. Replacing one running container while leaving the vulnerable base image in the deployment pipeline merely schedules the vulnerability’s return.

A follow-up vulnerability scan and manual version verification should confirm that remediation succeeded.

Post-exploitation hunting remains essential

Because all three vulnerabilities are actively exploited, organizations should assume that patching may have occurred after attackers already gained access.

N-central environments should be examined for unauthorized administrators, unusual remote sessions and persistence placed on managed endpoints.

Tomcat environments should be reviewed for unexpected cluster participants, abnormal replication traffic, suspicious sessions and activity originating from systems with access to the cluster network.

Langflow systems should be investigated for unknown superuser tokens, modified workflows, unexpected Python execution, new files and connections to unfamiliar destinations.

Logs should be collected centrally because local records on a compromised system may be deleted or altered.

The investigation period should begin before the public disclosure date when possible. Attackers may have exploited the vulnerabilities as zero-days or before defenders understood their significance.

Credential and token exposure should be assessed according to the privileges of the compromised application, not merely the original vulnerability description.

The broader cybersecurity lesson

CISA’s August 4 KEV update demonstrates that attackers target trusted platforms capable of multiplying their access.

N-central can reach managed endpoints, Tomcat can serve critical applications and Langflow can connect AI workflows to cloud services and sensitive data.

The value of these products comes from their connectivity and authority. Those same qualities make them dangerous when compromised.

Organizations should apply the required updates immediately, verify the corrected versions and investigate systems for signs of prior exploitation.

They should also rotate potentially exposed credentials, revoke active sessions and rebuild systems where integrity cannot be established confidently.

The alert reinforces why actively exploited vulnerabilities must be prioritized according to real-world risk rather than numerical severity alone.

A vulnerability becomes significantly more urgent when attackers have demonstrated that it works, useful targets remain exposed and exploitation can lead to broader control of the environment.

Security teams should therefore treat KEV additions as operational triggers. Asset discovery, containment, patching, credential review and threat hunting should begin immediately.

The objective is not simply to remove three vulnerable software versions. It is to determine whether attackers used N-central, Tomcat or Langflow as a doorway and whether they left another entrance behind before that doorway was closed.

CISA has added three new vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog , based on evidence of active exploitation. CVE-2026-9198 IBM Langflow Code Injection Vulnerability CVE-2026-18556 N-able N-central Authentication Bypass Using an Alternate Path or Channel Vulnerability CVE-2026-34486 Apache Tomcat Missing Encryption of Sensitive Data Vulnerability These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities . CISA will continue to add vulnerabilities to the catalog th

Source: CISA Adds Three Known Exploited Vulnerabilities to Catalog via CISA Advisories — published 04 Aug 2026.