Un chercheur a découvert qu'il était possible de se connecter sur n'importe quel tenant Entra ID avec les Actor Tokens et une faille dans l'API Azure AD Graph.
Si vous êtes sous Mac, je pense que comme moi, vous passez votre temps à chercher des fichiers ou lancer des applications avec Spotlight… Si vous ne connaissez pas cet outil, c’est un truc super pratique d’Apple qui indexe tout votre disque dur pour vous faire gagner du temps. Command+Espace, trois lettres tapées, et hop, votre document apparaît. Pratique, non ?
Sauf que voilà, depuis presque 10 ans maintenant, ce même Spotlight peut servir de cheval de Troie pour siphonner vos données les plus privées. Et le pire, c’est qu’Apple le sait et n’arrive toujours pas à vraiment colmater la brèche.
Patrick Wardle, le chercheur en sécurité derrière plusieurs outils populaires comme
LuLu
, vient d’expliquer
sur son blog Objective-See
une technique ahurissante qui permet à un plugin Spotlight malveillant de contourner toutes les protections TCC de macOS. Pour info, TCC (Transparency, Consent and Control), c’est le système qui vous demande si telle application peut accéder à vos photos, vos contacts, votre micro… Bref, c’est censé être le garde du corps de votre vie privée sous Mac.
Alors comment ça marche ?
Hé bien au lieu d’essayer de forcer les portes blindées du système, le plugin malveillant utilise les notifications Darwin comme une sorte de morse numérique. Chaque byte du fichier à voler est encodé dans le nom d’une notification (de 0 à 255), et un processus externe n’a qu’à écouter ces notifications pour reconstruire le fichier original, octet par octet. C’est du génie dans sa simplicité !
Ce qui rend cette histoire encore plus dingue, c'est que cette vulnérabilité a été présentée pour la première fois par Wardle lui-même lors de sa conférence #OBTS v1.0 en 2018. Il avait déjà montré comment les notifications pouvaient permettre aux applications sandboxées d'espionner le système.
Plus récemment, Microsoft a “redécouvert” une variante de cette technique cette année et l’a baptisée “
Sploitlight
”. Ils ont même obtenu un joli CVE tout neuf (CVE-2025-31199) pour leur méthode qui consistait à logger les données dans les journaux système. Apple a corrigé cette variante dans macOS Sequoia 15.4… mais la méthode originale de Wardle fonctionne toujours, même sur macOS 26 (Tahoe) !
Et sinon, savez-vous ce que ces plugins peuvent voler exactement ?
Il y a notamment un fichier bien particulier sur votre Mac, caché dans les profondeurs du système, qui s’appelle knowledgeC.db. Cette base de données SQLite est littéralement le journal intime de votre Mac. Elle contient tout :
Quelles applications vous utilisez et pendant combien de temps
Vos habitudes de navigation web avec Safari (historique détaillé, fréquence des visites, interactions)
Quand vous branchez votre téléphone
Quand vous verrouillez votre écran
Vos trajets en voiture avec CarPlay
Vos routines quotidiennes et patterns comportementaux
C’est le genre de données qui raconte votre vie mieux que vous ne pourriez le faire vous-même. Et avec les nouvelles fonctionnalités d’Apple Intelligence dans macOS Tahoe, cette base de données alimente directement l’IA d’Apple pour personnaliser votre expérience.
Avec ce fichier, quelqu’un pourrait non seulement voir ce que vous faites maintenant sur votre Mac, mais aussi reconstituer vos habitudes des 30 derniers jours. À quelle heure vous commencez votre journée, quelles apps vous lancez en premier, combien de temps vous passez sur tel ou tel site… C’est le rêve de n’importe quel espion ou publicitaire, et c’est accessible via une simple vulnérabilité Spotlight.
Apple a bien sûr essayé de corriger le tir. Dans macOS 15.4, ils ont ajouté de nouveaux événements TCC au framework Endpoint Security pour mieux surveiller qui accède à quoi. Ils ont aussi corrigé la variante découverte par Microsoft (CVE-2025-31199).
Mais… la vulnérabilité de base présentée par Wardle fonctionne toujours sur macOS 26 (Tahoe), même en version Release Candidate avec SIP activé ! C’est comme ajouter une serrure supplémentaire sur la porte alors que tout le monde passe par la fenêtre depuis 10 ans.
Wardle a une idée toute simple pour régler définitivement le problème : Apple pourrait exiger une notarisation pour les plugins Spotlight, ou au minimum demander l’authentification et l’approbation explicite de l’utilisateur avant leur installation. Actuellement, n’importe quel plugin peut s’installer tranquillement dans ~/Library/Spotlight/ et commencer à espionner vos données, sans même nécessiter de privilèges administrateur.
Alors bien sûr, avant que vous ne couriez partout comme une poule sans tête, il faut relativiser :
Cette attaque nécessite un accès local à votre système - on ne parle pas d’une vulnérabilité exploitable à distance
Il faut qu’un malware ou un attaquant installe d’abord le plugin malveillant sur votre Mac
La “bande passante” est limitée - transmettre octet par octet n’est pas très efficace pour de gros fichiers
macOS affiche une notification quand un nouveau plugin Spotlight est installé (même si cette alerte peut être contournée)
Ça fait quand même quelques conditions… mais le fait que cette faille existe depuis près de 10 ans et fonctionne toujours sur la dernière version de macOS reste préoccupant.
Cette histoire nous rappelle que les outils les plus dangereux sont souvent ceux auxquels on fait le plus confiance… Wardle fournit même un proof-of-concept complet sur son site pour que la communauté puisse tester et comprendre le problème. Espérons qu’Apple prendra enfin cette vulnérabilité au sérieux et implémentera les mesures de sécurité suggérées.
En attendant, restez vigilants sur les applications que vous installez et gardez un œil sur les notifications système concernant l’installation de nouveaux plugins Spotlight !
Vous attaquez votre lundi matin, tranquillement avec votre petit café… vous ouvrez ChatGPT pour lui demander votre planning de la semaine et là, PAF (façon De Funès ^^), toute votre correspondance Gmail part directement chez un cybercriminel.
Ce serait fou non ? Et bien c’est exactement ce qu’un chercheur vient de démontrer et tout ça à cause d’une simple invitation Google Calendar.
Eito Miyamura, co-fondateur d’EdisonWatch
, a lâché une bombe sur X le 12 septembre et sa démo est terrifiante. En gros, il simule un attaquant qui envoie une invitation Google Calendar vérolée, ensuite vous demandez innocemment à ChatGPT “Qu’est-ce que j’ai de prévu aujourd’hui ?”, et l’IA se transforme en espion qui fouille vos emails et les envoie au pirate. Vous n’avez même pas besoin de voir ou d’accepter l’invitation. Elle est là, dans votre calendrier, comme une bombe à retardement.
Et ça tombe mal niveau comm, car OpenAI vient tout juste d’intégrer le support complet du MCP (Model Context Protocol) dans ChatGPT. Cette technologie permet en effet à l’assistant de se connecter directement à Gmail, Google Calendar, SharePoint, Notion… Pratique pour la productivité, mais catastrophique pour la sécurité.
Cette attaque exploite ce qu’on appelle l’injection de prompt indirecte. Au lieu d’essayer de tromper ChatGPT directement, l’attaquant cache ses instructions malveillantes dans des données que l’IA est autorisée à lire. Dans ce cas précis, le texte d’un événement calendrier… Ensuite ChatGPT lit l’invitation, voit les instructions cachées, et les exécute docilement.
Selon les experts en sécurité
qui se sont penchés sur le problème, le MCP n’a pas été conçu avec la sécurité en priorité. Les risques incluent donc les injections de prompt, les permissions d’outils vulnérables et les outils sosies qui peuvent remplacer silencieusement les outils de confiance.
Sympa, hein ?
D’ailleurs, ce n’est pas la première fois qu’on voit ce genre d’attaque puisqu’en août, des chercheurs avaient déjà démontré comment
une invitation compromise pouvait manipuler Google Gemini
pour contrôler des appareils domotiques et voler des informations. Le papier s’appelait joliment “Invitation Is All You Need”. Prophétique.
Vitalik Buterin lui-même a réagi
à cette vulnérabilité. Il explique que compter aveuglément sur un seul système IA est trop fragile et facilement manipulable et je trouve que cette nouvelle exploitation de ChatGPT lui donne raison !
D’ailleurs, même avec les navigateurs IA, vous n’êtes pas tranquille.
D’après cette autre découverte,
vous pouvez littéralement vous faire vider votre compte bancaire en scrollant sur Reddit. En effet, des instructions malveillantes peuvent être cachées dans des commentaires sur des sites que l’attaquant ne contrôle même pas, ce qui peut entrainer votre navigateur IA à faire des choses que vous n’avez pas autorisé.
Bref, cette nouvelle vulnérabilité met en lumière un problème fondamental des LLM : ils ne savent pas faire la différence entre des instructions légitimes et des commandes malveillantes cachées dans du contenu. Car
contrairement aux applications traditionnelles
qui peuvent séparer les instructions développeur des inputs utilisateur, les LLM acceptent tout en langage naturel. Pour rester flexibles, ils doivent pouvoir répondre à des configurations infinies d’instructions et c’est cette flexibilité qui fait leur force… mais qui est également leur talon d’Achille.
Trail of Bits a même démontré une variante encore plus sournoise où
des images spécialement forgées
contiennent des prompts cachés. Invisibles en haute résolution, les instructions malveillantes apparaissent quand l’image est réduite par les algorithmes de prétraitement. L’IA lit alors le message et l’interprète comme une instruction légitime.
Ainsi, quand une IA suit des instructions malveillantes depuis du contenu web, les protections traditionnelles comme la same-origin policy ou CORS deviennent inutiles. L’IA opère avec tous vos privilèges sur toutes vos sessions authentifiées. Accès potentiel à vos comptes bancaires, systèmes d’entreprise, emails privés, stockage cloud… C’est vite le jackpot pour un attaquant.
Alors, comment se protéger ?
Hé bien Google recommande de changer les paramètres de Calendar pour que seules les invitations de contacts connus ou acceptées apparaissent. Cachez aussi les événements refusés et surtout, restez extrêmement prudent avec les intégrations tierces et les autorisations accordées…
Voilà, donc la prochaine fois que ChatGPT vous demandera l’autorisation d’accéder à votre Gmail, réfléchissez-y à deux fois car ça pourrait vous coûter bien plus cher qu’un peu de temps gagné.
Vous savez comme moi que parfois les failles de sécurité les plus dangereuses sont aussi les plus simples. Imaginez-vous un instant, déjouer complètement Windows Defender, le garde du corps intégré de Microsoft, avec juste… un lien symbolique.
Oui, un simple raccourci Windows créé avec la commande mklink, et paf, c’est la protection antivirus qui part en fumée. Et bien c’est exactement ce qu’a déniché un chercheur en sécurité russe connu sous le pseudo de Two Seven One Three.
L’astuce ici, c’est que l’attaque joue avec la manière dont Windows Defender gère ses propres mises à jour. Je vous explique… Vous voyez ce dossier C:\ProgramData\Microsoft\Windows Defender\Platform où l’antivirus range ses exécutables ? Eh bien, chaque mise à jour génère un nouveau sous-dossier avec un numéro de version, genre 4.18.24090.11-0. Et au démarrage, Defender se lance à la recherche de la version la plus fraîche pour s’exécuter.
C’est là que ça devient croustillant car le chercheur a découvert qu’avec des droits administrateur, n’importe qui peut créer un nouveau dossier dans Platform. Microsoft a bien sûr pensé à empêcher l’écriture de fichiers malveillants dans ce répertoire critique, mais la création de nouveaux dossiers reste possible. C’est cette faille apparemment mineure qui devient alors une porte d’entrée majeure.
Voici comment l’attaque se déroule : vous créez un lien symbolique avec un nom de version qui semble plus récent, disons 5.18.25070.5-0. Ce lien dirige vers un dossier que vous contrôlez de A à Z, par exemple C:\TMP\AV.
Ainsi, au prochain redémarrage de Windows, Defender se dit “Oh chouette, une nouvelle version !” et démarre depuis votre dossier piégé. De là, vous avez alors le contrôle total. Vous pouvez modifier les fichiers de Defender, lui injecter du code via DLL side-loading, ou carrément supprimer les exécutables, car sans ses fichiers principaux, l’antivirus ne peut plus démarrer et toute la protection s’effondre.
Y’a aussi
une variante encore plus sournoise détectée
en début d’année qui consiste à utiliser Process Monitor avec des liens symboliques, cet outil de monitoring système de Microsoft, avec lequel vous pouvez carrément écraser le fichier principal de Defender au démarrage. Il suffit de créer un lien symbolique C:\Windows\Procmon.pmb qui pointe vers MsMpEng.exe, et Process Monitor fait le sale boulot pour vous pendant le boot.
Les hackers combinent de plus en plus cette approche avec d’autres méthodes comme le BYOVD (Bring Your Own Vulnerable Driver). Par exemple, le
groupe de ransomware Akira qui utilise des drivers Intel légitimes
pour obtenir un accès kernel et désactiver ainsicomplètement les protections Windows.
Les implications sont énormes car une fois Defender neutralisé, la page Windows Security devient inaccessible car le service n’est plus actif. Il n’y a plus aucune protection en temps réel, plus de détection de malware, rien. La machine devient alors une proie facile pour n’importe quel ransomware ou malware.
Le pire dans tout ça c’est que cette attaque utilise uniquement des outils déjà présents dans Windows. C’est la simplicité même de cette technique qui explique comment elle a pu passer inaperçue si longtemps.
Microsoft n’a pas encore communiqué officiellement sur cette vulnérabilité spécifique déterrée par Two Seven One Three mais vu l’exploitation enfantine et son efficacité redoutable, on peut parier qu’un correctif arrivera rapidement.
En attendant, les entreprises feraient bien de surveiller de très près les modifications dans le dossier Platform de Windows Defender…
Une faille de sécurité critique affecte la solution SAP S/4HANA : CVE−2025−42957. Cette menace est à prendre au sérieux, car elle est exploitée par les pirates.
En ce moment, tout le monde veut son petit serveur local pour faire tourner des modèles IA, mais en vrai, j’ai l’impression que personne ne se pose la question de la sécurité. Du coup, on se retrouve avec un problème totalement anticipable mais j’ai l’impression que tout le monde s’en cogne…
En effet, j’ai découvert qu’il y a littéralement des milliers de serveurs Ollama qui traînent en libre-service sur le net. Pas protégés, pas sécurisés, que dalle. Ils sont juste là, accessibles à qui veut bien se connecter dessus. Le site
Malware Patrol
parle même de 14 000 instances publiquement accessibles. C’est fou !
Le truc, c’est qu’Ollama par défaut, ça vient sans authentification, car le créateur du truc s’est dit “bon, c’est pour du local, pas besoin de compliquer le choses”. Sauf que les gens installent ça sur des serveurs et ouvrent le port 11434 à tout Internet, comme ça, sans réfléchir.
Alors est ce que c’est grave ? Et bien
Cisco Talos
a fait une étude récente là-dessus et ils ont trouvé plus de 1 100 serveurs Ollama exposés, dont 20% qui hébergent des modèles vulnérables. Les États-Unis arrivent en tête avec 36,6% des serveurs exposés, suivis de la Chine (22,5%) et l’Allemagne (8,9%). Le Dr. Giannis Tziakouris de l’équipe Talos parle carrément de “négligence généralisée des pratiques de sécurité fondamentales”.
Hé oui parce que derrière cette négligence, il y a surtout des failles techniques vraiment critiques. Il y a par exemple la
CVE-2024-37032
, surnommée “Probllama”, qui est une vulnerability d’exécution de code à distance super facile à exploiter. En gros, avec une seule requête HTTP, un attaquant peut prendre le contrôle complet du serveur.
Faut quand même avoir conscience qu’il y a une grande variété d’attaques possibles sur ces trucs. Par exemple, on peut faire de l’extraction de modèles (genre, je pique votre IA propriétaire), de jailbreaking (je contourne les protections), d’injection de backdoors dans les modèles, d’épuisement des ressources pour vous faire exploser votre facture cloud, et même de mouvement latéral dans votre réseau.
The Hacker News
a recensé rien que l’année dernière six vulnérabilités dans Ollama qui permettent des attaques par déni de service, du vol de modèles et de l’empoisonnement de modèles et la plupart de ces instances Ollama tournent encore avec des versions obsolètes. Bref, c’est la cata, sans parler des déploiements Docker d’Ollama qui sont encore pire car par défaut, le serveur API tourne avec les privilèges root et se lie à toutes les interfaces réseau.
Et le nombre d’instances exposées ne fait qu’augmenter puisqu’en novembre 2024, on était à 3 000 instances, et maintenant on dépasse les 14 000. Les gens s’amusent bien et installent Ollama plus vite qu’ils n’apprennent à le sécuriser.
Donc, concrètement, si vous avez un serveur Ollama, faites moi plaisir et mettez-le derrière un reverse proxy avec authentification, pensez à bien configurer la variable d’environnement OLLAMA_HOST=127.0.0.1 pour limiter l’accès au localhost, et surtout, mettez à jour vers la dernière version. La vulnérabilité Probllama dont je vous parlais plus haut a été patchée dans la version 0.1.34, mais encore faut-il l’installer.
WhatsApp a corrigé une faille dans ses apps pour iOS et macOS. La faille CVE-2025-55177 de type zero-click, est déjà exploitée dans le cadre d'attaques ciblées.
Il suffit parfois d’un simple scan nmap pour tomber sur une faille monumentale. Et c’est pile poil ce qui est arrivé à Félix Boulet, un chercheur en sécurité qui farfouillait dans le réseau privé de Docker et qui a découvert que l’API interne du Docker Engine traînait tranquillement à l’adresse http://192.168.65.7:2375/, sans aucune authentification. Oui, accessible depuis n’importe quel conteneur qui tourne sur votre machine.
Du coup, la CVE-2025-9074 qui en découle a reçu une note de 9.3 sur l’échelle CVSS, ce qui en fait une vulnérabilité critique. En fait, le problème, c’est que cette API exposée permet à un conteneur malveillant de communiquer directement avec le moteur Docker sans avoir besoin de monter le socket Docker. En gros, deux petites requêtes HTTP POST suffisent pour compromettre entièrement le système hôte. La première crée un conteneur privilégié avec le disque C: monté, et la seconde démarre ce conteneur malveillant…
Sous Windows, la situation est particulièrement préoccupante car le Docker Engine fonctionne via WSL2, ce qui signifie qu’un attaquant pourrait monter l’intégralité du système de fichiers en tant qu’administrateur. À partir de là, il pourrait lire n’importe quel fichier sensible et même remplacer une DLL système pour obtenir des privilèges administrateur complets sur l’hôte. Philippe Dugre, un autre chercheur, a confirmé qu’il pouvait créer des fichiers dans le répertoire home de l’utilisateur sous Windows, chose qu’il n’a pas réussi à faire sur macOS grâce aux protections supplémentaires du système d’Apple.
Ce qui rend cette vulnérabilité encore plus vicieuse, c’est que même la fonction Enhanced Container Isolation (ECI) de Docker ne la bloque pas. Cette protection censée isoler les conteneurs est complètement inefficace face à cette faille et les conteneurs peuvent toujours accéder à l’API et lancer d’autres conteneurs sans restriction. Ça la fout mal…
Sur macOS, l’impact est heureusement plus limité grâce aux mécanismes de sécurité intégrés. L’application Docker Desktop conserve une bonne couche d’isolation et demande la permission à l’utilisateur quand un conteneur tente de monter un répertoire utilisateur. Par défaut, l’application macOS n’a pas accès au reste du système de fichiers et ne s’exécute pas avec des privilèges administratifs, ce qui rend l’hôte beaucoup plus sûr que dans le cas de Windows.
Docker a rapidement réagi (youpi !) et publié la version 4.44.3 de Docker Desktop qui corrige cette vulnérabilité. Donc si vous utilisez Docker Desktop sur Windows ou macOS, installez cette mise à jour immédiatement. Aucune exploitation dans la nature n’a été signalée pour l’instant, mais avec une vulnérabilité aussi simple à exploiter et aux effets potentiellement dévastateur, mieux vaut ne pas traîner.
Pour info, Docker a également mentionné une autre vulnérabilité, la CVE-2025-23266, qui affectait le NVIDIA Container Toolkit en mode CDI jusqu’à la version 1.17.7 . Docker Desktop inclut maintenant la version 1.17.8 qui n’est pas touchée, mais les anciennes versions de Docker Desktop pourraient être affectées si le mode CDI était activement activé. C’est une raison de plus pour mettre à jour vers Docker Desktop 4.44 ou ultérieur.
Une faille critique dans Docker Desktop, associée à la référence CVE-2025-9074, affecte les installations sur Windows et macOS. Voici comment se protéger.
Apple a publié un nouveau correctif pour combler une faille zero-day dans Image I/O. Elle est exploitée dans des attaques jugées "extrêmement sophistiquées".
Vous cliquez sur ce qui semble être un bouton parfaitement normal sur un site web tout à fait normal… Sauf qu’en réalité, vous venez de donner accès à tous ce qui est stocké dans votre gestionnaire de mots de passe. C’est exactement ce que permet une nouvelle technique de clickjacking découverte par le chercheur Marek Tóth et qui affecte potentiellement 40 millions d’utilisateurs dans le monde.
Si vous utilisez 1Password, Bitwarden, LastPass, Enpass, iCloud Passwords ou LogMeOnce, mauvaise nouvelle : ils sont tous vulnérables. En fait, sur les 11 gestionnaires de mots de passe testés, tous présentaient cette faille. Certains ont déjà patché (Dashlane, Keeper, NordPass, ProtonPass et RoboForm), mais pour les autres, c’est toujours open bar pour les hackers.
Selon l’analyse de Marek Tóth, les attaquants exploitent la façon dont les extensions de navigateur injectent leurs éléments dans les pages web. Ils créent une couche invisible par-dessus les boutons du gestionnaire de mots de passe et quand vous pensez cliquer sur un élément tout à fait innocent de la page, vous activez en réalité l’auto-remplissage (autofill) de votre gestionnaire.
Un seul clic suffit. Les pirates peuvent alors récupérer vos identifiants de connexion, vos codes de double authentification, vos numéros de carte bancaire avec le code de sécurité, et même dans certains cas, détourner vos passkeys. Le tout sans que vous ne vous rendiez compte de quoi que ce soit.
Voici une démo avec le piège :
Vous n’avez rien vu ?
Alors regardez cette vidéo maintenant :
D’après BleepingComputer, les réactions des entreprises concernées sont… décevantes. 1Password a classé le rapport comme “hors périmètre”. LastPass l’a marqué comme “informatif”, ce qui en langage corporate signifie “on s’en fout”. LogMeOnce n’a même pas répondu aux chercheurs. Seul Bitwarden affirme avoir corrigé le problème dans la version 2025.8.0, mais les tests montrent que ce n’est pas totalement le cas.
Ce qui est vraiment dommage, c’est que cette vulnérabilité était évitable. Les gestionnaires remplissent automatiquement les identifiants non seulement sur le domaine principal, mais aussi sur tous les sous-domaines donc si un pirate trouve une faille XSS sur n’importe quel sous-domaine d’un site, il peut voler tous vos identifiants stockés pour ce site.
Socket, une entreprise de cybersécurité, a vérifié les résultats et confirme l’ampleur du problème. Les chercheurs ont découvert que 6 gestionnaires sur 9 pouvaient divulguer les détails de carte bancaire, 8 sur 10 les informations personnelles, et 10 sur 11 les identifiants de connexion.
Alors comment se protéger ? Première chose, désactivez l’autofill. Oui, c’est chiant, mais c’est le seul moyen efficace pour le moment. Utilisez le copier-coller pour vos mots de passe. Et sur les navigateurs basés sur Chromium (Chrome, Edge, Brave), configurez l’accès aux sites de vos extensions sur “Au clic” plutôt qu’automatique. Ça vous donne le contrôle sur quand l’extension peut interagir avec la page.
Pour les plus paranos (et on ne peut pas vous en vouloir), activez les demandes de confirmation avant chaque remplissage automatique si votre gestionnaire le permet. C’est une friction supplémentaire, mais au moins vous verrez quand quelque chose tente d’accéder à vos données.
Le plus con dans cette histoire c’est que les gestionnaires de mots de passe sont censés nous protéger, mais cette vulnérabilité transforme notre bouclier en talon d’Achille. Les développeurs veulent rendre leurs outils faciles à utiliser, ce qui est louable mais chaque raccourci pris est une porte potentielle pour les attaquants. Et quand les entreprises ignorent les rapports de sécurité parce qu’elles les jugent “hors périmètre”, ce sont les utilisateurs qui risquent gros…
Bref, attendant que tous les gestionnaires corrigent cette faille, restez vigilants. Un clic de trop et c’est toute votre vie qui peut basculer.
Bon, si vous utilisez Plex Media Server pour organiser vos films, séries et musiques, il faut que vous sachiez un truc important : une vulnérabilité vient d’être découverte et heureusement corrigée. Et c’est du sérieux, donc vous allez lire cet article et ensuite filer mettre à jour votre Plex !
La vulnérabilité touche les versions 1.41.7.x à 1.42.0.x du Media Server donc si vous êtes sur une de ces versions, il faudra passer à la 1.42.1.10060 ou plus récente maintenant !! Pas demain, hein ! Maintenant.
Plex reste discret sur les détails techniques de cette faille, pas de CVE attribué pour l’instant, pas d’explications détaillées sur ce qui pouvait être exploité. Mais leur communication parle d’elle-même etont même averti directement leurs utilisateurs par email, ce qui est assez rare. Généralement, ils se contentent des notes de version.
Le bug a été signalée via leur programme de bug bounty, ce qui a permis à Plex de corriger le problème avant qu’il ne soit exploité dans la nature et pour mettre à jour, c’est simple comme bonjour. Soit vous passez par l’interface d’administration de votre serveur, soit vous téléchargez la dernière version sur le site officiel de Plex.
C’est pourquoi le message de Plex est important : maintenez vos serveurs à jour car dans un environnement où nos bibliothèques multimédia sont souvent accessibles depuis l’extérieur, une faille de sécurité peut rapidement devenir problématique.
Mieux vaut être en sécurité que désolé, mes amis ! Pensez-y !
CVE-2025-53816 dans 7-Zip : un attaquant peut exploiter cette faille pour provoquer un déni de service (DoS) à l'aide d'une archive RAR5 spécialement conçue.