Weekly #31 : Proxmox, FreshRSS 1.30, Jellyfin 12, Bitwarden et Nextcloud

Le sujet prioritaire de la semaine ne concerne pas une nouvelle version, mais des hyperviseurs restés sur une ancienne branche. Proxmox confirme l’exploitation d’un contournement d’authentification corrigé depuis juillet 2023. Aucun Proxmox VE encore supporté n’est vulnérable, mais une interface 7.x oubliée sur Internet mérite une vérification immédiate.

FreshRSS 1.30.0 demande également une mise à jour rapide. L’amont la présente comme une version majeure orientée sécurité et modifie, par défaut, l’accès aux adresses du réseau local. Ce comportement protège contre plusieurs chemins SSRF, mais peut casser les flux internes si l’exception n’est pas préparée proprement.

Jellyfin 12.0 est une maintenance d’un autre type. La migration réécrit la base, invalide les anciens plugins et impose un scan complet de la médiathèque. La mise à jour apporte de vraies améliorations, mais elle doit être traitée comme une opération planifiée, pas comme un simple redémarrage de conteneur.

En bref

#

• Proxmox VE : vérifier la version de libpve-access-control. Les versions de paquet à partir de 7.0-7 et avant 8.0.4 sont concernées. Les branches affectées sont EOL et la seule correction durable consiste à migrer vers une version supportée.
• FreshRSS : passer à 1.30.0 sans attendre inutilement. Inventorier auparavant les flux et fonctions de scraping qui contactent une adresse locale, puis n’autoriser que les destinations réellement nécessaires.
• Jellyfin : sauvegarder les répertoires de données et de configuration à l’arrêt. Il faut partir de 10.10.7 ou d’une version 10.11.x, retirer les plugins tiers et prévoir un premier scan long.
• Bitwarden : la version self-hosted 2026.8.1 permet d’exécuter Bitwarden Lite avec un utilisateur non privilégié et une racine en lecture seule. Le durcissement est proposé, mais reste à activer dans Compose.
• Nextcloud : installer 32.0.15, 33.0.9 ou 34.0.4 selon la branche. La série 32 est désormais EOL et doit ensuite sortir du parc communautaire.

Proxmox VE : une authentification contournable sur les anciennes branches

#

L’avis PSA-2026-00043-1 décrit une erreur dans le traitement du paramètre tfa-challenge par l’API de connexion de Proxmox VE. Ce paramètre doit normalement transporter un ticket signé après la première étape d’une authentification à deux facteurs.

Sur les versions vulnérables, sa simple présence désactivait la vérification du mot de passe pour un utilisateur qui n’avait pas de second facteur configuré. Un attaquant capable d’atteindre l’API sur le port 8006 pouvait donc fournir une valeur arbitraire et obtenir une session au nom d’un compte existant et actif. Par défaut, cela pouvait inclure root@pam.

La plage affectée est précise :

• libpve-access-control à partir de 7.0-7 et avant 8.0.4 ;
• approximativement Proxmox VE 7.0 à 7.4, branche EOL depuis juillet 2024 ;
• la première version 8.0, elle aussi EOL.

Le correctif se trouve dans libpve-access-control 8.0.4, publié le 20 juillet 2023, et dans toutes les versions ultérieures. Proxmox précise qu’aucune version actuellement supportée n’est affectée. L’identifiant CVE n’a été réservé et publié qu’en septembre 2026. Le changement de 2023 avait fermé le chemin vulnérable indirectement, sans que son impact de sécurité soit alors identifié.

La première vérification doit porter sur le paquet, pas seulement sur la version générale du cluster :

dpkg-query -W -f='${Version}\n' libpve-access-control
pveversion -v | grep 'libpve-access-control'

Contrôler ensuite l’écoute locale :

ss -ltnp | grep -E ':8006([[:space:]]|$)'

Voir pveproxy sur 0.0.0.0:8006 ne prouve pas une exposition publique. Il faut encore vérifier le pare-feu du nœud, celui du routeur ou du fournisseur, le reverse proxy et les règles VPN. À l’inverse, masquer le port derrière un nom DNS ou un proxy ne le rend pas privé si n’importe quel client peut toujours atteindre l’API.

Proxmox dit avoir reçu plusieurs signalements indépendants faisant état d’une exploitation dans la nature. Pour un nœud vulnérable dont l’API était accessible à des tiers, la réponse raisonnable est donc plus large qu’une mise à jour :

