CVE-2026-16015: poco-ai poco-claw Auth Bypass Vulnerability

CVE-2026-16015 Overview

CVE-2026-16015 is a missing authentication vulnerability in the poco-ai poco-claw project through version 0.5.4. The flaw resides in the create_task function within executor_manager/app/api/v1/tasks.py, part of the executor_manager API component. An adjacent network attacker can invoke manager API endpoints without presenting valid credentials or tokens. The vulnerability is classified under [CWE-287: Improper Authentication]. The exploit has been publicly disclosed, though no active exploitation in the wild has been confirmed. Upgrading to version 0.5.7 remediates the issue via commit 67fcc88505c57f77d3fcf04eb5b89425b10cbf48.

Critical Impact
Unauthenticated adjacent network attackers can invoke executor_manager task creation endpoints, enabling unauthorized task execution and manipulation of managed workloads.

Affected Products

poco-ai poco-claw versions up to and including 0.5.4
executor_manager API component (executor_manager/app/api/v1/tasks.py)
Deployments exposing manager APIs on adjacent networks

Discovery Timeline

2026-07-17 - CVE-2026-16015 published to NVD
2026-07-17 - Last updated in NVD database

Technical Details for CVE-2026-16015

Vulnerability Analysis

The poco-claw project exposes an executor_manager service that orchestrates task execution through a REST API. The create_task endpoint defined in executor_manager/app/api/v1/tasks.py accepted requests without validating any authentication token. Callers on adjacent networks could reach the manager endpoint and submit task creation requests directly. The upstream fix, applied in commit 67fcc88505c57f77d3fcf04eb5b89425b10cbf48, introduces a shared secret header (X-Internal-Token) that internal callers must present. Prior to the fix, the backend HTTP client did not attach this header, and the executor manager did not require it. The vulnerability is tracked under [CWE-287] and carries an EPSS probability of 0.384%.

Root Cause

The root cause is the absence of an authentication check on the executor_manager API surface. The service trusted any caller that could reach the network endpoint, an assumption that fails when the manager is exposed beyond an isolated interface. Both the client (executor_manager_client.py) and the schedules route (schedules.py) omitted the internal token header when issuing requests, and the server accepted requests without verifying it.

Attack Vector

Exploitation requires network reachability to the executor_manager API from an adjacent network segment. No privileges and no user interaction are required. An attacker sends a crafted HTTP request to the create_task endpoint to trigger task creation without authentication. The following patch demonstrates the fix that adds an internal token to outbound requests:

python

     url = f"{settings.executor_manager_url}/api/v1/schedules"
 
     try:
-        headers = {"accept": "application/json"}
+        headers = {
+            "accept": "application/json",
+            "X-Internal-Token": settings.internal_api_token,
+        }
         request_id = get_request_id()
         if request_id:
             headers["X-Request-ID"] = request_id

Source: GitHub Commit 67fcc88

A second hunk from the same commit updates the client to attach the token on every call:

python

     def __init__(self) -> None:
         settings = get_settings()
         self._base_url = (settings.executor_manager_url or "").rstrip("/")
+        self._internal_headers = {"X-Internal-Token": settings.internal_api_token}
         self._client = httpx.Client(
             base_url=self._base_url,
             timeout=httpx.Timeout(connect=3.0, read=10.0, write=10.0, pool=3.0),

Source: GitHub Commit 67fcc88

Detection Methods for CVE-2026-16015

Indicators of Compromise

HTTP requests to /api/v1/tasks or /api/v1/schedules on the executor_manager service that lack an X-Internal-Token header.
Task creation events in executor_manager logs originating from source addresses outside the expected internal caller set.
Unexpected spikes in create_task invocations on poco-claw versions at or below 0.5.4.

Detection Strategies

Enable HTTP access logging on the executor_manager service and alert when requests to create_task arrive without the X-Internal-Token header.
Compare deployed poco-claw versions against the fixed release 0.5.7 across inventory to identify vulnerable hosts.
Correlate task creation entries with authenticated frontend sessions and flag orphaned tasks that have no matching upstream request.

Monitoring Recommendations

Monitor network flows between adjacent subnets and the executor_manager listener for direct connections that bypass the frontend service.
Track process and container launches initiated by the executor to detect anomalous task payloads created through the unauthenticated endpoint.
Ingest poco-claw application logs into a central log platform and build queries that surface requests missing expected internal headers.

How to Mitigate CVE-2026-16015

Immediate Actions Required

Upgrade poco-claw to version 0.5.7 or later, which enforces the X-Internal-Token header on manager APIs.
Restrict network access to the executor_manager listener so only the backend service can reach it, using firewall rules or Kubernetes NetworkPolicies.
Rotate any internal_api_token values that may have been distributed in test or staging environments before upgrade.
Review executor_manager logs for prior unauthenticated create_task invocations that predate the upgrade.

Patch Information

The fix is delivered in the GitHub Release v0.5.7 and corresponds to commit 67fcc88505c57f77d3fcf04eb5b89425b10cbf48. The patch adds an X-Internal-Token header requirement to manager API calls and configures the backend HTTP client to attach the token on every request. See the GitHub Pull Request #135 and the tracking issues #136 and #137 for context.

Workarounds

Place the executor_manager service behind a reverse proxy that enforces mutual TLS or a static header check until the upgrade is deployed.
Bind the executor_manager listener to a loopback interface or a private overlay network unreachable from adjacent segments.
Deploy host-based firewall rules that permit inbound traffic to the manager port only from the backend service address.

bash

# Example: restrict executor_manager port to backend host only (iptables)
iptables -A INPUT -p tcp --dport 8080 -s <backend_service_ip> -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -j DROP