Qubes OS

All previous messages missed for an entire year has been recovered and posted here. Sorry for any inconveniences.

Xen 4.22: Strengthening Open Source Virtualization for Cloud, Embedded, and Automotive Systems https://xenproject.org/blog/xen-4-22-release/ Xen 4.22 adds modern hardware support, Arm improvements, continued RISC-V progress, Xenstore scalability updates, and a five-year security support lifecycle. Original message: t.me/QubesOS/1099

you just created.

gpg: key BB52274595B71262: public key "unman (Qubes Documentation Signing Key)" imported gpg: key DC2F3678D272F2A8: 1 signature not checked due to a missing key gpg: key DC2F3678D272F2A8: public key "Wojtek Porczyk (Qubes OS documentation signing key)" imported gpg: key FD64F4F9E9720C4D: 1 signature not checked due to a missing key gpg: key FD64F4F9E9720C4D: public key "Zrubi (Qubes Documentation Signing Key)" imported gpg: key DDFA1A3E36879494: "Qubes Master Signing Key" not changed gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported gpg: qubes-secpack/keys/release-keys/retired: read error: Is a directory gpg: no valid OpenPGP data found. gpg: key D655A4F21830E06A: public key "Marek Marczykowski-Górecki (Qubes security pack)" imported gpg: key ACC2602F3F48CB21: public key "Qubes OS Security Team" imported gpg: qubes-secpack/keys/security-team/retired: read error: Is a directory gpg: no valid OpenPGP data found. gpg: key 4AC18DE1112E1490: public key "Simon Gaiser (Qubes Security Pack signing key)" imported gpg: Total number processed: 17 gpg: imported: 16 gpg: unchanged: 1 gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 1 signed: 6 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: depth: 1 valid: 6 signed: 0 trust: 6-, 0q, 0n, 0m, 0f, 0u Verify signed Git tags. $ cd qubes-secpack/ $ git tag -v `git describe` object 266e14a6fae57c9a91362c9ac784d3a891f4d351 type commit tag marmarek_sec_266e14a6 tagger Marek Marczykowski-Górecki 1677757924 +0100 Tag for commit 266e14a6fae57c9a91362c9ac784d3a891f4d351 gpg: Signature made Thu 02 Mar 2023 03:52:04 AM PST gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full] The exact output will differ, but the final line should always start with gpg: Good signature from... followed by an appropriate key. The [full] indicates full trust, which this key inherits in virtue of being validly signed by the QMSK. Verify PGP signatures, e.g.: $ cd QSBs/ $ gpg --verify qsb-087-2022.txt.sig.marmarek qsb-087-2022.txt gpg: Signature made Wed 23 Nov 2022 04:05:51 AM PST gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full] $ gpg --verify qsb-087-2022.txt.sig.simon qsb-087-2022.txt gpg: Signature made Wed 23 Nov 2022 03:50:42 AM PST gpg: using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490 gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full] $ cd ../canaries/ $ gpg --verify canary-034-2023.txt.sig.marmarek canary-034-2023.txt gpg: Signature made Thu 02 Mar 2023 03:51:48 AM PST gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full] $ gpg --verify canary-034-2023.txt.sig.simon canary-034-2023.txt gpg: Signature made Thu 02 Mar 2023 01:47:52 AM PST gpg: using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490 gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full] Again, the exact output will differ, but the final line of output from each gpg --verify command should always start with gpg: Good signature from... followed by an appropriate key. For this announcement (QSB-116), the commands are: $ gpg --verify qsb-116-2026.txt.sig.marmarek qsb-116-2026.txt $ gpg --verify qsb-116-2026.txt.sig.simon qsb-116-2026.txt You can also verify the signatures directly from this announcement in addition to or instead of verifying the files from the qubes-secpack. Simply copy and paste the QSB-116 text into a plain text file and do the same for both signature files. Then, perform the same authentication steps as listed above, substituting the filenames above with the names of the files