1. isoler l’interface de gestion aux réseaux et postes d’administration de confiance ;
2. préserver les journaux du proxy, de pveproxy, de pvedaemon et du frontal éventuel ;
3. rechercher les connexions, créations de tickets et modifications de VM, de stockage, de sauvegarde et de comptes qui ne correspondent pas à l’exploitation normale ;
4. migrer vers une branche Proxmox VE supportée ;
5. en cas de compromission plausible, reconstruire depuis une base saine et renouveler les secrets après avoir repris le contrôle de l’hyperviseur.

Un premier triage en lecture seule peut commencer avec :

journalctl --since '2026-08-30' -u pveproxy -u pvedaemon --no-pager

La faille ne fournit pas à elle seule un indicateur unique et fiable. L’absence d’une ligne évidente dans ces journaux ne suffit donc pas à déclarer le nœud sain. Les comptes disposant déjà d’un second facteur ne sont pas contournables par ce scénario précis, mais la MFA ne remet pas à niveau un hyperviseur EOL.

L’avis contient un patch temporaire pour les installations qui ne peuvent réellement pas migrer immédiatement. Il faut reprendre la commande directement depuis l’avis, vérifier le nombre d’occurrences attendu puis redémarrer les services indiqués. Cette rustine ne corrige ni le noyau, ni QEMU, ni LXC, ni les autres composants qui ne reçoivent plus de maintenance sur Proxmox VE 7.

Avis Proxmox PSA-2026-00043-1

CVE-2023-54391

FreshRSS 1.30.0 durcit les entrées, les partages et les accès réseau

#

FreshRSS présente la 1.30.0 comme une version majeure orientée sécurité et recommande une mise à jour rapide. Aucun score CVSS global ne permet de résumer proprement cette publication. Le changelog regroupe plusieurs scénarios distincts, notamment :

• des protections supplémentaires contre les SSRF ;
• des correctifs CSRF sur la connexion et l’inscription ;
• un contrôle d’accès corrigé sur les actions RSS et OPML ;
• le filtrage des schémas d’URL pour les pièces jointes et miniatures ;
• la suppression d’informations sensibles dans certains exports et partages publics ;
• le durcissement de la désérialisation des caches FreshRSS et SimplePie ;
• des comparaisons de jetons résistantes aux attaques temporelles ;
• des limites de longueur et de profondeur sur les recherches par expressions régulières.

La portée pratique dépend des fonctions activées et de l’exposition de l’instance. Une interface uniquement accessible par VPN réduit certains chemins, mais FreshRSS traite par définition du contenu et des URL fournis par des sources externes. L’absence de CVE publique pour chaque correction ne justifie pas de laisser traîner cette mise à jour.

Le changement le plus visible bloque par défaut les requêtes vers les réseaux locaux, y compris 127.0.0.1. Il limite la possibilité qu’une URL de flux ou une fonction de récupération soit détournée pour sonder des services internes. Il peut aussi interrompre un flux servi par un conteneur voisin, un NAS ou une application du LAN.

Avant la mise à jour, inventorier les abonnements qui ne pointent pas vers une adresse publique. Après la mise à jour, les exceptions peuvent être définies dans la configuration système ou avec INTERNAL_HOST_ALLOWLIST. Il vaut mieux autoriser quelques hôtes précis que rétablir l’ancien comportement avec *, explicitement qualifié de non sûr par le projet.

Pour une installation Docker, commencer par relever l’image réellement déclarée et son identifiant :

docker inspect freshrss \
  --format 'image={{.Config.Image}} id={{.Image}} status={{.State.Status}}'

Le nom du conteneur est à adapter. Après sa recréation, vérifier au minimum :

• le rafraîchissement d’un flux public et d’un éventuel flux interne ;
• la tâche planifiée d’actualisation ;
• les clients mobiles utilisant l’API Google Reader ou Fever ;
• les partages OPML et requêtes enregistrées utilisés par d’autres outils.

La version ajoute aussi la recherche et le filtrage des flux dans la vue globale, une recherche dans les journaux, un niveau de log configurable et des attestations de provenance et SBOM sur l’image Docker. Ces fonctions sont utiles, mais la raison de prioriser la 1.30.0 reste le lot de correctifs de sécurité.

Notes de publication FreshRSS 1.30.0

Jellyfin 12.0 : la sauvegarde est le seul vrai retour arrière

#

Jellyfin abandonne le préfixe historique 10. : ce qui aurait été 10.12 devient 12.0.0. Ce choix rend les futures versions majeures plus lisibles, mais peut casser les scripts, checks de supervision et règles de mise à jour qui attendent encore un numéro commençant par 10.

