CVE-2024-27983

What it actually does

This vulnerability is a network-reachable denial-of-service flaw in the Node.js HTTP/2 server implementation as packaged in the affected Bitnami Git image. A remote, unauthenticated client can send a small sequence of HTTP/2 frames involving header processing and CONTINUATION frames, then abruptly close the TCP connection. Under the vulnerable code path, header data may remain in nghttp2 memory while the Http2Session destructor is triggered, creating a race condition that can exhaust or corrupt session processing state and make the HTTP/2 service unavailable. The main impact is loss of availability; the CVSS vector also notes limited integrity impact, but the practical security concern is service disruption rather than data theft.

Why it matters to the business

Successful exploitation can take Git-related web services, APIs, or dependent automation offline with relatively little attacker traffic. This can interrupt source-code access, CI/CD pipelines, release workflows, developer productivity, and integrations that depend on the affected service. Although this issue is not listed in CISA KEV and is not known to be used in ransomware campaigns, its high CVSS score and high EPSS probability indicate that exposed HTTP/2 endpoints should be prioritized for remediation, especially where internet-facing or business-critical.

How an attack unfolds

An attacker first identifies an exposed service using the affected Bitnami Git package with HTTP/2 enabled. They establish HTTP/2 connections and send crafted header blocks split across CONTINUATION frames. Before the server finishes processing those frames, the attacker abruptly closes the TCP connection. This triggers a timing-sensitive cleanup path in the Node.js HTTP/2 session handling while nghttp2 still has header data in memory. Repeating this sequence with a relatively small number of frames and connections can cause the HTTP/2 server to become unresponsive or crash, denying service to legitimate users.

How to fix it

Upgrade the affected package to a fixed release. For the listed affected product, upgrade Bitnami Git to version 1.11.0 or later. Where immediate upgrade is not possible, reduce exposure by disabling HTTP/2 on the affected service or terminating HTTP/2 at a patched reverse proxy/load balancer, restricting access to trusted networks, applying connection and header-size limits, and using rate limiting for abnormal HTTP/2 connection churn. Restart affected services after patching to ensure vulnerable runtime components are replaced.

How to confirm the fix worked

Confirm that all deployed Bitnami Git instances are running version 1.11.0 or later. Verify that the running container image, package manifest, or deployment artifact reflects the fixed version rather than only the source repository. Test externally and internally for HTTP/2 exposure using tools such as curl with HTTP/2 enabled, openssl/alpn checks, or approved vulnerability scanners. After remediation, confirm that HTTP/2 endpoints remain stable under malformed or incomplete header/CONTINUATION-frame test cases in a controlled environment, and verify that service logs no longer show crashes, worker exits, or repeated session resets during HTTP/2 traffic.

Typical attack path

1. Discover an internet-facing or reachable Git/HTTP service that supports HTTP/2.
2. Confirm the service is using a vulnerable Bitnami Git package or an affected Node.js HTTP/2 stack.
3. Open one or more HTTP/2 connections to the target service.
4. Send crafted HTTP/2 header sequences using CONTINUATION frames.
5. Abruptly close the TCP connection while the server is still processing the header frames.
6. Repeat the sequence until the HTTP/2 server becomes unavailable, crashes, or stops responding to legitimate requests.

How to detect it

Because this is primarily a denial-of-service vulnerability, exploitation may leave few durable host artifacts beyond crashes, restarts, and abnormal network/proxy logs. Review reverse proxy, load balancer, web server, container runtime, systemd, Kubernetes, and application logs around service outages for spikes in HTTP/2 connections that end abruptly, protocol errors involving CONTINUATION or header frames, repeated TCP resets, and worker or process crashes. Network telemetry should be examined for short-lived HTTP/2 sessions with incomplete header blocks, unusually high CONTINUATION-frame counts, repeated RST/FIN behavior from the client, and concentrated activity from one or a small set of source IPs. Host telemetry should be checked for Node.js process exits, container restarts, OOM events, core dumps, or service supervisor restarts temporally aligned with the suspicious HTTP/2 traffic. No named threat actors or active ransomware use are currently associated with this input, so detection should focus on behavior rather than actor-specific indicators.

• HTTP/2 CONTINUATION
• CONTINUATION frame
• HTTP2_SESSION_ERROR
• HTTP2 stream error
• ERR_HTTP2_SESSION_ERROR
• ERR_HTTP2_STREAM_ERROR
• NGHTTP2_PROTOCOL_ERROR
• NGHTTP2_INTERNAL_ERROR
• Http2Session
• session destroyed
• TCP connection reset by peer
• connection reset by peer
• client prematurely closed connection
• upstream prematurely closed connection
• worker process exited
• node process exited
• CrashLoopBackOff
• OOMKilled

What your security team should do

• Inventory all Bitnami Git deployments and identify any instance exposing HTTP/2, especially internet-facing services.
• Upgrade Bitnami Git to 1.11.0 or later as the primary fix.
• If patching cannot be completed immediately, disable HTTP/2 or terminate it at a patched proxy and enforce rate limits on connection churn and header abuse.
• Prioritize remediation for services supporting developer workflows, CI/CD, release automation, or public access because exploitation can directly disrupt operations.
• Review service, proxy, container, and orchestration logs for unexplained crashes, restarts, HTTP/2 protocol errors, and spikes in abruptly closed HTTP/2 connections.
• Add monitoring for elevated HTTP/2 CONTINUATION-frame activity, incomplete header blocks, TCP resets, and repeated short-lived HTTP/2 sessions from the same source.
• Validate that auto-scaling or restart policies are not masking repeated exploitation attempts without alerting.