Qubes OS Release History: Xen Compartments, Disposables and Support

Qubes OS is a desktop operating system that runs every task in its own Xen virtual machine, called a qube, so a compromised browser or document viewer cannot reach the rest of the system. As of 24 October 2026 the only supported release is Qubes OS 4.3, first released on 21 December 2025 and refreshed as 4.3.2 on 2 October 2026. Qubes 4.2 reached end of life on 21 June 2026.

Every Qubes release is supported until six months after the next major or minor release ships, so support dates are not fixed in advance: an end date appears only when the successor is out. This post walks through every release from R1 (September 2012) to 4.3 with start and end dates from the project's own supported releases page, explains how the system is put together (Xen, dom0, templates, app qubes, service qubes, qrexec and GUI isolation), how disposables, split GPG, vault qubes and Whonix fit in, how the project publishes security information, what hardware it needs, and a step by step routine from verifying the ISO signature to opening an untrusted attachment in a disposable.

Key takeaways

• One supported release today. The Qubes supported releases page lists Release 4.3 (start 2025-12-21, end "TBD") as the only supported release. Release 4.2 ran from 2023-12-18 to 2026-06-21.
• Support is relative, not calendar based. The same page says releases "are supported for six months after each subsequent major or minor release". The 4.2 end of life notice shows the arithmetic: 4.3.0 shipped on 2025-12-21, so 4.2 ended on 2026-06-21.
• Patch releases are ISO refreshes. 4.3.1 (11 June 2026) and 4.3.2 (2 October 2026) are not new releases; a fully updated 4.3.0 install is equivalent. The 4.3.2 announcement says to "update normally" from any 4.3 build.
• Isolation comes from Xen. Network and USB drivers live in unprivileged service qubes; dom0 has no network at all.
• Disposables are the everyday safety valve. They are destroyed when their first application closes, and 4.3 added preloading so they start faster.
• Security information is unusually transparent. 120 Qubes Security Bulletins since May 2011, an XSA tracker (121 of 507 Xen advisories affected Qubes as of 9 October 2026), and signed quarterly canaries.
• Every release is signed through one root key. ISOs are signed by a release signing key, which is in turn signed by the Qubes Master Signing Key, fingerprint 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494, created on 1 April 2010.
• Hardware is the hard part. You need VT-x with EPT (or AMD-V with RVI) and a working IOMMU; the project recommends Intel because it can ship microcode fixes there.

This post sits alongside our other operating system histories. For the Linux distributions that supply Qubes' dom0 and templates, see the Fedora, CentOS Stream and RHEL pipeline and every Debian release and support date. For isolation boundaries in server workloads, see Firecracker, Cloud Hypervisor and Kata compared, and for a desktop virtualization routine on a conventional host, see how to install Kali Linux in a virtual machine safely.

What Qubes OS is and where it came from

Qubes OS was announced by Joanna Rutkowska of Invisible Things Lab on 7 April 2010. The announcement post describes it as "an open source OS based on Xen, X, and Linux" designed for strong isolation in desktop computing. The project was then in alpha, and the post notes that a 40 page architecture document was published alongside it. The Qubes architecture page still links that Architecture Spec v0.3, describing it as "the original 2009 document that started this all" and marking it as of historical interest only.

What "security by compartmentalization" means

On most desktops your browser, mail client, PDF reader and code editor all run as you, read your files and share one network connection. Compromise one and the attacker usually has everything you have.

Qubes reverses that default. The architecture page says Qubes "implements a security-by-compartmentalization approach", using virtualization to isolate programs from each other and to sandbox system components such as networking and storage, "so that the compromise of any of these programs or components does not affect the integrity of the rest of the system." In practice you define compartments by the trust and purpose of the work. The getting started guide ships a "starter pack" of app qubes named work, personal, untrusted and vault, and says there is nothing special about them: they are suggestions.

The bet is not that every program is bug free. It is that a compromise stays inside one compartment, with one set of data and one network path.

Every Qubes OS release with start and end dates

The table below reproduces the supported releases page as of its last edit on 23 July 2026, with the dom0 base from the same page and the hypervisor and headline changes from each release's notes. Where a release's notes do not name the Xen version, the cell says so rather than guessing.

