Peplink 8.6.0 sécurité : FIPS, RadSec, WireGuard et ce qui a changé

La sécurité d'une infrastructure réseau n'est pas un état, c'est un processus continu. Peplink Firmware 8.6.0, publiée le 29 juillet 2026, trace une ligne claire : au lieu d'améliorations ponctuelles isolées, cette version livre un ensemble de sécurité cohérent qui couvre les standards cryptographiques, les protocoles d'authentification et les corrections de vulnérabilités concrètes. Au centre figure le mot-clé Peplink FIPS RadSec — la combinaison du fonctionnement FIPS 140-3 permanent et de RadSec (RADIUS over TLS), qui représente un progrès mesurable notamment pour les organisations soumises à des exigences de conformité réglementaire.

Pour les CISO et les équipes de sécurité IT, la 8.6.0 signifie la disparition d'obstacles opérationnels de longue date : le fonctionnement FIPS peut désormais être activé en permanence dans l'interface locale. RadSec sécurise le trafic d'authentification RADIUS pendant son transit sur des réseaux publics. WireGuard complète les options VPN d'un protocole moderne, auditable, à l'empreinte de code réduite. Et trois vulnérabilités corrigées — dont un accès Web Admin non authentifié — éliminent des surfaces d'attaque qui auraient été signalées à répétition lors de tests d'intrusion.

Cet article examine chaque changement sous l'angle des responsables sécurité : qu'est-ce qui change techniquement, quelles obligations de configuration apparaissent lors de la mise à niveau, et quels risques l'update atténue-t-il ? Toutes les informations s'appuient sur les Release Notes officielles de Peplink et ont été validées par les ingénieurs Peplink certifiés d'Ascend.

Ce qui change

Selon la page officielle de Peplink consacrée à la firmware 8.6.0, FIPS devient avec la 8.6.0 une fonction permanente, intégrée à l'interface locale, pour les équipements habilités : FIPS 140-3 peut être activé durablement dans l'interface locale — sans Care Plan actif. Remarque : Peplink University et d'autres sources secondaires mentionnent encore FIPS 140-2 ; l'indication du fabricant fait foi.

Détails techniques

• L'activation de FIPS s'effectue directement dans la Web-UI locale, dans les paramètres de sécurité. InControl 2 reflète l'état, mais l'interrupteur se trouve sur l'équipement.
• Les équipements habilités sont listés par Peplink, par série, dans les Release Notes officielles ; cette liste doit être vérifiée concrètement avant la mise à niveau.
• Lorsque FIPS est activé, des exigences renforcées s'appliquent aux configurations IPsec : les clés prépartagées (PSK) doivent comporter au moins 14 caractères. Selon les Release Notes, les profils IPsec existants avec des PSK plus courts risquent de ne plus pouvoir établir de connexion après la mise à niveau, tant que les clés ne sont pas mises à jour.
• Nouveauté également : SHA2-384 comme algorithme de hachage pour la phase 2 IPsec, ce qui élève la protection de l'intégrité des négociations de tunnel à un niveau supérieur.

Recommandations avant la mise à niveau

1. Réaliser un audit PSK : avant la mise à niveau vers 8.6.0, vérifier toutes les clés prépartagées IPsec. Moins de 14 caractères ? Remplacer avant la mise à niveau, sinon le tunnel casse.
2. Vérifier le contrat de service : la fonction FIPS elle-même n'est liée à aucun Care Plan actif ; le droit de votre équipement aux mises à jour logicielles dépend de votre contrat de service Peplink.
3. Documenter l'état FIPS : après la mise à niveau, activer le mode FIPS dans l'interface locale et documenter l'état à des fins d'audit.

Remarque pour les équipements PrimeCare : InControl doit rester activé pour recevoir les mises à jour de fonctionnalités logicielles. FIPS certes fonctionne durablement sans Care Plan, mais la livraison des fonctionnalités passe par InControl.

Pourquoi RadSec est pertinent