La migration demande surtout de respecter une séquence stricte. Jellyfin 12 modifie le schéma de base et réécrit des données au premier démarrage. Une fois cette opération terminée, remettre seulement l’ancienne image devant la base migrée n’est pas un rollback. Il faut restaurer la sauvegarde prise avant la mise à jour.

Les prérequis annoncés sont les suivants :

• partir de Jellyfin 10.10.7 ou d’une version 10.11.x ;
• si le serveur est plus ancien, passer d’abord par 10.10.7 ;
• arrêter Jellyfin puis sauvegarder manuellement les répertoires de données et de configuration ;
• vérifier qu’aucun compte utilisateur ne diffère d’un autre uniquement par les majuscules, car les noms deviennent insensibles à la casse ;
• retirer les plugins tiers, ceux compilés pour 10.11 n’étant pas compatibles avec 12.0 ;
• prévoir un scan complet de toutes les bibliothèques après la migration.

Sur Docker, cette commande permet de retrouver les chemins persistants à inclure dans la sauvegarde :

docker inspect jellyfin \
  --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

Il faut ensuite arrêter le service et sauvegarder les sources correspondant à la configuration et aux données. Le cache et les médias eux-mêmes n’ont pas le même rôle. Copier uniquement le fichier Compose ou le volume de cache ne permet pas de restaurer les utilisateurs, la base et les réglages.

Le premier scan sera nettement plus long qu’un scan habituel. Jellyfin reconstruit les associations automatiques entre versions et compare chaque élément avec les fichiers présents. Des films peuvent temporairement réapparaître comme récemment ajoutés. Interrompre le serveur pendant les migrations est à éviter. Les opérateurs qui veulent séparer cette phase du démarrage normal peuvent utiliser le nouveau mode --mode MigrateSystem, qui effectue la migration puis quitte.

Les anciens clients utilisant encore les chemins /emby/, /mediabrowser/ ou l’ancien mécanisme d’authentification cesseront de fonctionner. L’API change également sur plusieurs routes et le serveur cible désormais .NET 10 pour les plugins. Une instance partagée avec des téléviseurs ou clients peu maintenus doit donc être testée avant la bascule générale.

Le bénéfice n’est pas seulement visuel. Les collections et playlists passent à un stockage relationnel plus efficace, plusieurs écrans de bibliothèque deviennent plus rapides, les épisodes acceptent plusieurs versions, le support des livres et comics entre dans le serveur et l’interface Modern devient le choix par défaut sur desktop et mobile. La publication contient aussi plusieurs correctifs de sécurité sur l’accès aux fichiers, l’assistant initial, les paquets de plugins et les XSS du client web.

Jellyfin 12.0 et procédure de migration

Documentation Jellyfin sur la sauvegarde et la restauration

Bitwarden Lite peut enfin tourner sans root et avec une racine en lecture seule

#

La version self-hosted 2026.8.1 met à jour les composants Core et Web et intègre une contribution attendue depuis longtemps : le conteneur unique Bitwarden Lite peut maintenant fonctionner sous un UID/GID explicite, avec un système de fichiers racine en lecture seule et no-new-privileges.

Le périmètre est important. Cette évolution concerne Bitwarden Lite, anciennement nommé Unified, et non le déploiement classique composé de plusieurs conteneurs. Il ne faut pas copier mécaniquement les options sur l’ancienne stack en supposant que tous ses services écrivent déjà aux bons endroits.

L’image concentre les fichiers persistants sous /etc/bitwarden, déplace les écritures temporaires vers /tmp et conserve les journaux dans /var/log/bitwarden. L’exemple Compose de la release propose un bloc de durcissement commenté : il reste donc opt-in.

Pour l’activer correctement :

• créer deux bind mounts pour la configuration et les journaux ;
• donner ces répertoires à l’UID/GID utilisé par le conteneur, 999:999 dans l’exemple ;
• définir user: 999:999, read_only: true et no-new-privileges ;
• conserver /tmp en tmpfs avec les options noexec, nosuid et nodev ;
• sauvegarder et tester la restauration des répertoires et de la base avant de modifier la stack.

Il faut éviter de combiner le démarrage par PUID/PGID avec une racine en lecture seule. Dans ce mode, l’entrypoint démarre d’abord comme root pour créer l’utilisateur ou le groupe et doit écrire sous /run. Le Compose durci utilise directement user:, ce qui évite cette étape.

L’état réel d’un conteneur en cours d’exécution se contrôle sans afficher ses variables sensibles :