The overlap is real and often long. R3.2 shipped on 2016-09-29 but was supported until 2019-03-28, a full year after R4.0 arrived, because R4.0 needed newer hardware features and a major rewrite. R4.0 itself overlapped R4.1 by six months exactly (2022-02-04 to 2022-08-04). That six month window is now the norm.

R2's dom0 base is recorded differently in two places. The supported releases page lists Fedora 18 for Release 2, while the R2.0 release notes list "Dom0 distribution upgraded to Fedora 20" as a new feature. The likely explanation is that R2 started on Fedora 18 and moved to Fedora 20 during its life, but neither page says so, so treat the R2 row as uncertain.

Patch releases inside 4.2 and 4.3

Qubes uses three part version numbers. The 4.2 end of life notice explains that "Version numbers are written as [major].[minor].[patch]" and that a patch release designates its minor release "inclusive of all updates up to a certain point". When 4.2 ended, so did 4.2.0, 4.2.1, 4.2.2, 4.2.3 and 4.2.4. The Qubes news index gives these dates for the recent cycle:

The 4.3.2 announcement lists a default Fedora template upgraded to Fedora 44, the kernel-latest package moved to Linux 7.2, security updates and bug fixes. Its purpose is a fresh installer image. If you are already on 4.3, you do not reinstall.

Template support is a separate clock

Qubes support and template support are not the same thing. The supported releases page says Qubes support for each template ends "when that upstream release reaches end-of-life (EOL)". For Debian, Qubes support ends at the regular end of life date, not the long term support date, unless an exception is made. Whonix templates are supported by the Whonix Project under its own policy. As of the page's last edit, 4.3 supports Fedora 43 and 44 and Debian 13 templates.

Dom0 is the exception. The page explains that dom0 is isolated from the other domains, which can reach only a few interfaces (Xen, device backends and Qubes tools such as the GUI daemon and qrexec daemon), and the project patches those itself "regardless of the support status of the base distribution". That is why dom0 on 4.3 can stay on Fedora 41 even though the Qubes news index carried a "Fedora 41 approaching end of life" notice on 5 November 2025. The how to update guide says the dom0 release "doesn't have to be upgraded", but your templates do.

How Qubes is built

Xen runs on the hardware. Above it, dom0 is the privileged administrative domain; every other domain is unprivileged and runs applications, owns hardware or provides a network path.

Xen and why a bare metal hypervisor

The Qubes FAQ contrasts "Type 1" (bare metal) hypervisors with "Type 2" (hosted) hypervisors that run as applications inside a host operating system. With a hosted hypervisor, the host OS and everything running in it are part of what you trust. Qubes uses Xen, a Type 1 hypervisor, so "an attacker must be capable of subverting the hypervisor itself in order to compromise the entire system". The system requirements page adds that installing Qubes inside a virtual machine "is not recommended, as it uses its own bare-metal hypervisor (Xen)".

The architecture page's feature list adds network and USB drivers sandboxed in unprivileged VMs, no networking code in dom0, and centralized updates through templates.

Dom0: the administrative domain

Dom0 runs the desktop environment and window manager and holds the administrative tools. The getting started guide says that because of its importance "dom0 has no network connectivity and is used only for running the desktop environment and window manager" and should never be used for anything else.

No network in dom0 creates a practical problem: how does it get updates? The dom0 secure updates design answers it. The qubes-dom0-update script in dom0 asks an UpdateVM (by default the firewall qube) to download the RPM packages. The UpdateVM hands them to dom0 through a qrexec service, and dom0 verifies the package signatures itself. The design document assumes the download side "might get compromised", which is fine because dom0 does the checking.

Templates, app qubes and what persists

Most of the software you use is installed in templates and run in app qubes. The templates guide explains the security property: "Each qube has read-only access to the template on which it's based, so if a qube is compromised, it cannot infect its template or any of the other qubes based on that template."

An app qube inherits its root filesystem from its template, and only /home, /usr/local and /rw/config persist across reboots. Anything else a process writes to the root filesystem disappears when the qube restarts. One template update therefore updates every app qube built on it at their next restart, which is how a Qubes system with twenty qubes stays manageable. Since R4.0, templates also have no network interface by default and fetch updates through a qrexec based updates proxy, according to the R4.0 release notes.

