Qt CVE-2024-39936: Timing bug in HTTP/2 risks TLS redirects

Qt's HTTP/2 handling bug tracked as CVE-2024-39936 lets code make security-relevant decisions before a TLS session has been confirmed, creating a timing gap that can leak confidential data to the wrong endpoint when HTTP/2 and redirects are involved.

Background​

In early July 2024 a timing-related vulnerability in Qt's HTTP/2 support was publicly disclosed. The underlying issue is not a cryptographic flaw but a race condition in connection establishment: Qt may proceed with sending or acting on data for an established connection before the TLS handshake completion event (the QNetworkAccessManager/QSslSocket encrypted() signal) has been emitted and processed. The result is that decisions that should be gated on a completed and verified TLS session — for example, whether to follow a redirect to a different hostname — may occur too early, potentially allowing data to be sent to an endpoint whose certificate was never properly validated for the redirected address.
This vulnerability affects widely-used releases of Qt across both the 5.x LTS and 6.x series. Affected ranges reported by vendors and CVE databases include Qt versions before 5.15.18, 6.x before 6.2.13, 6.3.x through 6.5.x before 6.5.7, and 6.6.x through 6.7.x before 6.7.3. Vendor advisories and patch notes published by the Qt project and many Linux distributions confirm fixes were produced quickly and shipped through both upstream Qt patch releases and downstream distro updates.

---

What went wrong: the technical root cause​

Asynchronous signals, event loops, and timing​

Qt’s network stack is built around asynchronous events. When a TLS handshake completes on a QSslSocket, the QNetworkAccessManager infrastructure emits an encrypted() signal (or equivalent callback) to indicate the session is now encrypted and suitable for decisions that depend on TLS state (peer certificate checks, hostname matching, HSTS handling, etc.). In many designs this signal is the canonical point where TLS-dependent validation and policy enforcement occur.
The bug here is classic time-of-check/time-of-use (TOCTOU): some parts of the HTTP/2 handling path would perform security-relevant checks or proceed to send application data before the code that relies on the encrypted() signal had actually run. The asynchronous nature of the signal and Qt’s internal handling of connections (including connection reuse and multiplexing under HTTP/2) meant that encrypted() was not a robust synchronization point in some code paths. In practice this allowed a sequence such as:

• Client opens a TLS connection that will be or becomes HTTP/2-capable.
• Server issues a redirect (or connection reuse causes an address mismatch) before the application-level code receives and processes encrypted().
• Qt continues and sends data or follows the redirect without having enforced hostname/certificate checks for the redirected address, because the expected timing and ordering of events were not guaranteed.

Why HTTP/2 makes this worse​

HTTP/2’s multiplexing and connection semantics reduce the number of TCP/TLS connections used for multiple logical requests. That reuse is normally a performance benefit, but it also increases complexity:

• Connections may be pre-established or reused across multiple logical requests to different targets.
• Qt’s internal optimizations for HTTP/2 mean that the same physical connection may be used in ways that skip the usual “first connection => emit encrypted()” pattern.
• Because the encrypted() signal is only guaranteed for the first connection to a host within a QNetworkAccessManager lifespan, logic that assumes receiving encrypted() for every request can be wrong.

The combination of these design choices produced a narrow but real window where security policy checks could be bypassed.

---

Affected versions and patches​

Multiple trusted advisories and vendor trackers report the same vulnerable ranges: many 5.x and 6.x branches before key maintenance versions are affected. The Qt project published an official security advisory and patch series; major Linux distributors (Ubuntu, Red Hat derivatives, Amazon Linux, Oracle Linux) released coordinated package updates. Qt-provided fixes and recommended upgrade targets were published as soon as the problem was analyzed.

• Reported vulnerable ranges include:
• Qt before 5.15.18
• Qt 6.x before 6.2.13
• Qt 6.3.x through 6.5.x before 6.5.7
• Qt 6.6.x through 6.7.x before 6.7.3
• The Qt project published patches and recommended updates in July 2024. The Qt blog and advisory identified updated targets (examples): Qt 5.15.18, Qt 6.2.13, Qt 6.5.7, Qt 6.7.3 and more recent branch releases; downstream distributions issued their own fixed package versions on schedules varying by distro.
• Downstream vendor patches (examples):
• Amazon Linux published ALAS advisories and package updates in November 2024.
• Ubuntu, Red Hat and Oracle published security advisories and corresponding patched packages in the months after disclosure.

Note: reporting and patch numbering varied slightly between upstream Qt releases, Qt code branches, and downstream distro package versions. Some sources later show minor revision bumps in the maintenance releases where the final hardening landed. If you manage systems or apps that embed Qt, treat the vendor-provided package version your platform ships as the authoritative fixed indicator (see the remediation checklist below).

---

Severity, scoring, and real-world risk​

