An attacker anywhere on the internet can impersonate a trusted system inside your AI agent platform — without ever needing a password.
Who's Affected and Why It Matters
Rowboat, an open-source framework built by rowboatlabs for orchestrating multi-agent AI systems, is used by developers and organizations building autonomous AI workflows — the kind of infrastructure that can browse the web, call APIs, execute code, and interact with sensitive business data on your behalf. All versions up to and including 0.1.67 contain this flaw.
The exact number of production deployments isn't publicly known, but rowboat has gained traction in the fast-growing AI agent tooling space, where teams move quickly and security review often lags behind deployment. If your organization has stood up a rowboat instance — even internally — this vulnerability is relevant to you right now. And because the exploit has already been made publicly available, the clock is ticking.
What an Attacker Can Actually Do
Imagine your AI agent platform is a secure office building. Every visitor is supposed to show a verified badge at the front desk before being let in. That badge contains cryptographically signed information proving who you are and what you're allowed to do. Now imagine someone discovered they could walk up to the front desk, scribble their own name on a piece of paper, hand it over, and be waved straight through — because the guard stopped checking whether the badge was real.
That's essentially what's happening here. Rowboat's experimental tools webhook component accepts a special header in incoming web requests — think of it like a digital handshake — that is supposed to prove the request is coming from a legitimate, authorized source. But due to the way the application processes this header, an attacker can craft a manipulated version of it and send it from anywhere on the internet. The server accepts it without properly verifying its legitimacy. Authentication is bypassed entirely.
Once inside, an attacker isn't just a passive observer. The tools webhook component is specifically designed to trigger actions — calling external tools, firing off automated processes, and interacting with the broader agent pipeline. A successful exploit could mean an attacker causes your AI agents to execute unauthorized commands, exfiltrate data, interact with connected APIs using your credentials, or serve as a foothold for deeper compromise of your infrastructure. The danger scales directly with how much you've given your agents permission to do.
The Technical Detail Security Teams Need
The vulnerability lives in a single function: tool_call(), located in apps/experimental/tools_webhook/app.py. The attack vector is manipulation of the X-Tools-JWE request header — a JSON Web Encryption token that is supposed to authenticate inbound webhook calls. The flaw is classified as improper authentication (CWE-287), meaning the application fails to adequately verify that the entity sending the request is who it claims to be. This is not a subtle logic bug — it's a fundamental breakdown in the authentication gate for an externally reachable endpoint. The vulnerability carries a CVSS score of 7.3 (HIGH) and is exploitable remotely with no authentication required as a prerequisite.
How This Came to Light — and What the Vendor Did (and Didn't Do)
The vulnerability was publicly disclosed as CVE-2026-6635. In a detail that should concern anyone running rowboat in production, the researcher who discovered this flaw followed responsible disclosure practices and contacted rowboatlabs before going public. The vendor did not respond in any way. As a result, the exploit details are now publicly available with no official patch, no advisory from the vendor, and no coordinated fix to point users toward.
This is exactly the scenario defenders dread: a high-severity, remotely exploitable authentication bypass, with working exploit code in the wild, and no vendor patch to apply. While there is no confirmed active exploitation in the wild at time of publication, the combination of public exploit availability and vendor silence means that window could close quickly. Security teams should treat this as urgent.
What You Should Do Right Now
Here are three specific, actionable steps — in order of priority:
-
Immediately disable or isolate the tools_webhook component. If you are running rowboat version 0.1.67 or earlier, locate the
apps/experimental/tools_webhook/directory and disable or block external access to that endpoint at your network perimeter or reverse proxy level. This component is explicitly flagged as experimental — it should not be exposed to untrusted networks under any circumstances until a patch is available. Block all inbound requests that include theX-Tools-JWEheader at your edge if you cannot disable the component entirely. -
Audit your logs for unexpected webhook calls. Search your application and access logs for any requests hitting the tools_webhook endpoint — particularly any that arrived from unexpected IP addresses or at unusual times. Look specifically for requests carrying the
X-Tools-JWEheader. If you find anomalous entries, treat your environment as potentially compromised and begin incident response procedures. -
Monitor the rowboatlabs GitHub repository for a patched release above version 0.1.67. Since the vendor has not yet responded publicly, the most reliable signal that a fix exists will be a new release tag or a commit addressing this component. Subscribe to release notifications on the repository. Do not upgrade to any version above 0.1.67 without first verifying the changelog explicitly addresses CVE-2026-6635. If no patch is forthcoming and rowboat is critical to your operations, consider forking the repository and implementing your own JWE signature validation in the
tool_call()function as a temporary mitigation.
CVE: CVE-2026-6635 | CVSS: 7.3 (HIGH) | Affected versions: rowboatlabs/rowboat ≤ 0.1.67 | Patch available: No (as of publication) | Active exploitation: Not confirmed, but exploit is public