Service qubes: sys-net, sys-firewall and sys-usb

Hardware that talks to the outside world is assigned to unprivileged qubes:

• sys-net owns the network cards. The IOMMU (VT-d or AMD-Vi) lets Xen give the network controller to this qube while preventing the device from reading arbitrary memory through DMA.
• sys-firewall sits between app qubes and sys-net. The firewall guide says rules for a qube are enforced on its net qube, so if a qube uses sys-firewall as its net qube, sys-firewall implements the rules, and recommends that qubes connect to sys-firewall rather than directly to sys-net.
• sys-usb holds the USB controllers, so a malicious USB device first meets an unprivileged, often disposable qube rather than dom0. The USB qubes guide warns about the main side effect: if your keyboard is on the only USB controller, giving that controller to sys-usb can lock you out of dom0, so it describes a supported way to proxy a USB keyboard into dom0.

The installation guide offers to make sys-firewall and sys-usb disposable and says this is "Enabled by default as it fits most users' needs". The R4.1 notes list "sys-firewall and sys-usb are now disposables by default" as a change in that release.

qrexec: how qubes talk without trusting each other

Qubes are isolated, but they still need to cooperate: open a link from the mail qube in a browser, copy a file, request a signature from a key qube. The qrexec documentation describes the framework that does this. It is built on vchan, a Xen library for data links between VMs. A qrexec-daemon runs in dom0 for each VM, and a qrexec-agent runs inside the VM.

For service calls, the design decision was "to pass all control communication via dom0 which can enforce proper authorization." Each service, such as qubes.OpenURL or qubes.Filecopy, has policy lines in files under /etc/qubes/policy.d/ in dom0. A rule names the service, the source qube, the destination and an action (allow, deny or ask). Only standard input and output pass between the two ends, no command line arguments, and the receiving side learns the caller's name from an environment variable set by dom0, so the caller cannot lie about who it is. Lower numbered policy files override higher numbered ones, which is why the documentation suggests putting your own rules in something like 30-user.policy rather than editing 90-default.policy.

R4.1 introduced a new qrexec policy format and policy daemon, and the R4.2 notes record that qrexec services use the new format by default from that release, with the old format still supported.

GUI isolation: one desktop, many trust levels

The GUI virtualization document explains that each app qube runs its own X server with a dummy video driver that paints into memory, and a pair of processes (qubes-gui in the app qube and qubes-guid in the GUI domain, dom0 by default) connect over vchan. Rather than streaming pixels, the app qube shares the memory pages holding each window's composition buffer, and the GUI daemon draws them.

Two security properties follow. First, keyboard and mouse events go to a qube only when one of its windows has focus, and the document says a qube "has no way to get information on keystrokes fed to other AppVMs" or to inject events into them. Second, window borders are drawn by dom0 in the qube's label color, so a window cannot pretend to belong to a more trusted qube. QSB-105 in October 2024 concerned "missing enforced decorations for stubdomain windows under KDE", which shows how seriously the project treats that boundary.

Disposables, split GPG, vault qubes and Whonix

How disposables work

The disposables guide defines a disposable as "a stateless qube, which does not save data between reboots". There are three related objects:

The guide's worked example is the one most people care about. In a work-email qube you click a link; it opens in a new disposable through the qubes.OpenURL service. You open a PDF attachment; it opens in another disposable through qubes.OpenInVM. If either is malicious, it compromises a qube that will be destroyed in minutes and never had access to your mailbox.

Disposables can also sanitize files. Right click and choose "Convert in disposable qube", or run qvm-convert-pdf or qvm-convert-img, and a disposable renders the untrusted PDF or image to an RGBA bitmap, sends back only pixels, and the app qube rebuilds a clean file. The output is larger and loses selectable text, the price of removing anything active.

In qrexec policy, the @dispvm keyword means "a new disposable created for this request". The disposable implementation notes explain that a rule using @dispvm resolves to a disposable based on the calling qube's default_dispvm, and that you can target a specific disposable template with @dispvm:NAME.

What changed in 4.3. The 4.3 release notes list preloaded disposables as a headline feature: Qubes starts a configurable number of disposables in the background, hidden from most tools, and hands one over when you ask. The disposables guide shows the setting as qvm-features dom0 preload-dispvm-max 2, and says preloading works from any disposable template that supports qrexec except Qubes Windows Tools.

