GitLab a sorti hier (lundi 17 août), un correctif d'urgence , complètement en dehors de son calendrier habituel, pour une faille qui permet à quelqu'un sans compte ni mot de passe de modifier ou de supprimer vos projets publics et des données utilisateur. Hé ouais c'est chaud et c'est pour ça que son score CVSS est de 9,4 sur 10.

5 jours plus tôt, le 12 août, GitLab publiait son patch de routine pour la 19.2, 19.1 et 19.0. C'est un périmètre normal puisque sa politique de maintenance ne couvre que la version stable et les deux précédentes. Mais comme là, on est dans l'exceptionnel, ce correctif du 17 août en couvre une quatrième, la 18.11, dont le support avait pris fin le 16 juillet dernier. Ils sont allés rouvrir une branche morte juste pour patcher ce GROS problème !

La faille elle-même, on n'en sait presque rien par contre. Estampillée CVE-2026-19478, c'est une histoire de directive GraphQL, mais GitLab ne dit ni laquelle, ni dans quelles conditions ça se déclenche. Les détails techniques sortiront vers la mi-novembre, c'est-à-dire 90 jours après le correctif, comme d'habitude, histoire d'être sûr que tout le monde ait patché son install.

Maintenant, la bonne nouvelle c'est que si vous êtes sur GitLab.com ou sa version Dedicated , vous n'avez rien à faire, puisque c'est déjà patché. En fait cette histoire ne concerne que les instances auto-hébergées.

Et parmi elles, tout le monde n'est pas impacté de la même manière. En effet, le vecteur d'attaque passe par le réseau et vise les projets publics. Cela veut dire que votre instance planquée derrière un VPN, sans visibilité publique, risque beaucoup moins que celle qui expose ses dépôts à Internet.

Ensuite, pour la mise à jour, ça dépend d'où vous partez. Entre la 18.2 et la 18.10, aucun correctif n'existe sur votre branche. Il faudra upgrader jusqu'à la 18.11.11, en vous arrêtant aux paliers de 18.5 et 18.8 s'ils sont sur votre route.

Si vous tournez déjà en 18.11, prenez la 18.11.11. Sur une 19, c'est 19.0.8, 19.1.6 ou 19.2.4. Et plus ancien que 18.2 ? Bah là, GitLab ne liste pas ces versions parmi les affectées, mais elles ne reçoivent plus de correctif depuis un bon moment, donc ce serait bien de mettre à jour quand même, hein...

Pour le moment, personne n'a signalé d'attaque et aucun exploit ou PoC n'a fait surface sur GitHub. Ça ne veut pas dire grand-chose, je vous l'accorde mais on se rassure comme on peut...

Allez, bon courage !

Source : The Hacker News

Cloudflare Computer est un projet qui donne à votre agent IA un endroit rien qu'à lui. C'est-à-dire un vrai système de fichiers, avec des dossiers, des fichiers qui restent, et de quoi lancer des commandes dedans. Bref, un vrai poste de travail que l'agent garde entre deux sessions, au lieu de repartir de zéro à chaque fois, puisque tous les fichiers sont rangés dans une base SQLite.

Le système de fichiers s'utilise ensuite comme n'importe quel autre. Lire, écrire, créer un dossier, lister, supprimer, et un grep intégré pour fouiller dans le tas. Pour tout le reste, il n'y a qu'une fonction à retenir, exec(). Vous lui passez une commande, et elle vous rend la sortie et le code de retour.

Ce qui change par contre, c'est l'endroit où la commande tourne. 3 environnements sont disponibles et interchangeables sur les mêmes fichiers. Il y a d'abord un conteneur Linux complet, avec npm, node et de vrais binaires. Ou un shell léger pour les commandes simples. Et enfin, un dernier qui exécute directement votre code, sur une base neuve à chaque appel.

Comme ça, vous passez de l'un à l'autre sans réécrire une ligne de votre agent.

Les 9 exemples fournis montrent bien ce qu'on peut en tirer quand on aime bidouiller. Le plus parlant fait par exemple tourner un agent de discussion qui prendra l'espace de travail comme répertoire courant, donc qui travaillera dans de vrais fichiers au lieu de tout garder en mémoire.

Un autre colle pandoc dans le conteneur et laisse l'agent transformer une fiche markdown en PDF. Il y en a aussi un qui fabrique des images avec Workers AI, un quatrième joue sur les politiques de sortie réseau pour décider ce que l'agent a le droit de joindre, et enfin, un dernier génère un projet Worker complet, puis le publie.

