Un PDF reçu par mail ne contient pas de code exécutable au sens classique d’un .exe ou d’un .bat. Le format repose sur un langage de description de page, pas sur un langage de programmation. Le danger ne vient donc pas du fichier lui-même, mais de ce que le lecteur PDF accepte d’interpréter, et de ce que l’utilisateur fait après l’ouverture.
Surface d’attaque réelle d’un lecteur PDF : JavaScript, formulaires et objets embarqués
Le format PDF supporte nativement plusieurs fonctionnalités actives que la plupart des utilisateurs ignorent. La spécification autorise l’intégration de JavaScript embarqué dans le document, de formulaires interactifs (AcroForms, XFA), de pièces jointes encapsulées et d’actions automatiques au lancement (OpenAction, AA). Chacune de ces couches constitue un vecteur d’attaque distinct.
A lire en complément : Comment convertir un Fichier PDF en Word pour le modifier ?
Un script JavaScript inséré dans un PDF peut déclencher l’ouverture d’une URL, tenter d’exploiter une vulnérabilité du moteur de rendu ou exfiltrer des métadonnées. Adobe Acrobat Reader exécute ce JavaScript par défaut. Les lecteurs alternatifs (Sumatra PDF, Evince, l’aperçu natif de macOS) n’implémentent pas ou très partiellement cette couche, ce qui réduit la surface d’attaque de manière significative.
Les formulaires XFA, hérités d’anciennes versions d’Acrobat, permettent d’embarquer du contenu dynamique plus complexe. Adobe a officiellement déprécié le support XFA dans les versions récentes, mais de nombreuses entreprises utilisent encore des versions non mises à jour. C’est précisément ce décalage entre spécification et parc installé que les attaquants exploitent.
A lire en complément : Comment convertir la voix en texte ?
PDF piégé par phishing : le vrai risque en 2025-2026
La majorité des PDF malveillants que nous observons en circulation ne cherchent pas à exécuter du code sur la machine. Le PDF sert de support visuel à une attaque de phishing, pas de vecteur d’exploitation technique. Le fichier reproduit une facture, un avis de passage ou un relevé bancaire, et contient un lien cliquable pointant vers une page de collecte d’identifiants.
Le rapport d’activité 2025 de Cybermalveillance.gouv.fr confirme que l’hameçonnage reste la première menace tous publics confondus, avec une hausse de 70 % des cas traités par rapport à l’année précédente. Les campagnes décrites montrent un recours croissant aux pièces jointes présentées comme inoffensives (factures, formulaires, relevés) pour amener la victime à cliquer ou à saisir des données sensibles.
Ce type d’attaque fonctionne quel que soit le lecteur PDF utilisé, puisqu’il ne repose sur aucune faille logicielle. Il suffit que l’utilisateur clique sur le lien et saisisse ses identifiants sur la fausse page. Les statistiques de KeepnetLabs pour 2026 indiquent que 62 % des brèches impliquent un élément humain, ce qui confirme que le maillon faible reste le comportement, pas le logiciel.
Aperçu intégré dans le webmail : risque différent de l’ouverture locale
La question revient souvent : l’aperçu d’un PDF dans Gmail ou Outlook Web présente-t-il le même risque que son ouverture dans Acrobat ? Non. Les moteurs de prévisualisation des webmails effectuent un rendu côté serveur ou via un viewer sandboxé (PDF.js dans Firefox, moteur intégré de Chrome). Le JavaScript embarqué dans le PDF n’est pas exécuté dans ce contexte.
Le risque résiduel avec l’aperçu se limite à deux scénarios :
- Le PDF contient un lien de phishing visible dans l’aperçu, et l’utilisateur clique dessus depuis le navigateur, ce qui ramène au scénario d’ingénierie sociale classique.
- Une vulnérabilité 0-day affecte le moteur de rendu du navigateur lui-même, ce qui reste rare et rapidement corrigé par les éditeurs.
- Le fichier utilise une technique de masquage d’extension (double extension, caractère Unicode right-to-left override) pour inciter au téléchargement d’un exécutable déguisé en PDF.
Nous recommandons de conserver l’aperçu activé dans les webmails modernes : il permet justement de vérifier le contenu sans exécuter les couches actives du fichier.
Cas des clients lourds : Thunderbird, Outlook desktop
Les clients de messagerie desktop délèguent l’ouverture du PDF au lecteur par défaut du système. Si ce lecteur est Adobe Acrobat Reader avec JavaScript activé et mises à jour en retard, le risque remonte d’un cran. La configuration du lecteur par défaut est un point de durcissement que beaucoup d’administrateurs négligent.
Réduire le risque sans bloquer les PDF : mesures concrètes
Bloquer tous les PDF entrants n’est pas réaliste dans un contexte professionnel. La gestion du risque passe par la réduction de la surface d’exécution et par des réflexes de vérification.
- Désactiver JavaScript dans Adobe Acrobat Reader (Édition > Préférences > JavaScript > décocher « Activer Acrobat JavaScript »). Cette seule action neutralise la majorité des exploits techniques ciblant le lecteur.
- Utiliser un lecteur PDF minimal (Sumatra PDF sous Windows, Aperçu sous macOS) qui n’interprète ni JavaScript ni les formulaires XFA.
- Vérifier l’expéditeur et le contexte avant toute interaction avec un lien contenu dans le document. Un PDF légitime d’une administration ou d’une banque ne demande jamais de « confirmer vos identifiants » via un lien cliquable.
- Maintenir le lecteur PDF et le système d’exploitation à jour. Les vulnérabilités connues d’Acrobat sont corrigées par des patches réguliers, mais elles restent exploitables sur les postes non mis à jour.
Un PDF n’est pas dangereux par nature, il le devient par sa charge active et par le comportement du destinataire. La combinaison d’un lecteur durci, d’un aperçu webmail pour le premier tri et d’une vigilance sur les liens intégrés couvre la très grande majorité des scénarios d’attaque actuels. Les campagnes de phishing par PDF continueront de progresser tant que le taux de clic restera rentable pour les attaquants, et c’est sur ce levier humain que la sécurité se joue réellement.