RADIUS est le protocole standard d'authentification dans les environnements Wi-Fi — du WPA2/WPA3-802.1X d'entreprise aux portails invités. Sous sa forme classique, RADIUS transmet les données d'authentification en clair. Tant que les serveurs RADIUS et les points d'accès se trouvent dans le même segment réseau protégé, c'est acceptable. Mais dès que le trafic d'authentification traverse des réseaux publics — par exemple pour des agences distribuées, des services RADIUS cloud ou des liaisons MPLS entre plusieurs opérateurs —, une surface d'attaque réelle apparaît : identifiants, jetons challenge-response et clés de session peuvent être interceptés.

RadSec résout ce problème en encapsulant l'ensemble du trafic RADIUS dans un tunnel TLS. Authentification, autorisation et accounting (AAA) transitent par un canal chiffré, qui s'authentifie en outre mutuellement via des certificats. Peplink 8.6.0 apporte la prise en charge native de RadSec sur une large gamme de modèles.

Modèles pris en charge

RadSec est disponible sur : Balance 20X, 310 Fiber 5G, 310 5G HW3, tous les modèles Dome et MBX, tous les modèles UBR, la majorité de la série BR, ainsi que tous les modèles Transit, Orbit et B One. La matrice exacte des modèles figure dans les Release Notes.

Étapes de configuration

1. Préparer le serveur RADIUS pour RadSec : le serveur RADIUS cible doit prendre en charge RadSec (RFC 6614) — FreeRADIUS, Microsoft NPS avec passerelle RadSec ou fournisseurs de RADIUS cloud comme CloudPath.
2. Déposer les certificats dans le Peplink Certificate Manager : le certificat client du routeur Peplink et le certificat CA du serveur RADIUS doivent être importés.
3. Configurer RadSec comme profil d'authentification : RadSec peut y être choisi comme protocole d'authentification ; le port est généralement 2083 (le RADIUS classique utilise 1812).
4. Basculer les points d'accès Wi-Fi sur le nouveau profil : dans l'AP Controller, attribuer le profil d'authentification au profil SSID correspondant.

Exemple pratique : réseau d'agences avec RADIUS cloud

Une entreprise exploite 40 agences, chacune avec un Peplink Balance et plusieurs points d'accès Wi-Fi. L'authentification RADIUS passe par un service RADIUS cloud centralisé. Jusqu'ici, le trafic RADIUS entre les agences et le cloud était non protégé ou exigeait un VPN en amont. Avec RadSec dans la 8.6.0, un tunnel TLS suffit — configuré dans le Peplink Certificate Manager — et l'authentification est chiffrée de bout en bout. Cela réduit la complexité et élimine une surface d'attaque qui reste souvent non résolue dans les déploiements distribués.

Ce qui distingue WireGuard d'OpenVPN et d'IPsec

WireGuard est disponible avec la firmware 8.6.0 sur tous les modèles Peplink comme VPN d'accès utilisateurs distants. Il se positionne aux côtés des options existantes (OpenVPN, L2TP, PPTP) — non pas en remplacement, mais comme alternative moderne présentant des avantages spécifiques :

• Taille de la base de code : WireGuard environ 4 000 lignes, stacks OpenVPN de l'ordre de 100 000 lignes et plus — moins de code, surface d'attaque réduite.
• Établissement de connexion : WireGuard s'établit en une fraction du temps nécessaire aux protocoles classiques.
• Handover lors d'un changement de réseau : WireGuard reste en place sans interruption ; avec OpenVPN, la session est en général interrompue.
• Cryptographie : WireGuard avec ChaCha20 + Poly1305 figés ; IPsec configurable (avec FIPS notamment SHA2-384).
• Auditabilité : élevée grâce à la petite base de code ; les stacks complexes sont plus coûteux à auditer.

Pourquoi c'est important pour les CISO

• Surface d'attaque minimale : la base de code de WireGuard est environ 25 fois plus petite que celle d'OpenVPN. Cela signifie moins de vulnérabilités potentielles, des audits de sécurité plus rapides et des processus de certification plus simples.
• Mobilité : WireGuard conserve les sessions lors du changement d'interface réseau (par ex. Wi-Fi → LTE). Pour les télétravailleurs sur le terrain ou les commerciaux itinérants, cela signifie pas de tunnels VPN qui cassent lors d'un changement de réseau — un avantage opérationnel qui réduit aussi le taux de tickets au helpdesk.
• Cryptographie standard forte : WireGuard utilise fixement ChaCha20 pour le chiffrement symétrique et Poly1305 pour le MAC — pas de suites de chiffrement configurables, potentiellement faibles.

