X.Org Server 26.1 durcit la sécurité après cinq ans de maintenance
La première release candidate de X.Org Server 26.1, publiée le 19 août 2026, succède à la série 21.1 avec le refus des clients byte-swapped et la coupure du serveur de polices par défaut. Les mainteneurs de distributions et les parcs X11 historiques doivent auditer ces nouveaux défauts avant la version stable.
19 août 2026. X.Org Server 26.1 RC1 est étiqueté. Cinq ans. C’est le temps écoulé depuis la dernière version majeure de fonctionnalités du serveur d’affichage, la série 21.1 lancée en 2021. Deux. C’est le nombre de changements de sécurité qui vont casser des configurations historiques si personne ne les anticipe.
Le projet X.Org est si discret depuis des années qu’on l’a largement déclaré en maintenance pure, le monde ayant basculé sur Wayland. La publication de cette RC1 ne change pas ce constat — X11 reste un héritage qu’on maintient — mais elle le précise : la release qui arrive est moins riche en fonctionnalités qu’en durcissement. Et c’est précisément ce qui la rend intéressante pour un administrateur.
Ce que contient réellement la 26.1
Le communiqué de la RC1 liste les changements notables depuis xorg-server 21.1. Ils tiennent en une liste courte, et leur lecture dit tout du statut du projet.
- Suppression du système de build Autoconf/Automake, au profit de Meson seul. C’est une modernisation de la chaîne de packaging, pas une fonctionnalité utilisateur — mais elle change le travail des mainteneurs de distributions, qui devront adapter leurs recettes de compilation.
- Ajout de l’événement
DPMSInfoNotifyde la spécification DPMS 1.2, et du support de XFixes 6.1 avec l’optionAllowForceTerminatedansxorg.conf. - Refus des clients byte-swapped par défaut. C’est le changement de sécurité le plus structurant.
- Coupure des connexions au serveur de polices par défaut. Le second changement de sécurité.
- Plateforme DRM pour BSD côté Xorg, et déplacement des journaux des utilisateurs non-root vers
$XDG_STATE_HOME/xorg. - Xvfb gagne le support de plusieurs CRTC et de jusqu’à 13 boutons de souris, ainsi qu’une couverture de tests élargie.
Aucune de ces lignes ne va faire revenir un utilisateur Wayland vers X11. Mais trois d’entre elles ont des conséquences opérationnelles concrètes, et deux sont strictement sécuritaires.
Les deux durcissements qui comptent
Le refus des clients byte-swapped est le changement le plus important de la release. Historiquement, le protocole X11 autorisait un client dont l’ordre des octets diffère de celui du serveur à se connecter, le serveur effectuant la conversion à sa place. Cette générosité protocolaire est un héritage d’une époque où les stations hétérogènes se parlaient sur un réseau de confiance. Elle est devenue une surface d’attaque : le code de byte-swapping du serveur X a été au cœur de plusieurs vulnérabilités corrigées ces dernières années, parce qu’il manipule des tampons de longueurs variables transmis par le client.
En refusant ces clients par défaut, 26.1 réduit cette surface. La conséquence est concrète : tout client X11 s’exécutant sur une architecture dont l’ordre des octets diffère du serveur devra être explicitement autorisé, ou ne pourra plus se connecter. Sur les parcs homogènes x86-64, l’impact est nul ; sur les déploiements mixtes ou les vieux clients embarqués, il faut le savoir avant la bascule.
La coupure du serveur de polices par défaut relève du même esprit. Le serveur de polices (font server, protocole X Font Server) ouvrait un canal réseau par lequel un client pouvait demander des polices à distance — un service de plus exposé, souvent laissé actif par défaut sur des configurations qui ne l’utilisaient jamais. 26.1 l’éteint par défaut. Là encore, la majorité des installations n’y perdra rien ; les rares qui dépendent encore d’un serveur de polices distant devront l’activer explicitement.
Ces deux changements suivent la même logique que les durcissements récents du projet : moins de services ouverts par défaut, moins de complexité protocolaire exposée. Ils ne corrigent pas une CVE précise, ils retirent du code et des chemins réseau dont l’utilité réelle a disparu.
Ce que ça change pour Xvfb et la CI
La partie la plus utile pour un ingénieur moderne n’est pas dans le durcissement, elle est dans Xvfb. Ce serveur X virtuel sans matériel est le cheval de trait des tests navigateurs et des CI : il fournit un affichage aux tests d’interface qui ne tourneraient pas en mode headless natif.
Deux ajouts le concernent directement. Le support de plusieurs CRTC permet à Xvfb de présenter plusieurs sorties virtuelles, ce qui débloque les tests qui supposent un environnement multi-écrans. Et le support de 13 boutons de souris couvre les périphériques modernes que les tests d’automatisation simulent de plus en plus souvent. Aucun des deux n’est spectaculaire ; ensemble, ils réduisent les contournements que les équipes de test accumulent depuis des années autour de Xvfb.
Wayland, XWayland et la vraie position de X.Org
Il faut situer la 26.1 dans son contexte réel. Wayland est le protocole d’affichage par défaut de la quasi-totalité des distributions depuis plusieurs années. X11 survit sous deux formes : les déploiements hérités qui n’ont jamais migré, et XWayland, la couche de compatibilité qui fait tourner les applications X11 dans une session Wayland.
La 26.1 ne rivalise pas avec le travail en cours sur XWayland — XWayland 26.1 RC1 a été publié le même jour avec un volume de fonctionnalités nettement supérieur. Le rôle de X.Org Server lui-même est devenu celui d’un socle de compatibilité que l’on maintient proprement, sans le développer agressivement. Cette release est fidèle à ce rôle : elle nettoie, durcit et modernise l’outillage, sans prétendre inverser la trajectoire du marché.
Verdict
Si vous maintenez une distribution ou un parc X11 hérité, préparez la migration vers 26.1 autour des deux nouveaux défauts sécuritaires. Inventoriez vos clients X11 pour détecter ceux qui dépendent d’un ordre d’octets différent ou d’un serveur de polices distant, et testez le refus des clients byte-swapped sur un poste pilote avant la bascule. La version stable de 26.1 n’est pas encore datée, mais les distributions l’intègreront vite — mieux vaut découvrir les blocages en staging qu’en production.
Si votre seule exposition à X11 est Xvfb en CI, vous avez peu à craindre et quelque chose à gagner : le support multi-CRTC et les 13 boutons de souris supprimeront des contournements de test. Rebuilduez simplement vos images CI sur la nouvelle base quand elle sera disponible, et vérifiez qu’aucun de vos tests ne supposait l’ancien serveur de polices.
Si vous êtes déjà sous Wayland, cette release ne vous concerne qu’indirectement, via XWayland. Mais les deux durcissements de sécurité finiront par s’y propager à leur tour, pour la même raison qu’ils arrivent ici : moins de surface, moins de risques.