Split GPG: a software smart card in another qube

The split GPG guide describes it as "a concept similar to having a smart card with your private GPG keys, except that the role of the 'smart card' is played by another Qubes app qube." Your mail client runs in one qube. Your private keys live in a separate, network disconnected backend qube (the guide calls its example work-gpg). The client calls qubes-gpg-client, which passes requests over qrexec to the backend.

The guide's argument for this over a hardware smart card is about consent rather than key extraction. A smart card protects the key itself, but malware on the host can still ask the card to decrypt every document it finds. With split GPG the user must approve key access, with a time window that defaults to five minutes, and receives a notification from the backend each time the key is used, so unexpected requests stand out. The guide also notes that a newer implementation, Split GPG-2, adds features, and the R4.2 notes added split GPG management to Qubes Global Settings.

Vault qubes

"Vault" is one of the four starter app qubes the installer can create, and the split GPG guide's advanced example places the master secret key (sec) in a qube named vault, the signing subkeys in work-gpg, and only public keys in work-email. The point of a vault qube is simple: a qube with no net qube cannot send data anywhere over the network, and qrexec policy decides what can be copied in or out. Check that your vault really is offline with qvm-prefs vault netvm, as shown in the walkthrough below, rather than assuming.

Whonix on Qubes

Whonix is a separate project that routes traffic over Tor using two machines. The Whonix Qubes page describes "an isolated Whonix-Gateway" proxy qube, sys-whonix, that routes all its clients' traffic over Tor, and a Whonix-Workstation app qube, anon-whonix, for desktop applications. Because the workstation can only reach the network through the gateway, a compromised application in the workstation cannot learn the real IP address from the network stack it can see.

On Qubes 4.3 the templates are whonix-gateway-18 and whonix-workstation-18, and the 4.3 release notes say Whonix templates older than 18 are not supported. Whonix templates are built and supported by the Whonix Project under its own support policy, as the supported releases page notes. Qubes integration has a long history: the R2.0 notes list "Out of the box TorVM support", and the R3.0 notes list Whonix templates as new. The Qubes FAQ is direct about the limits: privacy "is difficult to achieve and maintain", and no tool is perfect.

How Qubes handles security information

Qubes publishes its security information through signed, verifiable channels rather than only a web page, because the project treats its own infrastructure as untrusted.

Qubes Security Bulletins

The QSB index defines a Qubes Security Bulletin as "a security announcement issued by the Qubes security team through the Qubes security pack". A QSB summarizes one or more vulnerabilities, analyses their impact on Qubes and explains how to patch. The first, QSB-001 on 12 May 2011, covered a GUI daemon bug and a VT-d escape on hardware without interrupt remapping. The most recent as of this post is QSB-120 on 8 October 2026, covering two CTAP proxy vulnerabilities.

The 2026 list shows the spread of causes:

Roughly half are hypervisor or CPU issues and the rest are in Qubes' own tools or desktop components. That matches the threat model: the hypervisor and the inter-qube plumbing are where a compartmentalization system can fail. The how to update guide says most QSBs are resolved by updating normally, but some ask you to restart components, and some ask Anti Evil Maid users to reseal.

The XSA tracker

Xen publishes its own advisories, the Xen Security Advisories, numbered XSA-1 upward, under the Xen Project security policy. That policy sends embargoed advisories with patches to members of a pre-disclosure list before the public release date, then publishes them to the mailing lists and the advisories page. As of 24 October 2026 the xenbits list shows XSA-522 (public on 9 October 2026) as the highest numbered public advisory, XSA-518 to XSA-521 going public on 13 October, and XSA-523 assigned but embargoed until 3 November 2026.

Not every Xen bug matters to Qubes. Some affect Arm, some affect features Qubes does not use, and some are denial of service only. The Qubes XSA tracker marks every XSA "Yes" or "No" for "Is Qubes affected?" and links the QSB when the answer is yes. It deliberately does not count pure denial of service as affecting Qubes security, and it omits embargoed XSAs because the Xen policy forbids saying whether Qubes is affected before the embargo lifts. Its statistics line, as fetched for this post, reads: 507 XSAs published between 14 March 2011 and 9 October 2026, 121 affecting Qubes, or 23.87 percent.