Scénarios d'utilisation chez Peplink

WireGuard dans la 8.6.0 est conçu principalement pour le Remote User Access — c'est-à-dire l'accès de clients individuels (ordinateur portable, smartphone, application Peplink SFC) au routeur Peplink. Pour les connexions site à site entre équipements Peplink, SpeedFusion reste le choix recommandé, car il offre en plus le bonding WAN et le failover. SFC Direct Access (également nouveau dans la 8.6.0) complète WireGuard pour les cas où une connexion Peplink à Peplink directe est nécessaire sans tunnel VPN classique.

Remarque de configuration

WireGuard se configure dans la Web-UI Peplink ; une paire de clés publique/privée est générée ou importée par client. La gestion des pairs suit le modèle WireGuard connu — pas de surcharge de certificats X.509 comme avec OpenVPN, mais une gestion explicite des clés comme discipline.

Les changements en un coup d'œil

La firmware 8.6.0 procède à un assainissement rigoureux des formats de certificats acceptés. Les types suivants ne sont plus acceptés :

• Type de certificat : DSA (Digital Signature Algorithm) · Statut avant 8.6.0 : accepté · Statut à partir de 8.6.0 : plus accepté
• Type de certificat : clés RSA courtes · Statut avant 8.6.0 : accepté · Statut à partir de 8.6.0 : plus accepté
• Type de certificat : conteneurs PKCS#12 hérités · Statut avant 8.6.0 : accepté · Statut à partir de 8.6.0 : plus accepté
• Type de certificat : RSA ≥ 2048 bits, ECDSA, Ed25519 · Statut avant 8.6.0 : accepté · Statut à partir de 8.6.0 : accepté (standard)

Les certificats qui ne sont plus acceptés sont remplacés par un certificat par défaut sécurisé qui sert automatiquement de solution de repli. L'exploitation ne s'interrompt pas — le chiffrement continue, mais avec le certificat par défaut au lieu d'un certificat hérité expiré ou non sécurisé.

Pourquoi c'est important

• DSA est considéré comme obsolète. Le NIST recommande la migration vers ECDSA ou RSA ≥ 2048 (NIST SP 800-131A) ; le BSI privilégie lui aussi, dans ses exigences, des méthodes modernes. Peplink s'inscrit dans cette direction avec la modernisation des certificats.
• Les clés RSA courtes sont considérées comme non sécurisées (NIST SP 800-131A exige au moins 2048 bits pour les signatures numériques). Lors de tests d'intrusion et d'audits de conformité, elles sont classées comme constat (finding). Les longueurs de clés RSA que Peplink refuse concrètement dans la 8.6.0 ne sont pas chiffrées dans les Release Notes — vérifiez vos certificats dans le Certificate Manager.
• Les conteneurs PKCS#12 hérités peuvent contenir des formats de chiffrement obsolètes qui ne correspondent plus aux standards actuels.

Obligation de vérification : contrôler le Certificate Manager

Avant la mise à niveau vers 8.6.0 :

1. Lister tous les certificats importés dans le Peplink Certificate Manager.
2. Vérifier chaque certificat pour DSA ou des clés RSA anormalement courtes.
3. Remplacer les certificats concernés par de nouveaux certificats RSA 2048+ ou ECDSA.

Après la mise à niveau vers 8.6.0 :

1. Revérifier le Certificate Manager — les certificats concernés auront été remplacés par le certificat par défaut.
2. Si un certificat auto-signé était utilisé pour la gestion ou le VPN, remplacer les certificats de remplacement par défaut par vos propres certificats d'au moins 2048 bits.
3. Pour les connexions TLS concernées (Synergy Mode, RadSec, Web Admin), informer les clients du changement de certificat afin d'éviter les problèmes de trust-store/pinning.

Synergy Mode : la 8.6.0 apporte un certificat de repli dédié pour les connexions TLS Synergy. Là aussi : vérifier le parc de certificats avant la mise à niveau.

CVE-2026-42945 — composante du service Web

