Skip to content
Back to Regulated Cyber
Alerts & Updates 4 min readCritical

CISA Adds Three Actively Exploited Vulnerabilities to Its KEV Catalog in One Bulletin, All Now Patched

Langflow, N-able N-central, and Apache Tomcat share no code and no vendor, but the pattern behind all three is one every product security team managing vendor risk should notice.

Andrew Chukwu, CISSP

Andrew Chukwu, CISSP, MBA | Editor-in-Chief

Aug 5, 2026

On August 4, 2026, the US Cybersecurity & Infrastructure Security Agency otherwise known as CISA, added three new vulnerabilities to its Known Exploited Vulnerabilities Catalog in the same bulletin. IBM's Langflow, an open source AI workflow tool, had an unauthenticated flaw that let an attacker skip login entirely and run their own code on the server. N-able's N-central, a remote monitoring platform IT service providers use to manage client networks, had a second authentication bypass surface after the company's first fix left a gap, and attackers used it before the follow-up patch arrived. Apache Tomcat, a web server software that supports a large share of Java-based applications, had a new bypass of an encryption safeguard, introduced by an earlier security fix that changed how the software handles certain network traffic. CISA's KEV listing confirms attackers are actively exploiting all three. Fixed versions are available for each, and none require special hardware or licensing to apply.

CISA KEV Catalog Additions
CVE IDVendor / ProductVulnerabilityDate publishedSeverityCVSSFix status
CVE-2026-9198IBM/Langflow OSSIBM Langflow Code Injection Vulnerability4th August, 2026Critical9.8Fixed
CVE-2026-18556N-able/N-centralUnauthenticated administrative account takeover4th August, 2026High8.2Fixed
CVE-2026-34486Apache Software Foundation/Apache TomcatApache Tomcat Missing Encryption of Sensitive Data Vulnerability4th August, 2026High7.5Fixed
These vulnerabilities are actively exploited in the wild and carry significant risk. Under CISA's Binding Operational Directive 26-04, US federal civilian agencies must prioritise remediation of these vulnerabilities based on risk; all other organisations are strongly urged to do the same.

It is important to note that none of these three tools is a medical device, and none are marketed to healthcare specifically. However, what connects them to this industry is where they tend to sit in the attack chain. Open source AI tools like Langflow often get adopted informally by medtech engineering teams for prototyping outside the software inventory a security team actively tracks. Remote monitoring platforms like N-central are frequently how a managed service provider administers the network of a healthcare organization or device manufacturer that outsources its IT. Tomcat also supports a large share of the web applications many organizations run without close visibility into that layer. The thread connecting all three is that a vulnerability in a tool you did not build is still your risk if it sits inside your network, or your vendor's. That is the logic behind regulatory requirements such as HIPAA's third party risk assessment requirement and the EU's NIS2 supply chain obligations, neither limits an organization's responsibility to software it owns outright.

Recommendations for This Week

  • Confirm whether your organization, or any vendor with access to your network, runs Langflow, N-central, or Tomcat with clustering enabled, and check the exact version against the Per-CVE Snapshot table above.

  • Patch each to its fixed line: Langflow to 1.10.1, N-central to build 2026.3.1.10 or later (not just 2026.3.1.7, N-able's own hardening did not stop at the first hotfix), and Tomcat to 11.0.21, 10.1.54, or 9.0.117 depending on your branch.

  • For N-central and Tomcat specifically, retest that the original exploit path is actually closed after patching rather than relying on the version number alone. Both flaws exist because an earlier vendor fix left a gap.

  • Ask every IT vendor or managed service provider with access to your network which of these three tools they run, and confirm their patch timeline.

  • Apply mitigations in accordance with each vendor's own instructions, and treat compliance with CISA's BOD 26-04, Prioritizing Security Updates Based on Risk, as the operative federal benchmark for how fast this class of finding should move through your patch queue, even if you're not a federal agency yourself.

Key Takeaways
Three different vendors, one CISA bulletin, and a shared lesson. Patch status on tools you did not build is still worth tracking, especially the ones your vendors run on your behalf. Fixes are available for all three now. Compliance gets you in the door, resilience is what keeps a bulletin like this from becoming your incident.

Sources:

How did this land?

Be the first to react.

Share this alert
LinkedInEmail