The U.S. Cybersecurity and Infrastructure Security Agency today added three actively exploited vulnerabilities to its Known Exploited Vulnerabilities catalog — including the original N-able N-central authentication bypass that an incomplete patch failed to close, giving attackers a second way into RMM consoles managing hundreds of client organizations simultaneously. Federal Civilian Executive Branch agencies have until August 7 to patch all three. Private-sector organizations should treat that deadline as a floor, not a ceiling.
N-able confirmed earlier this week that attackers exploited the flaw to gain administrative access to N-central servers, then pivoted through the platform’s built-in Take Control feature into the managed endpoints of the MSP’s clients. N-central describes itself as a centralized console for monitoring, patching, and remotely controlling servers and workstations across an MSP’s entire customer base — serving more than 25,000 MSP partners and tens of millions of managed endpoints globally. A compromised N-central instance is not one organization at risk; it is a master key to every organization that MSP manages.
If Your IT Is Managed by an MSP, This Breach May Already Affect You
The most consequential detail in N-able’s incident timeline is one that does not appear in any headline: you do not need to run N-central to be exposed by this vulnerability. If your organization’s IT infrastructure is managed by a third-party service provider that uses N-central — and tens of millions of endpoints globally fit that description — attackers who compromised your MSP’s console may have already reached your domain controllers, file servers, and workstations.
N-able traced the incident to July 31, 2026, when a surge in customer licensing anomalies triggered a deeper engineering and security investigation. What that investigation revealed — documented in N-able’s security update blog — was a two-stage breach: attackers had first found and exploited CVE-2026-18556, an authentication bypass the company believed it had closed in N-central version 2026.2. When the August 2 investigation uncovered a second, alternate route to exploit the same underlying weakness, a fresh fix was urgently developed and a new CVE — CVE-2026-18577 — was assigned. CISA added CVE-2026-18577 to the KEV catalog on Monday, August 4. Today’s addition of the original CVE-2026-18556 signals that the agency has confirmed both bypass paths are being exploited in the wild.
Security researchers at Huntress, responding to the active exploitation, confirmed seeing the same attack pattern across multiple organizations in their partner base. After gaining N-central access, threat actors immediately began targeting domain controllers — the most sensitive servers in most corporate environments — rather than randomly pivoting, which Huntress assessed as deliberate, strategic reconnaissance. Attackers then installed a Cloudflare tunnel registered as a Windows service, a technique that creates an encrypted, outbound-only persistence channel that survives reboots and circumvents traditional firewall blocking. As of the August 3 afternoon update from Huntress, 28.6% of reachable self-hosted N-central servers in their partner network were still unpatched, according to their active investigation.
N-able’s corrective build is version 2026.3.1.7. Organizations — and critically, the clients of any MSP that uses N-central — should confirm with their service provider that this specific build is installed. Upgrading to the base 2026.3 release is not sufficient; that version remained vulnerable until Hotfix 1 was applied.
What Went Wrong: The “Fail-Open” Lesson in Patch Engineering
The N-central incident illustrates a documented failure pattern in vulnerability remediation: a fix that closes the originally reported attack path while leaving an alternate route open. CVE-2026-18556 was the original flaw — an authentication bypass via an alternate path (CWE-288) that let an unauthenticated attacker gain full administrative access to an N-central server. N-able patched it in version 2026.2 and considered the issue resolved.
On August 2, attackers demonstrated that the underlying weakness had a second exploitable path — one that the 2026.2 fix did not address. This prompted the assignment of CVE-2026-18577 and an emergency hotfix. The sequence matters because many organizations operating standard change-management workflows would have closed the remediation ticket when they confirmed installation of 2026.2 or the base 2026.3 release, leaving themselves exposed.
CISA’s same-week inclusion of both CVEs in the KEV catalog carries a specific operational message: evidence of active exploitation exists for both the original bypass and the incomplete-patch bypass. Organizations that installed 2026.3 but not the 2026.3.1.7 hotfix are still running a vulnerable instance with a confirmed in-the-wild exploit.
The parallel to CVE-2026-34486 in Apache Tomcat is instructive. That flaw, also added to the KEV catalog today, traces directly to a prior security fix that introduced a new, more severe problem. The original patch for a Tomcat clustering padding-oracle vulnerability (CVE-2026-29146) altered the control flow of the EncryptInterceptor component in a way that caused decryption failures to fail open rather than fail closed. When decryption fails on an incoming message — as it will for any attacker-supplied bytes that cannot be properly decrypted — the unmodified code logs an error but then continues routing the raw bytes into the Java deserialization engine listening on TCP port 4000. If usable gadget classes from libraries like Commons-Collections are on the application’s classpath, this path yields unauthenticated remote code execution. Palo Alto Networks Unit 42 documented a Chinese-speaking threat actor exploiting CVE-2026-34486 to deploy Java deserialization-based reverse shells against vulnerable clustered Tomcat instances as part of a broader AI-enabled hacking campaign.
Langflow Earns Its Third KEV Entry: What CVE-2026-9198 Does Differently
Langflow, the open-source AI application development platform, today received its third addition to the CISA KEV catalog in less than a year. CVE-2026-9198 (CVSS 9.8) is a code-injection vulnerability in all Langflow versions from 1.0.0 through 1.10.0 that enables unauthenticated, full remote code execution on default-configured instances, as documented in IBM’s security bulletin.
The mechanism IBM’s advisory documented is a two-endpoint chain. An unauthenticated caller can reach the /api/v1/auto_login endpoint to receive a valid SUPERUSER bearer token — no credentials required under default settings. That token then grants access to the /api/v1/validate/code endpoint, which passes user-supplied Python code directly to Python’s exec() function. A public proof-of-concept exploit is now circulating, with additional reporting confirming that exploit-development artifacts including targeting lists have been observed in the wild. The fix is Langflow version 1.10.1.
Langflow has become a persistent target for the most sophisticated autonomous attack operations documented to date. The JADEPUFFER agent — an AI-driven operator documented by Sysdig researchers in July 2026 — exploited an earlier Langflow flaw to access and destroy production databases, later returning with the ENCFORGE ransomware specifically designed to encrypt model weights, vector indexes, and training datasets. The platform’s high value as a target stems from the credentials Langflow deployments typically hold: API keys for major model providers, cloud infrastructure access tokens, and database connection strings for production services.
CISA has not disclosed how CVE-2026-9198 is being actively exploited. Given the platform’s track record and the availability of public exploit code, organizations running internet-exposed Langflow instances should treat the upgrade to 1.10.1 as immediately required.
Who Was Exploiting the Tomcat Flaw: The AI-Enabled Campaign
The attribution context for CVE-2026-34486 in Apache Tomcat connects it to a documented campaign Unit 42 published on July 30, 2026 — the same research that identified a Chinese-speaking threat actor operating under the aliases knaithe and KnYuan who had wired the DeepSeek large language model into the open-source Hermes Agent framework to conduct autonomous offensive operations. That campaign, extensively documented by TechTimes last week, targeted over 460 organizations using a combination of autonomous AI-directed reconnaissance and manual exploitation.
The Tomcat exploitation took place in the manual phase of knaithe’s campaign. Unit 42 confirmed that alongside CVE-2026-34486, the actor exploited flaws in Citrix NetScaler and Marimo Notebook, achieving confirmed data exfiltration from three NetScaler targets and code execution on 11 Marimo instances. The autonomous DeepSeek-driven attack chains, by contrast, failed to compromise any server — stopped not by detection systems but by the presence of authentication requirements on targeted deployments.
The significance of CISA’s KEV additions today is not that the Tomcat exploitation is new — Unit 42 documented it last week. It is that CISA’s formal confirmation of active exploitation triggers mandatory remediation requirements for federal agencies and provides independent institutional corroboration for the urgency any Tomcat operator in a clustered configuration should feel.
Recommended Actions: What to Do Before August 7
For organizations running any of the three affected platforms, the August 7 FCEB deadline should be treated as applicable regardless of sector.
N-able N-central: Upgrade immediately to version 2026.3.1.7. Do not assume version 2026.2 or the base 2026.3 release is safe — confirmed exploitation exists for both the original flaw and the incomplete-patch bypass. After patching, review all administrator login activity for sessions from unexpected IP ranges, unusual geolocations, or times outside normal operations. Audit all N-central Take Control sessions targeting domain controllers and critical servers. Search managed Windows endpoints for files named svchost.exe in user document directories, and for registered Windows services named Cloudflared — N-able’s published indicators of compromise for post-exploitation persistence. Consider restricting N-central console access to known IP ranges if the console is currently reachable from the open internet. Clients who use MSPs should request written confirmation from their service provider that the 2026.3.1.7 hotfix has been applied.
Apache Tomcat: Patch to 11.0.21, 10.1.54, or 9.0.117 depending on the installed branch. Organizations running Tomcat in clustered configurations — where the Tribes component and EncryptInterceptor are active — face the most direct exposure. If the Tribes receiver port (TCP/4000) is reachable from untrusted network segments, treat this as a critical-priority update.
Langflow: Upgrade to version 1.10.1. Any Langflow instance reachable from the internet without an authenticating reverse proxy or VPN should be treated as a critical-priority target. Rotate all API keys, model provider credentials, and cloud access tokens stored in Langflow flows on any instance that may have been exposed — IBM’s bulletin details the full exposure. Audit hosts for new cron entries, new SSH authorized keys, and unexpected outbound connections.
CISA’s complete Known Exploited Vulnerabilities catalog is available at the CISA KEV catalog page.
Frequently Asked Questions
Is my business at risk if I use a managed service provider that runs N-central?
Potentially yes — without having done anything wrong yourself. N-central is the central console through which MSPs manage and remotely access their clients’ endpoints. If an attacker gains administrative access to your MSP’s N-central server, they have the same access to your systems that your MSP’s own technicians hold: the ability to push scripts, open remote-control sessions, deploy software, and access domain controllers and file servers. N-able has confirmed that active exploitation is occurring, and Huntress’s research as of August 3 found that a significant fraction of self-hosted N-central servers were still unpatched. Clients of MSPs should request written confirmation from their service provider that N-central version 2026.3.1.7 has been installed, and should review any recent domain-controller or file-server activity for unexplained sessions.
Why did patching N-central to version 2026.2 or 2026.3 fail to fully protect against this vulnerability?
N-able’s original fix for CVE-2026-18556 addressed the specific authentication bypass path the company had identified at the time. When exploitation continued after that fix was deployed, a deeper investigation on August 2 revealed a second, alternate path to the same underlying weakness — a route the 2026.2 patch had not closed. This second path is now tracked as CVE-2026-18577. N-able released an emergency hotfix to address it, and the corrective build is 2026.3.1.7. Organizations that updated to 2026.3 and considered the matter resolved were still running a vulnerable version until the hotfix was installed. Both CVEs are now in CISA’s Known Exploited Vulnerabilities catalog, confirming that both attack paths have been used against real targets.
How does the Apache Tomcat flaw work, and who is most at risk?
CVE-2026-34486 exploits a bug introduced by a prior security fix in Tomcat’s EncryptInterceptor, the component responsible for encrypting messages between nodes in a clustered Tomcat deployment. The fix for an earlier vulnerability accidentally changed the control flow so that when incoming messages fail decryption, the raw attacker-supplied bytes are still passed to Tomcat’s Java deserialization engine rather than being discarded. An attacker who can reach the Tribes receiver port (TCP/4000) and whose target has vulnerable library versions on the classpath can turn this decryption failure into unauthenticated remote code execution. Organizations most at risk are those running Tomcat in clustered configurations — common in large-scale enterprise and cloud environments — where the Tribes component is active and the receiver port is reachable from untrusted networks. The fix is available in Tomcat versions 11.0.21, 10.1.54, and 9.0.117.
Which version of Langflow patches CVE-2026-9198, and what does the vulnerability actually allow an attacker to do?
Langflow 1.10.1 patches CVE-2026-9198. The vulnerability affects versions 1.0.0 through 1.10.0 on default-configured deployments. An unauthenticated attacker can chain two API endpoints: first, the /api/v1/auto_login endpoint issues a SUPERUSER-level bearer token to any network caller without requiring credentials; second, the /api/v1/validate/code endpoint executes arbitrary Python code supplied by the caller via Python’s exec() function. The result is full, unauthenticated remote code execution on the host running Langflow — without any account, without any phishing, and without any prior foothold. Because Langflow deployments typically store API keys for AI model providers, cloud credentials, and database connection strings, a compromised Langflow instance provides an attacker with broad lateral-movement capability beyond the Langflow server itself.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.