Cette vulnérabilité concernait une composante du service Web de Peplink. Peplink a livré le patch directement dans la 8.6.0. Les détails du vecteur exact ont été communiqués avec réserve par Peplink — pratique courante chez les fabricants d'appliances réseau pour réduire la fenêtre d'exploitation. Ce que les CISO doivent savoir : le patch n'existe qu'à partir de la 8.6.0 — une mise à niveau rapide est vivement recommandée.

Injection de commandes CLI — corrigée

Une vulnérabilité d'injection de commandes dans la CLI a été corrigée. Les vulnérabilités d'injection de commandes permettent à des attaquants d'exécuter des commandes arbitraires avec les privilèges du processus CLI — généralement au niveau administration. La surface d'attaque suppose un accès CLI authentifié, mais le risque reste critique : escalade de privilèges verticale et contrôle complet de l'équipement sont possibles. Le patch ferme le traitement des entrées injectables.

Web Admin — accès non authentifié corrigé

La plus grave des trois vulnérabilités corrigées : un accès non authentifié à l'interface Web Admin était possible. Cela signifie : un attaquant sans identifiants pouvait atteindre des fonctions ou des informations d'administration. Les détails exacts de l'étendue n'ont pas été totalement divulgués, mais la seule catégorie — accès administrateur non authentifié — justifie le classement comme critique et fait de la mise à niveau une priorité.

Valeurs par défaut des points d'accès Wi-Fi sur WPA2/WPA3 Personal

Une modification sous-estimée aux grands effets : les nouveaux points d'accès Wi-Fi sont, à partir de la 8.6.0, configurés par défaut avec WPA2/WPA3 Personal — et non plus avec le WPA obsolète, ni même en mode ouvert. C'est particulièrement pertinent parce que les configurations par défaut restent en pratique souvent intactes pendant des jours, voire pour toujours. Avec WPA3 comme option par défaut, le risque d'attaques contre un chiffrement Wi-Fi obsolète diminue nettement.

Résumé des correctifs de sécurité

• Vulnérabilité : composante du service Web · Catégorie : vulnérabilité de service · CVE : CVE-2026-42945 · Corrigée dans : 8.6.0
• Vulnérabilité : injection de commandes CLI · Catégorie : injection de commandes authentifiées · CVE : — · Corrigée dans : 8.6.0
• Vulnérabilité : accès Web Admin non authentifié · Catégorie : accès administrateur non authentifié · CVE : — · Corrigée dans : 8.6.0
• Vulnérabilité : valeurs par défaut des AP Wi-Fi · Catégorie : configuration par défaut faible · CVE : — · Corrigée dans : 8.6.0

Peplink Firmware 8.6.0 est une version centrale du point de vue de la sécurité. La combinaison du Peplink FIPS RadSec — FIPS 140-3 permanent sans lien avec un Care Plan et RadSec pour RADIUS over TLS —, de WireGuard comme standard VPN moderne, d'une modernisation rigoureuse des certificats et de la correction de trois vulnérabilités critiques donne un ensemble de sécurité cohérent qui ne néglige aucun aspect du niveau appliance réseau.

Pour les CISO et les équipes de sécurité IT des secteurs réglementés — administrations, santé, finance, infrastructures critiques —, cette mise à niveau n'est pas un « nice to have », mais une obligation de conformité et de gestion des risques. Les trois vulnérabilités corrigées justifient à elles seules une mise à niveau rapide ; FIPS, RadSec et WireGuard constituent la valeur ajoutée au-delà.

Recommandation : vérifiez la préparation à la mise à niveau de vos équipements Peplink (longueur des PSK, certificats, mise à niveau échelonnée pour certains modèles), planifiez une fenêtre de maintenance et réalisez la mise à niveau. Ascend, en tant que Peplink Gold Partner, vous accompagne dans la planification, l'audit PSK et certificats, et le déploiement.

Prochaine étape : contactez Ascend pour un entretien de conseil sur la mise à niveau — nous vérifions la préparation de votre parc Peplink pour la 8.6.0, identifions les certificats et clés prépartagés concernés, et planifions le déploiement avec vous.

Cet article a été documenté et rédigé avec le soutien de l'IA et vérifié avant publication par les ingénieurs Peplink certifiés d'Ascend.