CVE-2026-15996: 
GitHub Enterprise Server vulnerability analysis and mitigation

CVE-2026-15996 is a denial of service (DoS) vulnerability in GitHub Enterprise Server (GHES) that allows an unauthenticated remote attacker to cause excessive CPU consumption and exhaust the pool of request-handling worker processes, rendering the instance unresponsive. The vulnerability affects all versions of GitHub Enterprise Server prior to 3.21, specifically versions 3.17.0–3.17.15, 3.18.0–3.18.9, 3.19.0–3.19.6, and 3.20.0–3.20.2. It was published on August 5, 2026, and fixed in versions 3.17.16, 3.18.10, 3.19.7, and 3.20.3. It carries a CVSS v4.0 base score of 6.6 (Medium) (Github Advisory).

The root cause is classified as CWE-674 (Uncontrolled Recursion): the server's HTTP request parameter parser processes deeply nested form-encoded parameters recursively without enforcing a depth limit, leading to unbounded CPU consumption (Github Advisory). Critically, request parameters are parsed before routing and authentication occur, meaning any HTTP POST endpoint on the server can be used to trigger the condition — no valid credentials or specific endpoint knowledge is required. An attacker simply sends a crafted application/x-www-form-urlencoded HTTP POST request with deeply nested parameter structures (e.g., a[b][c][d][...]=value) to any reachable POST endpoint. This attack pattern is consistent with CAPEC-230 (Serialized Data with Nested Payloads) and CAPEC-231 (Oversized Serialized Data Payloads) (Github Advisory).

Successful exploitation results in a complete availability impact on the affected GitHub Enterprise Server instance: excessive CPU consumption exhausts the worker process pool, causing the instance to become unresponsive to all users and automated systems. There is no confidentiality or integrity impact — the vulnerability is purely a denial of service. Organizations relying on GHES for source code management, CI/CD pipelines, and developer workflows would experience a full service outage for the duration of the attack, potentially disrupting software development and deployment operations (Github Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of active in-the-wild exploitation at the time of disclosure (Github Advisory). The EPSS score is 0.0, reflecting a currently low probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Despite the low current exploitation evidence, the attack requires no authentication and no special preconditions beyond network access to the GHES instance, making it straightforward to exploit if an attacker identifies a vulnerable target.

1. Reconnaissance: Identify internet-facing or network-accessible GitHub Enterprise Server instances using tools like Shodan, Censys, or internal network scanning. Confirm the version is prior to 3.17.16, 3.18.10, 3.19.7, or 3.20.3.
2. Identify a POST endpoint: Any HTTP POST endpoint on the GHES instance is exploitable. Common candidates include login pages, API endpoints, or form submission handlers — no authentication is required.
3. Craft the malicious payload: Construct a application/x-www-form-urlencoded HTTP POST request body containing deeply nested parameters (e.g., a[b][c][d][e][f][g][h][i][j][k][l][m][n][o][p]=value) designed to trigger uncontrolled recursion in the parameter parser.
4. Send the request: Transmit the crafted POST request to the target GHES instance using tools such as curl, python-requests, or a custom script. No authentication headers are needed.
5. Sustain the attack: Repeatedly send the crafted requests (or send multiple concurrent requests) to continuously exhaust CPU resources and deplete the worker process pool, maintaining the denial of service condition.
6. Observe impact: The GHES instance becomes unresponsive, denying service to all legitimate users and automated systems (Github Advisory).

• Network: Unusual volume of HTTP POST requests from a single or small set of source IPs targeting any POST endpoint on the GHES instance; requests with abnormally large or deeply structured application/x-www-form-urlencoded bodies.
• Logs: GHES web server access logs (e.g., nginx or haproxy logs) showing repeated POST requests with large parameter payloads; application logs showing worker process exhaustion or timeout errors.
• System: Sustained high CPU utilization on the GHES appliance without a corresponding increase in legitimate user activity; worker process pool saturation visible in system monitoring dashboards.
• Availability: Sudden unresponsiveness of the GHES web interface and API endpoints coinciding with the anomalous POST request activity.

GitHub has released patched versions addressing this vulnerability: 3.17.16, 3.18.10, 3.19.7, 3.20.3, and all versions 3.21 and later (Github Advisory). Administrators should upgrade to the appropriate patched release as the primary remediation. As a temporary workaround where immediate upgrade is not possible, implement network-level controls such as rate limiting or blocking POST requests with abnormally deep parameter nesting at a WAF, load balancer, or firewall layer. Restricting network access to the GHES instance to trusted IP ranges can also reduce exposure.