CVE-2026-91080: webhook DOS Memory Exhaustion Vulnerability

CVE-2026-91080 Overview

CVE-2026-91080 is a memory exhaustion vulnerability affecting the webhook project by adnanh through version 2.8.3. The service reads the entire HTTP request body into memory before evaluating trigger rules or validating signatures. Unauthenticated remote attackers can send multi-gigabyte request bodies with invalid signatures to consume all available memory. This behavior triggers out-of-memory conditions and crashes the webhook service. The flaw is classified under CWE-770: Allocation of Resources Without Limits or Throttling.

Critical Impact
Unauthenticated network attackers can crash the webhook service by transmitting oversized request bodies, denying webhook processing to legitimate CI/CD, automation, and integration workflows.

Affected Products

adnanh webhook versions up to and including 2.8.3
Deployments exposing the webhook HTTP listener to untrusted networks
Automation pipelines and integrations relying on webhook as a trigger service

Discovery Timeline

2026-09-14 - CVE-2026-91080 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-91080

Vulnerability Analysis

The webhook binary implements an HTTP listener that accepts POST payloads and evaluates configured trigger rules against the body. The request handler buffers the full body before signature validation or rule matching occurs. Because no upper bound is enforced on body size, a single request can allocate arbitrary amounts of heap memory. Repeated or concurrent oversized requests exhaust process memory and terminate the service.

The issue falls under resource-allocation-without-throttling weaknesses. It does not affect confidentiality or integrity, but availability impact is significant for automation systems that rely on webhook triggers. Public discussion of the flaw is tracked in GitHub Issue #756 and detailed in the VulnCheck Memory Exhaustion Advisory.

Root Cause

The request-handling code in webhook.go reads the full body into memory prior to any authentication or size check. Signature verification, which would normally reject unauthorized senders early, runs only after buffering completes. This ordering makes signature checks useless as a resource guardrail.

Attack Vector

An unauthenticated attacker sends an HTTP POST to any configured webhook endpoint with a body sized in gigabytes. The signature can be invalid because verification occurs after buffering. Each in-flight request consumes memory proportional to the declared or streamed content length. Multiple parallel requests accelerate exhaustion and force process termination by the operating system's OOM killer.

No verified proof-of-concept code has been published. Refer to the VulnCheck advisory and the upstream webhook project for further technical detail.

Detection Methods for CVE-2026-91080

Indicators of Compromise

Sudden termination of the webhook process with OOM-killer log entries in /var/log/syslog or journalctl.
HTTP POST requests to webhook endpoints with Content-Length values in the hundreds of megabytes or gigabytes.
Repeated requests from unauthenticated sources carrying invalid HMAC signatures against configured hooks.

Detection Strategies

Alert on any request to the webhook listener where Content-Length exceeds the expected payload size for legitimate integrations.
Correlate process restarts of the webhook service with inbound HTTP traffic volume spikes.
Monitor for signature validation failures immediately preceding memory pressure events.

Monitoring Recommendations

Track resident set size (RSS) and heap allocations of the webhook process using host metrics.
Log reverse-proxy access records with request-body sizes to preserve forensic evidence.
Enable rate-limit and anomaly telemetry on network devices fronting the webhook listener.

How to Mitigate CVE-2026-91080

Immediate Actions Required

Place webhook behind a reverse proxy such as nginx, HAProxy, or a Web Application Firewall and enforce a maximum request-body size.
Restrict inbound access to the webhook listener to trusted source IP ranges only.
Apply operating-system memory limits (systemd MemoryMax, cgroup limits, or container memory caps) so a crash cannot destabilize the host.

Patch Information

At the time of NVD publication, no fixed release beyond 2.8.3 is referenced in the advisory. Monitor the webhook GitHub project and Issue #756 for a corrective release that enforces body-size limits before buffering.

Workarounds

Configure nginx client_max_body_size (or equivalent) upstream of webhook to reject oversized payloads at the proxy layer.
Require mutual TLS or network-level authentication so only trusted clients reach the webhook endpoint.
Deploy webhook inside a container with a strict memory limit and automatic restart policy to contain the impact of exhaustion attempts.

bash

# Configuration example: nginx reverse-proxy limit in front of webhook
server {
    listen 443 ssl;
    server_name hooks.example.com;

    client_max_body_size 1m;
    client_body_buffer_size 128k;

    location /hooks/ {
        proxy_pass http://127.0.0.1:9000;
        proxy_read_timeout 30s;
        allow 10.0.0.0/8;
        deny all;
    }
}