Une faille PaperCut est activement exploitée par des attaquants pour prendre le contrôle de serveurs d’impression d’entreprise. L’éditeur a publié deux correctifs d’urgence en une seule semaine, signe que la première rustine ne fermait pas complètement la porte. Pour une PME ou une ETI, le serveur d’impression est souvent la machine la plus oubliée du parc : installée une fois, jamais mise à jour, et pourtant capable d’exécuter du code en tant que compte privilégié sur le réseau interne.
Faille PaperCut : deux vulnérabilités chaînées pour une RCE non authentifiée
PaperCut NG et PaperCut MF sont des solutions de gestion et de facturation d’impression déployées dans des milliers d’établissements : collectivités, cabinets, universités, industries. Les chercheurs ont montré que deux vulnérabilités distinctes peuvent être chaînées pour obtenir une exécution de code à distance sans aucune authentification.
- La première faille permet de contourner les contrôles d’accès de l’interface d’administration exposée.
- La seconde autorise l’écriture ou l’exécution de contenu contrôlé par l’attaquant depuis cette interface.
- Combinées, elles donnent un shell sur le serveur, avec les droits du service PaperCut — souvent
SYSTEMsous Windows.
L’exploitation a été observée avant la disponibilité du second correctif. Autrement dit : les organisations qui ont appliqué uniquement le premier patch se croyaient protégées alors que la chaîne d’attaque restait fonctionnelle. C’est exactement le scénario qui transforme une vulnérabilité connue en compromission réelle.
Pourquoi un serveur d’impression est une cible de choix
Un serveur d’impression n’a l’air de rien, mais il concentre plusieurs propriétés qui intéressent un attaquant :
- Il est joignable depuis tout le réseau bureautique, par construction.
- Il détient fréquemment un compte de service Active Directory avec des droits larges, pour l’authentification des utilisateurs et la synchronisation des annuaires.
- Il traite des documents : bulletins de paie, contrats, plans, factures — une mine pour l’extorsion.
- Il est rarement couvert par les campagnes de patch, qui se concentrent sur les postes et les serveurs applicatifs.
Historiquement, les failles PaperCut ont déjà servi de point d’entrée à des groupes de ransomware. Ce n’est pas un risque théorique : c’est un chemin d’attaque documenté et rejoué.
Corriger la faille PaperCut : les actions à mener aujourd’hui
1. Identifier vos instances, y compris celles que vous avez oubliées
Commencez par l’inventaire. Un serveur d’impression installé par un prestataire il y a cinq ans reste une instance exposée. Recherchez les ports d’administration PaperCut (typiquement 9191 en HTTP et 9192 en HTTPS) sur l’ensemble de vos plages internes, et vérifiez qu’aucun d’eux n’est publié sur Internet.
2. Appliquer le second correctif, pas seulement le premier
Vérifiez le numéro de version exact dans la console d’administration et comparez-le à la dernière version publiée par l’éditeur. Si votre mise à jour date d’avant le second bulletin, vous êtes toujours vulnérable. Sur ce type d’incident, « patché » ne veut rien dire sans numéro de build.
3. Retirer l’interface d’administration d’Internet
Aucune console d’administration PaperCut ne devrait être accessible publiquement. Placez-la derrière un VPN ou restreignez l’accès à un sous-réseau d’administration dédié. Cette seule mesure neutralise la majorité des tentatives opportunistes, y compris pour les prochaines failles encore inconnues.
4. Réduire les privilèges du compte de service
Si le service PaperCut tourne en SYSTEM ou avec un compte AD sur-privilégié, une RCE devient immédiatement une compromission de domaine. Basculez vers un compte de service dédié, sans droits d’administration de domaine, et appliquez le principe du moindre privilège aux partages qu’il consulte.
5. Chercher des traces de compromission
Un patch ne supprime pas une porte dérobée déjà installée. Recherchez les processus enfants anormaux lancés par le service PaperCut (cmd.exe, powershell.exe, interpréteurs de scripts), les fichiers déposés récemment dans les répertoires de l’application, les comptes d’administration créés hors procédure et les connexions sortantes inhabituelles depuis le serveur. Ces recherches sont exactement ce qu’un SOC instrumenté détecte en quelques minutes.
Industrialiser le patch pour éviter le prochain PaperCut
La faille PaperCut illustre un problème structurel plutôt qu’un incident isolé : les actifs « périphériques » (impression, sauvegarde, supervision, forge logicielle) échappent aux cycles de correctifs. La réponse n’est pas de patcher plus vite dans l’urgence, mais de réduire durablement la fenêtre d’exposition.
- Inventaire continu plutôt qu’annuel : tout service qui écoute sur le réseau entre dans le périmètre.
- Détection des versions automatisée, pour identifier en une requête toutes les instances non conformes.
- Surveillance comportementale sur les serveurs applicatifs, pour attraper l’exploitation même sans signature.
- Procédure de re-vérification après chaque correctif d’urgence : un second bulletin en quelques jours doit déclencher une nouvelle passe.
Nous avions détaillé cette logique de fenêtre de patch dans notre article sur la réduction de la fenêtre de patch du N-day au N-hour, et l’approche appliquée aux forges auto-hébergées dans sécuriser Gitea contre la RCE. Le raisonnement est identique ici : un service interne, discret et non supervisé, est le meilleur point d’entrée qu’un attaquant puisse espérer.
Ce qu’il faut retenir
La faille PaperCut exploitée en conditions réelles rappelle trois règles simples : un serveur d’impression est un serveur applicatif comme un autre, un correctif d’urgence suivi d’un second correctif impose une re-vérification complète, et une console d’administration exposée sur Internet est une compromission en attente de calendrier. Vérifiez vos versions aujourd’hui, sortez les interfaces d’administration du web public, et surveillez les processus enfants de vos services d’impression.