CVE-2024-2758

What it actually does

The flaw is an insecure default or ineffective rate-limit configuration for Tempesta FW handling of HTTP traffic, particularly HTTP/2 CONTINUATION frames. Because rate limits are disabled by default or set at inappropriate thresholds, an attacker with low-privileged access can send abnormal request patterns, including many empty CONTINUATION frames, that are not reliably throttled. This can consume connection, parsing, CPU, memory, or request-processing resources and may also create inconsistent enforcement where legitimate HTTP requests are blocked if limits are tuned too aggressively. The assessed impact is limited confidentiality, integrity, and availability degradation rather than direct arbitrary code execution.

Why it matters to the business

Exploitation can make Moodle-backed services slower, intermittently unavailable, or unreliable for students, staff, administrators, or other users. Because the EPSS score is high despite no CISA KEV listing, organizations should treat internet-facing deployments as meaningfully exposed, especially where HTTP/2 is enabled or Tempesta FW is relied on for traffic protection. Operational consequences may include failed logins, disrupted coursework or business workflows, increased support volume, and emergency infrastructure tuning during peak usage periods.

How an attack unfolds

An attacker first identifies a reachable affected deployment that uses the vulnerable Tempesta FW rate-limit behavior in front of or as part of a Moodle deployment. If authentication is required, the attacker uses a low-privileged account. The attacker then establishes HTTP/2 connections and sends request sequences containing many empty or excessive CONTINUATION frames, or otherwise sends requests crafted to fall outside the ineffective default rate limits. Because the rate limits are disabled or poorly sized, the firewall does not stop the traffic early enough. The backend or intermediary spends resources parsing or tracking the streams, causing service degradation, request failures, or partial denial of service. In some configurations, overly strict compensating limits may also cause legitimate users to be blocked, creating an availability issue even without a complete outage.

How to fix it

Upgrade affected Moodle source deployments to a fixed revision. The provided fixed commits are 5a1b6a9d50f5af06ac03fd9022c3fd4d23f60602 and 6f7e3ca2f7e853a183559cfb6d10fa0eb8fc6877; use the fixed commit appropriate for the maintained branch in use or upgrade to a vendor-supported release that includes the relevant fix. Review Tempesta FW and upstream proxy configuration to ensure HTTP/2 request and frame rate limits are explicitly enabled and set to values that block abusive CONTINUATION-frame floods without denying normal application traffic. If immediate patching is not possible, consider temporarily disabling HTTP/2 on exposed listeners, applying conservative connection and stream limits at an upstream load balancer or reverse proxy, enforcing per-IP and per-account request throttling, and monitoring for excessive HTTP/2 frame activity. Test changes against realistic Moodle workflows before production rollout to avoid self-inflicted blocking of legitimate users.

How to confirm the fix worked

Confirm that deployed code contains one of the fixed commits or a release incorporating them. Validate dependency and deployment inventories to ensure no older Git checkout remains in production, staging, container images, or golden images. Review active Tempesta FW and reverse-proxy configuration to verify rate limits are enabled rather than relying on unsafe defaults. From a controlled test environment, run normal Moodle user workflows and confirm they are not rate-limited, then run a bounded HTTP/2 CONTINUATION-frame stress test and confirm the service rejects, throttles, or closes abusive connections before backend degradation occurs. Confirm logs show expected enforcement events and that application latency, error rates, CPU, memory, and connection counts remain stable during testing.

Typical attack path

1. Identify a public or reachable Moodle deployment protected by or integrated with the affected Tempesta FW behavior.
2. Determine whether HTTP/2 is accepted by the service or upstream proxy.
3. Obtain or use a low-privileged account if the protected endpoint requires authentication.
4. Open one or more HTTP/2 sessions to the target.
5. Send abnormal request streams containing excessive or empty CONTINUATION frames or other high-rate request patterns that bypass ineffective default limits.
6. Maintain or repeat the traffic until connection handling, parsing, or backend request-processing resources are degraded.
7. Observe increased latency, failed requests, connection resets, or partial service unavailability.

How to detect it

To determine whether exploitation already occurred, review reverse-proxy, load-balancer, Tempesta FW, web server, WAF, and network telemetry for abnormal HTTP/2 behavior. Focus on periods with unexplained Moodle latency, elevated 4xx/5xx errors, connection resets, worker exhaustion, CPU spikes, memory growth, or high connection counts. Standard HTTP access logs may not record individual HTTP/2 frame types, so prioritize packet captures, HTTP/2-aware proxy logs, WAF telemetry, flow records, and firewall debug logs where available. Look for repeated zero-length HTTP/2 CONTINUATION frames, unusually long header block sequences, high stream counts per connection, many short-lived HTTP/2 sessions from the same source, or a small set of authenticated users or IP addresses generating disproportionate traffic. Correlate suspicious source IPs and accounts with login records, request volume, session creation, and error bursts. If packet capture is available, filter for HTTP/2 frame type 0x9 and zero-length frames, especially repeated in sequence without normal request completion.

• CONTINUATION
• empty CONTINUATION
• zero-length CONTINUATION
• HTTP/2 CONTINUATION frame
• HTTP2 CONTINUATION
• h2 CONTINUATION
• frame_type=CONTINUATION
• frame_type=0x9
• type=9 length=0
• length=0 type=9
• too many CONTINUATION frames
• excessive CONTINUATION frames
• HTTP/2 frame flood
• HTTP2 frame flood
• h2 frame flood
• client sent too many HTTP/2 frames
• HTTP/2 stream error
• HTTP/2 connection error
• RST_STREAM flood
• GOAWAY
• ENHANCE_YOUR_CALM

What your security team should do

• Prioritize remediation for internet-facing Moodle deployments, especially those with HTTP/2 enabled, because the EPSS score indicates elevated likelihood of exploitation activity even though the issue is not listed in CISA KEV.
• Upgrade to a fixed Moodle revision or supported release containing commit 5a1b6a9d50f5af06ac03fd9022c3fd4d23f60602 or 6f7e3ca2f7e853a183559cfb6d10fa0eb8fc6877, as appropriate for the branch.
• Explicitly enable and tune Tempesta FW, reverse-proxy, or load-balancer rate limits for HTTP/2 connections, streams, header blocks, and request rates.
• If patching is delayed, temporarily disable HTTP/2 or restrict access to affected endpoints until compensating controls are validated.
• Add monitoring for spikes in HTTP/2 CONTINUATION frames, zero-length frame sequences, unusual connection duration, request failures, and per-source connection counts.
• Review historical logs around periods of unexplained latency or outages for signs of HTTP/2 frame-flood activity.
• Load-test rate-limit settings with representative legitimate traffic to ensure mitigations do not block normal Moodle usage.