EN
en direct

Deux zero-days PaperCut se chaînent en exécution de code sans authentification et entrent au catalogue KEV

Le 27 août 2026, PaperCut a confirmé l’exploitation active de deux zero-days dans ses solutions d’impression NG et MF, chaînés en exécution de code sans authentification. Le premier correctif d’urgence a déjà été contourné : appliquez la seconde version et coupez l’accès Internet.

Une massicot industrielle sombre dont la lame, marquée d’un seul reflet ambre, plane au-dessus d’une feuille de papier.

27 août 2026. PaperCut Software publie un avis de sécurité urgent : il enquête sur l’exploitation active d’une faille touchant PaperCut NG et PaperCut MF. 28 août 2026. Le fournisseur attribue deux identifiants CVECVE-2026-81578 et CVE-2026-82078 — et livre un premier correctif d’urgence. 31 août 2026. Les deux failles entrent au catalogue KEV de la CISA. En quatre jours, une chaîne de deux zero-days est passée de « faille non identifiée » à « exploitée et patchée en urgence ».

PaperCut NG/MF est une plateforme de gestion d’impression déployée dans les entreprises, les universités et les administrations. Son serveur d’application expose une interface web d’administration — et c’est précisément là que se joue la compromission. Le chaînage des deux failles donne une exécution de code à distance sans authentification, ce qui en fait une urgence de premier rang pour tout serveur exposé.

Deux failles, une seule chaîne d’attaque

CVE-2026-81578 est un contournement d’authentification (CWE-306, CVSSv4 8.8) : un attaquant distant, sans identifiants, peut modifier certains paramètres de configuration système. CVE-2026-82078 est un chargement dynamique de classe non sûr dans les utilitaires de connexion à la base de données (CWE-470, CVSSv4 9.4, critique). C’est le second maillon qui transforme le contournement en exécution de code.

La chaîne, documentée par Rapid7, est un cas d’école de composition de failles. L’attaquant exploite d’abord le contournement pour reconfigurer quatre paramètres de recherche utilisateur externeuser-lookup.db-driver, user-lookup.db-url, user-lookup.id-to-username-sql et user-lookup.enabled. Ces paramètres permettent normalement à un administrateur de connecter PaperCut à une base de cartes externe. Entre de mauvaises mains, ils deviennent une porte : l’attaquant y place une connexion JDBC malveillante et une requête SQL arbitraire, puis déclenche la recherche, et le code s’exécute dans le contexte du serveur.

La mécanique Tapestry qui contourne l’authentification

Le contournement s’appuie sur une subtilité du framework Apache Tapestry, sur lequel PaperCut est bâti. Le format de requête « complex direct » de Tapestry permet d’indiquer une page à afficher et une autre page contenant le composant à exécuter. PaperCut ne valide l’accès que sur la page affichée. En choisissant la page publique Error ou Exception pour l’affichage, l’attaquant contourne l’authentification tout en invoquant des composants d’administration comme ConfigEditor ou UserList.

La leçon technique est profonde : la validation d’accès portait sur l’objet affiché, pas sur l’objet exécuté. C’est une classe de bug qui ne se voit ni dans les tests fonctionnels ni dans la revue de code classique — il faut auditer le cadre qui fait le pont entre la requête HTTP et le composant réellement invoqué. Le premier correctif d’urgence a d’ailleurs été contourné dès sa sortie, en utilisant la page Home pour l’affichage : seule la seconde version du correctif comble réellement la brèche.

Un correctif d’urgence qui a déjà été contourné

Le déroulé des patchs est lui-même un signal d’alerte. Le 28 août, PaperCut livre un premier correctif pour les versions 25 et 26, puis pour la 24. Le même jour, WatchTowr identifie plusieurs contournements du correctif et un second contournement d’authentification. PaperCut publie alors une seconde version du correctif. Concrètement : toute organisation qui a appliqué la première version du correctif d’urgence n’est pas protégée et doit appliquer la seconde immédiatement.