So roughly three quarters of hypervisor advisories did not affect Qubes' security as Qubes configures Xen, and the tracker says patches for the rest were almost always published together with the QSB.

Canaries

A Qubes canary is a signed statement, published through the security pack, that the signers have not been compromised. Canary 048, issued on 9 September 2026, states that 118 QSBs had been published, repeats the Qubes Master Signing Key fingerprint, says no warrants have ever been served with regard to the project, and plans the next canary for the first fourteen days of December 2026. The canary page lists them roughly every three months: 045 on 2025-12-10, 046 on 2026-03-12, 047 on 2026-06-03 and 048 on 2026-09-09. The canary also restates the project's founding assumption: Qubes "has been designed under the assumption that all relevant infrastructure is permanently compromised."

The signal is absence: a missing canary, or statements changed without explanation.

Signed ISOs and the Qubes Master Signing Key

The verifying signatures guide sets out the chain:

The guide calls this philosophy "distrusting the infrastructure": the website, mirrors, hosting staff and networks may all be compromised, so you trust the signature, not the download location. It is equally clear about what signatures do not prove. A signature shows a file came unaltered from the key holder; it cannot show the file is free of bugs or malice.

The hard step is authenticating the QMSK itself. Anyone can create a key named "Qubes Master Signing Key" with the short ID 0x36879494. The guide asks you to compare the full 40 character fingerprint against several independent sources (mailing lists, conference slides, old ISOs, other networks, people you know) before trusting it, then set its trust to ultimate so it can vouch for the release key.

What hardware Qubes needs and why laptops struggle

Minimum and recommended

From the system requirements page:

The page warns that these requirements are "necessary, but not sufficient": meeting them does not guarantee Qubes will install and run well.

Why the project recommends Intel today

The requirements page explains a security difference rather than a performance one. Some vulnerabilities can only be fixed with CPU microcode. On Intel platforms, microcode updates "can typically be loaded from the operating system", so the Qubes security team can ship them with other updates. On AMD client platforms, the page says, microcode updates typically arrive only inside system firmware updates, which depend on the processor maker releasing them to device makers and the device maker shipping a firmware update. The page states that Qubes runs on AMD systems and that the Qubes and Xen teams support them as well as they can, "However, without the ability to ship microcode updates, there is only so much they can do." It also recommends processors still receiving microcode updates at all.

Why some laptops struggle

The usual problems are all visible in the requirements and USB documentation:

• IOMMU off or broken in firmware. The installation guide says that even on supported hardware you must turn on VT-d or AMD-Vi in the firmware settings, and that the installer runs a compatibility test. Without a working IOMMU, sys-net and sys-usb lose the isolation they exist to provide.
• Graphics drivers. Dom0 drives the display. The requirements page says some discrete GPUs "may require significant troubleshooting".
• A single USB controller with the keyboard on it. Common on small laptops; this is why the requirements page recommends a non-USB keyboard or multiple USB controllers.
• Memory. Every qube is a virtual machine with its own kernel. 6 GB boots; 16 GB is what lets you run a browser, a mail client, a disposable and the service qubes at once.

The HCL and certified hardware

There are three hardware lists, and they mean different things. The requirements page distinguishes them: certified hardware is "Qubes developer certified, officially recommended", community recommended hardware is "unofficially recommended", and the hardware compatibility list is "community test results, neither recommended nor disrecommended".

Certification has stricter requirements than the minimum. The requirements page lists open source boot firmware such as coreboot, hardware switches for any built-in USB connected microphones, and either non-USB input devices or a separate USB controller only for input. The certified hardware page says certified computers are certified for a major release and that the developers test all new updates within that release to prevent regressions. The project certifies compatibility only, and says it takes no responsibility for any vendor's manufacturing, shipping or payment practices. The news index shows two more laptops certified on 21 October 2026.

Walkthrough: verify, install, update and open an attachment in a disposable

These steps follow the Qubes documentation for 4.3. Where a command writes to a disk, a warning and a device check come first.

Step 1: get and authenticate the master signing key

On the machine you will use for downloading (any Linux system with GnuPG), import the QMSK using one of the routes in the verifying signatures guide:

