CVE-2026-6119
Server-Side Request Forgery in AstrBot API Endpoint post_data.get
Publication date: 2026-04-12
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| astrbotdevs | astrbot | to 4.22.1 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-6119 is a Server-Side Request Forgery (SSRF) vulnerability found in AstrBot versions up to 4.22.1. It occurs because several API endpoints accept user-controlled URL or proxy parameters and perform server-side HTTP requests without validating these inputs. This lack of validation allows attackers to manipulate the server into making unauthorized HTTP requests to internal network services, cloud metadata endpoints, or other restricted resources.
- Affected API endpoints include POST /api/plugin/install, /api/stat/test-ghproxy-connection, /api/update/do, and /api/kb/document/upload/url.
- The vulnerability arises from passing user-supplied URLs or proxy parameters directly to HTTP client functions without checks for private IP ranges, loopback addresses, link-local addresses, or dangerous URL schemes.
- Attackers can exploit this by sending crafted requests with malicious proxy or URL parameters, causing the server to make unauthorized requests internally.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows unauthorized internal network access and potential exposure of sensitive data such as cloud metadata and internal services. This could lead to unauthorized data access or exfiltration, which may impact compliance with data protection regulations like GDPR and HIPAA that require safeguarding personal and sensitive information.
Specifically, the SSRF vulnerability could enable attackers to access internal resources and credentials, increasing the risk of data breaches and unauthorized disclosure of protected data, thereby potentially violating regulatory requirements for confidentiality, integrity, and availability of data.
However, the provided information does not explicitly mention compliance impacts or specific regulatory considerations.
How can this vulnerability impact me? :
This vulnerability can have several serious impacts if exploited:
- Unauthorized access to internal network services such as databases, caches, and admin panels that are normally protected by firewalls.
- Access to cloud instance metadata endpoints, which can expose sensitive information like IAM credentials.
- Internal network scanning and mapping, which can aid attackers in further exploitation.
- Data exfiltration by reading responses from internal services that should not be accessible externally.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unusual server-side HTTP requests originating from the AstrBot application to internal or restricted IP ranges, such as private IPs (10.x.x.x, 172.16-31.x.x, 192.168.x.x), loopback addresses (127.0.0.1), link-local addresses (169.254.x.x), or cloud metadata endpoints (169.254.169.254).
Detection can also involve checking for suspicious POST requests to the vulnerable API endpoints that include user-controlled parameters like 'proxy', 'proxy_url', or 'url'. These endpoints require JWT authentication.
Suggested commands to detect exploitation attempts include:
- Use network monitoring tools (e.g., tcpdump or Wireshark) to capture outgoing HTTP requests from the AstrBot server to internal IP addresses or unusual destinations.
- Example tcpdump command to capture traffic to internal IP ranges: tcpdump -i <interface> 'dst net 10.0.0.0/8 or dst net 172.16.0.0/12 or dst net 192.168.0.0/16 or dst host 169.254.169.254'
- Check AstrBot server logs for POST requests to the following endpoints with suspicious parameters: /api/plugin/install, /api/stat/test-ghproxy-connection, /api/update/do, /api/kb/document/upload/url.
- Use curl or similar tools with a valid JWT token to test these endpoints for SSRF by sending crafted POST requests with proxy or url parameters pointing to internal IPs or local listeners.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include implementing strict validation and restrictions on user-supplied URLs and proxy parameters in the affected API endpoints.
- Block requests to private/internal IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x), loopback addresses (127.0.0.1), link-local addresses (169.254.x.x), and cloud metadata endpoints (169.254.169.254).
- Restrict allowed URL schemes to only 'http' and 'https' to prevent dangerous schemes like 'file://' or 'gopher://'.
- Resolve DNS names before making requests and verify that the resolved IP addresses are not internal or restricted.
- Validate proxy parameters against a trusted allowlist to prevent arbitrary proxy usage.
- Limit the number of redirects and re-validate each redirect target to avoid bypassing restrictions.
Since the project has not yet responded with a patch, consider monitoring and restricting access to the vulnerable endpoints and applying network-level controls to prevent unauthorized internal requests from the AstrBot server.