CVE-2026-25883
SSRF Vulnerability in Vexa Webhook Allows Internal Service Access
Publication date: 2026-04-20
Last updated on: 2026-04-23
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| vexa | vexa | to 0.10 (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-25883 is a Server-Side Request Forgery (SSRF) vulnerability in the Vexa application's webhook feature. Authenticated users can configure an arbitrary webhook URL that the server calls via HTTP POST requests when meetings complete. The application does not validate these URLs, allowing attackers to make the server send requests to internal services such as Redis, databases, admin panels, localhost services, or cloud metadata endpoints like AWS or GCP.
This means an attacker with valid credentials can exploit this flaw to make the server interact with internal or protected resources that are normally inaccessible, potentially leading to credential theft or unauthorized access within the internal network.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unexpected HTTP POST requests originating from the Vexa server to internal services or unusual URLs configured as webhooks.
A practical detection method involves setting up an HTTP listener to capture outgoing webhook POST requests and verifying if any requests target internal services such as Redis, databases, admin panels, localhost services, or cloud metadata endpoints.
To reproduce and detect the vulnerability, you can:
- Clone and run Vexa with Docker and initialize the database.
- Create a test user and API token.
- Set up an HTTP listener (e.g., using netcat or a simple HTTP server) to capture SSRF requests.
- Configure a malicious webhook URL pointing to the listener.
- Create a test meeting and session, then trigger the webhook via a bot exit callback.
Example commands to set up a listener and detect SSRF requests might include:
- Using netcat to listen on port 8080: `nc -lvp 8080`
- Using curl or similar tools to verify webhook POST requests.
Additionally, reviewing Vexa logs for outgoing HTTP POST requests to unexpected URLs can help identify exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade Vexa to version 0.10.0-260419-1910 or later, where the vulnerability has been patched.
Until the upgrade can be applied, restrict authenticated users' ability to configure arbitrary webhook URLs, especially those pointing to internal or sensitive endpoints.
Implement network-level controls such as firewall rules to block outgoing HTTP requests from the Vexa server to internal services and cloud metadata endpoints.
Monitor webhook configurations and audit logs for suspicious URLs or changes.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The CVE-2026-25883 vulnerability allows an authenticated attacker to perform Server-Side Request Forgery (SSRF) by configuring arbitrary webhook URLs that the Vexa application calls without validation. This can lead to unauthorized access to internal services, cloud metadata endpoints, and potentially sensitive data such as credentials.
Such unauthorized access and potential data exposure can impact compliance with common standards and regulations like GDPR and HIPAA, which require protection of sensitive personal and health information. The SSRF vulnerability could lead to data breaches or unauthorized data access, thereby violating confidentiality requirements mandated by these regulations.
Therefore, until patched, this vulnerability poses a risk to maintaining compliance with data protection and privacy standards by exposing internal resources and sensitive information to attackers.
How can this vulnerability impact me? :
The vulnerability can have significant impacts, especially in self-hosted or cloud deployments of Vexa. An attacker with low privileges and no user interaction can exploit this SSRF to access sensitive internal resources.
- Access internal services such as Redis, databases, and admin panels.
- Reach localhost services that are not exposed externally.
- Access cloud metadata endpoints (AWS/GCP), which can lead to credential theft.
Overall, this can lead to unauthorized internal network access, data exposure, and potential compromise of cloud credentials.