Withdrawn Advisory: Libredesk has a SSRF Vulnerability in Webhooks

Summary

## Reconsidered - Working as designed. (Update 2026-05-28)

Libredesk is a single-tenant, self-hosted application. Configuring outbound webhook URLs requires an admin-only permission that is not granted by default - the operator must explicitly assign it.

Anyone holding this permission already has full administrative control over the application, and outbound HTTP to operator-chosen URLs is the documented purpose of the webhook feature. This is working as designed.

A SECURITY.md documenting the threat model will be added to the repo shortly.

------------------------------------------------------------------------------------------------------------------------------

**Date:** 2025-12-07 **Vulnerability:** Server-Side Request Forgery (SSRF) **Severity:** Medium **Component:** Webhooks Module

## Executive Summary A critical security vulnerability exists in the LibreDesk Webhooks module that allows an authenticated "Application Admin" to compromise the underlying cloud infrastructure or internal corporate network where this service is being hosted.

The application fails to validate destination URLs for webhooks. This allows an attacker to force the server to make HTTP requests to arbitrary internal destinations.

## Confirmed Attack Vectors

### 1. Internal Port Scanning (Network Mapping) Attackers can map the internal network by observing the difference between successful connections and connection errors. This works even if the response body is not returned.

**Proof of Exploitation (from Server Logs):** * **Open Port (8890)**: The server connects successfully. ```text timestamp=... level=info message="webhook delivered successfully" ... status_code=200 ``` * **Closed Port (8891)**: The server fails to connect. ```text timestamp=... level=error message="webhook delivery failed" ... error="... connect: connection refused" ```

**Impact**: An attacker can identify running services (databases, caches, internal apps) on the local network (e.g., `localhost`, `192.168.x.x`).

### 2. Information Leakage (Error-Based) If the internal service returns a non-2xx response (e.g., 403 Forbidden, 404 Not Found, 500 Error), the application **logs the full response body**.

**Proof of Exploitation (from Server Logs):** ```text timestamp=... level=error message="webhook delivery failed" ... response="{\"secret_key\": \"xxx123\", \"role\": \"admin\"}" ```

**Impact**: An attacker can extract sensitive data by targeting endpoints that return errors or by forcing errors on internal services.

## Technical Root Cause 1. **Missing Input Validation**: `cmd/webhooks.go` only checks if the URL is empty, not if it resolves to a private IP. 2. **Unrestricted HTTP Client**: `internal/webhook/webhook.go` uses a default `http.Client` that follows redirects and connects to any IP. 3. **Verbose Error Logging**: The application logs the full response body on failure, creating a side-channel for data exfiltration.

## Remediation Required To prevent this, the application must implement **Defense in Depth**:

1. **Input Validation**: Block URLs resolving to private IP ranges (RFC 1918) and Link-Local addresses. 2. **Safe HTTP Client**: Use a custom `http.Transport` that verifies the destination IP address *after* DNS resolution to prevent DNS rebinding attacks.