GHSA-WGM6-9RVV-3438

Vulnerability from github – Published: 2026-02-18 00:56 – Updated: 2026-02-20 16:46
VLAI?
Summary
Libredesk has a SSRF Vulnerability in Webhooks
Details

Date: 2025-12-07 Vulnerability: Server-Side Request Forgery (SSRF) 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):

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.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/abhinavxd/libredesk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.2-0.20260215211005-727213631ce6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26957"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-18T00:56:30Z",
    "nvd_published_at": "2026-02-20T00:16:15Z",
    "severity": "MODERATE"
  },
  "details": "**Date:** 2025-12-07\n**Vulnerability:** Server-Side Request Forgery (SSRF)\n**Component:** Webhooks Module\n\n## Executive Summary\nA 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.\n\nThe application fails to validate destination URLs for webhooks. This allows an attacker to force the server to make HTTP requests to arbitrary internal destinations.\n\n## Confirmed Attack Vectors\n\n### 1. Internal Port Scanning (Network Mapping)\nAttackers 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.\n\n**Proof of Exploitation (from Server Logs):**\n*   **Open Port (8890)**: The server connects successfully.\n    ```text\n    timestamp=... level=info message=\"webhook delivered successfully\" ... status_code=200\n    ```\n*   **Closed Port (8891)**: The server fails to connect.\n    ```text\n    timestamp=... level=error message=\"webhook delivery failed\" ... error=\"... connect: connection refused\"\n    ```\n\n**Impact**: An attacker can identify running services (databases, caches, internal apps) on the local network (e.g., `localhost`, `192.168.x.x`).\n\n### 2. Information Leakage (Error-Based)\nIf the internal service returns a non-2xx response (e.g., 403 Forbidden, 404 Not Found, 500 Error), the application **logs the full response body**.\n\n**Proof of Exploitation (from Server Logs):**\n```text\ntimestamp=... level=error message=\"webhook delivery failed\" ... \nresponse=\"{\\\"secret_key\\\": \\\"xxx123\\\", \\\"role\\\": \\\"admin\\\"}\"\n```\n\n**Impact**: An attacker can extract sensitive data by targeting endpoints that return errors or by forcing errors on internal services.\n\n## Technical Root Cause\n1.  **Missing Input Validation**: `cmd/webhooks.go` only checks if the URL is empty, not if it resolves to a private IP.\n2.  **Unrestricted HTTP Client**: `internal/webhook/webhook.go` uses a default `http.Client` that follows redirects and connects to any IP.\n3.  **Verbose Error Logging**: The application logs the full response body on failure, creating a side-channel for data exfiltration.\n\n## Remediation Required\nTo prevent this, the application must implement **Defense in Depth**:\n\n1.  **Input Validation**: Block URLs resolving to private IP ranges (RFC 1918) and Link-Local addresses.\n2.  **Safe HTTP Client**: Use a custom `http.Transport` that verifies the destination IP address *after* DNS resolution to prevent DNS rebinding attacks.",
  "id": "GHSA-wgm6-9rvv-3438",
  "modified": "2026-02-20T16:46:10Z",
  "published": "2026-02-18T00:56:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/abhinavxd/libredesk/security/advisories/GHSA-wgm6-9rvv-3438"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26957"
    },
    {
      "type": "WEB",
      "url": "https://github.com/abhinavxd/libredesk/commit/727213631ce6a36bcb06f50ce542155e78f51316"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/abhinavxd/libredesk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Libredesk has a SSRF Vulnerability in Webhooks"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…