gpg2 --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg2 --fingerprint "Qubes Master Signing Key"

The fingerprint must read 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494. Do not trust that string because this post printed it; compare it with copies from independent places, as the guide asks. Then mark the key as ultimately trusted:

gpg2 --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
# at the gpg> prompt: fpr, then trust, choose 5, confirm with y, then q
gpg2 -k "Qubes Master Signing Key"

The last command should show uid [ultimate] Qubes Master Signing Key.

Step 2: get the release signing key and check the QMSK signed it

Download the release signing key for 4.3 from the downloads page or the Qubes keyserver, import it and check its signatures:

gpg2 --keyserver-options no-self-sigs-only,no-import-clean \
  --fetch-keys https://keys.qubes-os.org/keys/qubes-release-4.3-signing-key.asc
gpg2 --check-signatures "Qubes OS Release 4.3 Signing Key"

You are looking for a line starting sig! from DDFA1A3E36879494 ... Qubes Master Signing Key. The guide explains that sig! means a valid signature, sig- means a bad one and sig% means an error.

Step 3: verify the ISO

Download the ISO and its detached .asc signature into the same directory, then:

gpg2 -v --verify Qubes-R4.3.2-x86_64.iso.asc Qubes-R4.3.2-x86_64.iso

Expect "Good signature from Qubes OS Release 4.3 Signing Key". Any other result means stop. The guide's troubleshooting section lists the usual causes (wrong file, wrong command, incomplete download) and suggests downloading the signature and the ISO again from a different source. Use the exact ISO filename from the downloads page; the name above follows the documented Qubes-RX-x86_64.iso pattern for 4.3.2.

Step 4: write the ISO to a USB drive

Warning: the next command overwrites the target device completely. Writing to the wrong device path destroys whatever is on it, including your current system disk. Run the device check first and confirm the path every time.

Check which device is the USB drive before writing. Plug it in, then:

lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS

Find the disk whose size, model and usb transport match your stick, for example /dev/sdY. Unmount any partitions on it. Only then write the image, as the installation guide shows:

sudo dd if=Qubes-R4.3.2-x86_64.iso of=/dev/sdY status=progress bs=1M conv=fsync

The verifying signatures guide also describes re-verifying the written stick on a different computer by piping exactly the ISO's byte count from the device into gpg -v --verify, which catches a compromised machine altering data as it writes.

Step 5: firmware settings and install

Warning: installing Qubes on a disk erases that disk. Back up anything you need first and confirm the installation destination on the installer's disk screen before you begin.

Per the installation guide: enable VT-x and VT-d (or AMD-V and AMD-Vi) in the firmware; on UEFI systems disable Secure Boot, which the guide says is needed for Qubes to boot; boot from the USB drive. The installer runs an IOMMU check before the main screen; if it fails, revisit the firmware settings. The destination needs at least 32 GiB and cannot be the installation medium itself. On first boot, the configuration screen offers to create the service qubes, make sys-firewall and sys-usb disposable (enabled by default), create the default app qubes, and, if memory allows, preload disposables.

Step 6: update dom0 and every template

From a dom0 terminal, using the commands in the how to update guide:

sudo qubes-dom0-update
qubes-vm-update -T

The first updates dom0 through the UpdateVM; the second updates all updatable templates. The guide warns against running dnf update or apt update directly in templates, because that bypasses Qubes' update security measures (installing packages directly is fine). Restart dom0 after Xen, kernel or microcode updates, and restart qubes after their template updates. To see what you are running:

cat /etc/qubes-release
qvm-ls --fields NAME,CLASS,STATE,TEMPLATE,NETVM

The second command also shows which qubes have a net qube. For the vault:

qvm-prefs vault netvm

An empty result means no network. If it prints a net qube name, set the vault's net qube to none in its Qube Settings (or with qvm-prefs vault netvm '') before putting secrets there.

Step 7: check that templates are still supported

Compare the templates in qvm-ls against the supported releases page (Fedora 43 and 44, Debian 13 for 4.3 at the time of writing). If you restored templates from a pre-4.3 backup, the 4.3.0 and 4.3.2 announcements both carry the same known issue: they may still target the old release's repositories. The fix from those announcements, run in dom0:

sudo qubes-dom0-update -y qubes-dist-upgrade
sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade -y

