This week&aposs work centers on kernel and board enablement, CI infrastructure and caching, and user-facing tooling improvements across the imager and configuration utilities.
On the kernel and board front, Rockchip edge moved to 7.1 and mainline was bumped to 7.1-rc7, while the Raspberry Pi 4B legacy target was re-enabled after a brief revert of the BCM2711 kernel bumps. New board support landed for BeagleBadge and TMDS64EVM (AM64x) on the TI platform, the Anbernic RG DS RK3568 handheld as CSC, and the Youyeetoo YY3588 received a mainline DTS rework with ES8388 audio routing. Several long-standing fixes were merged, including a meson64 GPIO can_sleep regression breaking 1-Wire, JMicron JMB582/JMB585 32-bit DMA forcing, and QRB2210 U-Boot load address corrections.
A substantial CI and caching effort introduces a new git_cdn module providing a GitHub caching git+http proxy, an apt-cacher-ng configng module, and multi-arch Docker images for both. GitHub Actions runners now export per-runner apt, ghcr, ccache, and proxy environments from the NetBox registry, with added retry guards, SSH/rsync timeouts, and workspace ownership reconciliation between jobs. The rootfs builder now routes mmdebstrap through APT_PROXY_ADDR when configured.
User-facing changes focus on the Armbian Imager and first-run experience. The imager gained marquee scrolling for long board names, a "Create new profile" shortcut, accurate progress-phase reporting, and surfaced flash write failures in place of blank error screens. The first-login flow now runs automatically on freshly-flashed boards, and armbian-firstrun uses atomic writes for armbianEnv.txt MAC randomization to prevent corruption.
Modern applications generate more traffic, serve more users, and depend on more distributed infrastructure than ever before. Whether you are running a SaaS platform, an e-commerce website, a banking application, or a public API, ensuring traffic reaches the right resources efficiently is critical for performance, availability, and security.
This is where load balancing plays a central role.
However, modern traffic management is no longer just about distributing connections across servers. Organizations increasingly need visibility into application behaviour, real-time traffic control, and integrated security capabilities to support complex digital services.
As a result, one of the most common questions infrastructure teams face is understanding the difference between Layer 4 (L4) and Layer 7 (L7) load balancing.
The answer is not simply a matter of choosing one over the other.
Layer 4 and Layer 7 address different aspects of application delivery. While Layer 4 focuses on fast and efficient traffic distribution at the transport layer, Layer 7 introduces application awareness, enabling advanced routing decisions, security enforcement, and traffic optimization.
In modern architectures, both approaches often work together. Understanding how they complement one another is essential for designing resilient application infrastructures capable of delivering performance, availability, visibility, and security at scale.
Why Modern Applications Require More Than Basic Load Balancing
Ten years ago, many organizations operated relatively simple environments: a web application on a handful of servers behind a basic load balancer distributing incoming connections evenly.
Today’s reality is fundamentally different. Modern infrastructures must support:
Cloud and hybrid deployments
Containerized workloads and Kubernetes environments
Public and private APIs
Microservices architectures
Multi-region applications with continuous traffic growth
Increasingly sophisticated security requirements
As applications become more distributed, traffic management becomes significantly more complex. A load balancer is no longer simply a tool for distributing connections between servers. It has become a critical component of application delivery, helping organizations maintain availability, optimize performance, enforce security policies, and gain visibility into application behaviour.
For some workloads, simple connection-based distribution is sufficient. For others, routing decisions must consider URLs, HTTP headers, SSL certificates, API requests, user sessions, and security policies. This is precisely where the distinction between Layer 4 and Layer 7 load balancing becomes important.
What Is Layer 4 (L4) Load Balancing?
Layer 4 load balancing operates at the Transport Layer of the OSI model. Instead of inspecting application content, it makes routing decisions using network-level information: source IP address, destination IP address, TCP/UDP ports, and protocol type.
When a connection arrives, the load balancer evaluates this information and forwards traffic to an available backend server according to predefined algorithms such as Round Robin, Least Connections, or Weighted Distribution.
Layer 4 load balancing is the fastest approach to traffic distribution. Because it does not inspect packet payloads, routing decisions are made with minimal computational overhead, making it ideal for latency-sensitive workloads processing high volumes of concurrent connections.
Imagine a financial platform processing tens of thousands of encrypted TCP connections per second. The priority is handling traffic efficiently while minimizing latency. In this scenario, Layer 4 load balancing is often the most effective choice.
Where Layer 4 Adds Value
Layer 4 excels when the primary objective is processing large volumes of traffic with the lowest possible latency. Typical use cases include:
DNS services and VoIP platforms
SMTP infrastructure and database traffic
High-volume TCP applications and real-time communication systems
Internal service communication where application-layer inspection adds no value
Advantages of L4 Load Balancing
Extremely high throughput with very low latency
Lower resource consumption and simpler configuration
Broad protocol support and efficient connection handling
Limitations of L4 Load Balancing
Because Layer 4 only understands network and transport information, it cannot:
Route traffic based on URLs or HTTP headers
Apply content-aware policies or understand API requests
Perform application-level security inspection
Integrate natively with WAF functionality
As applications become more sophisticated, these limitations can become significant, particularly for organizations exposing web applications, APIs, and digital services to the Internet.
What Is Layer 7 (L7) Load Balancing?
Layer 7 load balancing operates at the Application Layer of the OSI model. Unlike Layer 4, it understands application protocols such as HTTP, HTTPS, HTTP/2, gRPC, and WebSockets, enabling routing decisions based on application-specific information.
Instead of simply deciding where a connection should go, a Layer 7 load balancer understands what the user is trying to do. For example:
/api/* can be routed to dedicated API server clusters
/images/* can be directed to static content servers
/checkout/* can be forwarded to payment infrastructure
/admin/* can be restricted to administrative service pools
Layer 7 load balancing transforms traffic management from a network function into an application intelligence layer. It enables organizations to route, inspect, and secure traffic based on exactly what each request is trying to accomplish.
Where Layer 7 Becomes Essential
In many modern environments, Layer 7 capabilities are no longer optional. As organizations expose more applications, APIs, and digital services to the Internet, traffic management increasingly requires visibility, security controls, and application awareness. This is why Layer 7 functionality has become a fundamental component of modern Application Delivery and Security architectures.
Typical use cases include web applications, SaaS platforms, REST APIs, e-commerce environments, customer portals, multi-tenant applications, and Zero Trust architectures.
Advantages of L7 Load Balancing
Content-based routing and SSL/TLS termination
Session persistence and API traffic management
Advanced traffic policies and granular access control
Native WAF integration and application-level security visibility
Limitations of L7 Load Balancing
The additional intelligence comes with additional resource requirements. Compared to Layer 4, Layer 7 typically requires more CPU, more memory, more configuration effort, and greater operational expertise. For most modern web applications, however, the operational benefits significantly outweigh the overhead.
Key Differences Between L4 and L7 Load Balancing
The comparison between Layer 4 and Layer 7 is often presented as a choice between performance and functionality. In reality, modern application environments require both.
A useful way to think about it: Layer 4 answers “What connection needs to be delivered?” — Layer 7 answers “What is this request trying to do?” That distinction fundamentally changes what infrastructure teams can achieve.
Why L4 vs L7 Matters in Modern Application Architectures
Very few organizations today operate a single monolithic application running on a handful of servers. Instead, they manage ecosystems composed of APIs, microservices, Kubernetes clusters, cloud-native applications, multi-cloud environments, and distributed services.
Traffic is no longer homogeneous. A single application may include static content, dynamic transactions, authentication services, API gateways, third-party integrations, and internal microservices, each with different performance, availability, and security requirements.
Treating all traffic equally is rarely the optimal approach. Organizations increasingly need visibility into application behaviour so traffic can be routed intelligently, resources can be optimized, and security policies can be enforced consistently.
This is one of the primary reasons why Layer 7 traffic management has become such an important component of modern application delivery strategies.
When to Use L4 vs L7 Load Balancing
The right choice depends on the workload and the operational requirements behind it.
Layer 4 Is Ideal For
DNS infrastructure, VoIP services, and SMTP platforms
Database clusters and high-volume TCP services
Real-time communications where latency is the primary constraint
Internal service traffic where application-layer inspection adds no value
In these scenarios, inspecting application content adds little value while introducing unnecessary computational overhead.
Layer 7 Is Essential For
Modern web applications and customer-facing digital services
APIs and API gateways requiring intelligent routing
SaaS platforms, e-commerce systems, and multi-tenant environments
Applications requiring SSL offloading and session persistence
Deployments requiring WAF protection and application security policies
Environments with advanced routing requirements based on URL, hostname, or header
Organizations that attempt to manage modern web applications with Layer 4 alone frequently encounter architectural limitations as their traffic complexity and security requirements grow.
How Modern ADC Platforms Combine L4 and L7 Traffic Management
For many organizations, the discussion is no longer about choosing between Layer 4 and Layer 7 load balancing. The real challenge is how to combine both capabilities within a unified application delivery strategy.
Modern Application Delivery Controllers (ADCs) integrate Layer 4 traffic distribution, Layer 7 routing, SSL offloading, Web Application Firewall (WAF) protection, reverse proxy functionality, and high availability services into a single platform.
This approach enables infrastructure teams to optimize performance while maintaining the visibility and security controls required by today’s applications. For example, an organization may use Layer 4 load balancing to distribute high-volume TCP traffic efficiently while simultaneously applying Layer 7 policies for API routing, SSL termination, session persistence, and application security.
Why Deployment Flexibility Matters
Not every organization operates exclusively in the public cloud. Financial institutions, healthcare providers, government agencies, and organizations subject to data sovereignty requirements frequently operate on-premise or in hybrid environments where control over infrastructure is not optional — it is a compliance requirement.
For these environments, an ADC that can only be deployed as a SaaS product or cloud service is not a viable option. Organizations need platforms that can be deployed where their infrastructure actually lives: on bare metal servers, virtual machines, private cloud environments, or as part of hybrid architectures spanning both on-premise data centres and cloud providers.
Data sovereignty, regulatory compliance, and operational control are not edge cases. For many European organizations and regulated industries, the ability to deploy security-critical infrastructure on-premise is a fundamental requirement, not an optional feature.
SKUDONET addresses this challenge by combining L4 and L7 traffic management, WAF protection, SSL offloading, and high availability within a single Application Delivery and Security platform available for deployment on hardware appliances, bare metal, virtual machines, cloud environments, and hybrid architectures. This allows infrastructure teams to improve availability, simplify operations, and strengthen application security without deploying multiple disconnected solutions, regardless of where their infrastructure runs.
Beyond Load Balancing: Why Traffic Visibility and Security Matter
For years, load balancing was primarily associated with traffic distribution: prevent servers from becoming overloaded by spreading incoming connections across multiple backend systems.
While traffic distribution remains essential, modern application environments require much more. Today’s organizations must understand how traffic behaves, identify anomalies in real time, detect malicious activity, and maintain visibility across increasingly distributed infrastructures.
A traffic management platform that only distributes requests may help improve scalability, but it provides limited visibility into what is actually happening within the application environment. Modern ADC platforms address this by combining traffic delivery with observability and security capabilities, enabling teams to answer critical operational questions:
Which services are receiving the most traffic?
Are traffic patterns behaving normally?
Is a sudden traffic spike legitimate or an attack?
Which applications are experiencing performance degradation?
Are WAF security policies being triggered?
Security Is No Longer Separate from Traffic Delivery
Historically, organizations deployed multiple independent components to manage traffic and security. A load balancer distributed traffic. A firewall protected the network. A WAF protected web applications. Monitoring platforms provided visibility. While this approach can work, it increases complexity and creates operational silos.
Modern application environments require a more integrated approach. Today, security capabilities (including WAF, SSL/TLS inspection, API protection, DDoS mitigation, and threat detection) are becoming part of the traffic management process itself. This allows organizations to inspect, filter, and control traffic before it reaches critical application resources.
Real-World Architecture Example: Combining L4 and L7 Traffic Management
To understand how Layer 4 and Layer 7 work together in practice, consider a modern SaaS platform serving thousands of users across multiple regions, including web applications, REST APIs, authentication services, internal microservices, and static content delivery.
Figure 1. Example of a modern application delivery architecture combining L4 and L7 traffic management.
In this architecture:
Clients (users, mobile applications, and APIs) send traffic to the ADC.
Layer 4 Load Balancing efficiently distributes connections based on IP, port, and protocol — handling high-volume traffic with minimal latency.
Layer 7 Intelligence routes traffic based on URLs, hostnames, headers, and session context — enabling intelligent routing to the appropriate backend service.
SSL Offloading decrypts and re-encrypts traffic at the ADC layer, reducing backend server load and improving performance.
WAF and Security Protection inspects and filters traffic at the application layer, blocking attacks, bots, and malicious requests before they reach backend systems.
HA Standby Node ensures automatic failover and service continuity, eliminating the ADC itself as a single point of failure.
Backend Services — web applications, APIs, authentication services, and databases — receive only clean, properly routed traffic.
Rather than choosing between Layer 4 performance and Layer 7 visibility, this architecture combines both within a unified platform. Infrastructure teams benefit from high-throughput traffic distribution alongside intelligent routing, integrated security, and operational observability — without deploying multiple disconnected solutions.
Common Mistakes When Choosing Between L4 and L7
One of the most common mistakes is approaching Layer 4 and Layer 7 as competing technologies. In practice, they address different aspects of traffic management and are most effective when used together.
Applying Layer 7 Everywhere Without Justification
Layer 7 provides powerful capabilities, but not every workload requires deep application awareness. Applying Layer 7 inspection to high-volume internal TCP services, database connections, or DNS infrastructure increases complexity and resource consumption without adding operational value. Layer 4 remains the right choice for workloads where latency and throughput are the primary constraints.
Relying Only on Layer 4 for Modern Web Applications
Many organizations initially deploy Layer 4 because it is simple and highly efficient. However, as applications grow in complexity, requirements emerge that Layer 4 alone cannot address: content-based routing, SSL offloading, API management, session persistence, and WAF protection. Organizations that delay the transition to Layer 7 often face significant re-architecture work when security incidents or application growth force the issue.
Treating Security as a Separate Concern
Traffic management decisions are often made with performance as the primary objective, with security controls added later as separate projects with separate tooling. This creates operational complexity, visibility gaps, and inconsistent policy enforcement. Security requirements should be incorporated into the application delivery architecture from the beginning — not retrofitted after the fact.
Ignoring Traffic Visibility Until Something Breaks
Without visibility into traffic behaviour, organizations struggle to identify performance bottlenecks, detect emerging attacks, or troubleshoot application issues under pressure. Visibility into request patterns, error rates, latency metrics, and security events is most valuable when it is always present — not only when something has already gone wrong.
Load Balancing Best Practices
Regardless of whether Layer 4, Layer 7, or a combination of both is used, several principles consistently improve performance, resilience, and operational efficiency.
Design for High Availability from Day One
Load balancers should never become single points of failure. Redundant configurations, active-passive or active-active clustering, and automated failover mechanisms are essential for business-critical services. The ADC layer itself must be as resilient as the applications it protects.
Continuously Monitor Traffic Behaviour
Traffic patterns evolve over time. Continuous monitoring helps organizations identify performance issues, capacity constraints, unusual traffic spikes, and potential security threats before they affect users. Reactive troubleshooting after an incident is significantly more costly than proactive visibility.
Use Health Checks Aggressively
Traffic should only be routed to healthy backend systems. Automated health checks ensure that failed or degraded resources are immediately removed from the active server pool, preventing users from being forwarded to unavailable services.
Integrate Security Early in the Architecture
Security controls are most effective when integrated directly into the application delivery layer rather than deployed as disconnected components added later. WAF protection, SSL inspection, and DDoS mitigation should be part of the initial architecture design, not afterthoughts.
Build for Growth and Changing Requirements
Traffic requirements rarely remain static. Infrastructure decisions should account for future growth, evolving application architectures, new API surface areas, and increasing security requirements. Choose platforms that support flexible scaling without forcing architectural redesigns as requirements change.
Conclusion
The discussion around Layer 4 and Layer 7 load balancing is often framed as a choice between performance and functionality. Modern application environments require both.
Layer 4 remains essential for delivering high-performance traffic distribution with minimal latency. Layer 7 provides the visibility, intelligence, and security controls required by modern web applications, APIs, and digital services.
As applications become more distributed and more exposed to external threats, organizations are increasingly adopting Application Delivery Controller (ADC) platforms that combine both approaches within a unified architecture — alongside SSL offloading, WAF protection, and high availability — rather than assembling disconnected point solutions.
The goal is no longer simply delivering traffic. The goal is delivering traffic efficiently, securely, and with complete visibility into how applications behave.
Explore SKUDONET’s Application Delivery and Security Platform
SKUDONET combines Layer 4 and Layer 7 traffic management, WAF protection, SSL offloading, and high availability within a single platform — available for on-premise, bare metal, virtual machine, cloud, and hybrid deployments.
Unified ADC platform: L4 + L7 + WAF + SSL offloading in one place
Full deployment flexibility: no mandatory cloud dependency
Data sovereignty: designed for regulated and security-sensitive environments
European provider: built for organizations where infrastructure control is non-negotiable
What is the difference between L4 and L7 load balancing? Layer 4 load balancing operates at the Transport Layer, making routing decisions based on IP addresses, ports, and protocols without inspecting application content. Layer 7 operates at the Application Layer, routing traffic based on URLs, HTTP headers, cookies, API paths, and user sessions. L4 prioritizes speed and throughput; L7 enables intelligent routing, security enforcement, and application visibility.
Is Layer 7 load balancing better than Layer 4? Neither is inherently better — they solve different problems. Layer 4 is optimal for high-volume, latency-sensitive workloads such as DNS, VoIP, and database traffic. Layer 7 is essential for web applications, APIs, and services requiring content-based routing, SSL offloading, session persistence, or WAF integration. Most modern architectures use both layers together.
When should a company use a WAF alongside load balancing? A Web Application Firewall (WAF) should be integrated whenever an organization exposes web applications or APIs to the Internet. WAF protection operates at Layer 7 and inspects HTTP/HTTPS traffic for OWASP Top 10 threats, bot activity, injection attacks, and malicious payloads. In modern ADC architectures, WAF functionality is embedded directly into the application delivery layer rather than deployed as a separate appliance.
What is an Application Delivery Controller (ADC)? An Application Delivery Controller (ADC) is a network infrastructure component that combines load balancing, high availability, SSL offloading, reverse proxy functionality, and application security into a single platform. Modern ADCs operate across both Layer 4 and Layer 7, providing traffic distribution, intelligent routing, WAF protection, and traffic visibility. ADCs have largely replaced standalone load balancers in enterprise application delivery architectures.
What are the alternatives to Netscaler or F5 for ADC and load balancing? Organizations evaluating alternatives to Netscaler (now Citrix ADC) or F5 BIG-IP typically consider platforms such as SKUDONET, HAProxy Enterprise, A10 Networks, and Loadbalancer.org. SKUDONET is a European ADC platform that combines L4 and L7 load balancing, WAF protection, SSL offloading, and high availability — with full support for on-premise, bare metal, virtual machine, cloud, and hybrid deployments, making it particularly relevant for organizations with data sovereignty or regulatory requirements.
Do modern ADCs support both Layer 4 and Layer 7 load balancing? Yes. Enterprise ADC platforms combine Layer 4 traffic distribution with Layer 7 routing, security, and visibility capabilities within a single platform. This allows organizations to apply the appropriate traffic management strategy for each workload — high-performance L4 distribution for latency-sensitive services and intelligent L7 policies for web applications and APIs — without deploying separate systems.
Can load balancing improve application security? Yes, particularly when combined with Layer 7 capabilities. At Layer 7, traffic management platforms can integrate WAF protection, perform SSL/TLS inspection, enforce API security policies, detect anomalous traffic patterns, and block malicious requests before they reach backend application servers. Modern ADC platforms treat security as an integral part of the application delivery architecture rather than a separate function.
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!
There is a new application available for Sparkers: ZapZap What is ZapZap? Features: – Adaptive light and dark mode – Fullscreen mode – Custom window decorations – Interface scaling adjustment (ideal for 2K/4K screens) – Keyboard shortcuts for main options – Adaptive system tray icon (notifies new messages) – Background process support – Drag-and-drop functionality – Account Grid…
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!
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 are available on the downloads page.
Qubes OS User Survey 2026 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!
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 the Qubes 4.3.1 ISO and follow our installation guide.
If you’re currently on Qubes 4.3 (4.3.0 or 4.3.1-rc1), update normally (which includes upgrading any EOL templates and standalones 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.
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). After restoring such templates in 4.3.1, enter the following additional commands in a dom0 terminal:
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.
The Qubes OS Project uses the semantic versioning 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 for a comprehensive list of major and minor releases and our version scheme documentation for more information about how Qubes OS releases are versioned.
Exploitation of vulnerabilities has now emerged as the most common way that attackers gain initial access into an organization’s environment, which underlines the ongoing importance of getting the basics right. Verizon 2026 Data Breach Investigation Report [1] More CVEs, Less Time The industrialization of vulnerability exploitation is not new; the process-driven approach to vulnerability weaponization […]
XSA-493: Only Arm systems are affected. Qubes OS does not run on Arm systems.
XSA-494: Shadow paging is disabled in Qubes OS at build time.
About this announcement
Qubes OS uses the Xen hypervisor as part of its architecture. When the Xen Project publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA). 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). (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, 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.
---===[ Qubes Security Bulletin 115 ]===---
2026-06-09
HVM I/O port list traversal (XSA-491)
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-06-09, the Xen Project published XSA-491, "x86 HVM I/O port list
traversal" (CVE-2026-42487) [3]:
| HVM guest I/O port accesses are subject to either emulation or at
| least translation. Translations are managed by the device model (via
| XEN_DOMCTL_ioport_mapping), and hence the linked list used may changed
| at any time. Traversal of those lists (while handling guest I/O port
| accesses) therefore needs synchronizing with updates, which was
| missing so far.
Impact
-------
A malicious stub domain can crash the hypervisor (and hence the entire
system). A stub domain is a qube that accompanies a "fully-virtualized"
(HVM) qube and in which QEMU is isolated. Privilege escalation and
information leaks cannot be ruled out.
Affected systems
-----------------
All supported versions of Qubes OS are affected.
Only qubes running in HVM mode are affected. In the default
configuration, this includes sys-net and sys-usb.
Patching
---------
The following packages contain security updates that address the
vulnerabilities described in this bulletin:
For Qubes 4.2, in dom0:
- Xen packages, version 4.17.6-6
For Qubes 4.3, in dom0:
- Xen packages, version 4.19.4-9
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 Advisory. [3]
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-491.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
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) is a security announcement issued by the 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. 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 signature is a cryptographic digital signature made in accordance with the OpenPGP standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG). 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.)
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
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
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.
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
Import the included PGP keys. (See our 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
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-115), the commands are:
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-115 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 you just created.
This week&aposs updates center on new board enablement, Rockchip platform refinements, and tooling and kernel maintenance.
Board support expanded across multiple silicon families, with the addition of Seeed Studio reComputer RK3576/RK3588 DevKits and the Anbernic RG DS handheld image. The EasePi A2/R2 received substantial revisions to its board configurations and device trees, alongside a vendor logo transition to Linkease. SpacemiT K1 boot support was updated, and per-SoC LINUXCONFIG separation was introduced for the TQ family to better isolate kernel configurations.
Rockchip received the bulk of low-level improvements. Notable changes include AUX recovery for USB-C DP Alt Mode in the dw-dp driver, device-tree-based LED configuration for the r8169/r8125 controllers, and an updated patch ensuring stable PCIe Ethernet MAC addresses across many boards. Additional fixes resolve slow WiFi on the NanoPi R76S via SDIO SDR104, enable Bluetooth on the Orange Pi 5 Ultra edge kernel, and restore the tm16xx driver on current kernels.
On the tooling and maintenance side, Armbian Imager 2.0 was released, the mainline kernel was bumped to 7.1-rc6, and the rtl8192eu driver was re-enabled following a cleanup of compilation warnings. A previously merged USB gadget NULL pointer fix was reverted pending further evaluation.
We&aposre releasing Armbian Imager 2.0. We rebuilt the whole thing, the interface and the flashing engine underneath it. The part you&aposll notice first: your board boots already set up. Username, password, Wi-Fi, timezone, language. You tell Imager once, it writes that into the image, and the board comes up configured on first boot. No monitor, no keyboard, none of that blind first login.
Set it up once. It configures itself.
This is the big change in 2.0. You build a profile in settings: username and password, an SSH key, your Wi-Fi network and country code, timezone, locale, shell. Imager writes it straight into the image&aposs filesystem while it flashes. Power on the board, it reads the profile and brings itself up. Qualcomm boards over QDL get the same treatment.
It&aposs the difference between "flash, hook up a screen and keyboard, sit through the setup" and "flash, slot the card, switch on." I didn&apost expect to care this much about it, and now I can&apost flash without it.
Pick everything on one screen
The old pop-up windows are gone. In their place is a single animated flow: manufacturer, board, OS, device, all on one page that moves with you. You page through the board and vendor grids, the distro logos are drawn by hand, and the app glides instead of slamming between screens. Settings got the same redesign. So did the cache manager, which now shows where your gigabytes actually went, by category, and clears them in a tap.
Know what you&aposre writing before you write it
Every image tells you what it is up front: build date, badges for the desktop and the kernel branch, a label when it ships with something preinstalled like the SDK build, openHAB, or Kali. Anything you&aposve already downloaded carries a small check, so you don&apost pull it twice. If you want the trunk rolling releases, there&aposs a filter for them, with a plain warning before you commit. And images that can&apost be written to a card, like the VM disk formats, simply aren&apost in the list.
Every write, checked byte for byte
The download is verified against its SHA256. After writing, the app reads the card back and compares it to the source, byte for byte. While that runs, your board floats over a warm glow that follows the progress, with one line telling you the stage instead of a wall of numbers. When the check turns green, it&aposs because the data on the card matches. Not because we&aposre optimistic.
Bring your own images, online or offline
Have an image of your own? Drop it in. We handle img, iso, xz, gz, bz2, and zst, and decompress before writing. Lose your connection partway through the day and Imager still works: the offline mode was reworked so your cache and your own files stay one click away.
The same app on Mac, Linux, and Windows
Same look and behavior on all three. On Mac it&aposs a single universal build for Intel and Apple Silicon. Pick a light theme, a dark one, or let it follow the system. Eighteen languages, chosen automatically from your locale. Free and open source, the way it started.
Get it
Armbian Imager 2.0 is available now, free, on Mac, Linux, and Windows. It does the same job it always has, writing a good image to a card. The new part is what happens after: you power the board on, and it&aposs already yours.
Time-sensitive This article focuses on the 11 September 2026 vulnerability reporting deadline — the first hard enforcement milestone under the Cyber Resilience Act. As of June 2026, you have approximately 100 days to prepare. Most companies treating the CRA as a 2027 problem are already behind. According to the 2026 CRA Awareness and Readiness Report […]
Learn more about deepin on DistroWatch: https://distrowatch.com/table.php?distribution=deepin I. May Community Data Overview II. Community Products 1. UOS AI 3.0 In May, UOS AI was officially upgraded, transforming from a “ask-and-leave” dialog box into a system‑level “hardcore co‑pilot”, achieving breakthroughs in several core capabilities: Native system intelligence Leveraging MCP capabilities and extensive Skill support, the operational chain between deepin system and applications is now fully connected. With a single‑sentence command (e.g., “Download WeChat” or “Turn on Do Not Disturb mode”), XiaoU (Little U) completes the operation via native system control cards – new users never get lost, and veterans double their ...Read more
Learn more about deepin on DistroWatch: https://distrowatch.com/table.php?distribution=deepin Recently, the 2026 Qualcomm & Radxa AI Developer Day was successfully held in Shenzhen. Under the theme “AI Advancing Together, Open Source Reborn,” the event attracted attention from numerous embedded developers, hardware and software ecosystem partners, and open-source community enthusiasts. As a leading open-source operating system community in China, deepin attended the conference with its latest porting achievements and set up a dedicated experience booth. On site, deepin highlighted the recent adaptation progress of the deepin 25 operating system on Qualcomm-based development boards newly released by Radxa, including the Dragon Q8B and Dragon Q6A, ...Read more
This release is an emergency release to fix a serious security vulnerability in
the Linux kernel, as well as security vulnerabilities in the Tor client.
Update the Linux kernel to 6.12.90-2, which fixes
CVE-2026-43503,
a vulnerability that could allow an application in Tails to gain
administration privileges.
For example, if an attacker was able to exploit other unknown security
vulnerabilities in an application included in Tails, they might then use this
vulnerability to take full control of your Tails and deanonymize you.
This attack is very unlikely, but could be performed by a strong attacker,
such as a government or a hacking firm. We are not aware of this vulnerability
being used in practice until now.
Get Tails 7.8.1
To upgrade your Tails USB stick and keep your Persistent Storage
Automatic upgrades are available from Tails 7.0 or later to 7.8.1.
If you cannot do an automatic upgrade or if Tails fails to start after an
automatic upgrade, please try to do a manual upgrade.
NIST Significantly Reduces Independent CVSS Scoring in the NVD For years, the routine has been the same. A new vulnerability appears, the security team checks the NVD, looks at the CVSS score, and decides: patch now or wait. A single number, produced by a U.S. federal agency, has become the pace-setter for millions of systems […]
We have published Qubes Canary 047. The text of this canary and its accompanying cryptographic signatures are reproduced below. For an explanation of this announcement and instructions for authenticating this canary, please see the end of this announcement.
Qubes Canary 047
---===[ Qubes Canary 047 ]===---
Statements
-----------
The Qubes security team members who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is June 03, 2026.
2. There have been 114 Qubes security bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
fourteen days of September 2026. Special note should be taken if no new
canary is published by that time or if the list of statements changes
without plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently compromised.
This means that we assume NO trust in any of the servers or services
which host or provide any Qubes-related data, in particular, software
updates, source code repositories, and Qubes ISO downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other means,
like blackmail or compromising the signers' laptops, to coerce us to
produce false declarations.
The proof of freshness provided below serves to demonstrate that this
canary could not have been created prior to the date stated. It shows
that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to anybody.
None of the signers should be ever held legally responsible for any of
the statements made here.
Proof of freshness
-------------------
Wed, 03 Jun 2026 02:51:46 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
NSDAP archive: How DER SPIEGEL processed the data from the Nazi card file
Interactive Research Tool: What Your Family Did Under Hitler – Find Out Here
Human Rights in the US: Meet the Transgender Americans Forced to Flee GOP Persecution
An Interview with Maduro's Son: "We Should Have Done More to Protect My Father"
Forced Mercenaries: How Russia Dupes Kenyans into Fighting in Ukraine
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Iran War Live Updates: Iran Targets Neighbors as U.S. Condemns ‘Aggressive’ Strikes
Russia Launches Deadly Strikes on Kyiv After Threatening Ukraine for a Week
U.S. Ebola Unit Plans in Kenya, Subject of Protests, Suffers New Setback From Court Ruling
The New Zealand Parakeet Pair That Are Saving Their Species
U.S. Was Asked to Blacklist Colombian Cartel Gold. It Was Also Buying It.
Source: BBC News (https://feeds.bbci.co.uk/news/world/rss.xml)
Israel strikes southern Lebanon but partial truce with Hezbollah appears to hold
US and Iran launch new strikes as ceasefire negotiations stall
Putin remains uncompromising on Ukraine, but is public discourse on war changing in Russia?
'They'll fix the building, but not our souls': Sleepy Kyiv neighbourhood hit in Russian strike
British couple lose Iran jail sentence appeal, family says
Source: Blockchain.info
00000000000000000001c7c4fb4f5b739e74f18ca4b3b6add30011982c0735d7
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this canary
in the qubes-secpack.git repo, and (2) via digital signatures on the
corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures! Instructions for doing so are documented here:
https://doc.qubes-os.org/en/latest/project-security/security-pack.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
The purpose of this announcement is to inform the Qubes community that a new Qubes canary has been published.
What is a Qubes canary?
A Qubes canary is a security announcement periodically issued by the Qubes security team consisting of several statements to the effect that the signers of the canary have not been compromised. The idea is that, as long as signed canaries including such statements continue to be published, all is well. However, if the canaries should suddenly cease, if one or more signers begin declining to sign them, or if the included statements change significantly without plausible explanation, then this may indicate that something has gone wrong.
The name originates from the practice in which miners would bring caged canaries into coal mines. If the level of methane gas in the mine reached a dangerous level, the canary would die, indicating to miners that they should evacuate. (See the Wikipedia article on warrant canaries for more information, but bear in mind that Qubes Canaries are not strictly limited to legal warrants.)
Why should I care about canaries?
Canaries provide an important indication about the security status of the project. If the canary is healthy, it’s a strong sign that things are running normally. However, if the canary is unhealthy, it could mean that the project or its members are being coerced in some way.
What are some signs of an unhealthy canary?
Here is a non-exhaustive list of examples:
Dead canary. In each canary, we state a window of time during which you should expect the next canary to be published. If no canary is published within that window of time and no good explanation is provided for missing the deadline, then the canary has died.
Missing statement(s). Canaries include a set of numbered statements at the top. These statements are generally the same across canaries, except for specific numbers and dates that have changed since the previous canary. If an important statement was present in older canaries but suddenly goes missing from new canaries with no correction or explanation, then this may be an indication that the signers can no longer truthfully make that statement.
Missing signature(s). Qubes canaries are signed by the members of the Qubes security team (see below). If one of them has been signing all canaries but suddenly and permanently stops signing new canaries without any explanation, then this may indicate that this person is under duress or can no longer truthfully sign the statements contained in the canary.
Does every unexpected or unusual occurrence related to a canary indicate something bad?
No, there are many canary-related possibilities that should not worry you. Here is a non-exhaustive list of examples:
Unusual reposts. The only canaries that matter are the ones that are validly signed in the Qubes security pack (qubes-secpack). Reposts of canaries (like the one in this announcement) do not have any authority (except insofar as they reproduce validly-signed text from the qubes-secpack). If the actual canary in the qubes-secpack is healthy, but reposts are late, absent, or modified on the website, mailing lists, forum, or social media platforms, you should not be concerned about the canary.
Last-minute signature(s). If the canary is signed at the last minute but before the deadline, that’s okay. (People get busy and procrastinate sometimes.)
Signatures at different times. If one signature is earlier or later than the other, but both are present within a reasonable period of time, that’s okay. (For example, sometimes one signer is out of town, but we try to plan the deadlines around this.)
Permitted changes. If something about a canary changes without violating any of the statements in prior canaries, that’s okay. (For example, canaries are usually scheduled for the first fourteen days of a given month, but there’s no rule that says they have to be.)
Unusual but planned changes. If something unusual happens, but it was announced in advance, and the appropriate statements are signed, that’s okay (e.g., when Joanna left the security team and Simon joined it).
In general, it would not be realistic for an organization to exist that never changed, had zero turnover, and never made mistakes. Therefore, it would be reasonable to expect such events to occur periodically, and it would be unreasonable to regard every unusual or unexpected canary-related event as a sign of compromise. For example, if something usual happens with a canary, and we say it was a mistake and correct it (with valid signatures), you will have to decide for yourself whether it’s more likely that it really was just a mistake or that something is wrong and that this is how we chose to send you a subtle signal about it. This will require you to think carefully about which among many possible scenarios is most likely given the evidence available to you. Since this is fundamentally a matter of judgment, canaries are ultimately a social scheme, not a technical one.
What are the PGP signatures that accompany canaries?
A PGP signature is a cryptographic digital signature made in accordance with the OpenPGP standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG). The Qubes security team cryptographically signs all canaries so that Qubes users have a reliable way to check whether canaries are genuine. The only way to be certain that a canary is authentic is by verifying its PGP signatures.
Why should I care whether a canary is authentic?
If you fail to notice that a canary is unhealthy or has died, you may continue to trust the Qubes security team even after they have signaled via the canary (or lack thereof) that they been compromised or coerced.
Alternatively, an adversary could fabricate a canary in an attempt to deceive the public. Such a canary would not be validly signed, but users who neglect to check the signatures on the fake canary would not be aware of this, so they may mistakenly believe it to be genuine, especially if it closely mimics the language of authentic canaries. Such falsified canaries could include manipulated text designed to 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 canary?
The following command-line instructions assume a Linux system with git and gpg installed. (For Windows and Mac options, see 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
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
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.
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
Import the included PGP keys. (See our 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
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 (Qubes Canary 047), the commands are:
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 Qubes Canary 047 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 you just created.
This release of Clonezilla live (3.3.2-31) includes major enhancements and bug fixes.
ENHANCEMENTS AND CHANGES SINCE 3.3.1-35
The underlying GNU/Linux operating system was upgraded. This release is based on the Debian Sid repository (as of 2026/May/17).
Linux kernel was updated to 7.0.7-1.
Partclone was updated to 0.3.47.
Package ezio was updated to 2.0.23.
Implemented the gocryptfs mechanism for image encryption due to eCryptFS deprecation. Added options -goc/-sgoc/ and -pg/-pfg in ocs-sr and the TUI menu.
Added a new program, ocs-cvtimg-enc, to convert encrypted images (ecryptfs to gocryptfs), decrypt, or encrypt images.
Improved MDRAID support:
Added programs ocs-mdraid-start, ocs-mdraid-stop, ocs-purge-mdraid-layout, ocs-save-mdraid-layout, and ocs-restore-mdraid-layout.
Lite server now supports MDRAID deployment.
Standardized naming conventions for MDRAID management.
Improved MDRAID stop/clean operations to prevent "busy" errors during restoration.
Added support for LVM thin provisioning.
Added b3sum to the initrd of the live system and implemented a new checksum mechanism for the live system using b3sum instead of sha256sum.
Added a menu to verify the boot medium.
Default to use XXH128 checksum (-a3) for Partclone in saving images and device-to-device cloning.
Enhanced ocs-blk-dev-info to output logical block size and improved its performance.
Language files updated: ca_ES, ja_JP.UTF-8, Brazilian Portuguese.
Added 6 new language files: cs_CZ, id_ID, nl_NL, th_TH, uk_UA, and vi_VN.
Added manuals for ocs-sr and ocs-onthefly.
Included new packages: brightness-udev, ansifilter, thin-provisioning-tools, gocryptfs, fido2-tools.
ocs-clean-disk-part-fs now runs interactively by default for improved safety.
Added a mechanism to prompt for bcdboot fix during 512n/e <-> 4kn conversions in ocs-onthefly.
Sorted Partclone-related variables by separating dd and non-dd usages (e.g., PARTCLONE_SAVE_OPT_DD_INIT).
BUG FIXES
Fixed a failure in reduce_multipath_dev when acting on a whole disk with a filesystem.
Fixed a bug where the ncurses TUI was not shown when running partclone.dd in TUI mode.
Avoided duplicated outputs from virtual mapped devices (e.g., Ventoy) in ocs-blk-dev-info.
Fixed MDRAID issues: ensured arrays are only shut down during restoration, and implemented udev race condition prevention.
Skip thin pool data containers when saving, checking, or converting.
Fixed a bug in ocs-pt-size-from-sf regarding device name matching.
Fixed a typo in ocs-restore-mbr.
Improved ocs-chkimg to skip checking partition tables for MDRAID devices.
Some attacks steal data. Some attacks spy on users. And some attacks have only one goal: to make your service unavailable.
DDoS attacks fall into the latter category, and they are more common and more accessible to attackers than many organizations realize. They don’t require exploiting a specific vulnerability or gaining access to internal systems. All it takes is generating enough traffic to cause your infrastructure to collapse under its own weight.
What makes a modern DDoS attack particularly dangerous is not only the volume it can reach (attacks exceeding 2 Tbps have been recorded), but also the variety of forms it can take. A volumetric attack that saturates bandwidth is relatively easy to identify. However, an application-layer attack that mimics legitimate traffic and silently exhausts your server’s resources is far more difficult to detect and stop.
This article explains how DDoS attacks work, the different forms they take, the damage they have caused in real-world incidents, and the mitigation strategies that actually work.
What Is a DDoS Attack?
A DDoS (Distributed Denial of Service) attack involves flooding a server, network, or application with more traffic than it can process, making it inaccessible to legitimate users.
The key word is distributed. Unlike a traditional DoS attack, which originates from a single source and is relatively easy to block, a DDoS attack is launched simultaneously from thousands or even millions of compromised devices. That means there is no single IP address to filter. The attack comes from everywhere at once.
With that in mind, what exactly is the difference between DoS and DDoS?
In a DoS attack, the traffic originates from a single source. In a DDoS attack, however, malicious traffic comes from a distributed network of malware-infected devices that the attacker controls remotely. These networks are known as botnets. That distribution is what makes DDoS attacks an entirely different challenge.
How a DDoS Attack Works
The Role of Botnets
As mentioned earlier, most DDoS attacks are carried out through botnets, which may consist of personal computers, servers, IP cameras, home routers, IoT devices running default credentials, and more. Any of these devices can become part of a botnet without their owners ever knowing, as attackers do not need to build the infrastructure themselves.
Botnets can be rented on underground marketplaces at prices that have dropped significantly in recent years. This has effectively democratized the ability to launch large-scale attacks: any actor with sufficient motivation and a modest budget can orchestrate a DDoS attack capable of overwhelming well-provisioned infrastructure.
OSI Layers: Where the Attack Strikes
Not all DDoS attacks operate at the same level. Depending on their objective, they target different layers:
Network Layer (L3): Saturates bandwidth with massive volumes of packets.
Transport Layer (L4): Exploits the behavior of protocols such as TCP to consume server resources or overwhelm intermediary network devices.
This distinction is not merely academic. Each layer requires a different defense strategy, and misidentifying the type of attack you’re facing can lead to ineffective mitigation measures.
Types of DDoS Attacks
Volumetric Attacks
The objective is simple: consume all available bandwidth between the target system and the rest of the internet.
Massive traffic volumes are generated using techniques such as UDP floods, ICMP floods, and amplification attacks (DNS, NTP, Memcached), in which attackers exploit misconfigured servers that respond with packets far larger than the original requests.
A well-executed amplification attack can multiply the original traffic by factors of 10x, 50x, or even more. The attacker sends very little; the target receives an enormous amount.
Protocol Attacks
These attacks do not aim to saturate bandwidth. Instead, they seek to exhaust the resources of servers or intermediary network devices, such as firewalls and load balancers, by exploiting the way communication protocols work.
The most well-known example is the SYN flood. Attackers initiate thousands of TCP connections by sending SYN packets but never complete the handshake. The server reserves resources for each pending connection, eventually filling its connection table until it can no longer accept new connections—including legitimate ones.
Application-Layer Attacks (Layer 7)
These are the most sophisticated and the most difficult to detect.
Rather than overwhelming the network, they generate HTTP or HTTPS requests that appear completely legitimate. The server processes them as though they came from real users until CPU, memory, or database resources are exhausted.
An HTTP flood can generate millions of GET or POST requests targeting a specific URL. Slowloris attacks open multiple connections and keep them active by intermittently sending partial headers, occupying connection slots without ever completing a request.
From the outside, the traffic may appear entirely normal. A traditional firewall cannot distinguish between a legitimate HTTP request and a malicious one. Mitigating these attacks requires deep inspection at the application layer.
DDoS Attack Examples: Real Incidents That Disrupted Major Organizations
The following DDoS attack examples show how denial-of-service campaigns have disrupted governments, stock exchanges, cloud providers, and some of the largest websites on the internet.
2025: NoName057(16) Attacks Against Spanish Public Institutions
In March 2025, dozens of Spanish municipalities, provincial councils, and public-sector organizations saw their websites taken offline following a coordinated wave of denial-of-service attacks carried out by the group NoName057(16). Although no data was stolen, the impact was significant, leaving thousands of citizens without access to essential digital services.
2020: Amazon Web Services – 2.3 Tbps
AWS reported in its threat intelligence report that it had mitigated the largest DDoS attack recorded at the time: a 2.3 Tbps attack sustained over three days. The target was an unidentified customer, and the attack relied on CLDAP reflection techniques.
The scale of the incident highlights the fact that cloud infrastructure providers are themselves targets, and that the capacity of even the largest providers is not unlimited.
2020: New Zealand Stock Exchange – Days of Disruption
For several consecutive days in August 2020, the New Zealand Stock Exchange experienced disruptions severe enough to force the suspension of trading operations.
The attack was not particularly sophisticated from a technical perspective, but it was persistent and targeted an organization with an extremely low tolerance for downtime.
The incident illustrates how the criticality of the affected service can exponentially amplify the impact of an attack that, in a different context, might have been contained with far fewer consequences.
In February 2018, GitHub suffered the largest DDoS attack ever recorded at that point, peaking at 1.35 Tbps.
Attackers used Memcached amplification, exploiting internet-exposed caching servers to multiply traffic volumes on a massive scale.
GitHub was able to mitigate the attack within minutes by redirecting traffic to its scrubbing service. The incident delivered a clear lesson: even top-tier enterprise infrastructure can become a target, and response time is everything.
2016: Dyn – When DNS Goes Down, the Internet Goes Down
In October 2016, the Mirai botnet—made up primarily of security cameras and digital video recorders running default credentials—launched a massive attack against Dyn, one of the internet’s leading DNS providers.
The result was widespread outages affecting Twitter (now X), Netflix, Reddit, Spotify, and PayPal for several hours.
The attack revealed something many organizations had not fully considered: dependence on shared infrastructure as a risk vector. It did not matter how well each individual company protected its own systems. If the DNS provider resolving their domains went down, their services went down as well.
The Real Business Impact of a DDoS Attack
A DDoS attack is not just a technical problem for the IT team to solve. Its consequences affect the entire organization.
Service Disruption
The most immediate consequence. For e-commerce businesses, financial services, and SaaS platforms, every minute of downtime carries a direct and measurable cost.
Reputational Damage
Users who cannot access a service do not always understand the cause. The perception of unreliability can erode trust even after service has been fully restored.
Remediation Costs
Mitigating an ongoing attack requires human and technical resources that organizations are rarely staffed for under normal circumstances. In many cases, it means bringing in emergency services or purchasing additional capacity at short notice.
Regulatory Consequences
In sectors such as finance, healthcare, and critical infrastructure, a prolonged outage may result in SLA breaches or non-compliance with availability requirements, potentially leading to regulatory penalties.
DDoS as a Distraction
This is perhaps the most concerning—and least discussed—scenario: in some advanced attacks, the DDoS campaign is not the primary objective but rather a smokescreen designed to distract the security team while an intrusion is carried out elsewhere in the infrastructure.
While the team is focused on traffic alerts, someone is coming through another door.
Could your infrastructure withstand a Layer 7 DDoS attack?
Many organizations discover weaknesses only after an outage occurs.
Take our free infrastructure resilience assessment to identify potential availability and security gaps before attackers do.
Early detection can make the difference between a contained incident and a prolonged outage. The most common indicators include:
A sudden and unexplained spike in traffic, especially if it originates from multiple geographic locations or unusual IP ranges.
Progressive performance degradation with no apparent cause, including increased latency, frequent timeouts, and slow response times.
Resource exhaustion, such as CPU, memory, or active connection counts reaching their limits without any correlation to normal system activity.
Anomalous patterns in logs, including unusually high volumes of requests to the same URL, large numbers of incomplete connections, or statistically improbable distributions of source IP addresses.
Monitoring system alerts indicating availability issues or traffic thresholds being exceeded.
None of these symptoms alone confirms an attack. However, the combination of several indicators—especially when they appear suddenly and simultaneously—should trigger your incident response procedures.
DDoS Mitigation Strategies
There is no single solution that can protect against every type of DDoS attack. Effective mitigation requires a layered approach, where each defense mechanism complements the others.
Rate Limiting and Traffic Filtering
Rate limiting establishes a maximum number of requests or connections allowed per IP address within a defined period of time.
It provides a useful first line of defense against floods and brute-force attacks, but it has clear limitations when facing distributed attacks originating from thousands of different IP addresses.
Filtering based on IP reputation, geolocation, or behavioral patterns helps block known malicious traffic before it reaches the application. Its effectiveness depends on the quality of the threat intelligence feeding the system and the ability to update that intelligence in real time.
Cloud Scrubbing vs. Infrastructure-Based Protection
Scrubbing services redirect traffic to dedicated filtering centers where malicious traffic is removed before reaching the target environment.
They are highly effective against large-scale volumetric attacks because they can absorb enormous traffic volumes through their global network capacity.
However, this model has limitations that organizations should understand:
Traffic passes through third-party infrastructure. This may conflict with data sovereignty requirements or regulations such as GDPR, particularly in highly regulated industries.
If the cloud provider itself becomes the target, the protection fails. The Dyn attack discussed earlier demonstrated this clearly. More recently, several incidents affecting major CDNs have created cascading disruptions for their customers.
Hybrid and on-premises environments cannot always reroute traffic externally without compromising architectural requirements or introducing unacceptable latency.
For these organizations, an alternative approach is to deploy protection directly within their own infrastructure—at the network perimeter, in front of applications, with real-time inspection and response capabilities that do not depend on third-party intermediaries.
WAF and IPDS: Application-Layer Protection
When defending against Layer 7 attacks, surface-level traffic inspection is not enough.
Organizations need visibility into request content, client behavior, and long-term access patterns.
A WAF (Web Application Firewall) performs deep inspection of HTTP/HTTPS requests and applies rules designed to identify anomalous behavior, including floods, aggressive scraping activity, and injection attempts disguised as DDoS traffic. Malicious requests are blocked before reaching the application.
An IPDS (Intrusion Prevention and Detection System) operates at the network level, identifying known attack signatures, traffic anomalies, and botnet-related behavior. It can automatically block or rate-limit suspicious traffic in real time.
Example of a Layer 7 DDoS Mitigation Architecture
In a modern Application Delivery Controller (ADC) architecture, DDoS mitigation typically occurs before traffic reaches backend servers.
When a DDoS pattern is detected, the platform can apply connection limits, reputation-based filtering, HTTP request inspection, and dedicated DoS protection rules to block malicious traffic in real time.
This architecture illustrates how these protection layers work together. In this example, the mitigation layer is implemented using SKUDONET.
When an IP address exceeds defined thresholds or exhibits behavior associated with botnets, requests are automatically blocked while legitimate traffic continues to reach backend servers.
Best Practices for Preventing DDoS Attacks
Build Redundancy into the Architecture from the Start
An architecture with multiple entry points, distributed load balancing, and automatic failover capabilities reduces the impact of any attack.
If one node fails, traffic is redistributed. High availability is not just a performance enhancement—it is operational resilience.
Audit Your Attack Surface Regularly
Unnecessarily exposed services, unjustified open ports, internet-accessible Memcached servers, or publicly reachable DNS services can all be leveraged by attackers to launch or amplify attacks.
If something should not be exposed, it should not be accessible.
Keep Systems Updated and Properly Patched
Many amplification attacks exploit vulnerable or misconfigured services.
Maintaining up-to-date systems and regularly auditing the configuration of exposed services significantly reduces the attack surface.
Configure Proactive Alerts with Realistic Thresholds
Do not wait until systems begin to fail before detecting an attack.
Establish a baseline for normal traffic patterns and configure alerts that trigger when those patterns are exceeded, leaving enough time to respond before the impact becomes irreversible.
Have an Incident Response Plan Before You Need One
When an attack begins, it is too late to decide what to do.
Teams should already know exactly which steps to follow: who to notify, which countermeasures to activate and in what order, how to communicate internally, and, when necessary, how to communicate with customers.
DDoS attacks have evolved from a form of digital protest into a systematic disruption tool used by actors driven by financial, competitive, or geopolitical motives.
They have evolved as well. Modern application-layer attacks are quieter, harder to distinguish from legitimate traffic, and often more effective than traditional volumetric floods while requiring far less traffic.
The response cannot be reactive.
An effective protection strategy combines architectural redundancy, early detection, multi-layer traffic filtering, and application-specific defenses. None of these measures is sufficient on its own, and relying exclusively on external cloud-based services introduces a single point of failure that recent incidents have shown to be very real.
Organizations responsible for critical infrastructure need to know exactly where their protection resides, who controls it, and what happens when that protection fails.
How Prepared Is Your Infrastructure?
DDoS attacks continue to grow in scale and sophistication, but the biggest risk is often not knowing whether your current architecture can withstand them.
Take the infrastructure assessment and receive an instant evaluation of your application’s resilience against availability and security threats.
What is the difference between a DoS and a DDoS attack?
A DoS attack originates from a single source. A DDoS attack uses a distributed network of compromised devices (a botnet) to generate the volume of traffic required to overwhelm a target.
That distributed nature is what makes DDoS attacks exponentially more difficult to stop using traditional defenses.
Can a traditional firewall stop a DDoS attack?
Partially.
A firewall can block known IP addresses and filter certain traffic patterns, but its capabilities are limited against large-scale volumetric attacks or Layer 7 attacks that mimic legitimate traffic.
Dedicated solutions are required, such as WAFs, IPDS platforms, scrubbing services, or a combination of all three.
What is a Layer 7 DDoS attack?
A Layer 7 DDoS attack targets the application layer of the OSI model.
Rather than saturating bandwidth, it generates seemingly legitimate HTTP or HTTPS requests that consume application resources such as CPU, memory, and database connections.
These attacks are among the most difficult to detect because the traffic appears normal and requires deep application-layer inspection to be mitigated effectively.
Do cloud providers automatically protect against DDoS attacks?
Major cloud providers offer some level of built-in DDoS protection, but it is neither universal nor foolproof.
Sophisticated application-layer attacks can bypass these defenses. In addition, when the cloud provider itself becomes the target, the protection may become ineffective for all of its customers simultaneously.
What is a botnet, and how does it relate to DDoS attacks?
A botnet is a network of compromised devices remotely controlled by an attacker.
In a DDoS attack, the botnet serves as the delivery mechanism: all devices send traffic to the target in a coordinated manner, generating the volume required to overwhelm it.
Today, IoT devices running default credentials remain one of the primary sources of botnet recruitment.
How much can a DDoS attack cost a business?
The answer depends on the duration of the attack, the industry, and the criticality of the affected services.
Beyond the direct cost of downtime, organizations must also consider remediation expenses, reputational damage, and—in regulated industries—potential penalties for failing to meet availability requirements.
Taken together, serious incidents often cost tens or hundreds of thousands of euros, and in some cases significantly more.
The 5th monthly Sparky project and donate report of the 2026: – Linux kernel updated up to 7.0.10, 6.18.33-LTS, 6.12.91-LTS – Sparky 8.3 of the stable line released Sparky of the rolling line will be released in June. Many thanks to all of you for supporting our open-source projects. Your donations help keeping them and us alive. Don’t forget to send a small tip in June too, please.
Learn more about deepin on DistroWatch: https://distrowatch.com/table.php?distribution=deepin The deepin 25.1.1 update is here! This update brings comprehensive optimizations in system security, hardware compatibility, desktop experience, AI capabilities, and more, including multiple feature improvements, bug fixes, and CVE vulnerability patches. We recommend upgrading as soon as possible via Control Center → System Update, or by using the terminal command: sudo apt update && sudo apt dist-upgrade I. deepin 25.1.1 Release Notes Security Fixes Fixed high‑risk vulnerabilities including CVE‑2026‑6276 (curl cookie leak), systemd, and CVE‑2026‑35385 (OpenSSH). Addressed security issues in components such as inetutils, gnutls28, xorg-server, mesa, glibc, rsync, nginx, and wireshark. Fixed vulnerabilities in open‑source components including jpeg-xl, wget2, pillow, libexif, python-ldap, and ...Read more
Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.
Armbian v26.5.1 delivers another strong round of improvements across the project, focusing on expanded hardware support, desktop and userland refinements, build framework modernization, and infrastructure enhancements. This release introduces new board images and platform updates, improves Ubuntu 26.04 "Resolute" integration, refines Bianbu desktop support, adds firmware and driver updates including AX210 wireless support, and continues ongoing work to strengthen the build system, CI pipelines, and developer tooling. Numerous kernel, bootloader, and device tree updates further improve stability, compatibility, and performance across a wide range of ARM and x86 platforms, reinforcing Armbian&aposs commitment to providing a reliable and flexible Linux distribution for single-board computers, embedded devices, and edge computing deployments.
SPONSORED
Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices.
The May development update is here. Despite the fact that we had to deal with a downpour of vulnerabilities such as Copy Fail, Dirty Frag, and others (they are all fixed in rolling and in emergency LTS release updates available to subscription holders now!), the VyOS team and community members still added quite a lot of new features and bug fixes this month.
They include a fix for the long-standing, very annoying bug that led to needless OpenVPN server restarts on config changes that only affected user settings that go to the client config dir, multiple new options for DHCPv4 and DHCPv6 servers, initial support for traffic engineering in segment routing, and more.
We are pleased to announce the release of Proxmox Datacenter Manager 1.1!
This point release focuses on expanding visibility and automation for large-scale, multi-site deployments. Our main focus for this iteration has been introducing integrated automation installation workflows and taking our first major steps toward comprehensive, cross-remote guest management. This helps you manage your virtualized environments safely and efficiently at scale.
The debate around Digital Sovereignty is often framed as a contest between the United States and Europe, yet the underlying issue resonates far beyond these regions. Around the world, countries seek measurable control over government IT systems and data infrastructures while safeguarding citizens’ privacy and civil society. Their shared goal is to reclaim autonomy in a world where the “rules-based international order,” which once guaranteed security, reliability, and access, has eroded.
During my work with clients in Canada, I’ve seen how sovereignty serves as both a technological and diplomatic solution. By ensuring that the infrastructure managing data, identity, and public services remains under national control, so-called “middle powers,” like Canada, can shape their own fate. At this intersection, a geopolitical challenge becomes a technical one: when code is open, inspectable, and locally governed, nations can transition from mere consumers of technology to co‑creators of it.
Sovereignty in Action
On the surface, there seems to be little chance for controversy when it comes to satellite systems. Yet when companies like GHGSat monitor greenhouse gases and thus climate change, there is a real risk of running afoul of governments that want to hide pollution or simply don’t believe in climate change. Digital dependencies can quickly threaten a business. After all, there is no quicker way to force an organization to its knees than to cut it off from its email or logins.
Yet, it is not just the private sector that fears this overreach. Sovereign-oriented IT might look like a ministry of education operating thousands of schools through a federated, self-hosted identity system. Or a regional government integrating healthcare, transport, and licensing platforms under an Open Source identity framework that ensures privacy and legal compliance. Such implementations bring the principle of sovereignty to everyday life, making the abstract tangible through operational systems.
There is no project, big or small, that cannot gain some additional control. Even veritable institutions like the International Criminal Court must fear technological influence. The recent US sanctions against the ICC, as well as China’s push to control technology through foreign investment, underscore the need to place technological independence at the forefront of every business and organization.
Sovereign Identity Management
Identity management sits at the heart of digital sovereignty. Whoever controls identity controls access, policy enforcement, and data visibility. Univention’s self‑hostable platform allows public and private entities to retain this control locally or within accountable institutions, rather than in opaque cloud infrastructure abroad.
Added transparency and accountability are especially important as geopolitical uncertainty deepens. In Canada, for instance, dependency on large U.S. cloud providers is declining in favor of open, sovereign-ready alternatives. Univention’s infrastructure enables governments, schools, and enterprises to unify digital identities across diverse applications while maintaining freedom of choice. Its customizable login portal and user interface not only streamline the IT landscape but symbolize practical sovereignty where compliance, flexibility, and consistency coexist.
Catalyzed by these Open Source solutions, many Canadian institutions are redesigning how they manage IT. Digital sovereignty, they’ve realized, isn’t a single product. It is an ecosystem. Identity management, as the key to access, data privacy, and integration, forms one of its essential pillars. The same realization now guides public sector digitization across the globe: nations modernizing education, healthcare, or citizen services must choose between proprietary, extra-territorial systems and open, sovereign architectures. The latter option grants local control and space for domestic innovation.
Middle Powers in a Fragmented Order
For Middle powers such as Canada, Germany, and South Korea, this local control and technological independence is especially important. Globally, these countries are neither dominant superpowers nor passive players, but influential states that depend heavily on global stability and trade. Historically, their geopolitical toolkit centered on diplomacy, development aid, and carefully measured defense partnerships. Yet in today’s fractured digital landscape, where data localization laws and cloud contracts touch the core of sovereignty, foreign policy increasingly overlaps with IT strategy.
The European Union exemplifies this evolution, defining digital sovereignty as the ability to control and make decisions about digital infrastructure without dependency on outside providers. The same logic drives every state seeking freedom of choice amid the U.S. and Chinese technological spheres. Open Source doesn’t erase these tensions, but it transforms their geometry. Governments and businesses can share resources on open foundations, avoid vendor lock-in, and retain the ability to adapt independently. In a world where agility matters more than scale, that flexibility is a crucial force multiplier.
From Consumers to Co‑Architects of the Future
No single country or organization will by default define the global digital future. Yet each organization faces a choice between outsourcing its critical systems and investing in the capacity to co‑architect shared infrastructure. Open Source tilts this equation toward cooperation and agency. It allows coalitions of users, whether nations, industries, or institutions, to co‑develop platforms aligned with their specific legal frameworks, cultures, and values.
As Canadian Prime Minister Mark Carney recently warned, the comfortable predictability of the old, rules‑based order has vanished. The replacement will be a network of shifting alliances, standards, and digital dependencies that evolve continuously. In this complex environment, technology decisions are inherently political. Every cloud migration, procurement contract, or identity system quietly reinforces one configuration of power over another.
In the technology sector, Open Source offers an antidote. It gives us transparency, flexibility, and collective stewardship. It lets nations, organizations, and individuals keep essential parts of that power within their regulatory reach and aligned with their values. By transforming conference slogans into working code maintained by accountable local teams, Open Source operationalizes digital sovereignty rather than leaving it rhetorical. For middle powers and others navigating between global giants, open architectures and sovereign-ready identity platforms remain among the last reliable levers to ensure autonomy in a world of contested connectivity.
The first release candidate (RC) for Qubes OS 4.3.1 is now available for testing. This patch release aims to consolidate all the security patches, bug fixes, and other updates that have occurred since the release of Qubes 4.3.0.
That depends on the number of bugs discovered in this RC and their severity. As explained in our release schedule documentation, our usual process after issuing a new RC is to collect bug reports, triage the bugs, and fix them. If warranted, we then issue a new RC that includes the fixes and repeat the process. We continue this iterative procedure until we’re left with an RC that’s good enough to be declared the stable release. No one can predict with certainty, at the outset, how many iterations will be required (and hence how many RCs will be needed before a stable release), but we tend to get a clearer picture of this as testing progresses.
Since the changes between 4.3.0 and 4.3.1 are relatively minor, we currently don’t anticipate any major problems requiring a second RC. We currently expect to be able to publish the stable 4.3.1 release in one to two weeks.
As an alternative to a clean installation, there’s also the option of performing an in-place upgrade without reinstalling. However, since Qubes 4.3.1 is a patch release, it’s essentially Qubes 4.3.0 inclusive of all updates to date, which largely amounts to just using a fully-updated 4.3.0 installation. By contrast, a clean installation covers other areas that could also benefit from testing, such as the installation procedure, which is why it’s the recommended testing method.
It is possible that templates restored in 4.3.1 from a pre-4.3 backup may continue to target their original Qubes OS release repos. This does not affect fresh templates on a clean 4.3.1 installation. For more information, see issue #8701.
A release candidate (RC) is a software build that has the potential to become a stable release, unless significant bugs are discovered in testing. RCs are intended for more advanced (or adventurous!) users who are comfortable testing early versions of software that are potentially buggier than stable releases. You can read more about Qubes OS supported releases and the version scheme in our documentation.
What’s a patch release?
The Qubes OS Project uses the semantic versioning 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 for a comprehensive list of major and minor releases and our version scheme documentation for more information about how Qubes OS releases are versioned.
Armbian&aposs next release boots the FriendlyElec NanoPi M5 end-to-end from UFS on a mainline U-Boot, with no proprietary recovery image in the loop. It is the first RK3576 board in the catalogue to reach this state, and the integration pattern paves the way for the others.
UFS, the storage class that replaced eMMC in phones, is packet-based and full-duplex with command queuing. The practical gain over an SD card shows up in random I/O, in latency under concurrent load, and in write endurance that holds up over years of deployment. FriendlyElec ships UFS on the M5 because the RK3576 has a native UFS controller, a sensible choice for any board destined for kiosks, robots, or industrial gateways.
What mainline was missing
The UFS controller IP itself had a partial driver in mainline U-Boot. Everything around it was not wired: PHY init sequencing, the regulator rails the device needs before it responds, the device-tree glue that tells U-Boot "yes, this board has UFS." For the M5, none of it existed. There is also a cosmetic detail that catches every newcomer, namely that Rockchip&aposs loader tooling labels UFS as SATA in the RKDevTool storage dropdown. Flashing goes through upgrade_tool, not the more familiar rkdeveloptool, because rkdeveloptool has never had UFS support.
How it came together
Three workstreams had to converge. Jonas Karlman&aposs kwiboo/rk3576 branch carried the upstream RK3576 U-Boot enablement, pinctrl, clocks, storage controller bindings, and has been merging into mainline through 2026. The rockchip-linux/rkbin tree had to ship a UFS-capable MiniLoader, which the RK3576MINIALL.ini recipe assembles from the DDR init, the UFS-aware loader, and the OP-TEE/ATF blobs. The Armbian side was the integration: a board config on U-Boot v2026.04, a U-Boot DT overlay that brings the UFS regulators and PHY up at the right moment, and a flashing path that upgrade_tool accepts. None of these were individually hard. Making them line up is what took the time.
On the device, the stack does its job cleanly. The BootROM reads the IDB off UFS and pulls in the TPL; the TPL initialises DDR and the UFS host controller, sequences the regulators, negotiates the link, and reads the next stage; ATF jumps to U-Boot; U-Boot enumerates ufs 0 and loads the kernel; the kernel re-probes the same controller it just booted through. The work, almost all of it, lived at the TPL stage. Controller fine, PHY fine, but the device sits silent if regulator sequencing is wrong by a handful of milliseconds. Once that is right, the upper layers see a clean SCSI-shaped block device and the rest is unsurprising.
What it leaves us with
For users with a UFS-equipped M5, the next release image flashes through the FriendlyElec Rockchip workflow with upgrade_tool, BOOT switch on UFS/SD, storage dropdown labelled "SATA". The board boots without an SD card or eMMC involvement, and armbian-install writes the same image to UFS in place once the system is running from another medium. Against microSD on the same hardware the difference is felt rather than benchmarked: small reads land faster, the system stays responsive under concurrent I/O, and the write endurance is in a different ballpark.
A few rough edges remain. The vendor tooling will keep calling UFS "SATA" until either Rockchip relabels the GUI or rkdeveloptool grows a cs ufs opcode, neither on the immediate horizon. The BOOT switch is a hardware gate with no software override. And upgrade_tool ships only as a Linux x86_64 ELF, so flashing from an Apple Silicon Mac means a Linux VM with USB passthrough or a Windows host running the GUI.
The same plumbing now unlocks every other UFS-equipped RK3576 board in the catalogue. The M5 reached the line first because the hardware was available and the upstream pieces were the most complete. The others should be substantially less work, now that the integration pattern exists and the loader path has been proven on real silicon.
This week&aposs work centers on board support expansion, kernel and U-Boot maintenance, and desktop and CI tooling refinements.
On the platform side, the Radxa Cubie A5E received Wi-Fi enablement and a kernel refresh as part of a broader update, while the youyeetoo YY3588 was promoted from CSC to standard support and the YY3568 gained PCIe NVMe functionality. The NanoPi R76S and Rock 5 ITX were both migrated to mainline U-Boot v2026.04, dropping vendor-branch gates, and the Vanxoak HD-RK3506-EVB was added with vendor and board imagery.
Kernel hygiene dominated the maintenance work: duplicate OPP labels on the Xiaoxin Pad Pro (sm8250) were corrected, broken UHS-I, xo-clock, SD, and DSI patches were removed from sm8550 trees for both 6.18 and 7.0, and a now-upstream r-spi backport was dropped from sunxi-6.18. The odroidxu4-current branch advanced to 6.6.141 across two successive bumps.
Desktop and infrastructure tooling saw layered improvements through configng: alsa-ucm-conf and libcamera/v4l userspace were added to the minimal tier, PackageKit and AppStream landed at the mid tier, and DE postinst scripts now execute in the build chroot to resolve missing wallpaper. UEFI x86 and arm64 desktop spins were switched to GNOME on the edge kernel, and build infrastructure gained inline ShellCheck PR feedback, scoped token permissions, fork-aware artifact gating, and event-driven runner cleanup via systemd hooks.
In application delivery environments, not every meaningful improvement needs to be disruptive.
A large part of maintaining stable and efficient infrastructures comes from continuously refining how systems behave in production: reducing operational friction, improving compatibility, and making administration more predictable for technical teams managing critical services.
That is the direction behind SKUDONET Enterprise Edition 10.2.0, a release focused on operational consistency, HTTPS flexibility, and incremental improvements across the ADC and WAF stack.
Enhanced HTTPS listener flexibility
SKUDONET EE 10.2.0 introduces additional flexibility in HTTPS farm listener management, allowing HTTP/2 behaviour to be configured directly from the farm settings.
This enhancement simplifies the activation and management of modern HTTP delivery capabilities within HTTPS services, streamlining configuration across different application environments.
Designed for modern web applications and APIs, HTTP/2 improves connection efficiency through features such as request multiplexing and optimised resource delivery, helping reduce latency and improve responsiveness under concurrent traffic loads.
The new configuration approach allows administrators to manage listener behaviour more dynamically while maintaining the operational simplicity of HTTPS farms.
Improved WebGUI usability for day-to-day administration
This release also includes several refinements in WebGUI sections that rely on picklist-based components.
While these changes may appear subtle, they have a direct impact on daily administration tasks, especially in environments with larger configurations or multiple managed objects.
The improvements focus on:
Smoother interactions
Better responsiveness
Improved handling of large lists
Greater consistency across configuration views
The goal is simple: to make administration more fluid without adding unnecessary complexity.
For technical teams working across multiple farms, services, or security policies, these kinds of usability refinements can significantly improve operational efficiency over time.
Smarter cookie domain handling in HTTP/S farms
Session persistence management has also been improved in HTTP and HTTPS farms.
When a cookie domain is not explicitly configured, and a dynamic feature is enabled, SKUDONET can now automatically use the incoming request virtual host as the cookie domain.
This behaviour helps simplify deployments involving multiple domains or virtual hosts while reducing the need for additional manual configuration.
In practice, this makes multi-site and multi-tenant environments easier to manage and helps maintain more predictable persistence behaviour across distributed applications.
More consistent WAF rule management
SKUDONET EE 10.2.0 also refines the behaviour associated with WAF rule movement actions.
The rule move process now correctly respects the selected administrative action, improving consistency when reorganising or managing security rules within the configuration.
For teams working with customised security policies, predictable rule management becomes especially important in order to maintain visibility and operational control across complex environments.
As part of its application security architecture, SKUDONET integrates WAF and IPDS capabilities directly into the ADC layer to help protect applications and APIs from modern web threats .
Better compatibility with backend applications
Another important refinement in this release affects URL handling within HTTP farms.
Previously, incoming request URLs could be automatically decoded before being forwarded to backend services. With 10.2.0, SKUDONET now preserves and forwards the original encoded URL exactly as received from the client.
Although technically small, this adjustment improves compatibility with applications and APIs that depend on encoded paths, special URL characters, or framework-specific routing behaviours.
In modern microservice architectures and API-driven environments, preserving request integrity can help avoid unexpected behaviours and simplify backend integrations.
A release focused on real operational environments
SKUDONET EE 10.2.0 does not aim to reinvent the platform, but rather to continue refining how it behaves in real production environments.
From enhanced HTTPS flexibility to improvements in administration workflows, persistence handling, and backend compatibility, this release follows the same practical and progressive approach that defines the platform: reducing operational complexity without sacrificing control, performance, or security capabilities.
These are the kinds of improvements designed for teams that need predictable, stable, and easy-to-manage infrastructures in their day-to-day operations.
As part of its unified Application Delivery and Security approach, SKUDONET continues evolving as an ADC solution built for physical, virtual, cloud, and hybrid environments.
The latest Nubus for Kubernetes release improves observability: a new API endpoint provides metrics for operator dashboards, and additional information in the Management UI gives operators and administrators easy access to information that helps prevent or analyze incidents.
Univention Directory Manager Metrics
The REST API of the Univention Directory Manager (UDM) now includes a new endpoint that provides metrics about the Nubus deployment. The API has been designed to work best with Prometheus, the most commonly used implementation for collecting and storing metrics and providing them to dashboard solutions such as Grafana.
In the initial release, the metrics endpoint of the UDM REST API provides the following metrics:
Number of registered users
Number of licensed users
Nubus domain name and domain identifiers
Detailed information about the Nubus release, including software version, patch level, and platform information (whether it runs on Kubernetes or UCS)
Operators can easily identify when user growth reaches critical levels, exceeds the license limits, or when the installed Nubus version is outdated. Thanks to the domain information, it is also easy to distinguish between multiple Nubus deployments in larger environments. Detailed information can be found in the metrics chapter of the Nubus Manual.
Detailed Backend Information for All Directory Objects
When analyzing configuration issues or end-user incidents, it is often necessary to access technical information used in the backends, such as the Univention Object Identifier introduced with Nubus for Kubernetes 1.10. To simplify the process of matching real names with technical identifiers for users, groups, and any other information stored in the directory service, Univention Nubus now includes these identifiers in the Web UI.
This is helpful in several scenarios: if a warning or error containing a technical identifier such as the Univention Object Identifier is logged in a backend service, administrators can now search for that identifier directly in the Web UI of Univention Nubus and easily access the full information about the affected user. If a user reports an issue to the end-user helpdesk, administrators can now easily retrieve the technical identifiers from the Nubus Web UI and use them to search log messages.
In addition, further information such as the LDAP DN, as well as timestamps and actors for object creation and last modification, are available, together with OpenLDAP internal information such as the entryUUID. This information is available for every object stored in the directory service and can be accessed both in the Web UI and in the UDM REST API. As this information is not needed for day-to-day administration, the UI elements are located in the “Advanced settings” section within a new “Technical Information” area.
Bits & Pieces
As with every release, there are many smaller changes. One noteworthy aspect is the increasing number of security-related fixes we deliver for upstream components included in Univention Nubus. We assume that AI-based analysis of open source software also impacts the software included in Nubus, and we aim to release patched versions as quickly as possible — for example, for critical findings in Keycloak that were already addressed in the Nubus 1.19.1 patch-level release. Thanks to the infrastructure we introduced to prevent supply chain attacks, we can identify and fix these issues quickly.
A cost-saving improvement for operators of larger deployments is the newly introduced configuration option for the two data volumes used by the LDAP container images. One of these volumes stores the LDAP database with all stored objects and therefore requires larger and faster storage, while the other stores only runtime data and requires only a small volume with average performance. In previous releases, it was not possible to configure different storage classes and sizes for these volumes, resulting in runtime data being placed on large, fast, and therefore expensive storage. Thanks to the new configuration options, it is now possible to choose different storage classes and reduce costs.
The recent National Bureau of Economic Research (NBER) study on effectiveness of school phone bans has reignited debate over whether restricting smartphones in schools actually helps students. Its headline result—that strict bans show “close to zero” immediate impact on test scores—has been interpreted by some as evidence that regulation doesn’t work.
The Inspector General’s audits uncovered a systemic collapse in mobile‑device security across DHS’s Intelligence & Analysis (I&A) office and CIO organization.
California’s data broker crackdown, AI creeping into browsers, and global surveillance trends signal one truth—individual privacy are under attack. Here’s how Purism is building a future where your data stays yours.
We are excited to announce the release of Proxmox Virtual Environment 9.2. This release focuses heavily on platform refinement, stability, and core optimization.
Proxmox VE 9.2 is built on the robust Debian 13.5 "Trixie" and ships with Linux kernel 7.0 as the new stable default. In addition to core system enhancements, this update integrates the latest versions of our key underlying technologies, including QEMU 11.0, LXC 7.0, and ZFS 2.4. Storage capabilities have also been advanced with...
For nearly two decades, stolen credentials have been the focus of many analyses of security breaches. This picture is now changing. According to the Verizon 2026 Data Breach Investigations Report (DBIR), vulnerability exploitation has overtaken credential abuse as the top breach vector for the first time — accounting for 31% of breaches, compared to just […]
In early 2025, internet users across Spain began experiencing something unexpected: legitimate websites going dark, developer tools becoming unreachable, and businesses losing access to their own online services. GitHub, GitLab, Docker registries, corporate websites, and e-commerce platforms all affected not by a cyberattack, not by a provider outage, but by a court-ordered IP block targeting illegal football streaming.
The mechanism was straightforward. A ruling from the Commercial Court No. 6 of Barcelona, issued in December 2024, authorised Spanish ISPs to block IP addresses identified as sources of illegal IPTV broadcasts during football matches.
The problem was that many of those addresses were Cloudflare IPs shared simultaneously by thousands of unrelated websites and services. When ISPs blocked the flagged addresses, they didn’t take down one streaming site. They took down everything behind the same shared IP.
The football piracy angle captured headlines. The infrastructure lesson is what matters for organisations operating critical services anywhere in the world.
What happened technically and Why Shared IP Blocking Scales So Broadly
To understand why IP-level blocking caused collateral damage at this scale, it helps to understand how large CDN and edge-delivery infrastructures work.
Cloudflare, like most major content delivery networks, operates a shared global edge infrastructure. When a company routes its traffic through Cloudflare, it passes through Cloudflare’s distributed network of nodes rather than reaching the origin server directly. From the outside, that service’s visible IP address is a Cloudflare IP pooled across many other customers simultaneously. A single IP address in a shared CDN infrastructure can front hundreds or even thousands of completely unrelated domains.
This is the multi-tenant model applied at the network edge: multiple organisations share the same underlying infrastructure resources, including IP address ranges, reverse proxy layers, TLS termination systems, and WAF infrastructure. Clients are logically separated; the network layer beneath them is not.
The consequence follows directly. Any action operating at the IP level (a court-ordered block, a blacklist entry, an ISP-level firewall rule) doesn’t target a single service. It targets every service resolving through that address. Developers found they couldn’t pull packages. Companies found their websites unreachable. None of them had any connection to the reason for the block.
It is important to note that this operational model is not unique to Cloudflare. Most large CDN, WAF, and edge delivery providers rely on shared, multi-tenant infrastructure to deliver scalability and cost efficiency globally. This architectural model is deeply embedded across much of the modern internet delivery stack.
The Spain case became a highly visible example of shared infrastructure risk in modern cloud delivery architectures.
The court order didn’t create this vulnerability. It revealed one that was already there.
The tradeoffs of multi-tenant architecture that rarely get discussed
Multi-tenant architecture is not inherently flawed. It became the dominant model in cloud computing for legitimate, well-understood reasons.
For providers, it enables resource pooling, centralised maintenance, elastic scalability, and cost efficiency at scale. For customers, it translates into lower entry costs, faster deployment, and freedom from managing infrastructure directly. Most organisations don’t need (or want) to operate their own edge networks, WAF layers, or global traffic distribution systems. Consuming those capabilities as a shared service makes practical and economic sense.
The issue isn’t that multi-tenancy is inefficient. The issue is that shared infrastructure creates shared operational exposure and that exposure is rarely top of mind when organisations choose SaaS platforms or CDN services.
In a multi-tenant environment, organisations can inherit operational risk from events that have nothing to do with their own services:
An IP address is blacklisted because another tenant was abusing it
DDoS traffic targeting a neighbouring tenant is degrading shared network performance
A legal or regulatory action that catches shared IPs in its scope
A provider-level policy change applied uniformly across the customer base
Under normal conditions, these risks remain invisible. Most of the time, shared infrastructure works exactly as advertised. But under stress (a security incident, a large-scale abuse event, a court order), the shared layer is precisely where failures propagate.
This is what infrastructure engineers refer to as a shared blast radius: the operational scope of an incident isn’t defined by the intended target, but by the boundaries of the shared environment.
Why infrastructure isolation is becoming a resilience decision
Single-tenant architecture reverses the model. Each client operates a dedicated environment: isolated IP addresses, independent compute resources, and exclusive security policies that are not shared with other organisations.
The tradeoff has traditionally been cost and operational overhead. Dedicated infrastructure is more resource-intensive than shared SaaS deployments. That gap is why multi-tenancy became the default.
But the relevant question is not which model is architecturally superior. It is the operational risks that the organisation is prepared to carry.
For many workloads, multi-tenant SaaS remains the correct and efficient decision. For critical applications (platforms where availability directly affects revenue, SLA compliance, customer trust, or operational continuity) the calculation looks different.
Consider the practical implications. An e-commerce platform that becomes unreachable during peak sales hours due to a shared IP block loses revenue that it cannot recover. A SaaS provider whose service goes dark due to an incident involving a neighbouring tenant faces SLA breach conversations with its own customers. A financial service or healthcare platform that loses availability (even briefly, even for reasons entirely outside its control) faces reputational and regulatory consequences that extend well beyond the technical incident itself.
These aren’t theoretical edge cases. They represent the downstream business impact of shared operational exposure.
This is why infrastructure isolation is increasingly appearing in resilience discussions rather than just security or compliance contexts. The growing interest in dedicated environments, private edge infrastructure, and hybrid deployment models reflects a broader recognition: that shared platforms also mean shared operational exposure, and that for critical services, reducing that exposure is a legitimate architectural strategy, not just a premium option.
Managed single-tenant deployments (where the provider handles infrastructure operations on dedicated resources) narrow the practical gap between SaaS convenience and isolated control, without requiring organisations to operate everything themselves.
Questions worth asking before relying on shared infrastructure
The Spain controversy highlighted something important: many organisations don’t fully understand how shared their infrastructure actually is. Before deploying critical services on SaaS or CDN platforms, the following questions are worth examining carefully.
Are IP addresses shared with other tenants? If multiple customers share the same edge IPs, reputation issues, legal restrictions, or blocking measures targeting one tenant can affect others.
What is the actual isolation boundary? Logical separation and operational isolation are not equivalent. Understanding how traffic, policies, rate limits, and security rules are enforced or shared across tenants matters for availability planning.
What is the provider’s blast radius during incidents? Every platform experiences incidents. The relevant question is how broadly those incidents propagate across the customer base.
Can another tenant’s actions affect your availability? This includes abuse-triggered IP restrictions, DDoS spillover, shared WAF rate limiting, and legal or compliance measures applied at the infrastructure level without tenant-specific granularity.
Is an isolated or hybrid deployment available? For critical services, the ability to deploy on dedicated infrastructure (on-premise, private cloud, or dedicated cloud instances) reduces dependency on shared operational models and gives organisations direct control over their exposure.
How transparent is the provider about its architecture? Providers that clearly document whether they operate as multi-tenant SaaS, isolated instances, or dedicated environments enable informed infrastructure decisions. Opacity here is itself a risk signal.
The debate in Spain will evolve through legal appeals, technical adjustments, and regulatory review. But the infrastructure question that surfaced isn’t tied to football season.
Organisations have spent years consolidating digital operations onto shared, efficient, globally distributed platforms. That consolidation brought genuine benefits: lower costs, faster deployment, and reduced operational complexity. It also created dependencies on shared infrastructure that those organisations do not control — and cannot protect themselves from when something goes wrong on the shared layer.
The Spain controversy is not fundamentally a story about piracy enforcement or internet freedom. It is a visibility event for a problem that already exists across large parts of modern cloud infrastructure: organisations are increasingly dependent on shared operational layers they neither fully control nor fully understand.
For critical services, resilience is no longer only about redundancy or scalability. It is also about understanding where infrastructure boundaries actually exist and whether an event targeting someone else can reach you through a layer you assumed was yours.
If you have both the Thunderbird Email Client and Additional Software
features of the Persistent Storage turned on, Tails automatically adds
Thunderbird to your list of additional
software.
A new version of Thunderbird is released in Debian shortly after each Tails
release, because both Tails and Thunderbird follow the release calendar
of Firefox. As a consequence,
until Tails 7.5 (February 2026), the version of Thunderbird in Tails was
almost always outdated, with known security vulnerabilities.
By installing Thunderbird as additional software, the latest version
of Thunderbird is installed automatically from your Persistent Storage each
time you start Tails.
Fixed problems
Fix multiple security vulnerabilities in the Linux kernel and haveged, that
could allow an application in Tails to gain administration privileges.
For example, if an attacker was able to exploit other unknown security
vulnerabilities in an application included in Tails, they might then use one
of these vulnerabilities to take full control of your Tails and
deanonymize you.
The finish line! The moment we have anticipated is finally here – PureOS Crimson is released! All devices running PureOS Byzantium will receive the PureOS Upgrade application with their regular software updates. If you’d like to install Crimson fresh, refer to our installation instructions for PCs, servers, and the Librem 5. This has been an […]
I was getting “<XF86AudioPlay> is undefined” in the status bar of Emacs displayed every 2-3 seconds. Nowhere else I noticed any misbehavior or problems, and also couldn’t find any related log entries. It didn’t stop, though didn’t want to reboot my system to see whether that would fix the problem, but it was driving me nuts.
Now, as a starting point I adjusted my sway configuration, to react to the XF86AudioPlay key press event:
bindsym XF86AudioPlay exec playerctl play-pause
After reloading sway, my music player started to play for 2-3 seconds, stopped playing, started again, etc. It wasn’t a Emacs bug, but something indeed seemed to send the XF86AudioPlay key event every 2-3 seconds. It wasn’t my USB keyboard or any stuck key on it, as verified also by unplugging it. So which device was causing this?
Behind this event12 is sof-hda-dsp Headphone, and evtest confirms that:
% sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: AT Translated Set 2 keyboard
/dev/input/event1: Sleep Button
/dev/input/event10: ThinkPad Extra Buttons
/dev/input/event11: sof-hda-dsp Mic
/dev/input/event12: sof-hda-dsp Headphone
/dev/input/event13: sof-hda-dsp HDMI/DP,pcm=3
/dev/input/event14: sof-hda-dsp HDMI/DP,pcm=4
/dev/input/event15: sof-hda-dsp HDMI/DP,pcm=5
/dev/input/event16: Yubico YubiKey OTP+FIDO+CCID
/dev/input/event17: Apple Inc. Magic Keyboard with Numeric Keypad
/dev/input/event18: Apple Inc. Magic Keyboard with Numeric Keypad
[...]
Select the device event number [0-24]: ^C
We can even get further information:
% sudo evtest /dev/input/event12
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "sof-hda-dsp Headphone"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 164 (KEY_PLAYPAUSE)
Event code 582 (KEY_VOICECOMMAND)
Event type 5 (EV_SW)
Event code 2 (SW_HEADPHONE_INSERT) state 0
Properties:
Testing ... (interrupt to exit)
Event: time 1779295060.175766, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1779295060.175766, -------------- SYN_REPORT ------------
Event: time 1779295061.951168, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295061.951168, -------------- SYN_REPORT ------------
Event: time 1779295061.951194, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295061.951194, -------------- SYN_REPORT ------------
Event: time 1779295064.548671, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295064.548671, -------------- SYN_REPORT ------------
Event: time 1779295064.548689, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295064.548689, -------------- SYN_REPORT ------------
Event: time 1779295067.437172, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295067.437172, -------------- SYN_REPORT ------------
Event: time 1779295067.437187, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295067.437187, -------------- SYN_REPORT ------------
Event: time 1779295070.323775, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295070.323775, -------------- SYN_REPORT ------------
Event: time 1779295070.323790, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295070.323790, -------------- SYN_REPORT ------------
Event: time 1779295073.200350, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295073.200350, -------------- SYN_REPORT ------------
Event: time 1779295073.200373, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295073.200373, -------------- SYN_REPORT ------------
Event: time 1779295076.076228, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295076.076228, -------------- SYN_REPORT ------------
Event: time 1779295076.076250, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295076.076250, -------------- SYN_REPORT ------------
Event: time 1779295078.961740, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295078.961740, -------------- SYN_REPORT ------------
Event: time 1779295078.961754, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295078.961754, -------------- SYN_REPORT ------------
Event: time 1779295081.850156, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295081.850156, -------------- SYN_REPORT ------------
Event: time 1779295081.850175, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295081.850175, -------------- SYN_REPORT ------------
Event: time 1779295083.306612, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 0
Event: time 1779295083.306612, -------------- SYN_REPORT ------------
So when I plug in my headphone (see the `SW_HEADPHONE_INSERT` event), the unexpected behavior starts, unplugging stops the problem.
Good! But what was totally unexpected for me: my headphone, being a Beyerdynamic DT-990 Pro, does not have any keys. 8-)
As it turned out, the headphone jack seemed to have been not entirely clean. The analog side of the jack triggers a behavior within the audio codec, where it seems to interpret the fluctuating impedance as a play button of the headset, being pressed, again and again.
I cleaned the jack of my headphone and my XF86AudioPlay problem is gone, case closed.
This week&aposs work advances on three fronts: kernel and bleedingedge alignment across Rockchip and Sunxi trees, board and platform enablement spanning RV1106 to SpacemiT, and CI hardening with self-hosted runner maintenance.
On the kernel side, bleedingedge was bumped to 7.1-rc3, accompanied by cfg80211 API fixes and re-enablement of the rtl8189fs and rtl8852bs drivers for the new release. Both the rockchip64 and sunxi patch stacks for current and edge were rewritten, an upstream ptrace fix for CVE-2026-46333 was backported to linux-rockchip, and the odroidxu4-current kernel moved to 6.6.139.
Platform enablement was broad. The Ayn Odin2 gained 7.0 kernel support, the Mekotronics R58X-Pro switched its vendor build to mainline U-Boot with a corrected LCD driver, and the H96 TV box advanced to U-Boot v2026.04. RV1106 transitioned from extlinux to a bootscript and gained DS1307, PCF85063, and RV8803 RTC drivers, while SpacemiT received OpenSBI, U-Boot, and BPI-F3 DTS fixups. Smaller but user-visible improvements include NanoPi M5 second USB3 port exposure via DRD0 host-mode pinning, NORCO EMB-3531 LPDDR4X variants, RK3528 USB2 PHY corrections for high-speed NCM, and UEFI x86 images enabling iwlwifi MLD and Intel SOF audio for MTL, LNL, and PTL.
Infrastructure work centered on self-hosted runner reliability and supply-chain hygiene. A new runner-cleanup module provides hourly disk and memory maintenance, skips busy runners, and ships via .deb, while a maintenance watchdog was added to the SDK repository. Multiple StepSecurity hardening passes landed across build and SDK workflows, though an overly strict egress-policy was subsequently reverted after breaking builds.
The Supreme Court’s consideration of geofence warrants represents one of the most technically and constitutionally significant privacy cases of the modern era. The core issue is whether bulk collection of location metadata—generated by consumer devices and cloud-based services—can coexist with the Fourth Amendment’s prohibition against unreasonable searches.
Defenders deploying Ubuntu will be pleased to know that Greenbone’s OPENVAS SCAN now includes detection for Ubuntu 26.04 LTS security notices via the OPENVAS ENTERPRISE FEED and COMMUNITY FEED. Ubuntu 26.04 LTS, aka “Resolute Raccoon”, is a long-term support (LTS) version of Ubuntu that was released on April 23rd, 2026. LTS releases receive standard security […]
Defenders deploying Fedora will be pleased to know that Greenbone’s OPENVAS SCAN now includes detection for Fedora 44 security advisories via the OPENVAS ENTERPRISE FEED and COMMUNITY FEED. Fedora Linux 44 was released on April 28th, 2026, and releases are typically maintained for 13 months. Fedora 44 has been assigned an expected end-of-life (EOL) date […]
Together with Bluella, we’ve hosted a live technical webinar around a problem that many infrastructure and cybersecurity teams eventually face:
What actually happens when applications start failing under pressure?
Not in theory.
Not in a slide deck.
But in real environments, with real traffic, real attacks, and real operational stress.
From the beginning, the idea behind the session was simple: instead of talking about infrastructure problems abstractly, we wanted to show them happening live.
Throughout the webinar, we recreated several scenarios using the SKUDONET Application Delivery & Security Platform, demonstrating how modern infrastructures behave when traffic spikes, backend services become unstable, or malicious requests begin targeting exposed applications.
The session brought together professionals working across cloud, infrastructure, DevOps, and cybersecurity environments, and one of the most rewarding parts for us was the level of interaction during the event itself.
Many attendees stayed connected after the webinar officially ended to continue discussing deployment models, traffic visibility, failover strategies, and application security challenges they are currently facing in production environments.
One of the recurring ideas during the session was that modern infrastructure problems rarely look dramatic at the beginning.
Most incidents don’t start with systems suddenly collapsing.
Instead, they usually begin with small signs:
latency increases slightly
requests start behaving differently
backend nodes become inconsistent
traffic patterns stop looking normal
And in many cases, by the time teams fully understand what is happening, they are already reacting under pressure.
That’s why we wanted the webinar to focus less on theory and more on operational behaviour.
Rather than presenting isolated product features, the demonstrations focused on how load balancing, high availability, Web Application Firewall (WAF) protections, and traffic inspection work together during real infrastructure stress scenarios.
Load Balancing Under Real Traffic Conditions
The first part of the webinar focused on Layer 4 and Layer 7 load balancing.
During the live demonstration, attendees could see how traffic was distributed dynamically across backend nodes while monitoring concurrency, health checks, and response behaviour in real time.
One interesting discussion that emerged during this section was how operational complexity continues to be a challenge in many environments.
Even today, adjusting traffic distribution policies or deploying failover mechanisms often involves fragmented tooling, manual processes, or long intervention times.
The goal of the demonstration was not simply to show traffic balancing itself, but to illustrate how quickly infrastructure teams need to react when services begin degrading under pressure.
High Availability Is No Longer Optional
Another important moment during the webinar came during the high availability and failover demonstrations.
Instead of explaining failover conceptually, we simulated node failure conditions live while maintaining service continuity through an active-passive cluster configuration.
What became very clear during this part of the session is that availability is no longer just an infrastructure metric.
For many organizations, even small periods of service degradation directly affect:
operational continuity
customer trust
internal productivity
and revenue generation
Modern applications are now deeply connected to business operations, which means infrastructure resilience is no longer a secondary concern.
DDoS Traffic and Visibility Under Stress
One of the most dynamic parts of the webinar focused on DDoS mitigation and traffic behaviour under stress.
Using live traffic simulations, attendees could observe the difference between legitimate user traffic and malicious flooding attempts designed to exhaust backend resources.
What made the demonstration especially interesting was not simply the attack mitigation itself, but the visibility aspect behind it.
Because one of the biggest challenges during modern attacks is not only stopping malicious traffic.
It’s understanding what is actually happening before systems become unstable.
Many attacks today are designed to degrade infrastructure progressively rather than immediately taking services offline. Performance deteriorates slowly, observability becomes harder, and teams lose operational clarity while trying to identify the root cause.
The session showed how traffic filtering and inspection at the application delivery layer can help isolate malicious behaviour before backend services are affected.
Looking Beyond the Surface: XSS and SQL Injection
The webinar also explored application-layer attacks such as Cross-Site Scripting (XSS) and SQL Injection.
Rather than discussing these threats abstractly, attendees could see how malicious payloads interact with exposed applications in real time and how WAF protections identify and block suspicious requests before they reach backend services.
One of the most interesting conversations during this section focused on how difficult modern attacks can be to distinguish from normal traffic patterns.
From the outside, many malicious requests initially appear legitimate.
But underneath, they may be attempting to:
manipulate application behaviour
extract information
bypass validation mechanisms
or exploit backend vulnerabilities
This is where application visibility becomes critical.
Because modern application delivery is no longer only about distributing traffic efficiently.
It’s about understanding whether that traffic should be trusted in the first place.
More Than Security: Operational Control
Although the webinar covered load balancing, failover, DDoS mitigation, and WAF protections separately, one common theme appeared throughout the entire session: operational control.
Modern infrastructures generate enormous volumes of traffic, requests, logs, alerts, and behavioural changes.
Without visibility, teams often end up reacting blindly during incidents.
This is one of the reasons why modern Application Delivery Controllers (ADCs) like SKUDONET increasingly combine:
load balancing
high availability
traffic inspection
observability
automation
and application security
into a single operational layer.
The objective is not simply performance.
It’s maintaining control when infrastructure conditions become unpredictable.
A Very Technical and Very Real Conversation
For us, one of the most valuable parts of the webinar was what happened after the official presentation ended.
Several attendees stayed connected to continue discussing infrastructure architectures, deployment flexibility, hybrid environments, operational bottlenecks, and the practical challenges of maintaining application availability under increasing traffic and security pressure.
Those conversations reinforced something we see constantly across the industry:
Teams are no longer looking only for “more features”.
They are looking for:
operational simplicity
better visibility
faster incident response
integrated security
and infrastructure that remains manageable as complexity grows
Emilio Campos, CEO of SKUDONET, showcasing a live demo during the webinar
Assess Your Own Infrastructure Readiness
The scenarios explored during the webinar reflect operational challenges that many organizations already face today from traffic spikes and Layer 7 attacks to limited visibility during incidents and increasing pressure on critical applications.
To help teams evaluate their own environments, we’ve prepared a short technical assessment inspired by the same types of real-world scenarios covered during the session:
Three new high-severity local privilege escalation (LPE) vulnerabilities affecting Linux were recently disclosed, creating significant global risk. Although user-level access is a prerequisite for their exploitation, the new CVEs allow command execution as the root user and full system takeover. The CVEs are considered reliably exploitable on all major Linux distributions. The name “Copy Fail” […]
The VyOS documentation site has carried us a long way. Sphinx + reStructuredText served the project well for years — but the world around our documentation has changed faster than our toolchain. Contributors write in Markdown. LLM coding assistants pull docs into their context windows. Reviewers expect machine-assisted feedback. AI agents need a stable, machine-readable surface to reason about VyOS configuration.
---===[ Qubes Security Bulletin 114 ]===---
2026-05-13
Intel CPU data exposure vulnerability
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-05-12, Intel published "2026.2 IPU-Intel Processor Firmware
Advisory" (INTEL-SA-01420, CVE-2025-35979). [3] Unfortunately, this
advisory does not provide sufficient information for us to make a
definitive assessment about the extent to which this vulnerability
affects the security of Qubes OS. Based on the limited information
available, we surmise that it is likely that it might affect cross-qube
data exposure.
Impact
-------
On affected systems, an attacker who has managed to compromise one qube
can attempt to exploit this vulnerability in order to infer data
belonging to other qubes.
Affected systems
-----------------
Intel Core Ultra Series 2 and 3 processors are affected. For a more
detailed list of affected products, see Intel's "2026.2 IPU-Intel
Processor Firmware Advisory." [3]
Patching
---------
The following packages contain security updates that address the
vulnerabilities described in this bulletin:
For Qubes 4.2 and 4.3, in dom0:
- microcode_ctl version 2.1.20260512
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
microcode updates.
Credits
--------
See Intel's "2026.2 IPU-Intel Processor Firmware Advisory." [3]
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://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01420.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
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) is a security announcement issued by the 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. 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 signature is a cryptographic digital signature made in accordance with the OpenPGP standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG). 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.)
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
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
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.
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
Import the included PGP keys. (See our 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
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-114), the commands are:
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-114 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 you just created.
![[RSS 1.0 Feed]](/common/rss10.png){kind=small}
![[RSS 2.0 Feed]](/common/rss20.png){kind=small}
![[Atom Feed]](/common/atom.png){kind=small}
![[FOAF Subscriptions]](/common/foaf.png){kind=small}
![[OPML Subscriptions]](/common/opml.png){kind=small}
![[Hacker]](/common/hacker.png){kind=small}
![[Planet]](/common/planet.png){kind=small}