C’est le piège classique des correctifs « hors cycle » : publiés sans la batterie de tests habituelle, ils peuvent être incomplets. Pour un défenseur, la règle est simple — suivre l’avis du fournisseur jusqu’à sa version la plus récente, et ne pas considérer « patch appliqué » comme « dossier clos » tant que l’éditeur n’a pas confirmé la couverture.

L’ampleur de l’exposition

Le risque n’est pas théorique. La ShadowServer Foundation compte environ 1 000 instances PaperCut actuellement exposées à Internet, majoritairement en Amérique du Nord et en Europe. Huntress a constaté des attaques contre au moins deux de ses clients, avec des premières tentatives dès le 26 août — la veille de l’avis public. L’activité observée se concentre pour l’instant sur la découverte du système ; aucun malware secondaire ni trafic de commande n’a encore été identifié. Mais l’historique commande la prudence : en 2023, CVE-2023-27350, une RCE PaperCut, avait été massivement exploitée par plusieurs groupes, y compris des opérateurs de ransomware.

Le tableau est donc celui d’une cible connue, d’une chaîne d’exploitation désormais publique — un module Metasploit est disponible depuis le 31 août — et d’un parc exposé de l’ordre du millier de serveurs. La fenêtre entre la publication technique et l’exploitation de masse se mesure en jours, pas en semaines.

De la requête SQL à l’exécution de commande

Le chaînage complet mérite d’être déroulé, parce qu’il montre comment des briques a priori anodines s’assemblent en RCE. Après le contournement d’authentification, l’attaquant configure une connexion JDBC malveillante et une requête SQL arbitraire dans les paramètres de recherche utilisateur. Il s’appuie ensuite sur le pilote Apache Derby embarqué par PaperCut : une instruction CALL activant la fonctionnalité foreignViews de Derby ouvre une URL JDBC H2 contrôlée par l’attaquant. H2 traite alors une instruction INIT en ligne qui crée un déclencheur de base de données adossé à du JavaScript. Comme PaperCut embarque le moteur Nashorn, ce déclencheur peut lancer un processus du système d’exploitation — et l’exécution de commande arbitraire est acquise.

La portée pédagogique est réelle : aucune des briques n’est vulnérable en soi. C’est leur combinaison — contournement d’auth, reconfiguration, SQL, foreignViews, H2, Nashorn — qui transforme une modification de configuration en shell. Pour un défenseur, cela signifie que les défenses en profondeur ne peuvent pas s’arrêter à la couche d’authentification : il faut aussi surveiller ce qu’une configuration modifiée peut déclencher.

Les traces à chercher

PaperCut a publié des indicateurs préliminaires de compromission. Côté application, les alertes des outils d’IDS, d’EDR ou de surveillance réseau impliquant le serveur PaperCut — en particulier une activité post-exploitation inhabituelle de pc-app.exe — sont le premier signal. Côté journaux, deux anomalies sont caractéristiques : des fichiers server.log manquants, tronqués ou supprimés, et des entrées telles que « No suitable driver found for jdbc:no:x » ou « DatabaseUtils - Database error looking up cardID: VALUES CAST ».

Un point d’attention contre-intuitif : PaperCut précise que l’absence de ces indicateurs ne prouve pas qu’un serveur est sain. Et comme le nettoyage programmé des blobs non attachés peut supprimer des preuves, l’évaluation forensique doit commencer sans attendre. C’est le corollaire logique d’une chaîne d’exploitation publique : un serveur exposé doit être traité comme potentiellement compromis jusqu’à preuve du contraire, pas l’inverse.

Verdict

Si vous exploitez PaperCut NG ou MF, appliquez immédiatement la seconde version du correctif d’urgence — la première est contournable. Si votre serveur est accessible depuis Internet, restreignez dès maintenant l’accès web aux plages d’adresses de confiance, via pare-feu, reverse proxy ou contrôle d’accès réseau, en attendant le correctif définitif. Si vous avez appliqué la première version du correctif, traitez votre serveur comme potentiellement compromis : surveillez pc-app.exe, les fichiers server.log tronqués ou supprimés, et les entrées suspectes « No suitable driver found for jdbc:no:x » ou « DatabaseUtils - Database error looking up cardID ».

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer