CVE-2026-85667: xiaobei Authentication Bypass Vulnerability

CVE-2026-85667 Overview

CVE-2026-85667 affects xiaobei through version 5.5.2, an open-source agent platform maintained by TeamWiseFlow. The application fails to implement authentication or signature validation on webhook endpoints. Unauthenticated attackers can publish arbitrary messages into the agent pipeline through the /webhook_worktool handler. The same handler fetches media URLs without validation, enabling server-side request forgery (SSRF) against internal services. This weakness is classified under CWE-306: Missing Authentication for Critical Function.

Critical Impact
Remote, unauthenticated attackers can inject messages into the agent pipeline and pivot to internal services through SSRF, compromising confidentiality and integrity of downstream systems.

Affected Products

xiaobei versions up to and including 5.5.2
The awada-server component exposing the /webhook_worktool route
Deployments consuming the agent pipeline downstream of the webhook handler

Discovery Timeline

2026-09-04 - CVE-2026-85667 published to the National Vulnerability Database (NVD)
2026-09-10 - Last updated in the NVD database

Technical Details for CVE-2026-85667

Vulnerability Analysis

The /webhook_worktool route in xiaobei accepts inbound webhook requests without verifying the caller's identity or validating a shared-secret signature. Any network-reachable client can craft a POST request that the server treats as authentic vendor traffic. The handler forwards the payload directly into the agent message pipeline, where downstream consumers process it as trusted input. Because the handler also retrieves referenced media URLs on the server side, an attacker can supply URLs that point to internal HTTP services, cloud metadata endpoints, or loopback administrative interfaces. The resulting requests originate from the xiaobei host and inherit its network trust, converting the webhook into an SSRF proxy. See the GitHub webhook route file for the affected implementation.

Root Cause

The root cause is missing authentication on a critical function [CWE-306]. The webhook handler does not enforce a shared secret, HMAC signature, mTLS, or IP allow-list. It also performs no allow-list validation on media URLs before dereferencing them. Both controls are standard mitigations for public webhook receivers and outbound URL fetchers.

Attack Vector

Exploitation requires only network access to the xiaobei HTTP endpoint. An attacker sends a POST request to /webhook_worktool containing a crafted message and a media URL pointing to an internal resource. The server processes the message and issues a server-side HTTP request to the attacker-supplied URL. This produces two distinct impacts: injection of untrusted content into the agent pipeline, and unauthorized reachability into internal networks. Additional detail is available in the VulnCheck advisory and GitHub issue #440.

No verified proof-of-concept code is published. Refer to the vendor
repository and VulnCheck advisory for technical details.

Detection Methods for CVE-2026-85667

Indicators of Compromise

Inbound HTTP POST requests to /webhook_worktool from source IPs outside the expected upstream vendor ranges
Outbound HTTP requests from the xiaobei host to internal RFC1918 addresses, 127.0.0.1, or cloud metadata endpoints such as 169.254.169.254
Agent pipeline messages containing content that does not correlate with legitimate upstream webhook activity

Detection Strategies

Inspect reverse-proxy or ingress logs for /webhook_worktool requests lacking expected signature headers
Correlate webhook receipt timestamps with subsequent egress requests to identify SSRF chains
Baseline expected outbound destinations from the xiaobei host and alert on deviations, especially to internal ranges

Monitoring Recommendations

Enable verbose HTTP access logging on the awada-server process, including request source, headers, and body size
Forward host process and network telemetry to a centralized data lake for retrospective hunting
Add network policy telemetry to record any connections initiated by xiaobei to non-public destinations

How to Mitigate CVE-2026-85667

Immediate Actions Required

Restrict network reachability of the xiaobei webhook endpoint to trusted upstream provider IP ranges only
Place /webhook_worktool behind a reverse proxy that enforces authentication or shared-secret validation until an upstream fix is available
Block outbound traffic from the xiaobei host to internal management ranges, loopback, and cloud metadata endpoints

Patch Information

No fixed version has been published at the time of NVD entry. Monitor the xiaobei GitHub repository and issue #440 for a vendor patch, and upgrade beyond 5.5.2 once released.

Workarounds

Terminate webhook traffic at a gateway that validates an HMAC signature header before proxying to xiaobei
Deploy an egress proxy that enforces an allow-list of permitted media hostnames for server-side URL fetches
Run the xiaobei container in a network namespace with no route to internal services or cloud metadata addresses

bash

# Example egress restriction using iptables to block SSRF targets
iptables -A OUTPUT -m owner --uid-owner xiaobei -d 169.254.169.254 -j DROP
iptables -A OUTPUT -m owner --uid-owner xiaobei -d 127.0.0.0/8 -j DROP
iptables -A OUTPUT -m owner --uid-owner xiaobei -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -m owner --uid-owner xiaobei -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -m owner --uid-owner xiaobei -d 192.168.0.0/16 -j DROP