Il y a même une interface web qui balance la même tâche dans le conteneur et dans un environnement léger, côte à côte.

Reste à savoir ce qui est gratuit là-dedans... Le code est sous licence MIT, et le système de fichiers seul, sans aucune exécution, tourne sans souci dans le plan Workers gratuit puisque les Durable Objects qui portent ce stockage y sont inclus, avec 100 000 requêtes par jour et 5 Go d'espace.

Il faut un compte Cloudflare, évidemment...

Puis si vous voulez faire tourner des vraies commandes ou avoir un shell, faudra payer puisque le conteneur comme les environnements légers réclament le plan Workers payant, facturé 5 dollars par mois au minimum.

Après j'ai quelques réserves quand même parce que le projet est très récent, encore en preview et clairement inadapté à de la production. Ensuite, la limite technique d'un espace de travail tourne autour de 10 Go, et les accès disque lourds restent plus lents que sur un vrai disque. Puis surtout, tout vit chez Cloudflare, et pas chez vous (si vous préférez l'inverse, je vous avais montré workerd , le moteur des Workers en local).

Mais bon, c'est à garder à l'œil si vous êtes client Cloudflare.

Source

Gérer un serveur à la main, c'est nginx à configurer, les certificats à renouveler, les sauvegardes à planifier et les conteneurs à surveiller... C'est beaucoup de travail. Mais vous allez avoir de l'aide grâce à DockPanel, d'Ovidiu Drobotă, qui met tout ça derrière une jolie interface web tenant dans 19 Mo de RAM.

L'installation se colle en une ligne sur un VPS frais et vous récupérez un panneau d'admin sur le port 8443. Ubuntu, Debian, Rocky, Fedora ou Amazon Linux, en x86_64 comme en ARM64.

À partir de là vous créez des sites en PHP, Node ou Python, avec nginx configuré tout seul et les certificats Let's Encrypt qui se renouvellent sans y penser. Les bases MySQL et PostgreSQL vont avec, navigateur SQL intégré et restauration à un instant T via les journaux binaires.

Ensuite, c'est surtout le catalogue Docker qui fait le gros du travail. Environ 150 modèles en un clic répartis sur 14 catégories, WordPress, Postgres, Grafana, n8n ou Immich, et le reverse proxy, le SSL et le réseau se câblent automatiquement derrière. Les conteneurs inactifs peuvent même se mettre en veille tout seuls pour libérer la machine.

Je vous parlais l'an dernier de Coolify pour le déploiement en self-hosted , et avant ça de aaPanel, le clone gratuit de cPanel mais aucun des deux ne couvre autant de terrain.

Côté déploiement, vous poussez votre code et ça part en production, avec bascule atomique par lien symbolique et retour arrière en un clic quand le déploiement du vendredi tourne mal. Nixpacks reconnaît plus de 30 langages, donc pas de Dockerfile à écrire, et chaque branche peut avoir son environnement de préversion.

Il y a aussi un serveur mail complet, Postfix, Dovecot et DKIM, avec Roundcube en webmail et Rspamd contre le spam. La partie DNS pilote Cloudflare et PowerDNS, avec vérification de propagation, DNSSEC et les tunnels Cloudflare. Un module CDN gère BunnyCDN et Cloudflare, purge du cache comprise.

Pour la surveillance, des sondes HTTP, TCP et ping, une gestion d'incidents avec chronologie et post-mortem, une page de statut publique à laquelle vos utilisateurs peuvent s'abonner, et des alertes qui partent sur Slack, Discord ou PagerDuty. Un point de collecte Prometheus est dispo, avec un tableau Grafana prêt à importer.

La sécurité est activée par défaut avec pare-feu applicatif ModSecurity par site, Fail2Ban, durcissement SSH en un clic, connexion par passkey ou 2FA, et chaque image Docker déployée peut être scannée à la recherche de CVE avec grype, avec refus de déploiement au-dessus du seuil que vous fixez. Les sauvegardes passent par Restic, chiffrées et dédupliquées, vers S3, SFTP, B2 ou GCS, avec vérification de restauration.

Le reste ensuite, c'est que du confort. Terminal web avec enregistrement de session, gestionnaire de fichiers, palette de commandes en Ctrl+K, 6 thèmes, boîte à secrets chiffrée, passerelle à webhooks et une ligne de commande. La configuration complète s'exporte en YAML pour être rejouée ailleurs. Si vous gérez plusieurs machines, un seul panneau les pilote toutes, avec des comptes revendeur en marque blanche pour ceux que ça intéresse.

Deux choses à savoir avant de lancer l'installation quand même... En mars, une injection de commande dans le formulaire de création de site a permis à un visiteur de passer root sur la machine de l'auteur. C'est corrigé depuis, mais l'agent tourne en root par conception puisque c'est lui qui touche à Docker, à nginx et aux certificats.

L'autre point, c'est la licence. DockPanel est en Business Source License 1.1, ce qui n'est pas de l'open source même si la page d'accueil le présente comme ça. L'usage est libre et gratuit sur vos propres serveurs, mais la revente en service hébergé est interdite. Une bascule en MIT est quand même programmée pour mars 2030.

Voilà, je me suis dit que ça pourrait vous intéresser.

Source

On reçoit tous des mails un peu bizarres avec des liens qu'on n'ose pas ouvrir, et pourtant on est curieux, on est tenté parfois... C'est difficile de résister mais heureusement l'équipe de Linuxserver.io a pondu un truc super pour ça.

Il s'agit tout simplement d'une instance de Firefox qui tourne dans un conteneur Docker et qui est totalement pilotable depuis votre navigateur habituel.

Comme ça, quand vous recevez un lien louche que vous voulez ouvrir, vous le mettez là-dedans, dans une session jetable qui est totalement coupée de votre vraie machine. Et comme ça, si ça part en couille, vous butez le conteneur et on n'en parle plus.

Voilà, ça se présente juste comme une page HTTPS avec un navigateur dedans. Et comme c'est LinuxServer qui maintient l'image, vous êtes tranquilles parce que c'est du sérieux.

L'avantage d'avoir ce truc, c'est qu'un Firefox en conteneur ne voit ni votre répertoire personnel, ni vos cookies, ni vos sessions Google, ni vos extensions, absolument rien, il est totalement isolé. Donc si un site tente un drive-by download ou un exploit navigateur, eh bien en principe les dégâts resteront coincés dans le conteneur. Et le simple fait de le redémarrer remettra tout à 0.

Attention quand même, un conteneur, ce n'est pas une machine virtuelle. Une vulnérabilité au niveau du noyau pourrait en théorie s'en échapper. Mais c'est pas le genre d'attaque qui se fait avec juste un clic douteux sur une page web.

Les chercheurs en sécu s'en servent pour ouvrir des pièces jointes chelou, les marketeux pour jongler avec 12 comptes ad sans cookie cross-tracking , et les paranos dans mon genre pour cliquer sur les liens des mecs bizarres de Discord sans rien flinguer chez eux..

Après y'a des petits inconvénients. Je pense aux perfs graphiques qui prennent une claque par rapport à un Firefox natif ou encore l'audio qui transite par le pipeline du navigateur, du coup ça crachote parfois sur les vidéos lourdes. Le copier-coller marche, mais en passant par la section presse-papiers de la barre latérale Selkies , pas en direct. Et la persistance ne tient que si vous mappez le volume /config comme il faut, sinon vos onglets et vos bookmarks gicleront dès que le conteneur sera recréé (à la première mise à jour d'image, typiquement).

Côté vie privée c'est plutôt une qualité mais pour un usage quotidien, ça peut devenir relou.

Installation en une commande

L'image officielle, c'est lscr.io/linuxserver/firefox:latest. Elle tourne sur Selkies depuis juin 2025 (avant c'était KasmVNC) et démarre en Wayland par défaut depuis mars 2026. Maintenant, si un site part en vrille à cause de ça, vous ajoutez le paramètre PIXELFLUX_WAYLAND=false à la commande Docker et vous serez de retour en X11.

La commande minimale ressemble à ça :

docker run -d \
--name=firefox \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Europe/Paris \
-e LC_ALL=fr_FR.UTF-8 \
-p 3001:3001 \
-v $HOME/firefox-config:/config \
--shm-size=1gb \
--restart unless-stopped \
lscr.io/linuxserver/firefox:latest

Le --shm-size=1gb, c'est la mémoire partagée de Docker et vous n'y couperez pas, désolé. Si vous le zappez, YouTube comme les sites un peu lourds vous planteront le navigateur. Le port 3001, c'est l'accès HTTPS, avec un certificat auto-signé qui fera râler votre Firefox principal (c'est normal, faut l'accepter). Y'a aussi un port 3000, mais lui c'est du HTTP en clair, à réserver derrière un reverse proxy genre SWAG et rien d'autre.

Ensuite, direction https://localhost:3001/ et un joli Firefox vous attend. Notez que par défaut, il n'y a AUCUNE authentification. Personne ne vous demande rien, alors si vous voulez l'exposer sur votre réseau, définissez bien un CUSTOM_USER et PASSWORD pour activer le basic auth avant qu'un petit malin de votre réseau ne tombe dessus.

La version docker-compose, plus propre

Envie d'un setup versionnable, que vous pouvez reproduire ailleurs sans réfléchir ? Le compose fait ça mieux :

---
services:
firefox:
image: lscr.io/linuxserver/firefox:latest
container_name: firefox
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Paris
- LC_ALL=fr_FR.UTF-8
- CUSTOM_USER=korben
- PASSWORD=changezmoi
- HARDEN_DESKTOP=true
- HARDEN_OPENBOX=true
volumes:
- ./firefox-config:/config
ports:
- 3001:3001
shm_size: "1gb"
restart: unless-stopped

Ensuite, un docker compose up -d et roulez jeunesse. Le volume ./firefox-config conserve votre profil entre deux redémarrages avec bookmarks, extensions installées depuis le store Mozilla, tout reste en place.

Et si vous avez envie de repartir de zéro, on met le dossier à la poubelle, on relance, et voilà. Et pour glisser des outils tiers dans le conteneur (filezilla, un éditeur, ce genre de bidule), [proot-apps install](https://github.com/linuxserver/proot-apps) les posera dans $HOME, où ils survivront aux mises à jour de l'image.

Le hardening qu'il faut absolument activer

Maintenant, le piège que la doc évoque du bout des lèvres et qui mérite d'être écrit en gros c'est que l'interface web embarque un terminal avec sudo passwordless . Traduction : quiconque accède à votre Firefox conteneurisé devient root dans le conteneur en deux clics. Exposez ça sur votre réseau, ou pire sur Internet, sans durcir le machin, et vous ouvrez un boulevard.

La parade tient en une variable : **HARDEN_DESKTOP=true**, qui pose les principaux verrous d'un coup. Ça coupe sudo, ça vire les terminaux, et ça bloque xdg-open et exo-open, qui pourraient lancer des trucs hors conteneur. Vous pouvez empiler ça avec HARDEN_OPENBOX=true par-dessus, histoire de neutraliser les raccourcis clavier dangereux genre Alt+F4, de désactiver le clic droit et de masquer le bouton de fermeture. Firefox reste parfaitement utilisable, mais impossible de s'évader pour faire mumuse avec le système derrière.

Et pour une exposition sur Internet, le basic auth CUSTOM_USER/PASSWORD ne suffira pas car c'est trop léger. Moi ce que je vous recommande, c'est de coller le tout derrière un reverse proxy SWAG avec une vraie couche OAuth2 ou Authelia. Le basic auth, gardez-le pour le LAN entre potes ou collègues de confiance, mais pas au-delà.

SealSkin, le bonus qui change tout

SealSkin , c'est la cerise sur le conteneur ^^. C'est une extension navigateur, dispo pour Chrome et Firefox, qui monte la garde sur votre navigateur principal et détourne ce qui sent mauvais vers le conteneur isolé. Un lien repéré comme suspect ? Hop, il s'ouvre direct dans le Firefox conteneurisé. Pareil pour les téléchargements, qui atterrissent dans le conteneur au lieu de finir sur votre machine.

Du coup, l'isolation devient un réflexe permanent au lieu d'un machin que vous activez à la main quand vous y pensez (c'est-à-dire jamais). Seule contrainte par contre, faudra héberger le serveur SealSkin vous-même, et installer l'extension dans votre vrai Firefox. Mais vous verrez, après quelques jours à ce régime, vous aurez du mal à faire autrement.

Et sur tablette ou mobile ?

J'imagine que vous comptiez sur l'ancien tag kasm pour le tactile ? Eh bien c'est raté, puisque LinuxServer l'a déprécié début juillet. En échange, la barre latérale Selkies embarque désormais un trackpad virtuel et un clavier à l'écran, donc de quoi rendre l'interface utilisable depuis un iPad ou un smartphone sans bidouille en plus. On reste loin, c'est vrai, du confort d'un vrai desktop, et taper Ctrl+Tab au doigt c'est toujours la misère, mais pour dépanner ça fait le job.

Et voilà, votre Firefox jetable vit désormais dans son petit conteneur, bien au chaud. Comme ça, le prochain lien douteux, vous l'ouvrirez sans trembler... pour tester des sites au calme, difficile de trouver mieux, je pense.