CVE-2023-32762 Overview
An issue was discovered in Qt before 5.15.14, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1. Qt Network incorrectly parses the strict-transport-security (HSTS) header, allowing unencrypted connections to be established, even when explicitly prohibited by the server. This happens if the case used for this header does not exactly match.
Critical Impact
Applications built with vulnerable Qt versions may silently downgrade from HTTPS to HTTP connections when servers use non-standard casing for the Strict-Transport-Security header, exposing sensitive data to network-based attacks.
Affected Products
- Qt versions before 5.15.14
- Qt 6.x versions before 6.2.9
- Qt 6.3.x through 6.5.x versions before 6.5.1
- Debian Linux 10.0
Discovery Timeline
- 2023-05-28 - CVE-2023-32762 published to NVD
- 2025-03-05 - Last updated in NVD database
Technical Details for CVE-2023-32762
Vulnerability Analysis
This vulnerability exists in Qt Network's HSTS (HTTP Strict Transport Security) header parsing implementation. HSTS is a critical web security mechanism that forces browsers and HTTP clients to use encrypted HTTPS connections instead of unencrypted HTTP. When a server sends the Strict-Transport-Security header, compliant clients should refuse to connect via HTTP for the specified duration.
The flaw occurs because Qt Network performs a case-sensitive string comparison when checking for the HSTS header name. According to HTTP specifications (RFC 7230), header field names are case-insensitive. This means Strict-Transport-Security, strict-transport-security, and STRICT-TRANSPORT-SECURITY should all be treated identically.
Due to this implementation error, if a server sends the HSTS header with any casing that doesn't exactly match "Strict-Transport-Security", Qt-based applications will fail to recognize and enforce the HSTS policy. This allows connections to fall back to unencrypted HTTP, potentially exposing sensitive data to man-in-the-middle attacks.
Root Cause
The root cause is an improper input validation issue in the QHstsHeaderParser::parse() function within src/network/access/qhsts.cpp. The code used the == operator for direct byte-by-byte comparison of the header name string, which performs a case-sensitive match. This violates RFC 7230 Section 3.2, which explicitly states that HTTP header field names are case-insensitive.
Attack Vector
An attacker positioned on the network path between a Qt-based application and a web server could exploit this vulnerability through the following scenario:
- The legitimate server sends an HSTS header with non-standard casing (e.g., strict-transport-security in lowercase)
- The Qt application fails to recognize the HSTS directive due to case-sensitive matching
- The HSTS policy is not cached or enforced by the application
- Subsequent requests to the same domain may use unencrypted HTTP
- The attacker can then intercept, read, or modify traffic via man-in-the-middle techniques
bool QHstsHeaderParser::parse(const QList<QPair<QByteArray, QByteArray>> &headers)
{
for (const auto &h : headers) {
- // We use '==' since header name was already 'trimmed' for us:
- if (h.first == "Strict-Transport-Security") {
+ // We compare directly because header name was already 'trimmed' for us:
+ if (h.first.compare("Strict-Transport-Security", Qt::CaseInsensitive) == 0) {
header = h.second;
// RFC6797, 8.1:
//
Source: GitHub Commit Details
Detection Methods for CVE-2023-32762
Indicators of Compromise
- Network traffic analysis showing HTTP connections to domains that should be HTTPS-only
- Log entries indicating HSTS policies not being applied for known HSTS-enabled domains
- Unexpected cleartext HTTP traffic from Qt-based applications
Detection Strategies
- Monitor network traffic for Qt-based applications connecting over HTTP to domains known to implement HSTS
- Review application logs for failed HTTPS upgrades or missing HSTS policy enforcement
- Implement TLS inspection to identify connections that should have been upgraded to HTTPS but were not
- Deploy network intrusion detection rules to alert on HTTP traffic to sensitive domains from Qt applications
Monitoring Recommendations
- Configure network monitoring tools to flag HTTP connections from Qt-based applications to sensitive services
- Implement alerting for any HTTPS downgrade events in network traffic logs
- Establish baseline behavior for Qt applications and monitor for deviations in protocol usage
- Review SSL/TLS termination logs for unusual patterns indicating HSTS bypass attempts
How to Mitigate CVE-2023-32762
Immediate Actions Required
- Update Qt to version 5.15.14 or later for the 5.x branch
- Update Qt to version 6.2.9 or later for the 6.2.x branch
- Update Qt to version 6.5.1 or later for the 6.3.x through 6.5.x branch
- Rebuild and redeploy all applications using affected Qt versions
- Review network security controls to ensure TLS is enforced at the network level as an additional layer of defense
Patch Information
The Qt Project has released patched versions addressing this vulnerability. The fix modifies the QHstsHeaderParser::parse() function to use Qt::CaseInsensitive comparison when matching the Strict-Transport-Security header name. Organizations should upgrade to the following minimum versions:
- Qt 5.15.14 for the 5.x series
- Qt 6.2.9 for the 6.2.x series
- Qt 6.5.1 for the 6.3.x through 6.5.x series
Detailed patch information is available through the Qt Project Code Review and the Qt Project Mailing List Announcement.
Workarounds
- Implement network-level enforcement of HTTPS using firewall rules or proxy configurations
- Deploy HSTS preloading for critical domains at the DNS or gateway level
- Use TLS-terminating proxies that enforce encryption regardless of client HSTS support
- Configure network monitoring to detect and block HTTP connections to sensitive domains
# Example: Force HTTPS at the proxy level for Qt applications
# Add to proxy configuration (e.g., Squid)
acl qt_apps browser -i Qt
acl https_domains dstdomain .example.com .sensitive-domain.com
http_access deny qt_apps !CONNECT https_domains
# Alternative: iptables rule to redirect HTTP to HTTPS proxy
iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner --uid-owner qt-app-user -j REDIRECT --to-port 8443
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