docker inspect bitwarden --format \
  'user={{json .Config.User}} readonly={{.HostConfig.ReadonlyRootfs}} security_opt={{json .HostConfig.SecurityOpt}}'

Une racine en lecture seule réduit les possibilités de persistance et les dégâts liés à certaines écritures arbitraires. Elle ne remplace ni les mises à jour, ni la MFA, ni une base correctement sauvegardée, ni la restriction de l’interface d’administration.

Bitwarden self-hosted 2026.8.1

Implémentation du mode rootless et read-only

Compose Bitwarden Lite 2026.8.1

Nextcloud 32 reçoit une maintenance et sort du support

#

Nextcloud publie trois versions de maintenance :

L’annonce mentionne des correctifs de fonctionnement, de stabilité et de sécurité, sans détailler de nouveaux scénarios publics. Il faut donc appliquer la maintenance sans inventer une vulnérabilité précise à partir de cette formulation générale.

Le point plus structurant concerne la série 32. Une branche EOL ne reçoit plus de correctifs communautaires, y compris de sécurité. Installer 32.0.15 remet l’instance au dernier niveau annoncé, mais ne constitue pas une cible durable. Il faut préparer le passage vers une branche encore suivie, en respectant le chemin de mise à niveau documenté et la compatibilité des applications.

Vérifier d’abord la version et l’état de maintenance avec occ :

sudo -u www-data php /var/www/nextcloud/occ status
sudo -u www-data php /var/www/nextcloud/occ app:list --shipped false

Les chemins et l’utilisateur sont à adapter aux paquets et conteneurs utilisés. L’inventaire des applications non livrées avec le serveur est important : une extension incompatible bloque plus souvent une montée de version qu’un changement du cœur lui-même.

Avant toute mise à niveau majeure, sauvegarder séparément la base, config/, les données et les applications ajoutées, puis tester la restauration. Sur un parc de plusieurs instances, traiter d’abord un clone représentatif permet aussi de mesurer la durée du mode maintenance et de voir les migrations réellement exécutées.

Maintenances Nextcloud de septembre 2026

Calendrier de support Nextcloud

Signaux de veille cette semaine

#

Ubuntu 24.04.5 LTS fournit de nouveaux médias d’installation. L’ISO cumule les mises à jour de sécurité et corrections importantes publiées depuis la précédente point release. Une machine 24.04 déjà maintenue n’a pas besoin d’être réinstallée pour devenir une « 24.04.5 » : le travail reste d’appliquer normalement les paquets et de redémarrer lorsque le noyau ou une bibliothèque chargée l’exige. Le média est surtout utile pour réduire le volume de mises à jour après une nouvelle installation.

OpenVPN 2.7.7 corrige plusieurs problèmes de sécurité. La release traite notamment un délai TLS fiable non borné, suivi sous CVE-2026-84732, ainsi que des défauts Windows autour du quoting de CreateProcess() et de l’appel à netsh.exe. La priorité dépend de la plateforme et du rôle client ou serveur. Sur une distribution stable, il faut vérifier l’avis du mainteneur du paquet avant de conclure qu’un numéro inférieur signifie forcément l’absence de rétroportage.

Uptime Kuma 2.5.4 ajoute un moniteur SFTP et corrige une dépendance vulnérable. Le projet met jsonata à niveau vers 2.2.2 pour CVE-2026-77415 et mentionne une faiblesse de déni de service. La release corrige aussi la fermeture des contextes du navigateur réel et plusieurs comportements de moniteurs. Une instance de supervision est souvent très connectée au réseau interne : sa mise à jour et la limitation de son exposition restent aussi importantes que les fonctions qu’elle surveille.

Papermerge cherche désormais des mainteneurs. Le développeur indique concentrer son travail sur l’offre Cloud après neuf ans de développement. Le dépôt self-hosted reste disponible et accepte toujours les contributions ; il n’est donc pas exact de le déclarer déjà abandonné. Pour une nouvelle installation, l’absence actuelle de responsable identifié doit néanmoins entrer dans le choix. Pour une instance existante, exporter les documents et tester une restauration en dehors de Papermerge réduit le risque de dépendre d’un projet sans cycle de maintenance prévisible.