pub rsa4096/DDFA1A3E36879494 2010-04-01 Qubes Master Signing Key Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494 Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key (https://doc.qubes-os.org/en/latest/project-security/verifying-signatures.html#how-to-import-and-authenticate-the-qubes-master-signing-key). Tip: After you have authenticated the QMSK out-of-band to your satisfaction, record the QMSK fingerprint in a safe place (or several) so that you don’t have to repeat this step in the future. Once you are satisfied that you have the genuine QMSK, set its trust level to 5 (“ultimate”), then quit GnuPG with q. gpg> trust pub rsa4096/DDFA1A3E36879494 created: 2010-04-01 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). Qubes Master Signing Key Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y pub rsa4096/DDFA1A3E36879494 created: 2010-04-01 expires: never usage: SC trust: ultimate validity: unknown [ unknown] (1). Qubes Master Signing Key Please note that the shown key validity is not necessarily correct unless you restart the program. gpg> q Use Git to clone the qubes-secpack repo. $ git clone https://github.com/QubesOS/qubes-secpack.git Cloning into 'qubes-secpack'... remote: Enumerating objects: 4065, done. remote: Counting objects: 100% (1474/1474), done. remote: Compressing objects: 100% (742/742), done. remote: Total 4065 (delta 743), reused 1413 (delta 731), pack-reused 2591 Receiving objects: 100% (4065/4065), 1.64 MiB | 2.53 MiB/s, done. Resolving deltas: 100% (1910/1910), done. Import the included PGP keys. (See our PGP key policies (https://doc.qubes-os.org/en/latest/project-security/security-pack.html#pgp-key-policies) for important information about these keys.) $ gpg --import qubes-secpack/keys/*/* gpg: key 063938BA42CFA724: public key "Marek Marczykowski-Górecki (Qubes OS signing key)" imported gpg: qubes-secpack/keys/core-devs/retired: read error: Is a directory gpg: no valid OpenPGP data found. gpg: key 8C05216CE09C093C: 1 signature not checked due to a missing key gpg: key 8C05216CE09C093C: public key "HW42 (Qubes Signing Key)" imported gpg: key DA0434BC706E1FCF: public key "Simon Gaiser (Qubes OS signing key)" imported gpg: key 8CE137352A019A17: 2 signatures not checked due to missing keys gpg: key 8CE137352A019A17: public key "Andrew David Wong (Qubes Documentation Signing Key)" imported gpg: key AAA743B42FBC07A9: public key "Brennan Novak (Qubes Website & Documentation Signing)" imported gpg: key B6A0BB95CA74A5C3: public key "Joanna Rutkowska (Qubes Documentation Signing Key)" imported gpg: key F32894BE9684938A: public key "Marek Marczykowski-Górecki (Qubes Documentation Signing Key)" imported gpg: key 6E7A27B909DAFB92: public key "Hakisho Nukama (Qubes Documentation Signing Key)" imported gpg: key 485C7504F27D0A72: 1 signature not checked due to a missing key gpg: key 485C7504F27D0A72: public key "Sven Semmler (Qubes Documentation Signing Key)" imported

4znS5FAHrlPSv4xi7aWiypVwB/MsMbrdNcd0/g9px6RbszpNGpA= =BjeB -----END PGP SIGNATURE----- Source: qsb-116-2026.txt.sig.simon (https://github.com/QubesOS/qubes-secpack/blob/f9001423ffb11de26bdcf0b4478838739cc3f6b3/QSBs/qsb-116-2026.txt.sig.simon) What is the purpose of this announcement? The purpose of this announcement is to inform the Qubes community that a new Qubes security bulletin (QSB) has been published. What is a Qubes security bulletin (QSB)? A Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/) is a security announcement issued by the Qubes security team (https://doc.qubes-os.org/en/latest/project-security/security.html#qubes-security-team). A QSB typically provides a summary and impact analysis of one or more recently-discovered software vulnerabilities, including details about patching to address them. Why should I care about QSBs? QSBs tell you what actions you must take in order to protect yourself from recently-discovered security vulnerabilities. In most cases, security vulnerabilities are addressed by updating normally (https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-update.html). However, in some cases, special user action is required. In all cases, the required actions are detailed in QSBs. What are the PGP signatures that accompany QSBs? A PGP (https://en.wikipedia.org/wiki/Pretty_Good_Privacy) signature is a cryptographic digital signature (https://en.wikipedia.org/wiki/Digital_signature) made in accordance with the OpenPGP (https://en.wikipedia.org/wiki/Pretty_Good_Privacy#OpenPGP) standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG) (https://gnupg.org/). The Qubes security team cryptographically signs all QSBs so that Qubes users have a reliable way to check whether QSBs are genuine. The only way to be certain that a QSB is authentic is by verifying its PGP signatures. Why should I care whether a QSB is authentic? A forged QSB could deceive you into taking actions that adversely affect the security of your Qubes OS system, such as installing malware or making configuration changes that render your system vulnerable to attack. Falsified QSBs could sow fear, uncertainty, and doubt about the security of Qubes OS or the status of the Qubes OS Project. How do I verify the PGP signatures on a QSB? The following command-line instructions assume a Linux system with git and gpg installed. (For Windows and Mac options, see OpenPGP software (https://doc.qubes-os.org/en/latest/project-security/verifying-signatures.html#openpgp-software).) Obtain the Qubes Master Signing Key (QMSK), e.g.: $ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc gpg: directory '/home/user/.gnupg' created gpg: keybox '/home/user/.gnupg/pubring.kbx' created gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc' gpg: /home/user/.gnupg/trustdb.gpg: trustdb created gpg: key DDFA1A3E36879494: public key "Qubes Master Signing Key" imported gpg: Total number processed: 1 gpg: imported: 1 (For more ways to obtain the QMSK, see How to import and authenticate the Qubes Master Signing Key (https://doc.qubes-os.org/en/latest/project-security/verifying-signatures.html#how-to-import-and-authenticate-the-qubes-master-signing-key).) View the fingerprint of the PGP key you just imported. (Note: gpg> indicates a prompt inside of the GnuPG program. Type what appears after it when prompted.) $ gpg --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494 gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub rsa4096/DDFA1A3E36879494 created: 2010-04-01 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). Qubes Master Signing Key gpg> fpr

includes malicious HVM qubes with memory balancing enabled, as well as templates and standalones that use in-qube kernels and that have memory balancing enabled. The default Qubes OS configuration is not affected, nor are commonly-used HVM qubes like Windows, since they don't have memory balancing enabled. Patching --------- The following packages contain security updates that address the vulnerabilities described in this bulletin: For Qubes 4.3, in dom0: - Xen packages, version 4.19.5-2 These packages will migrate from the security-testing repository to the current (stable) repository over the next two weeks after being tested by the community. [2] Once available, the packages should be installed via the Qubes Update tool or its command-line equivalents. [1] Dom0 must be restarted afterward in order for the updates to take effect. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Xen binaries. Credits -------- See the original Xen Security Advisories. [3][4][5][6] References ----------- [1] https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-update.html [2] https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/testing.html [3] https://xenbits.xen.org/xsa/advisory-500.html [4] https://xenbits.xen.org/xsa/advisory-505.html [5] https://xenbits.xen.org/xsa/advisory-506.html [6] https://xenbits.xen.org/xsa/advisory-507.html [7] A PV qube is a qube that is running with virt_mode set to "pv." [8] For each qube that is running with virt_mode set to "hvm," there's a small Xen-internal helper VM running alongside it, in which QEMU is executed to provide device emulation for that qube. This helper VM runs in PV mode and is called a "stubdomain." -- The Qubes Security Team https://www.qubes-os.org/security/ Source: qsb-116-2026.txt (https://github.com/QubesOS/qubes-secpack/blob/f9001423ffb11de26bdcf0b4478838739cc3f6b3/QSBs/qsb-116-2026.txt) Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki)’s PGP signature -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmpoeyMACgkQ1lWk8hgw 4GqUjw//brO4x3oOygOpewPqcjgYqohh4qPu5Dpm6JBvtxiIZQWEv9UZg0RqfMVc omoalUCQhoTPu8QYnXu3HKo87LGcrUKKf2KeRx4CyT8LsZCQufA25uWD3Sr6eVsA 38Q/Znq3VyUpa5tMQm28JIIA9m2PMAMaXu5ElZVAw5kvcRncwRh8WDOrkVOO97ll gSfBo3SJ0OfSUDcQvGa8f5+4Jx/SPoJn5zLo3Ott4tT7Tz2NAfE2Xlxl7karasY/ vCY+Lo8ACN+0ShELslGKYZnNdwLuwkz3lVN+FqDbLrHauBUjDLH7+yTXJvO9ZoXq 3LTpHopzv8oSJJyhq0YeO4XlKt+USn2HbIMqhJ9ON8aHHVE3/YhVJume4RuxSlHx WAStN0bYH/NqSywYB3wWmGEho9wRw8bxLrOBIuZO3V63HpMJnCL412F7RFA2/9iS muq3Iix9YpqfI/Q1Q18JSnYYLlWaphMtc/OJki5FAzp1B5DtQtPcQtg/vcy9tsrX P9zrK4j3Dj/vPzZd6DwDmTBPxuiLQX79TQojl7NClVatkULfdHQGDKogfPmsJng9 IpKMBkMZ85QVv+DG/XFtXpynBdeg/6eTeWiexC7WF3HgILkhy2RadQz0eHsEwCmp fIeVYQ2Es3eVH7aNaPHwaAcklNP+7yppgw5O81PGOlbD3Z9a15Y= =vPOZ -----END PGP SIGNATURE----- Source: qsb-116-2026.txt.sig.marmarek (https://github.com/QubesOS/qubes-secpack/blob/f9001423ffb11de26bdcf0b4478838739cc3f6b3/QSBs/qsb-116-2026.txt.sig.marmarek) Simon Gaiser (aka HW42) (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42)’s PGP signature -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmpoh00ACgkQSsGN4REu FJCSVhAApAdVntLjACF7SJ9h7SF4M1IiDKKUQRnUhwEa06d/qDjFg/aVlsL6LghW +cKpPdjSDWwGPhAsJhbxTeiSSAkX300qJuqX3/K0h6iw7jaQkqb6kmwaAhK7J8Ym 9F5LvcP8Vvx3G0Gi4YogNzrwA+AMlfCgKLgp7MsHKumE1TY0pp5dI6DMqz2/EasV ODrppsfXkMMmES5aR8C6Pxe51pfBbXVqVmffjYxaz/C9VvcfGbHja8OdnOuNeqmo yzR2pP6BGdIl2KGfq1GzuuYWtitIcrG8aEnYfcmhiHbHkTIObNwHo7MOwBT2Q9H4 ALJfuBfC1ChBvmmzRIPgOzPbiz0MLIWcjFvKRmXW8azTTQOyRQQbG5lDGeu+aJm0 ZRdyXPQh2294MmmL3r+xtyFJTFw5WABdxjZa10nlB5B5JQ8FrV7koNc4quXhCS4U ceAwpvCuRKTX1Lg+NDaPFtxAmYX98QkLT09V34vyqksOcMR+DY7stHol8T+hYIMM 8DXZDBdndUMkU/DU5xfj4Z/wtgkB66eLKBypxqibiPx33vkBZOIAYtNYK7zFnrTk HnrHAGpm0sLlNdLzNA4XQ7yMTdDwzxW6GeYacYWxDT3t9Qc9vroGVju3CExQtljs

QSB-116: Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507) https://www.qubes-os.org/news/2026/07/28/qsb-116/ We have published Qubes Security Bulletin (QSB) 116: Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507) (https://github.com/QubesOS/qubes-secpack/blob/f9001423ffb11de26bdcf0b4478838739cc3f6b3/QSBs/qsb-116-2026.txt). The text of this QSB and its accompanying cryptographic signatures are reproduced below, followed by a general explanation of this announcement and authentication instructions. Qubes Security Bulletin 116 ---===[ Qubes Security Bulletin 116 ]===--- 2026-07-28 Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507) User action ------------ Continue to update normally [1] in order to receive the security updates described in the "Patching" section below. No other user action is required in response to this QSB. Summary -------- On 2026-07-28, the Xen Project published the security advisories below. XSA-500 [3] "grant-table: type confusion in grant-copy": | When grant-copy operations are processed, the respective grant may or | may not already be in use by another operation (a mapping or another | copy). For all copy operations the referenced guest frame is looked | up. When another operation is already active for the grant (the grant | is "pinned"), what is being supplied back to actually carry out | permission checks and copy operation may not be consistent: The | permission check may be carried out on a page different from the one | involved in the copy. XSA-505 [4] "evtchn: Race between FIFO expand and reset": | The EVTCHNOP_expand_array hypercall checks for whether FIFO event | channels are enabled, but without holding the correct lock. It can | race with EVTCHNOP_reset, resulting in deferencing a NULL pointer. XSA-506 [5] "correct buffer checks for DM_OP hypercalls": | Parts of the DM_OP handling code assumes the caller has provided the | required number of buffers for the given operation without any | checking being done. As a result, certain operations might access | stack rubble as structures are possibly uninitialized. XSA-507 [6] "PoD: Don't try to reclaim special pages": | A guest started with Populated on Demand enabled (PoD) can attempt to | reclaim pages which aren't regular guest RAM. This can cause | corruption of memory management state in Xen. Impact ------- XSA-500 and XSA-507: A malicious qube may be able to compromise Qubes OS. XSA-505: A malicious PV qube [7] may be able to compromise Qubes OS. The same impact applies to stubdomains for HVM qubes [8], but in this case an attacker would first have to discover and exploit an independent vulnerability (in QEMU) in order to gain access to the stubdomain. XSA-506: The stubdomain for an HVM qube may be able to leak data from other qubes in the system. In order to exploit this vulnerability, an attacker would first have to discover and exploit an independent vulnerability (in QEMU) in order to gain access to the stubdomain. Affected systems ----------------- XSA-500: All systems are affected. XSA-505: Systems with either PV qubes or stubdomains for HVM qubes (or both) are affected, but the vulnerability is easier to exploit on systems with PV qubes. In the default Qubes OS configuration, there are no PV qubes, but sys-net and sys-usb are HVM qubes that have stubdomains. This means that the vulnerability is more difficult to exploit in the default Qubes OS configuration, but if a user has manually created PV qubes in a particular system, the vulnerability will be easier to exploit on that system. XSA-506: Systems with untrusted HVM qubes are affected. In the default configuration of Qubes OS, sys-net and sys-usb are HVM qubes and are considered to be untrusted. XSA-507: Systems are affected if they have qubes that are included in memory balancing but that don't advertise memory hotplug support. This

XSAs released on 2026-07-28 https://www.qubes-os.org/news/2026/07/28/xsas-released-on-2026-07-28/ The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/). The security of Qubes OS is affected. XSAs that DO affect the security of Qubes OS The following XSAs do affect the security of Qubes OS: XSA-500 (https://xenbits.xen.org/xsa/advisory-500.html): See QSB-116 (https://www.qubes-os.org/news/2026/07/28/qsb-116/). XSA-505 (https://xenbits.xen.org/xsa/advisory-505.html): See QSB-116 (https://www.qubes-os.org/news/2026/07/28/qsb-116/). XSA-506 (https://xenbits.xen.org/xsa/advisory-506.html): See QSB-116 (https://www.qubes-os.org/news/2026/07/28/qsb-116/). XSA-507 (https://xenbits.xen.org/xsa/advisory-507.html): See QSB-116 (https://www.qubes-os.org/news/2026/07/28/qsb-116/). XSAs that DO NOT affect the security of Qubes OS The following XSAs do not affect the security of Qubes OS, and no user action is necessary: XSA-495 (https://xenbits.xen.org/xsa/advisory-495.html): Denial of service only. Shadow paging is disabled in Qubes OS at build time. XSA-496 (https://xenbits.xen.org/xsa/advisory-496.html): Denial of service only. Affects only Xen 4.21 and higher; Qubes OS 4.3 uses Xen 4.19. XSA-497 (https://xenbits.xen.org/xsa/advisory-497.html): Qubes OS does not use pygrub. XSA-499 (https://xenbits.xen.org/xsa/advisory-499.html): Denial of service only. XSA-501 (https://xenbits.xen.org/xsa/advisory-501.html): Qubes OS has grant tables v2 disabled. XSA-502 (https://xenbits.xen.org/xsa/advisory-502.html): Qubes OS does not use vnuma. XSA-503 (https://xenbits.xen.org/xsa/advisory-503.html): Allows leaking internal information about a qube only to itself, not other qubes. XSA-504 (https://xenbits.xen.org/xsa/advisory-504.html): Viridian is not enabled in Qubes OS. XSA-508 (https://xenbits.xen.org/xsa/advisory-508.html): Qubes OS does not use pygrub. About this announcement Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://doc.qubes-os.org/en/latest/developer/system/architecture.html). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.

Fedora 44 templates available https://www.qubes-os.org/news/2026/07/23/fedora-44-templates-available/ The following new Fedora 44 templates (https://doc.qubes-os.org/en/latest/user/templates/fedora/fedora.html) are now available for Qubes OS 4.3: fedora-44-xfce — default Fedora template with the Xfce (https://xfce.org/) desktop environment fedora-44-gnome — alternative Fedora template with the GNOME (https://www.gnome.org/) desktop environment fedora-44-minimal — minimal template (https://doc.qubes-os.org/en/latest/user/templates/minimal-templates.html) for advanced users There are two ways to upgrade a template to a new Fedora release: Recommended: Install a fresh template to replace an existing one. (https://doc.qubes-os.org/en/latest/user/templates/fedora/fedora.html#installing) This option is simpler for less experienced users, but it won’t preserve any modifications you’ve made to your template. After you install the new template, you’ll have to redo your desired template modifications (if any) and switch everything that was set to the old template to the new template (https://doc.qubes-os.org/en/latest/user/templates/templates.html#switching). If you choose to modify your template, you may wish to write those modifications down so that you remember what to redo on each fresh install. To see a log of package manager actions, open a terminal in the template and use the dnf history command. Advanced: Perform an in-place upgrade of an existing Fedora template. (https://doc.qubes-os.org/en/latest/user/templates/fedora/fedora-upgrade.html) This option will preserve any modifications you’ve made to the template, but it may be more complicated for less experienced users. Note: No user action is required regarding the OS version in dom0 (see our note on dom0 and EOL (https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/supported-releases.html#note-on-dom0-and-eol)).

If you or your organization are interested in sponsoring Qubes OS Summit 2026 or becoming a Qubes Partner (https://www.qubes-os.org/partners/), please contact us at funding@qubes-os.org (mailto:funding@qubes-os.org). Code of conduct This event is covered by the Qubes OS Project’s code of conduct (https://doc.qubes-os.org/en/latest/introduction/code-of-conduct.html).

Qubes OS Summit 2026: Tickets for sale and speaker proposals now open! https://www.qubes-os.org/news/2026/07/23/qubes-os-summit-2026-tickets-for-sale-and-speaker-proposals-now-open/ Qubes OS Summit 2026 (https://pretix.eu/qubes/summit2026/) is a three-day gathering of security enthusiasts, open-source developers, and digital privacy experts. When and where Friday, October 30 @ 9:30 AM — Sunday, November 1 @ 3:00 PM (GMT+1) (A more specific schedule will be published after the speaker lineup is finalized.) Refugio Berlin (https://refugio.berlin/) Lenaustraße 3-4 12047 Berlin View on OpenStreetMap (https://www.openstreetmap.org/way/263350430) Attend in person or online There are three ways to attend the Summit: In person at Refugio Berlin (https://refugio.berlin/) Requires a paid on-site ticket (https://pretix.eu/qubes/summit2026/) Grants access to the hackathon (including interactive workshops) and any design sessions (depending on conference schedule) Provides the opportunity to socialize, network, and mingle with like-minded individuals who are passionate about secure computing Grants exclusive access to any non-livestreamed, non-recorded presentations (see below) Grants access to attend presentations and participate as a live audience member Actively participate online Requires a free virtual ticket (https://pretix.eu/qubes/summit2026/) For those who are presenting remotely For those who are attending presentations remotely and wish to ask questions or engage in active discussion in a live chat during the presentations Does not grant access to the hackathon or any design sessions Does not provide the opportunity to socialize, network, or mingle with like-minded individuals who are passionate about secure computing Does not grant access to any non-livestreamed, non-recorded presentations (see below) Does not grant access to attend presentations as a live audience member Passively view online No ticket or registration required For those who simply wish to watch the presentations via the public livestream and recorded videos Does not provide the ability to ask questions or engage in active discussion during the presentations Does not grant access to the hackathon or any design sessions Does not provide the opportunity to socialize, network, or mingle with like-minded individuals who are passionate about secure computing Does not grant access to any non-livestreamed, non-recorded presentations (see below) Does not grant access to attend presentations as a live audience member Note: Presenters have the option to request that their presentations not be recorded. If a presenter opts out of recording, there will be a “no recording” icon next to that presentation in the conference schedule. Only on-site attendees will be able to view that presentation. It will not be livestreamed or recorded for later viewing. Become a presenter If you’d like to present at the Summit, please submit your proposal (https://pretalx.com/qubes-os-summit-2026/cfp) by 2026-08-31. You may present either on site or virtually from anywhere in the world. If your proposal is accepted and you wish to present in person, you’ll be issued an on-site ticket free of charge, no purchase necessary. If you select “Don’t record this session” when submitting your proposal, your presentation will not be livestreamed or recorded. Online attendees will not be able to view it. Conference schedule We’re still reviewing proposals from prospective presenters, so the list of talks has not been decided yet. We’ll publish a detailed conference schedule after the speaker lineup has been finalized. Become a sponsor

XSAs released on 2026-07-14 https://www.qubes-os.org/news/2026/07/14/xsas-released-on-2026-07-14/ The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/). The security of Qubes OS is not affected. XSAs that DO affect the security of Qubes OS The following XSAs do affect the security of Qubes OS: (none) XSAs that DO NOT affect the security of Qubes OS The following XSAs do not affect the security of Qubes OS, and no user action is necessary: XSA-498 (https://xenbits.xen.org/xsa/advisory-498.html): Qubes OS does not use XAPI. About this announcement Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://doc.qubes-os.org/en/latest/developer/system/architecture.html). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.

Last chance to take the 2026 user survey! (10-20 minutes) https://www.qubes-os.org/news/2026/07/11/last-chance-to-take-the-2026-user-survey/ As previously announced (https://www.qubes-os.org/news/2026/06/29/reminder-take-the-2026-user-survey-to-help-shape-the-future-of-qubes/), Qubes OS User Survey 2026 will close on 2026-07-13. If you still wish to take the survey and haven’t completed it yet, please do so now. Whether you’re a long-time Qubes user or haven’t even installed it yet, we want to hear about your experiences and about what matters to you. Help us make Qubes the best reasonably secure operating system it can be. If you’ve ever wanted to influence the development of Qubes, now is your chance. Make your voice heard! Qubes OS User Survey 2026 (https://pad.itl.space/form/#/2/form/view/4+jrJP2pyim2EyFwrbXrOVbQpzUg71Kt+DWR6p2M3IU/) This survey is fully anonymous. We do not collect any data except for the answers you provide.

Reminder: Take the 2026 user survey to help shape the future of Qubes! (10-20 minutes) https://www.qubes-os.org/news/2026/06/29/reminder-take-the-2026-user-survey-to-help-shape-the-future-of-qubes/ As previously announced (https://www.qubes-os.org/news/2026/06/11/qubes-os-user-survey-2026/), Qubes OS User Survey 2026 is currently live! The survey will remain open for two more weeks, until 2026-07-13. Whether you’re a long-time Qubes user or haven’t even installed it yet, we want to hear about your experiences and about what matters to you. Help us make Qubes the best reasonably secure operating system it can be. If you’ve ever wanted to influence the development of Qubes, now is your chance. Make your voice heard! Qubes OS User Survey 2026 (https://pad.itl.space/form/#/2/form/view/4+jrJP2pyim2EyFwrbXrOVbQpzUg71Kt+DWR6p2M3IU/) This survey is fully anonymous. We do not collect any data except for the answers you provide.

According to our release support policy (https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/supported-releases.html), stable Qubes OS releases are supported for six months after each subsequent major or minor release (https://doc.qubes-os.org/en/latest/developer/releases/version-scheme.html). This means that the EOL date for Qubes 4.2 was set at the time Qubes 4.3 was released by adding six months to the Qubes 4.3 release date. Qubes 4.3.0 was released on 2025-12-21 (https://www.qubes-os.org/news/2025/12/21/qubes-os-4-3-0-has-been-released/). Adding six months to this date gives us 2026-06-21, which is Qubes 4.2’s EOL date. Since the EOL date of 4.2 was determined at the time 4.3 was released, we also included this information in the 4.3.0 release announcement (https://www.qubes-os.org/news/2025/12/21/qubes-os-4-3-0-has-been-released/#support-for-older-releases).

Qubes OS 4.2 has reached end of life https://www.qubes-os.org/news/2026/06/21/qubes-os-4-2-has-reached-end-of-life/ As previously announced (https://www.qubes-os.org/news/2026/04/27/qubes-os-4-2-approaching-end-of-life/), the Qubes OS 4.2 release series has officially reached end of life (EOL) as of today, 2026-06-21. We strongly urge any remaining Qubes 4.2 users to upgrade to Qubes 4.3 (https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/upgrade/4_3.html) immediately. Recommended actions If you’re already using Qubes 4.3, then you don’t have to do anything. This announcement doesn’t apply to you. If you’re still using Qubes 4.2, then you should upgrade to Qubes 4.3 as soon as possible. There are two ways to do this: Perform a clean installation of Qubes 4.3 (https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/upgrade/4_3.html#clean-installation-of-qubes-4-3) using the latest stable Qubes OS 4.3.1 ISO (https://www.qubes-os.org/news/2026/06/11/qubes-os-4-3-1-has-been-released/). This involves backing up your current system (https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-back-up-restore-and-migrate.html), replacing your current installation with a fresh Qubes 4.3 installation (https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/installation-guide.html), then restoring from your backup (https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-back-up-restore-and-migrate.html#restoring-from-a-backup). Many users find this option to be simpler, easier, and less error-prone. However, if you’ve made extensive customizations in dom0, they may need to be redone. Perform an in-place upgrade from Qubes 4.2 to Qubes 4.3. (https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/upgrade/4_3.html#in-place-upgrade-from-qubes-4-2-to-qubes-4-3) Instead of replacing your existing installation, this method involves installing a special command-line tool in dom0, then using it to upgrade your existing Qubes 4.2 installation to Qubes 4.3. This is a more complex multi-stage process, which makes it most suitable for advanced users. This method preserves your qubes and all the customizations you’ve made in dom0 that are compatible with the in-place upgrade process. While not strictly required, we still strongly recommend making a full backup (https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-back-up-restore-and-migrate.html) before attempting an in-place upgrade. This way, if anything goes wrong, your data is still safe, and you always have the option of falling back to performing a clean installation. If you need help, please consult our help and support (https://doc.qubes-os.org/en/latest/introduction/support.html) page. What does end of life (EOL) mean? When an operating system reaches end of life (EOL), it is no longer supported. This means that it will no longer receive security updates, bug fixes, or new features. An OS that does not receive security updates will not be protected against new vulnerabilities, which is why it’s critically important to upgrade to a supported release. What about patch releases? The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as [major].[minor].[patch]. When a major or minor release reaches EOL, all of its patch releases also reach EOL. In this case, when we say that “Qubes 4.2” (without specifying a [patch] number) has reached EOL, we’re specifying a particular minor release inclusive of all patch releases within it. This means that Qubes 4.2.0, 4.2.1, 4.2.2, 4.2.3, and 4.2.4 have all reached EOL, since they’re all patch releases of the same minor release. How are EOL dates determined?

It’s possible that templates restored in 4.3.1 from a pre-4.3 backup may continue to target their original Qubes OS release repos (#8701 (https://github.com/QubesOS/qubes-issues/issues/8701)). After restoring such templates in 4.3.1, enter the following additional commands in a dom0 terminal: sudo qubes-dom0-update -y qubes-dist-upgrade sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade -y This will automatically choose the templates that need to be upgraded. The templates will be shut down during this process. Fresh templates on a clean 4.3.1 installation are not affected. Users who perform an in-place upgrade from 4.2 to 4.3 (instead of restoring templates from a backup) are also not affected, since the in-place upgrade process already includes the above fix in stage 4. For more information, see issue #8701 (https://github.com/QubesOS/qubes-issues/issues/8701). View the full list of known bugs affecting Qubes 4.3 (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20type%3ABug%20label%3Aaffects-4.3%20-label%3A%22R%3A%20cannot%20reproduce%22%20-label%3A%22R%3A%20declined%22%20-label%3A%22R%3A%20duplicate%22%20-label%3A%22R%3A%20not%20applicable%22%20-label%3A%22R%3A%20self-closed%22%20-label%3A%22R%3A%20upstream%20issue%22) in our issue tracker (https://doc.qubes-os.org/en/latest/introduction/issue-tracking.html). What’s a patch release? The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as [major].[minor].[patch]. Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.3) inclusive of all updates up to a certain point. See our supported releases (https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/supported-releases.html) for a comprehensive list of major and minor releases and our version scheme (https://doc.qubes-os.org/en/latest/developer/releases/version-scheme.html) documentation for more information about how Qubes OS releases are versioned.

Qubes OS 4.3.1 has been released! https://www.qubes-os.org/news/2026/06/11/qubes-os-4-3-1-has-been-released/ We’re pleased to announce the stable release of Qubes OS 4.3.1! This patch release aims to consolidate all the security updates and bug fixes that have occurred since the previous stable release. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO. The ISO and associated verification files (https://doc.qubes-os.org/en/latest/project-security/verifying-signatures.html) are available on the downloads (https://www.qubes-os.org/downloads/) page. Announcements Qubes 4.2 will reach end of life (EOL) on 2026-06-21 (https://www.qubes-os.org/news/2026/04/27/qubes-os-4-2-approaching-end-of-life/). If you’re a current 4.2 user who’s been waiting to upgrade to 4.3, the release of Qubes 4.3.1 is the perfect opportunity to do so. Qubes OS User Survey 2026 (https://pad.itl.space/form/#/2/form/view/4+jrJP2pyim2EyFwrbXrOVbQpzUg71Kt+DWR6p2M3IU/) is now live! Whether you’re a long-time Qubes user or haven’t even installed it yet, we want to hear about your experiences and about what matters to you. Help us make Qubes the best reasonably secure operating system it can be. The survey takes 10-20 minutes and is fully anonymous. We do not collect any data except for the answers you provide. If you’ve ever wanted to influence the development of Qubes, now is your chance. Make your voice heard! What’s new in Qubes 4.3.1? Security updates (https://www.qubes-os.org/security/qsb/) Bug fixes (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aclosed%20reason%3Acompleted%20type%3ABug%20label%3A%22affects-4.3%22%20closed%3A2025-12-21..2026-05-28%20-label%3A%22R%3A%20cannot%20reproduce%22%20-label%3A%22R%3A%20declined%22%20-label%3A%22R%3A%20duplicate%22%20-label%3A%22R%3A%20not%20applicable%22%20-label%3A%22R%3A%20self-closed%22%20-label%3A%22R%3A%20upstream%20issue%22%20-label%3A%22C%3A%20website%22%20-label%3A%22C%3A%20infrastructure%22%20-label%3A%22C%3A%20tests%22) Included Fedora template upgraded to Fedora 43. (Reminder: Fedora 42 has reached end of life. (https://www.qubes-os.org/news/2026/03/13/fedora-42-approaching-end-of-life/)) If you’re upgrading from Qubes 4.2, also see the Qubes 4.3 release notes (https://doc.qubes-os.org/en/r4.3/developer/releases/4_3/release-notes.html). How to get Qubes 4.3.1 If you’d like to install Qubes for the first time or perform a clean reinstallation on an existing system, there’s never been a better time to do so! Simply download (https://www.qubes-os.org/downloads/) the Qubes 4.3.1 ISO and follow our installation guide (https://doc.qubes-os.org/en/r4.3/user/downloading-installing-upgrading/installation-guide.html). If you’re currently using Qubes 4.2, make sure to upgrade from 4.2 to 4.3 (https://doc.qubes-os.org/en/r4.2/user/downloading-installing-upgrading/upgrade/4_3.html) no later than 2026-06-21, which is when 4.2 will reach EOL (https://www.qubes-os.org/news/2026/04/27/qubes-os-4-2-approaching-end-of-life/). If you’re currently on Qubes 4.3 (4.3.0 or 4.3.1-rc1), update normally (https://doc.qubes-os.org/en/r4.3/user/how-to-guides/how-to-update.html) (which includes upgrading any EOL templates and standalones (https://doc.qubes-os.org/en/r4.3/user/how-to-guides/how-to-update.html#upgrading-to-avoid-eol) you might have) in order to make your system essentially equivalent to the stable Qubes 4.3.1 release. No reinstallation or other special action is required. In all cases, we strongly recommend making a full backup (https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-back-up-restore-and-migrate.html) beforehand. Known issues in Qubes 4.3.1