Step 8: open untrusted attachments in a disposable by default

From inside an app qube, open a single file in a disposable, either editable or view only, with the commands from the disposables guide:

qvm-open-in-dvm -- 'invoice.pdf'
qvm-open-in-dvm --view-only -- 'invoice.pdf'

From dom0, start a browser in a fresh disposable:

qvm-run --dispvm=default-dvm --service -- qubes.StartApp+firefox

To make it the default for one qube, set which disposable template that qube uses, and route its "open" requests to disposables with a qrexec policy line in a file such as /etc/qubes/policy.d/30-user.policy in dom0:

qubes.OpenInVM  *  work-email  @dispvm  allow
qubes.OpenURL   *  work-email  @dispvm  allow

Then set the disposable template the email qube should use and turn on preloading so disposables appear quickly:

qvm-prefs work-email default_dispvm default-dvm
qvm-features dom0 preload-dispvm-max 2

The policy format, service argument source destination action, is described in the qrexec documentation. Test it by opening an attachment and checking in the Qubes Domains widget that a new dispNNNN qube appeared and vanished when you closed the viewer. For a file you need to keep, convert it rather than opening the original:

qvm-convert-pdf invoice.pdf

Qubes, a hardened single OS, Tails and container sandboxes compared

There is no single answer to "is Qubes more secure than X?". The table compares isolation boundary, usability and update model.

Some notes on reading it:

• Qubes and Tails solve different problems. The Qubes FAQ points out that live systems such as Tails are "still monolithic": all software runs in the same OS, so a compromise reaches everything in that session. Tails' strength is different: its about page says it "always starts empty and leaves no trace", and that everything you do on the internet from Tails "goes through the Tor network". On Qubes, Whonix provides the Tor routing, and the Qubes documentation lists running Tails inside Qubes as a community guide.
• Containers share the kernel. The namespaces manual page describes a namespace as wrapping a global system resource so processes inside see their own isolated instance of it. That is an excellent packaging and resource tool, but the boundary is the host kernel's system call interface, which is much larger than a hypervisor's. That is the same trade-off our server side virtualization comparison covers for cloud workloads.
• A hardened single OS suits most people. Qubes earns its cost when the threat model includes targeted attacks on the desktop or routine handling of untrusted files and devices.
• A separate physical machine is still an option. The FAQ lists its advantage honestly: physical separation "doesn't rely on a hypervisor". Its costs are convenience and the lack of controlled channels (secure copy and paste, qrexec policy) between machines.

Common mistakes

• Treating 4.3.2 as a new release you must reinstall. It is a patch release. A fully updated 4.3.0 or 4.3.1 system is equivalent; reinstall only if you want a fresh image.
• Staying on 4.2. It has received nothing since 21 June 2026. Upgrade in place or reinstall and restore.
• Trusting the fingerprint on the website alone. The verifying signatures guide says qubes-os.org "will surely be compromised one day" and asks you to confirm the fingerprint from multiple independent sources.
• Running dnf update or apt update in templates. Use the Qubes Update tool, qubes-vm-update or the Salt states, which keep the update proxy and checks in the loop.
• Forgetting templates have their own end of life. Qubes support for a Fedora or Debian template ends when upstream support does; for Debian that is the regular end date, not long term support.
• Installing software in an app qube and expecting it to persist. Only /home, /usr/local and /rw/config survive a restart. Install in the template.
• Giving the only USB controller to sys-usb with a USB keyboard. Use the documented qvm.usb-keyboard Salt state, or keep a non-USB keyboard available.
• Leaving the vault with a net qube. Check qvm-prefs vault netvm and clear it.
• Opening attachments in the email qube "just this once". Make the disposable route the default with a qrexec policy rule so it is not a decision you make each time.

FAQ

What is the latest version of Qubes OS?

Qubes OS 4.3, with the 4.3.2 installer image released on 2 October 2026. It is the only supported release. A fully updated 4.3.0 or 4.3.1 system is equivalent to 4.3.2.

When did Qubes OS 4.2 reach end of life?

On 21 June 2026, six months after 4.3.0 was released on 21 December 2025. All 4.2 patch releases (4.2.0 to 4.2.4) ended at the same time.

