Korben
Une faille présente depuis 18 ans découverte dans nginx, le serveur qui fait tourner un tiers du web
Nginx, c'est ce logiciel discret qui sert les pages d'environ un site populaire sur trois sur la planète. Quand vous chargez une page web, il y a une bonne chance que ce soit lui qui vous l'envoie. La société DepthFirst AI, spécialisée dans la recherche de failles assistée par intelligence artificielle, vient d'y trouver un trou de sécurité, et il est plutôt balèze : présent dans le code depuis 2008. Soit environ 18 ans de service sans que personne ne le remarque. La faille (référencée CVE-2026-

Une faille présente depuis 18 ans découverte dans nginx, le serveur qui fait tourner un tiers du web

Par : Vincent Lautier

15 mai 2026 à 10:54

Nginx, c'est ce logiciel discret qui sert les pages d'environ un site populaire sur trois sur la planète. Quand vous chargez une page web, il y a une bonne chance que ce soit lui qui vous l'envoie.

La société DepthFirst AI, spécialisée dans la recherche de failles assistée par intelligence artificielle, vient d'y trouver un trou de sécurité, et il est plutôt balèze : présent dans le code depuis 2008. Soit environ 18 ans de service sans que personne ne le remarque.

La faille (référencée CVE-2026-42945, le système de numérotation officiel des vulnérabilités) est notée 9,2/10 sur l'échelle de gravité, ce qui la classe en critique. Concrètement, elle vit dans un module précis de nginx qui gère la réécriture d'URL, et elle se déclenche quand deux instructions de configuration ("rewrite" et "set") sont utilisées en même temps.

C'est un débordement de mémoire tampon, c'est-à-dire que des données débordent dans une zone qu'elles ne devraient pas occuper. Quand on contrôle ce débordement, on peut faire planter le serveur, voire dans certains cas exécuter son propre code à distance sur la machine.

Pour le déni de service (DoS), c'est-à-dire faire tomber le serveur, l'exploitation est démontrée et fonctionne. Pour l'exécution de code à distance, c'est plus délicat : les chercheurs y arrivent uniquement quand une protection mémoire appelée ASLR est désactivée, ce qui n'est pas le cas par défaut sur les systèmes modernes. Bonne nouvelle relative, donc, mais ça reste à prendre très au sérieux.

Côté correctifs, les versions à installer sont nginx Open Source 1.31.0 ou 1.30.1, et NGINX Plus R36 P4 pour les clients commerciaux. Toutes les versions précédentes depuis 0.6.27 sont vulnérables, donc autant dire à peu près tout ce qui tourne en production aujourd'hui.

Si vous administrez un serveur, c'est le moment de regarder ce qui tourne dessus et de patcher rapidement. Les exploits publics ont une fâcheuse tendance à apparaître quelques jours après les divulgations de ce genre.

Le détail qui pique, c'est la méthode de découverte. DepthFirst AI utilise l'intelligence artificielle pour faire de l'analyse de code à grande échelle, en cherchant des motifs suspects que des outils classiques ne repèrent pas. Le fait qu'une faille planquée dans nginx depuis dix-huit ans soit sortie comme ça donne une idée de ce qui dort encore dans tout le code qu'on utilise au quotidien.

Source : Bleeping Computer

Korben
Nginx Proxy Manager - Le reverse proxy que même ma grand-mère pourrait configurer
L'autre jour, je voulais juste exposer un petit service tournant sur mon NAS pour y accéder à distance quand je suis en déplacement. Alors je me suis dit "Allez, je vais faire ça propre avec Traefik" mais bon, debugger du fichier YAML parce qu'on oublie des indentations à un moment ça casse la tête. J'ai +40 balais et pas que ça à foutre. Si vous hébergez vos propres services à la maison (self-hosting powaaaah !) et que vous êtes un peu bordélique comme moi, vous installez un truc, puis un autre

Nginx Proxy Manager - Le reverse proxy que même ma grand-mère pourrait configurer

Korben

Par : Korben

3 février 2026 à 08:48

L'autre jour, je voulais juste exposer un petit service tournant sur mon NAS pour y accéder à distance quand je suis en déplacement. Alors je me suis dit "Allez, je vais faire ça propre avec Traefik" mais bon, debugger du fichier YAML parce qu'on oublie des indentations à un moment ça casse la tête. J'ai +40 balais et pas que ça à foutre.

Si vous hébergez vos propres services à la maison (self-hosting powaaaah !) et que vous êtes un peu bordélique comme moi, vous installez un truc, puis un autre, et vous finissez avec une collection de ports impossible à mémoriser du genre monip:8080, monip:32400, monip:9000… Aarrgh, l'enfer !!!

Et ne me lancez pas sur la gestion des certificats SSL !! Si vous voulez faire ça bien, faut générer des certificats Let's Encrypt à la main pour chaque service, modifier les fichiers de conf Nginx en priant pour ne pas oublier un point-virgule… et j'en passe et des pas mûres… Alors je sais, oui ça nous occupe et pendant ce temps là, on n'est pas dehors en train de voler des voitures mais j'sais pas vous, moi j'ai mieux à faire.

Hé bien, figurez-vous les copains, qu'il existe un outil qui transforme ce cauchemar en promenade de santé. Ça s'appelle Nginx Proxy Manager, et une fois que vous aurez lu mon article et testé vous penserez : "Mais pourquoi je me suis emmerdé la vie pendant tout ce temps, mortecouille ?!".

Nginx Proxy Manager, c'est quoi ce truc ?

En gros, c'est une interface graphique super propre pour gérer Nginx. Au lieu de taper des lignes de commandes et d'éditer des fichiers de config obscurs, vous avez un beau tableau de bord pour :

Rediriger vos domaines (ex: plex.mondomaine.fr) vers vos conteneurs Docker.
Gérer vos certificats SSL (HTTPS) automatiquement.
Sécuriser l'accès à certains services avec un mot de passe.

Mais en vrai, c'est plus riche que ça. Dans la barre du haut, vous avez tout ce qu'il faut pour piloter votre reverse proxy comme un adulte responsable : des hosts (proxy, redirections, streams, 404), des certificats (Let's Encrypt ou certifs locaux), des utilisateurs, des règles d'accès (Access Lists), et même des logs d'audit pour savoir qui a fait quoi (au cas où un de vos potes "teste un truc vite fait" et casse tout).

C'est le reverse proxy pour ceux qui veulent que ça marche, tout de suite, sans devenir ingénieur réseau bac+12 ou devoir se taper 2h d'explications IRL d'un barbu qui pue de la gueule ^^.

Installation en 3 minutes chrono (avec Docker)

Bon, on ne va pas y passer la nuit. La méthode la plus propre, c'est évidemment Docker Compose. Si vous ne l'avez pas, installez-le (allez, un petit apt install docker-compose et on n'en parle plus).

Créez un dossier nginx-proxy-manager et collez-y ce fichier docker-compose.yml :

version: '3.8'
services:
 app:
 image: 'jc21/nginx-proxy-manager:latest'
 restart: unless-stopped
 ports:
 - '8080:80' # Port HTTP public
 - '8181:81' # Port d'administration (à garder pour vous)
 - '8443:443' # Port HTTPS public
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt
 db:
 image: 'jc21/mariadb-aria:latest'
 restart: unless-stopped
 environment:
 MYSQL_ROOT_PASSWORD: 'npm'
 MYSQL_DATABASE: 'npm'
 MYSQL_USER: 'npm'
 MYSQL_PASSWORD: 'npm'
 volumes:
 - ./mysql:/var/lib/mysql

Petit piège à éviter : Faites gaffe si vous avez déjà un serveur web (Apache ou Nginx) qui tourne sur la machine hôte. Il va falloir couper le service ou changer les ports, sinon Docker va vous jeter une erreur parce que le port 80 est déjà pris. Du coup, vérifiez bien avec un petit netstat -tulpn | grep 80 avant de lancer la sauce.

Ah oui, et si vous utilisez un pare-feu comme UFW (ce que je vous recommande chaudement), n'oubliez pas d'ouvrir le port 81 : ufw allow 81. Sinon, vous allez pleurer devant une page blanche et vous demander pourquoi ça marche pas.

Ensuite, lancez la bête :

docker-compose up -d

Et voilà ! C'est tout. Votre serveur tourne. Si vous avez des erreurs, c'est probablement parce que vos ports sont déjà utilisés. Ou que les dossiers data, Let's Encrypt et MySQL n'existent pas encore. Moi j'ai ça sur mon NAS :

La configuration que même ma grand-mère pourrait le faire

Ouvrez votre navigateur et allez sur http://votre-ip:8181 et créez vous un compte.

Une fois dedans, pour exposer un service, c'est ridicule tellement c'est easyyyy

Cliquez sur "Add Proxy Host".
Entrez votre nom de domaine (ex: nextcloud.mondomaine.fr).
Indiquez l'IP de la machine et le port du service (ex: 8080).
Allez dans l'onglet "SSL", cochez "Request a new SSL Certificate" et "Force SSL".
Sauvegardez.

En fait, le seul truc qui peut coincer, c'est la propagation DNS. Si vous venez d'acheter votre nom de domaine il y a 5 minutes, pas de panique si Let's Encrypt refuse de générer le certificat. Attendez une petite heure et réessayez. C'est classique.

Et hop, fini. Votre service est accessible en HTTPS, avec le petit cadenas vert qui va bien. Nginx Proxy Manager s'occupe de discuter avec Let's Encrypt et de renouveler le certificat tout seul. C'est carrément magique.

Tour d'horizon des fonctionnalités qui sauvent des week-ends

Parce que oui, Nginx Proxy Manager ne fait pas "juste" proxy + "cadenas". Dans le menu Hosts, vous avez plusieurs types de trucs à créer, et chacun sert à un usage bien précis. Et côté Certificats et sécurité, il y a de quoi faire sans sortir le marteau-piqueur.

Certificats Let's Encrypt (HTTP et DNS) + certifs locaux

On va commencer par le sujet qui donne des boutons : les certificats. Dans l'onglet Certificates, vous pouvez gérer tout ça au même endroit :

Let's Encrypt en HTTP-01 : le classique. NPM ouvre la voie, répond au challenge, et basta. Pratique pour un service.mondomaine.fr exposé "normalement".
Let's Encrypt en DNS-01 : là, c'est le mode "j'ai compris la vie". Vous pouvez valider le certificat via votre DNS (donc sans dépendre d'un port 80 accessible), et surtout ça permet les wildcards du style *.mondomaine.fr. Donc un seul certif et roule ma poule, même si vous ajoutez 12 sous-domaines demain à 3h du mat.
Certificats locaux : vous pouvez aussi importer un certificat existant (genre un certif de votre boîte, un truc interne, un CA maison, ou même un self-signed si vous aimez vivre dangereusement). Ça évite de dépendre de Let's Encrypt si vous êtes en mode "tout en local, rien sur Internet".

Et le meilleur c'est que NPM gère le renouvellement automatique. Donc plus de rappel calendrier "renouveler les certifs" tous les 2 mois, sinon c'est le drame et tout le monde vous écrit "ça marche plus ton truc".

Plusieurs comptes, parce que tout le monde n'est pas "admin"

Dans Users, vous pouvez créer plusieurs comptes pour accéder à l'interface. Typiquement :

un compte admin pour vous, le chef, le patron, le seigneur des reverse proxies.
un compte "moins dangereux" pour quelqu'un qui doit juste consulter ou bidouiller un truc sans toucher à toute l'infra.

Et ça, couplé aux Audit Logs (j'y reviens juste après), c'est très pratique quand plusieurs personnes mettent les mains dedans. Parce que "c'est pas moi, j'ai rien touché" est une phrase universelle, on la retrouve dans toutes les cultures.

Access Lists, le videur à l'entrée

Alors ça, c'est une des fonctions les plus sous-cotées. Les Access Lists permettent de mettre en place des règles d'accès et de les réutiliser partout :

Basic Auth (login/mot de passe) : parfait pour protéger une appli pas prévue pour être publique, ou un petit outil d'admin que vous ne voulez pas exposer "en clair".
Allow/Deny par IP : le top pour dire "seulement depuis mon IP / mon VPN / mon réseau". Et là, même si quelqu'un devine votre URL, il se prend un mur.

Vous créez une Access List une fois, et ensuite vous l'appliquez à vos Proxy Hosts. Du coup, pas besoin de refaire 50 fois la même conf. C'est propre, c'est net, c'est carré.

Les redirections propres (HTTP -> HTTPS, domaine A -> domaine B, etc.)

Besoin de rediriger un vieux domaine vers un nouveau ? Ou de faire un joli http:// qui part systématiquement en https:// ? Les Redirection Hosts servent exactement à ça. C'est bête mais ça évite d'aller trifouiller des règles Nginx à la main.

Exemples typiques :

mondomaine.fr -> www.mondomaine.fr
ancientruc.mondomaine.fr -> nouveautruc.mondomaine.fr
http -> https (pour les retardataires)

Streams - Quand ce n'est pas du HTTP mais que vous voulez quand même un reverse proxy

Le web, c'est bien, mais tout n'est pas en HTTP. Certaines applis parlent en TCP/UDP (bases de données, services réseau, protocoles chelous, etc.). C'est là que Streams entrent en jeu. Cette fonctionnalité vous permet de proxyfier des flux réseau, genre "ce port externe pointe vers ce port interne".

Alors oui, c'est plus "brut" que les Proxy Hosts, mais ça dépanne vraiment quand vous avez un service qui n'a rien à faire derrière un vhost HTTP. Et ça se configure aussi en 2 clics, sans incantations démoniaques.

404 Hosts - La sortie de secours

Les 404 Hosts, c'est la petite finition qui fait plaisir (non, rien à voir avec votre salon de massage préféré). Vous pouvez définir un "host poubelle" qui répond proprement quand quelqu'un tape un domaine qui n'existe pas chez vous, ou quand un bot scanne votre serveur en espérant trouver /phpmyadmin par magie.

Au lieu de laisser traîner une réponse moche ou ambiguë, vous renvoyez une 404 nette, propre, assumée. C'est pas de la sécurité absolue, mais c'est une bonne hygiène, et ça évite de donner trop d'infos aux curieux.

Audit Logs

Dans Audit Logs, vous avez l'historique des actions effectuées dans l'interface : création/modif de hosts, changements de certifs, etc. C'est le genre de truc dont on se fout… jusqu'au jour où on en a besoin. Et là, vous êtes content de pouvoir remonter le film de l'horreur.

Et enfin, mon bonus : Le mode "je sais ce que je fais" (les options avancées Nginx)

Et si un jour vous voulez aller un cran plus loin, NPM permet aussi d'ajouter des réglages plus "Nginx pur jus" par host (headers, règles, conf custom). Donc vous commencez en mode clic-clic, et si vous devenez un peu psycho sur l'optimisation, vous pouvez aussi affiner. Sans tout casser, normalement.

2/3 conseils de daron pour éviter les boulettes

Ne laissez pas l'admin ouvert au monde : le port 8181 (ou votre port d'admin) c'est "pour vous". Si possible, limitez-le via pare-feu / VPN / IP autorisées. C'est le panneau de commande de votre château, pas un distributeur de bonbons.
Utilisez les Access Lists pour tout ce qui est sensible : dashboards, outils d'admin, services pas prévus pour Internet, etc.
Pensez au DNS-01 si vous voulez des wildcards ou si vous n'avez pas envie d'exposer le port 80.

Et par rapport aux autres ?

Je vous vois venir les puristes : "Oui mais Traefik c'est mieux car c'est dynamique". C'est vrai. J'ai testé Traefik, et c'est une tuerie pour les environnements qui bougent tout le temps. Mais sa config en YAML peut vite devenir une usine à gaz si vous débutez. Caddy est top aussi (un seul fichier de conf), mais il faut quand même mettre les mains dans le cambouis.

Perso, je pense que Nginx Proxy Manager est un excellent choix pour un homelab par exemple. C'est un peu le choix du confort, celui des grosses feignasses comme moi parce que c'est visuel, c'est du clic-bouton clic clic, et pour un petit serveur perso, c'est franchement imbattable.

Bref, si vous galérez encore avec vos vhosts Nginx, arrêtez de vous faire du mal. Installez ça, et profitez de la vie (et de vos week-ends).

Nginx Proxy Manager c'est par ici !

Korben
Comment bloquer les crawlers IA qui pillent votre site sans vous demander la permission ?
Vous en avez marre de voir GPTBot, ClaudeBot et toute la bande de crawlers IA se servir sur votre site comme dans un buffet à volonté ? Perso, j'utilise Cloudflare qui propose des options pour ça directement mais tout le monde n'utilise pas ce service. Du coup ce projet ai.robots.txt est super pratique pour ceux qui gèrent leur propre serveur et qui veulent reprendre le contrôle sur ce qui se fait aspirer. L'idée c'est de maintenir sur Github une liste exhaustive de tous les crawlers liés à l'IA

Comment bloquer les crawlers IA qui pillent votre site sans vous demander la permission ?

Korben

Par : Korben

15 décembre 2025 à 13:11

Vous en avez marre de voir GPTBot, ClaudeBot et toute la bande de crawlers IA se servir sur votre site comme dans un buffet à volonté ? Perso, j'utilise Cloudflare qui propose des options pour ça directement mais tout le monde n'utilise pas ce service. Du coup ce projet ai.robots.txt est super pratique pour ceux qui gèrent leur propre serveur et qui veulent reprendre le contrôle sur ce qui se fait aspirer.

L'idée c'est de maintenir sur Github une liste exhaustive de tous les crawlers liés à l'IA, que ce soit pour entraîner des modèles ou alimenter des moteurs de recherche IA. On y retrouve les suspects habituels comme GPTBot (OpenAI), Claude-Web (Anthropic), Google-Extended, meta-externalagent, mais aussi des trucs plus obscurs comme img2dataset ou laion-huggingface-processor qui servent à aspirer des images.

Le truc cool, c'est que le projet ne se contente pas juste de fournir un robots.txt à copier-coller. Y'a aussi des fichiers de config prêts à l'emploi pour Apache (.htaccess), Nginx, Caddy et même HAProxy. Du coup vous pouvez carrément renvoyer une erreur HTTP aux crawlers au lieu de juste leur dire "non" poliment via robots.txt (qu'ils ignorent parfois de toute façon, les malotrus).

Pour Nginx par exemple, vous récupérez le fichier nginx-block-ai-bots.conf et vous l'incluez dans votre config de virtual host. Le fichier contient une regex qui matche tous les User-Agent connus des crawlers IA. Même principe pour Apache avec le .htaccess, ou pour HAProxy où vous ajoutez quelques lignes dans la section frontend pour détecter et bloquer ces bots.

Le projet est maintenu activement par une communauté de contributeurs qui surveille les nouveaux crawlers qui débarquent et dès qu'un nouveau bot IA se pointe, la liste est mise à jour et les fichiers de config sont regénérés automatiquement via GitHub Actions.

Après, le robots.txt ça reste un "gentlemen's agreement" et y'a que les crawlers sympas le respectent... Les autres font semblant de pas le voir. A voir maintenant si c'est une bonne idée ou pas de bloquer ces crawlers...

C'est à vous de voir mais si vous n'aimez pas l'IA je pense que vous adorerez cette liste de blocage . Après si vous vous inquiétez sur votre audience votre référencement et compagnie, peut-être que vous voulez quand même récupérer un peu de trafic en provenance de ces chatbots IA.

Donc à vous de voir...

Vue normale