This is a confidentiality-impacting bug: an application using a vulnerable Qt network stack could inadvertently send data to an attacker-controlled host (or other unintended endpoint) if an adversary is able to trigger a redirect or otherwise influence connection reuse and target name selection. The most commonly published severity rating for CVE-2024-39936 is high; MITRE and many trackers list a CVSS v3.1-like vector with a base score of 8.6 (Network, Low complexity, No privileges, No user interaction, Scope: changed, Confidentiality high).
There is some variance among sources in precise numeric scoring and scope details — this is common during the vulnerability disclosure lifecycle as vendors, CVE authorities, and distros reassess context and exploitability. The important takeaway is that an attacker with network access who can influence server responses (for example, via a malicious redirect or an on-path manipulation) could cause sensitive request payloads to be transmitted to an endpoint whose certificate was not validated for that address.
Real-world exploitability requires conditions that make the HTTP/2 + redirect path usable; it is not an “automatic RCE” style hole. But for client applications that do automatic redirects, send credentials or tokens in requests, or perform sensitive transactions without explicit per-redirect verification, the confidentiality impact can be material.

---

Practical exploitation scenarios​

Attackers could exploit this bug in several plausible ways:

• Malicious redirect: A man-in-the-middle (MITM) or compromised upstream server causes an HTTP redirect to a host under the attacker’s control. Because Qt might act before TLS validation completes for the new target, sensitive headers or POST bodies could be sent to the attacker's host.
• Hostname mismatch via connection reuse: If an application relies on connection reuse and Qt reuses a connection between two logical targets in unexpected ways, the code path that checks the certificate against the intended hostname might not run before data is transmitted.
• Rogue intermediary (proxy) controlling ALPN/HTTP/2 negotiation: An adversary that can influence ALPN or HTTP/2 negotiation may edge the connection onto the vulnerable code path and then induce early send behavior.

Each scenario requires a specific environment (the app must use Qt’s network stack and HTTP/2 features, it must be configured to follow redirects automatically or reuse connections in certain ways, and the attacker must be able to influence responses or the path). Still, many desktop and embedded apps match those criteria — especially those that are user-facing clients that follow redirects automatically.

---

Detection, mitigation and hardening — what developers and admins should do now​

Immediate steps for mitigation fall into two categories: short-term mitigations you can apply without rebuilding libraries, and the definitive fix: apply the upstream or distribution patch.
Short-term mitigations (quick, low-friction)

• Disable HTTP/2 for requests that can carry sensitive data. In Qt this can be achieved by setting the QNetworkRequest attribute:
• Example:
• request.setAttribute(QNetworkRequest::Http2AllowedAttribute, false);

This prevents the network access manager from negotiating HTTP/2 for the affected request and forces HTTP/1.1 behavior, avoiding the connection-reuse/multiplexing semantics that expose the timing window.

• Prevent automatic redirects for sensitive requests. Set the redirect policy to manual and handle redirects only after explicit certificate/hostname checks:
• request.setAttribute(QNetworkRequest::RedirectPolicyAttribute, QNetworkRequest::ManualRedirectPolicy);
• Or set the manager-level redirect policy to NoLessSafeRedirectPolicy / ManualRedirectPolicy depending on application needs.
• Avoid sending sensitive credentials in redirectable requests. Design your application to avoid attaching tokens or credentials to requests that could be redirected across domains.

Definitive remediation (apply updates)

• Inventory your attack surface:
• Identify binaries and builds that link to Qt network libraries (libQt5Network, libQt6Network, etc.) or that bundle Qt statically.
• For Linux: use package tools (rpm, dpkg) or ldd on binaries to identify linked Qt versions.
• For Windows: check DLL versions and embedded Qt runtime files.
• Update Qt to a patched release:
• Upgrade to the Qt versions recommended in the official Qt advisory or to versions containing the vendor patches delivered by your distribution. The Qt project released patches and recommended specific maintenance updates; Linux distributions and vendors issued coordinated security packages. Use your platform package manager or rebuild against the patched Qt sources as appropriate.
• Rebuild and redeploy:
• For applications that statically link or bundle Qt, rebuild against the patched Qt libraries and redeploy updated application binaries to users and devices.
• Verify:
• After patching, test redirect behavior and TLS handshake sequencing in a controlled environment. Confirm that encrypted()/handshake completion is processed before any sensitive headers or payloads are sent across redirect boundaries.

Hunting and detection guidance

• Search application logs for unexpected redirects or TLS certificate validation errors that coincide with data-sending events.
• Monitor for outbound connections to unusual hosts that occur immediately after legitimate server responses — these might indicate redirects followed by early sends.
• On servers, correlate logs to see if client behavior shows data sent to hosts that did not match the expected hostname.

---

Recommended developer changes and coding best practices​

To reduce future exposure from similar timing/ordering issues, adopt defensive patterns:

• Treat TLS handshake completion as a synchronization point. Do not make security decisions or send application-sensitive data until you have a confirmed, processed event indicating handshake success and certificate validation.
• Use explicit redirect handling for sensitive flows. Automatic redirect handling is convenient but dangerous when application logic needs to verify the target hostname or certificate before proceeding.
• Avoid indiscriminate credential forwarding. Use granular policies that prevent automatic forwarding of authentication headers or tokens across hostnames by default.
• Log and validate events surrounding connection establishment. Instrument code to log when encrypted()/handshake-complete is signaled and when sensitive payloads are transmitted; this assists post-incident review and telemetry-based detection.
• Prefer the platform’s explicit certificate validation APIs. Where possible, do peer name checks and certificate chain checks in application code (or in explicitly registered callbacks) rather than relying entirely on implicit behavior.

