CVE-2026-5205: Chatwoot Webhook API SSRF Vulnerability

CVE-2026-5205 Overview

A Server-Side Request Forgery (SSRF) vulnerability has been identified in Chatwoot, an open-source customer engagement platform. The vulnerability exists in the Webhooks::Trigger function within the lib/webhooks/trigger.rb component of the Webhook API. By manipulating the url argument, an authenticated attacker can force the server to make arbitrary HTTP requests to internal or external resources, potentially exposing sensitive internal services, bypassing network security controls, or facilitating further attacks.

Critical Impact

Attackers can exploit this SSRF vulnerability to access internal network resources, potentially leading to data exfiltration, internal service enumeration, or pivot attacks against infrastructure not normally accessible from the internet.

Affected Products

• Chatwoot versions up to and including 4.11.2
• Webhook API component (lib/webhooks/trigger.rb)
• Self-hosted Chatwoot installations with webhook functionality enabled

Discovery Timeline

• 2026-03-31 - CVE-2026-5205 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-5205

Vulnerability Analysis

This vulnerability is classified as CWE-918 (Server-Side Request Forgery). The flaw resides in how Chatwoot's Webhook API processes user-supplied URL parameters within the Webhooks::Trigger function. When a webhook is configured or triggered, the application fails to properly validate and sanitize the destination URL, allowing attackers to specify arbitrary targets including internal network addresses, localhost services, and cloud metadata endpoints.

The network-based attack vector with low complexity requirements makes this vulnerability accessible to any authenticated user with webhook configuration privileges. While the vendor was contacted about this disclosure, no response was received, leaving users without an official patch at this time.

Root Cause

The root cause of this vulnerability is insufficient input validation on the url parameter passed to the Webhooks::Trigger function in lib/webhooks/trigger.rb. The application does not implement proper allowlisting or URL scheme restrictions, nor does it block requests to private IP ranges (RFC 1918), loopback addresses, or cloud provider metadata services. This allows the server to be abused as a proxy for making requests to otherwise inaccessible resources.

Attack Vector

The attack is conducted remotely over the network by an authenticated user with access to webhook configuration functionality. The attacker crafts a malicious webhook URL pointing to an internal resource, cloud metadata endpoint (such as http://169.254.169.254/), or other sensitive target. When the webhook is triggered, the Chatwoot server makes the request on behalf of the attacker, returning the response or confirming connectivity to the target.

The vulnerability allows for limited confidentiality, integrity, and availability impact as the attacker can read responses from internal services, potentially modify data through forged requests, and cause resource exhaustion through targeted requests. Technical details regarding the exploitation mechanism can be found in the VulDB submission.

Detection Methods for CVE-2026-5205

Indicators of Compromise

• Webhook configurations containing internal IP addresses (10.x.x.x, 172.16.x.x-172.31.x.x, 192.168.x.x)
• Webhook URLs targeting localhost (127.0.0.1) or IPv6 loopback (::1)
• Requests to cloud metadata endpoints (169.254.169.254) originating from the Chatwoot server
• Unusual outbound HTTP requests from the Chatwoot application to non-standard ports

Detection Strategies

• Monitor webhook creation and modification events for suspicious URL patterns in application logs
• Implement network-level monitoring for outbound requests from the Chatwoot server to internal network ranges
• Deploy web application firewall (WAF) rules to detect and block SSRF attack patterns in webhook configurations
• Review audit logs for webhook configurations targeting cloud metadata endpoints or internal services

Monitoring Recommendations

• Enable verbose logging for the Webhooks::Trigger function to capture all webhook destination URLs
• Configure network intrusion detection systems (IDS) to alert on unexpected internal network traffic from web application servers
• Implement egress filtering and logging to track all outbound HTTP requests from the Chatwoot server
• Set up alerts for webhook configurations that reference private IP ranges or known cloud metadata endpoints

How to Mitigate CVE-2026-5205

Immediate Actions Required

• Audit all existing webhook configurations for suspicious or internal URLs and disable any that appear malicious
• Implement network-level egress controls to restrict outbound connections from the Chatwoot server to approved external endpoints only
• Restrict webhook configuration privileges to only trusted administrative users
• Consider temporarily disabling webhook functionality if not business-critical until a patch is available

Patch Information

No official patch is currently available from the vendor. The vendor was contacted early about this disclosure but did not respond. Users should monitor the Chatwoot GitHub repository for security updates and apply patches immediately when released. Additional vulnerability details are available through VulDB.

Workarounds

• Implement a reverse proxy or WAF rule to validate webhook URLs before they reach the application, blocking requests to internal IP ranges
• Deploy network segmentation to isolate the Chatwoot server from sensitive internal services
• Use URL allowlisting at the application or network level to restrict webhooks to known, trusted external endpoints only
• Block outbound access to cloud metadata endpoints (169.254.169.254) from the Chatwoot server

# Example iptables rules to block common SSRF targets
# Block requests to cloud metadata endpoint
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Block requests to private IP ranges from the Chatwoot server
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP

# Block localhost/loopback (if applicable for your setup)
iptables -A OUTPUT -d 127.0.0.0/8 -j DROP