How long is each Qubes OS release supported?

Until six months after the next major or minor release. There is no fixed number of years. The end date for 4.3 will be set when 4.4 or 5.0 ships.

Is Qubes OS based on Linux?

Qubes runs on the Xen hypervisor. Dom0 and most app qubes run Linux, with Fedora as dom0's base (Fedora 41 in 4.3) and Fedora, Debian and Whonix templates for app qubes. Windows qubes are also possible, and 4.3 reintroduced Qubes Windows Tools.

Does Qubes OS work on AMD processors?

Yes, but the project recommends Intel. Its requirements page explains that on AMD client platforms microcode security fixes usually arrive only through firmware updates from the device maker, so Qubes cannot ship them directly.

What is a disposable qube in Qubes OS?

A qube started from a disposable template that is destroyed when its first application closes, so nothing it did persists. Qubes can open links and attachments in disposables automatically, and 4.3 can keep some preloaded for instant start.

Is Qubes OS more secure than Tails?

They protect against different things. Tails is an amnesic live system focused on leaving no trace and using Tor, but everything in a session shares one OS. Qubes separates tasks into virtual machines on one installed system and can use Whonix for Tor routing.

How do I verify a Qubes OS ISO?

Import the Qubes Master Signing Key, confirm its fingerprint from several independent sources, import the release signing key and check that the master key signed it, then run gpg2 -v --verify on the ISO and its .asc file and look for a good signature.

What are Qubes Security Bulletins and XSAs?

XSAs are Xen Project advisories for the hypervisor. QSBs are Qubes' own bulletins, covering Xen issues that affect Qubes plus bugs in Qubes tools, desktop components and CPUs. The Qubes XSA tracker marks which XSAs affect Qubes: 121 of 507 as of 9 October 2026.

Where Safeguard fits, honestly

Safeguard does not secure Qubes OS itself. It is not an endpoint product, it does not scan dom0, firmware or the Xen hypervisor, and Qubes updates come only from the Qubes project and the template distributions. The fit is the software you build on a Qubes machine, usually in a dedicated development qube or a disposable.

A compartmentalized workstation limits what a compromised tool can reach, but the code you build in a development qube still pulls open source dependencies and base images that end up in what you ship. Those components need their own fix path, which is what the options below cover; fixes for Qubes, Xen and the template distributions still come from those projects.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On Qubes, the natural home for that is a dedicated development app qube with network access through sys-firewall, so the runner and the code it scans stay in the same compartment as your builds and away from your vault and email qubes.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. That approval at each step suits the Qubes habit of deciding explicitly what crosses a boundary, and running it in a development qube keeps the session confined to that qube's files.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Choosing tools one by one is the same least privilege idea as a qrexec policy: once your projects are in Safeguard, you can ask which of them contain a given component and version without granting more access than that question needs.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Qubes OS supported releases
• Introducing Qubes OS, Invisible Things Lab blog, 7 April 2010
• Qubes architecture overview
• Qubes Architecture Spec v0.3 (PDF, historical)
• Qubes OS 4.3.0 has been released
• Qubes OS 4.2 has reached end of life
• Qubes OS 4.3.2 has been released
• Qubes news index
• Qubes R1.0 release notes
• Qubes R2.0 release notes
• Qubes R3.0 release notes
• Qubes R3.2 release notes
• Qubes R4.0 release notes
• Qubes OS 4.1 release notes
• Qubes OS 4.2 release notes
• Qubes OS 4.3 release notes
• Qubes getting started
• Qubes FAQ
• Qubes templates
• Qubes dom0 secure updates
• Qubes firewall
• Qubes USB qubes
• Qrexec: secure communication across domains
• Qubes GUI virtualization
• How to use disposables
• Disposable implementation
• Split GPG
• Whonix on Qubes
• Qubes Security Bulletins
• Qubes XSA tracker
• Xen Security Advisories
• Xen Project security policy
• Qubes canaries
• Qubes Canary 048
• Verifying signatures
• System requirements
• Certified hardware
• Hardware compatibility list
• About Tails
• namespaces(7) Linux manual page
• Installation guide
• How to update

Last reviewed: 24 October 2026. Qubes support dates are set when each successor release ships; check the Qubes supported releases page and the news index before planning an upgrade.