---

How to check whether your application is affected​

• Identify the Qt runtime used by your application:
• On Linux: check package manifests (dpkg -l, rpm -qa) or run ldd on the application binary to see libQtNetwork linkage.
• On Windows: check the version information of Qt DLLs bundled with the application executable or use dependency inspection tools to discover linked Qt DLL versions.
• For statically linked/embedded Qt builds, verify the Qt version used at build time (build logs, binary version strings, or compile-time defines).
• Compare with the vulnerable ranges listed in vendor advisories:
• If your runtime or bundled Qt is in the vulnerable range, treat the application as affected until patched.
• Read your distribution’s security advisory:
• Many OS vendors published updated packages that map directly to fixed Qt versions; use your platform’s security notices for the package-level indicator that the issue is fixed.
• Test behavior:
• In a controlled test environment, simulate a redirect from a legitimate server to an attacker-controlled host and observe whether the application sends sensitive data prior to handshake/completion validation.

---

Why this matters to admins, IoT vendors, and end users​

Qt is embedded in a broad ecosystem: desktop applications, cross-platform client software, embedded/IoT devices, instrumentation consoles and more. Many of these programs:

• Bundle Qt statically (so shipping an updated OS package is insufficient — the app itself must be rebuilt).
• Automatically follow redirects or send tokens without additional checks.
• Run in constrained environments where security updates are slow to arrive.

This combination makes CVE-2024-39936 particularly relevant to organizations that ship or operate third-party software or IoT devices. For enterprise asset owners, the remediation profile is multi-pronged: coordinate vendor updates, push application rebuilds where required, and apply configuration-level mitigations (disable HTTP/2 or redirects for at-risk requests) where code changes are not immediately possible.

---

The fixes: what Qt changed​

The vendor patches enforce stricter ordering and ensure that no application-data transmission or security-relevant decision happens until the TLS session is reliably confirmed and the encrypted() notification has been processed. In short, the patch delays any communication that depends on certificate/hostname validation until the handshake-complete event has been acknowledged by the relevant Qt objects. The upstream change set and per-branch patches were prepared and released; downstream vendors rebased these fixes into their maintenance packages.

---

Limitations, ambiguity, and things we could not fully verify​

• Version-number noise: during the disclosure and patch cycle, different sources listed slightly different “fixed in” version numbers (some maintenance branches received immediate one-off patches while LTS branches received later maintenance bumps). If your environment relies on vendor-supplied packages, treat the vendor package and advisory as authoritative rather than relying on a single upstream version number.
• CVSS variation: some trackers assigned slightly different scores based on their judgment of the exploitability and scope. The pragmatic approach is to treat the issue as high-risk for any client that follows redirects or sends credentials automatically.
• Exploit proof-of-concept: as of the advisories and coordinated distro updates, public exploit code suitable for widespread automated scanning was not the primary vector of the disclosure. Nevertheless, an attacker with on-path capability and the right conditions could exploit the timing window.

Where specific claims differ between advisories, rely on the upstream Qt advisory and the security packages from your platform vendor.

---

Action checklist​

• Inventory — find applications and devices that use Qt network libraries or bundle Qt.
• Prioritize — flag clients that:
• Automatically follow redirects.
• Transmit credentials, tokens, or sensitive payloads without manual vetting.
• Bundle Qt statically (requires app rebuild).
• Mitigate short-term:
• For sensitive requests, set request.setAttribute(QNetworkRequest::Http2AllowedAttribute, false).
• Use manual redirect policies for sensitive flows.
• Patch:
• Apply upstream Qt patches or vendor-supplied security package updates.
• Rebuild and redeploy any statically linked or bundled applications against patched Qt libraries.
• Verify:
• Test redirect and connection flows post-patch to confirm the behavior has changed and encrypted()/handshake processing now precedes sensitive data transmission.
• Monitor:
• Watch for outbound connections to unusual endpoints and for configuration changes that re-enable HTTP/2 without verification.

---

Final assessment​

CVE-2024-39936 is a clear example of how asynchronous event ordering and protocol performance optimizations can create subtle, high-impact security windows. The bug is not an attack on TLS itself, but a logic/timing issue in how TLS completion is synchronized with application actions in a widely distributed framework. That combination — a popular cross-platform framework and a timing/ordering bug that affects confidentiality — is why the vulnerability was treated as high priority by both the Qt project and the major distribution vendors.
For developers: apply the principle of explicit validation before use. For operators and admins: inventory, patch, and where necessary apply configuration mitigations (disable HTTP/2 for sensitive flows or require manual redirect handling) until patched bits are deployed and validated. The vulnerability is fixable and fixes have been issued — but because many applications embed or bundle Qt, the remediation work often goes beyond a single OS package update; it requires coordinated rebuilds and redeployments in many environments. Take the simple mitigations now and plan the rebuilds as your long-term solution.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center