Revision control
Copy as Markdown
// Copyright (C) 2024 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
/*!
\page security.html
\title Security in Qt
\brief Addressing security issues in Qt.
\ingroup security
Qt's security relies on the infrastructure created and maintained by
the Qt Group and Qt Project. This infrastructure involves the development,
testing, and build environments. For example, there is an established code
review process, a testing process using static analyzers and fuzzing tools,
testing of third-party components, and further antivirus testing for each
release. Qt also has an established process for handling security
vulnerabilities.
The \e{security of an application or device that uses Qt} is a shared
responsibility between the application developers, the Qt Group and
Qt Project as providers of the Qt Framework, and operators or device
manufacturers. For an overview of the respective obligations and
boundaries, see \l{Qt Shared Security Model}.
\section1 Qt Project security policy
The Qt Project specifies its security policy in
A summary of the security policy:
\list
\li Qt has a \e{Core Security Team} that enforces the security policy
and addresses issues.
\li Proactive measures to prevent security issues---code reviews, code
analysis, fuzz testing, and so on.
\li Reporting Security Issues: the Core Security Team monitors security
issues for Qt modules and affected third-party components.
\li Handling Security Issues: the maintainers, Core Security Team,
Chief Maintainer, and Qt Group share and handle security
issues.
\li Disclosure of confirmed security issues at
and a public announcement to the Qt
\l{mailto:announce@qt-project.org} mailing list.
You can subscribe to the mailing list by visiting the
{Qt Project Mailing List Information Page}.
\endlist
\section1 Reporting security issues
Report vulnerabilities in open source Qt to
\l{mailto:security@qt-project.org}{security@qt-project.org}. For Qt Group
commercial products, you can also contact \l{mailto:psirt@qt.io}{psirt@qt.io}.
Qt Group's
{Coordinated Vulnerability Disclosure Policy} describes the available
reporting channels, the commitments the Qt Group and Qt Project make to
researchers who disclose responsibly, and the response and disclosure timelines.
Qt does not currently have a bug bounty program.
\section1 Qt vulnerabilities
When technical experts confirm a security issue in one of the Qt products,
a Common Vulnerabilities and Exposures entry (CVE) will be
created. A CVE consists of an ID and a description. Further metadata
is added over time.
For Qt products, The Qt Company is managing the CVE creation process as the
{CVE Numbering Authority (CNA)}. It lists new CVEs in the
{List of known vulnerabilities in Qt Products}, but also contributes to
To uniquely identify products affected by a vulnerability, CVEs contain entries
in the \e{Common Platform Enumeration} (CPE) format. For issues in the Qt Framework, the
\e vendor and \e product parts of such a CPE are \c qt:qt.
For example, a hypothetical CVE that affects Qt \QtVersion will have the following CPE:
\badcode \QtVersion
cpe:2.3:a:qt:qt:\1:*:*:*:*:*:*:*
\endcode
\section1 Software Bill of Materials (SBOM)
Starting from Qt 6.8, the Qt installation includes Software Bill of
Materials (SBOM) documents, containing information about installed Qt
modules, packages, and third-party components in SPDX format. Since
Qt 6.11, the SBOM documents are also available in CycloneDX format.
Use the documents in either of these formats to track Qt installed
packages for vulnerability management and license compliance.
\list
\li \l{Software Bill of Materials}
\endlist
\section1 Untrusted data
Several Qt modules handle data such as user input and executable resources.
Qt expects application developers to handle untrusted data appropriately.
If a Qt API fetches and processes untrusted data before the application
could do the processing, then Qt considers this API as
\e{security critical}. Security critical APIs undergo extra scrutiny and
testing during development.
In general, avoid unprocessed data from unknown sources if possible and
perform safety procedures when handling data. Qt provides several
mechanisms for processing data, such as validators for user input.
For more information, see \l{Handling Untrusted Data}.
\section1 Developer tools
The Qt Framework ships developer tools that run on your build machine
while building a Qt application, such as \l{moc}{Meta-Object Compiler (moc)},
\l{rcc}{Resource Compiler (rcc)}, and the various code and asset generators.
These tools treat the project they process as trusted input and are not
a security boundary. Building a project you do not trust can therefore
lead to code execution on your build machine.
For more information, see \l{Using Qt's Developer Tools Securely}.
\section1 Permissions
Qt 6.5 introduces a cross-platform permission API for handling permissions.
The permission API is for user-related private data and hardware such as
contact lists, calendar, camera, and microphone.
For more information, see \l{Application Permissions}.
\section1 Extended Security Maintenance
We acknowledge that your product may have a lifecycle that is longer than
our usual support window for a given Qt release. We now offer maintenance
services for customers with an end-of-support (EoS) version of Qt.
The Extended Security Maintenance subscription service provides you access
to Critical Vulnerability and Security (CVS) maintenance patches relating to
Qt libraries for select \l{lts-releases}{Long Term Support (LTS) releases}
after the end-of-support (EoS).
The ESM service is available for the following versions:
\table
\header
\li Version
\li ESM since
\row
\li Qt 5.15 LTS
\li 2025-05-26
\row
\li Qt 6.5 LTS
\li 2026-03-30
\endtable
*/