Notifuse 40 passe de l’AGPL à la BSL 1.1. Les versions 39.x et antérieures restent définitivement sous AGPL. À partir de la 40, chaque version bascule vers l’AGPL quatre ans après sa publication. Sans clé, cinq fonctions de production sont limitées : plus de trois espaces, permissions granulaires, tenant Amazon SES, SSO OIDC et variantes multilingues. Les éléments existants ne sont pas supprimés, mais certaines créations ou modifications deviennent impossibles. Une instance utilisant le SSO doit notamment vérifier le chemin de connexion par code magique avant la mise à jour.

• Annonce Ubuntu 24.04.5 LTS
• OpenVPN 2.7.7
• Uptime Kuma 2.5.4
• Papermerge recherche des mainteneurs
• Licence Notifuse à partir de la version 40

Les pépites de la semaine

#

NextExplorer est un explorateur de fichiers web auto-hébergé, livré sous la forme d’une image unique. Il propose comptes locaux, groupes, OIDC, prévisualisation, édition, partages et recherche de contenu avec ripgrep. Son intérêt est clair pour fournir un accès contrôlé à quelques arborescences. Son niveau de privilège l’est aussi : un montage en lecture-écriture donne à l’application la capacité de modifier ou supprimer les fichiers correspondants. Il faut monter en lecture seule ce qui n’a pas besoin d’être édité, épingler une version d’image et ne pas exposer l’interface sans authentification forte.

Pluton ajoute une interface et un ordonnanceur autour de restic et rclone. Les dépôts restent des dépôts restic standards, accessibles avec les outils habituels, ce qui limite le verrouillage. L’interface ne dispense pas des contrôles classiques : monter les sources en lecture seule, conserver la clé de chiffrement hors de l’instance, exécuter restic check selon une fenêtre maîtrisée et surtout restaurer régulièrement quelques fichiers puis une machine complète.

PostgreSQL Migrator 1.0 vise les migrations Oracle et MySQL/MariaDB vers PostgreSQL. Cette première version stable inspecte et convertit rôles, schémas, séquences, tables, index et contraintes, puis transfère les données avec COPY. Les vues, triggers et partitions sont encore sur la feuille de route. Les débits annoncés par l’éditeur doivent être reproduits sur ses propres types, LOB, volumes et contraintes ; une migration de test et une procédure de retour arrière restent indispensables avant toute bascule.

• NextExplorer
• Pluton
• PostgreSQL Migrator 1.0

Commande du jour

#

docker inspect bitwarden --format \
  'user={{json .Config.User}} readonly={{.HostConfig.ReadonlyRootfs}} security_opt={{json .HostConfig.SecurityOpt}}'

Cette commande lit la configuration effective du conteneur. Pour le Compose durci de Bitwarden Lite, le résultat doit montrer un utilisateur non vide, readonly=true et une option no-new-privileges.

Elle permet de vérifier ce qui tourne, pas ce qui est seulement écrit dans un fichier Compose. Un changement de configuration sans recréation du conteneur ne modifie pas ces valeurs. Elle ne vérifie pas non plus les droits des volumes persistants ni le contenu du tmpfs, qui doivent être contrôlés séparément.

Conclusion

#

Un Proxmox VE supporté et à jour n’est pas concerné par CVE-2023-54391. En revanche, une branche 7.x encore exposée demande une isolation, une recherche de compromission et une migration, pas seulement l’application tardive d’un paquet. C’est le seul sujet de la semaine qui justifie de bousculer immédiatement un planning lorsque les conditions d’exposition sont réunies.

FreshRSS 1.30.0 mérite ensuite une mise à jour rapide, précédée d’un inventaire des flux internes pour ne pas neutraliser le nouveau contrôle SSRF avec une exception trop large. Jellyfin 12 demande une fenêtre plus longue et une sauvegarde restaurable. Le mode rootless de Bitwarden améliore utilement la défense en profondeur, tandis que Nextcloud 32 doit désormais être considéré comme une étape transitoire vers une branche maintenue.

Sources

#

• Proxmox - PSA-2026-00043-1
• CVE-2023-54391
• Proxmox - commit ayant fermé le chemin vulnérable
• FreshRSS 1.30.0
• Jellyfin 12.0
• Jellyfin - sauvegarde et restauration
• Bitwarden self-hosted 2026.8.1
• Bitwarden - mode rootless et read-only
• Bitwarden Lite - exemple Compose 2026.8.1
• Nextcloud - maintenances de septembre 2026
• Nextcloud - calendrier de support
• Ubuntu 24.04.5 LTS
• OpenVPN 2.7.7
• Uptime Kuma 2.5.4
• Papermerge - recherche de mainteneurs
• Notifuse - politique de licence
• NextExplorer
• Pluton
• PostgreSQL Migrator 1.0