Blog | Easy-Hébergement

Failles PHP critiques CVE-2026-109618 et CVE-2026-109619 : situation et actions pour votre site

Faille PHP php2shell : situation et actions à mener

21 octobre 2026 6 min de lecture Par Marcelo Romero

🕒

Dernière mise à jour : 21 octobre 2026, 22h30. Statut : protections actives sur notre hébergement mutualisé. Le correctif définitif de PHP n’est pas encore déployé. Cet article sera mis à jour à chaque étape (voir l’historique des mises à jour en bas de page).

Deux failles critiques ont été publiées dans PHP le 21 octobre 2026. Elles permettent à un attaquant d’exécuter du code sur un serveur sans avoir besoin de se connecter. Un outil d’attaque public, php2shell, circule déjà, et des tentatives d’exploitation ont été constatées sur Internet depuis le matin.

Nous en avons observé sur notre hébergement mutualisé. Voici ce qui se passe, ce que nous avons déjà mis en place, ce qui reste à faire et ce que vous pouvez faire dès maintenant pour votre site.

L’essentiel

Deux failles PHP de gravité 9,2 sur 10 (CVSS v4) touchent le traitement des formulaires avec envoi de fichiers.
Des tentatives d’exploitation ont visé quelques sites de notre hébergement mutualisé. Aucune compromission n’est prouvée à ce stade, mais nous ne pouvons pas l’exclure. Les clients concernés seront contactés directement.
Des protections sont actives depuis ce soir. Elles réduisent fortement le risque, mais ne remplacent pas le correctif de PHP, que nous préparons.
De votre côté : utilisez une version de PHP encore maintenue, mettez à jour votre CMS et vérifiez votre site (6 actions plus bas).

Alerte de sécurité : failles PHP critiques CVE-2026-109618 et CVE-2026-109619 (php2shell) — Failles PHP critiques publiées le 21 octobre 2026 : situation sur notre hébergement

Que se passe-t-il exactement ?

Deux failles, un outil d’attaque public

Les failles portent les références CVE-2026-109618 et CVE-2026-109619. Elles se situent dans la façon dont PHP traite les requêtes multipart/form-data, c’est-à-dire les formulaires qui envoient des fichiers : formulaire de contact avec pièce jointe, import d’images, espace membre.

CVE-2026-109618 corrompt la mémoire du processus PHP pendant la lecture de la requête. Selon l’avis officiel, elle peut aussi laisser fuiter des informations sensibles, comme des identifiants.
CVE-2026-109619 réutilise l’état d’une requête précédente dans une requête suivante, ce qui peut conduire à l’exécution de code.

php2shell est le nom du code d’exploitation publié sur Internet. Concrètement, il rend ces failles exploitables par n’importe qui, sans compétence particulière. Des chercheurs en sécurité ont constaté des attaques dès la matinée du 21 octobre, avant même la publication des correctifs.

Sources : avis officiels PHP (CVE-2026-109618, CVE-2026-109619), Sansec et CERT-FR.

Quels sites sont concernés ?

Toutes les versions de PHP sont touchées, selon les chercheurs de Sansec et de watchTowr. Les correctifs officiels n’existent que pour quatre branches :

Version de PHP	Correctif officiel	Notre état
8.5	8.5.12	Correctif en préparation
8.4	8.4.27	Correctif en préparation
8.3	8.3.36	Correctif en préparation
8.2	8.2.35	Correctif en préparation
8.1 et antérieures (7.x, 5.6…)	Aucun, et il n’y en aura pas	Protections actives, sans correctif possible

Ces failles concernent aussi les sites sous WordPress, PrestaShop ou tout autre CMS : le problème vient de PHP lui-même, pas de votre extension ou de votre thème.

Notre situation, en toute transparence

Ce qui est déjà en place

Depuis le début de la soirée du 21 octobre, plusieurs protections sont actives sur notre hébergement mutualisé :

Réglages de PHP durcis : nous avons désactivé les fonctions que les attaquants utilisent pour la seconde faille.
Filtrage avant PHP : les requêtes d’envoi de fichiers qui ont le profil d’une attaque sont refusées avant même d’atteindre votre site. Plus de 150 requêtes de scan ont été rejetées en quelques minutes, sans impact constaté sur les envois légitimes.
Blocage des sources hostiles : les adresses à l’origine des tentatives d’exploitation sont bloquées.
Surveillance renforcée : chaque envoi de fichier et chaque rejet sont désormais journalisés et analysés.

Ce qui reste à faire

Soyons clairs : ces protections réduisent le risque, elles ne le suppriment pas. La faille CVE-2026-109618 ne peut être corrigée par aucun réglage. Seule la mise à jour de PHP la règle, et uniquement pour les versions 8.2 à 8.5.

Nous préparons donc les versions corrigées de PHP. Nous n’annonçons pas d’heure de déploiement tant que nous n’avons pas validé les nouveaux binaires. Cet article sera mis à jour dès qu’ils seront en production.

Des tentatives d’exploitation ont été observées

En début de soirée, quelques sites de notre hébergement mutualisé ont reçu une séquence d’attaque typique de l’exploit php2shell. Elle a provoqué des erreurs côté serveur, puis elle a cessé.

Nous n’avons trouvé aucun signe de compromission : pas de processus anormal, pas de fichier déposé. Mais la fuite d’informations décrite par les avis ne laisse pas de trace visible dans nos journaux. Nous ne pouvons donc pas prouver que rien n’a fuité. Les clients dont le site a été visé seront contactés directement, avec les consignes précises à suivre.

Que faire maintenant ? Les 6 actions pour votre site

Utilisez une version de PHP encore maintenue. Si votre site tourne en PHP 8.1 ou plus ancien, passez en 8.3, 8.4 ou 8.5, qui recevront le correctif en premier. Testez la compatibilité avant : consultez notre guide pour modifier la version de PHP. Notre article sur PHP 8.5 détaille les gains et la compatibilité.
Mettez à jour votre CMS, vos thèmes et vos extensions. Voir comment mettre à jour un CMS. Une attaque réussie s’appuie souvent sur plusieurs failles combinées.
Supprimez les formulaires d’envoi de fichiers dont vous n’avez pas besoin. Pas de formulaire d’upload, pas de surface d’attaque.
Ne réactivez pas session.upload_progress.enabled. Nous l’avons désactivé. Si un fichier .user.ini ou php.ini de votre site le remet à On, retirez cette ligne.
Surveillez votre site. Cherchez des fichiers PHP que vous ne reconnaissez pas, des redirections inattendues ou des comptes administrateur inconnus (détails ci-dessous).
Faites une sauvegarde complète maintenant et conservez-la hors de votre hébergement. Elle vous permettra de restaurer une version saine si besoin.

Protéger son site après les failles PHP : mise à jour, sauvegarde et vérification des fichiers — Mise à jour, sauvegarde, vérification : les gestes qui protègent votre site

Notre pare-feu et nos conseils pour sécuriser un blog WordPress complètent ces mesures.

Comment savoir si mon site a été compromis ?

Un site piraté ne se voit pas toujours. Voici les signes à vérifier dans les prochains jours :

Fichiers inconnus : des fichiers .php récents dans les dossiers uploads, wp-content ou tmp que vous n’avez pas créés.
Comportement anormal : redirections vers d’autres sites, pages de spam, lenteurs soudaines.
Comptes administrateur que vous ne connaissez pas.
Alertes de Google ou d’un antivirus signalant votre site.

🚨

En cas de doute, changez les mots de passe de la base de données, du FTP et de l’administration de votre CMS, puis restaurez une sauvegarde saine.

Notre guide Mon site WordPress a été piraté : ce que vous devez vérifier détaille la marche à suivre. Contactez notre support si vous avez besoin d’aide pour analyser votre site.

Questions fréquentes

Mon site a-t-il été piraté ?

Nous n’avons aucune preuve de compromission à ce stade. Nous ne pouvons toutefois pas exclure une fuite d’informations sur les sites visés, car elle ne laisse pas de trace. Si votre site a été visé, nous vous contactons directement.

Dois-je changer mes mots de passe ?

Si nous vous contactons, suivez nos consignes sans attendre. Sinon, c’est une précaution raisonnable si vous avez un doute, par exemple en cas de signes suspects sur votre site : mots de passe de la base de données, du FTP et de l’administration du CMS.

Puis-je rester en PHP 7.4 ou 8.1 ?

Ce n’est pas recommandé. Ces versions ne recevront jamais de correctif officiel pour ces failles. Nos protections limitent le risque, mais seule une version maintenue (8.3, 8.4 ou 8.5) pourra être corrigée.

Quand le correctif de PHP sera-t-il déployé ?

Nous préparons les versions corrigées de PHP 8.2 à 8.5. Nous ne donnons pas d’heure avant de les avoir validées. Cet article sera mis à jour dès que le déploiement sera terminé.

Qu’est-ce que php2shell ?

C’est le nom d’un code d’exploitation publié sur Internet pour ces deux failles. Il permet à un attaquant de prendre le contrôle d’un site vulnérable sans identifiant. D’où l’importance de la mise à jour de PHP.

Un hébergement avec PHP à jour

Si votre site tourne sur une version de PHP ancienne, ou si vous cherchez un hébergement où le choix de la version est simple, découvrez notre hébergement mutualisé, nos serveurs cloud VDS et notre offre d’infogérance pour déléguer la sécurité de votre serveur.

Pas sûr du bon choix ? Notre page choisir son hébergement vous aide à comparer. Pour comprendre comment nous protégeons nos serveurs, voyez notre infrastructure.

Historique des mises à jour

21 octobre 2026, 22h30 : publication. Protections actives (réglages PHP, filtrage avant PHP, blocage des sources hostiles, surveillance). Correctif définitif de PHP en préparation, non déployé.

Dernière mise à jour : 21 octobre 2026, 22h30 — Auteur : Marcelo Romero

Faille WordPress CVE-2026-87902 : mettez votre site à jour dès aujourd’hui

CVE-2026-87902 WordPress : mettez à jour vers la 7.1.2

Savez-vous quelle version de WordPress fait tourner votre site ? Si la réponse est « je ne sais pas », prenez deux minutes pour la vérifier aujourd’hui. Une faille de sécurité, baptisée CVE-2026-87902, vient d’être corrigée. Des robots la testent déjà partout sur Internet, y compris chez nous.

Pas de panique : le correctif existe et il s’applique en quelques clics. Ce guide explique en mots simples ce qu’est cette faille, pourquoi il faut agir vite, et comment protéger votre site pas à pas.

Points clés

La faille CVE-2026-87902 touche WordPress de la version 4.7.0 à la 7.1.1.
La version 7.1.2 la corrige : c’est la mise à jour à faire.
Le 23 septembre 2026, 113 domaines hébergés chez nous ont reçu des tentatives d’exploitation.
Vérifier votre version prend moins de deux minutes depuis l’administration.
Notre support vous aide si la mise à jour vous inquiète.

Robots automatiques testant les portes de sites WordPress : faille CVE-2026-87902 — Les robots testent les sites un par un : un site à jour garde sa porte fermée.

Qu’est-ce que la faille CVE-2026-87902 ?

CVE-2026-87902 est une vulnérabilité (une faille de sécurité) dans le cœur de WordPress. Elle permet à un visiteur malveillant, sans aucun compte sur votre site, de forcer celui-ci à lire un fichier qu’il ne devrait pas ouvrir. Dans certains cas, cela peut aller jusqu’à la prise de contrôle du site.

Imaginez une porte de service mal verrouillée à l’arrière d’un magasin. La clientèle passe par l’entrée principale et ne la voit jamais. Un intrus, lui, la trouve en testant les poignées. La différence, ici, c’est que les intrus sont des programmes automatiques qui testent des milliers de sites à la minute.

Les versions 4.7.0 à 7.1.1 de WordPress sont concernées. La version 7.1.2 corrige le défaut.

Pourquoi il faut agir maintenant

Les attaques ne sont pas théoriques. Help Net Security et Patchstack rapportent des sondages lancés quelques heures seulement après la publication du correctif. C’est un schéma classique : dès qu’un correctif sort, les attaquants comprennent où se trouvait la faille et cherchent les sites qui ne l’ont pas encore reçu.

Nous le constatons sur notre propre infrastructure. Le 23 septembre 2026, 113 domaines hébergés chez nous ont reçu des tentatives d’exploitation. Ces robots ne choisissent pas leurs cibles : un blog d’association et une boutique en ligne reçoivent les mêmes visites.

Une tentative n’est pas une intrusion. La plupart échouent, notamment sur les sites à jour. Mais chaque site resté en retard offre une occasion de plus. Voilà pourquoi la mise à jour vaut mieux que l’attente.

Votre site est-il concerné ? Vérifiez votre version

Savoir si CVE-2026-87902 vous concerne prend moins de deux minutes.

Connectez-vous à l’administration de votre site (généralement votresite.fr/wp-admin).
Ouvrez le menu Tableau de bord, puis Mises à jour.
Lisez la version indiquée en haut de page : elle s’affiche sous la forme « Vous utilisez WordPress 7.x.x ».

Si le numéro est inférieur à 7.1.2, votre site doit être mis à jour. Si vous n’arrivez pas à vous connecter, ou si l’écran ne ressemble pas à cela, contactez notre support : nous vérifions la version avec vous.

Comment mettre à jour WordPress en 4 étapes

Corriger CVE-2026-87902 se prépare comme un déménagement : on protège d’abord ce qui compte, puis on avance sereinement.

Faites une sauvegarde. Copiez vos fichiers et votre base de données avant de toucher à quoi que ce soit. Si un doute apparaît, cette copie permet de revenir en arrière.
Lancez la mise à jour de WordPress. Dans Tableau de bord > Mises à jour, cliquez sur le bouton de mise à jour vers la 7.1.2. La documentation officielle de WordPress détaille cette étape, et notre guide pour mettre à jour un CMS ajoute nos conseils.
Mettez à jour le thème et les extensions. Supprimez ceux que vous n’utilisez plus. Une extension inactive reste une porte d’entrée possible.
Vérifiez que votre site s’affiche bien. Parcourez la page d’accueil, une page de contenu et, pour une boutique, un passage de commande test.

Les 4 étapes pour mettre à jour WordPress en 7.1.2 : sauvegarder, mettre à jour, extensions, vérifier — Sauvegarder, mettre à jour, nettoyer les extensions, vérifier : quatre gestes suffisent.

Votre site est très ancien ? Dans ce cas, la mise à jour peut demander de changer aussi la version de PHP, le langage sur lequel il fonctionne. Ne le faites pas seul : notre équipe vous guide.

Et si mon site a déjà été visé ?

Rappelons-le : être visé ne veut pas dire être piraté. À ce stade, nos vérifications du 23 septembre n’ont révélé aucun fichier malveillant déposé sur les comptes contrôlés. Ce constat date de ce soir-là et nous continuons la surveillance.

Après la mise à jour contre CVE-2026-87902, gardez l’œil ouvert quelques jours. Trois signes doivent vous alerter :

un compte administrateur que vous n’avez pas créé ;
des pages ou des redirections que vous ne reconnaissez pas ;
un site soudain très lent ou qui affiche des messages étranges.

Si l’un d’eux apparaît, ne supprimez rien dans la précipitation. Écrivez-nous : nous regardons ensemble ce qui s’est passé.

Un doute sur la version ou l’état de votre site WordPress ?
Notre support technique vérifie avec vous la version installée et vous accompagne dans la mise à jour.

Envie de repartir sur un hébergement adapté à votre site ?
Un site à jour, sur une plateforme suivie de près, reste la meilleure protection. Pour un site vitrine, un blog ou une boutique, découvrez notre hébergement mutualisé. Pour un projet qui demande plus de puissance et de contrôle, découvrez nos serveurs cloud VDS.

Questions fréquentes

Qu’est-ce que la faille CVE-2026-87902 ?

C’est une faille de sécurité dans WordPress. Elle permet à un visiteur sans compte de faire lire à un site un fichier qu’il ne devrait pas ouvrir. Dans certains cas, elle peut mener à la prise de contrôle du site.

Quelles versions de WordPress sont concernées ?

Les versions 4.7.0 à 7.1.1. La version 7.1.2 corrige la faille.

Comment savoir quelle version de WordPress j’utilise ?

Connectez-vous à l’administration, puis ouvrez Tableau de bord > Mises à jour. La version installée s’affiche en haut de la page. Si vous ne parvenez pas à la trouver, notre support peut la vérifier pour vous.

Mon site est-il piraté parce qu’il a été visé ?

Non. Une tentative montre seulement qu’un robot a testé votre site. Elle échoue le plus souvent, en particulier sur un site à jour. Après la mise à jour, surveillez les comptes administrateurs et les pages inconnues.

Dois-je aussi changer la version de PHP ?

Seulement si votre site est très ancien. Contactez notre support : nous vous indiquons la version adaptée avant de mettre WordPress à jour.

En bref : vérifiez, sauvegardez, mettez à jour

La faille CVE-2026-87902 est corrigée dans WordPress 7.1.2, et les robots la testent déjà. Trois gestes suffisent : vérifier votre version, faire une sauvegarde, puis lancer la mise à jour. Ces informations datent du 23 septembre 2026 et pourront évoluer.

Votre site est-il déjà en 7.1.2 ? Si vous n’en êtes pas certain, notre support vous répond et vous accompagne.

Facturation électronique : ce qui change au 1er septembre 2026 (et comment s’y préparer) ensemble…

Dernière ligne droite : à quelques jours du 1ᵉʳ septembre 2026, la réforme de la facturation électronique entre dans sa phase concrète. Toutes les entreprises françaises assujetties à la TVA sont concernées — y compris les micro-entreprises et les associations. Voici ce que dit la loi, ce qui change pour vous, et comment Easy-Hébergement (marque du cloud provider français Swiiptel) peut vous accompagner.

D’où vient cette réforme ?

Instaurée par l’article 91 de la loi de finances pour 2024 (qui complète l’article 289 bis du Code général des impôts), la réforme impose progressivement l’usage de factures électroniques structurées pour les échanges entre professionnels établis en France (B2B domestique). Objectif affiché de l’État : lutter contre la fraude à la TVA, simplifier les obligations déclaratives des entreprises et moderniser la gestion administrative.

Après plusieurs reports (le calendrier initial datait de 2023-2024), l’échéance est désormais fixée et confirmée par la DGFiP : 1ᵉʳ septembre 2026.

Le calendrier officiel en un coup d’œil

Taille d’entreprise	Réception obligatoire	Émission obligatoire	E-reporting
Grandes entreprises (> 5 000 salariés ou CA > 1,5 Md€)	1ᵉʳ sept. 2026	1ᵉʳ sept. 2026	1ᵉʳ sept. 2026
ETI (250 à 4 999 salariés)	1ᵉʳ sept. 2026	1ᵉʳ sept. 2026	1ᵉʳ sept. 2026
PME, TPE et micro-entreprises	1ᵉʳ sept. 2026	1ᵉʳ sept. 2027	1ᵉʳ sept. 2027

À retenir : la réception est universelle. Dès le 1ᵉʳ septembre 2026, si une grande entreprise ou une ETI vous adresse une facture électronique, vous devez être équipé pour la recevoir et la traiter — même si vous n’êtes pas encore tenu d’en émettre.

Ce qui change concrètement au 1ᵉʳ septembre 2026

1. Recevoir, obligatoirement via une plateforme agréée

Les factures ne circuleront plus de logiciel à logiciel : elles transiteront par une Plateforme Agréée (PA, encore appelée PDP — « Plateforme de Dématérialisation Partenaire »), immatriculée par l’administration fiscale (environ 160 plateformes référencées). Le Portail Public de Facturation (PPF) conserve un rôle limité : annuaire des entreprises et concentration des données de facturation pour l’administration.

2. Des formats normalisés

Une facture électronique n’est pas un simple PDF ! Trois formats sont reconnus :

Factur-X : PDF hybride intégrant des données structurées XML — le format le plus répandu pour les PME ;
UBL : format XML « pur » très utilisé dans les grands comptes et le secteur public ;
CII : Cross Industry Invoice, format XML pour les échanges automatisés à haut volume.

3. L’émission pour les grandes entreprises et les ETI

Environ 300 000 structures devront émettre l’intégralité de leurs factures B2B en format électronique dès septembre 2026. Les PME, TPE et micro-entreprises disposent d’un an de plus (1ᵉʳ septembre 2027) — mais elles doivent pouvoir recevoir dès cette année.

4. L’e-reporting

Les opérations hors périmètre e-invoicing (ventes aux particuliers B2C, transactions internationales) devront faire l’objet d’une transmission périodique de données à l’administration fiscales via votre plateforme.

Quels impacts pour vos clients et votre entreprise ?

Choisir une plateforme agréée sans attendre : c’est LE prérequis du 1ᵉʳ septembre. Comparez tarifs, connecteurs avec votre outil de facturation/compta et services d’archivage.
Mettre à jour vos outils : logiciel de facturation, ERP, comptabilité devront générer et lire les formats Factur-X, UBL ou CII.
Synchroniser vos référentiels : SIREN de vos clients et fournisseurs, adresses e-mail de facturation, coordonnées bancaires.
Former les équipes : le circuit de validation change aussi côté réception (statuts, motifs de rejet, avoirs).
Penser archivage : conservation des factures pendant 10 ans, avec intégrité garantie — un sujet d’hébergement et de sauvegarde, justement.
Anticiper les sanctions : à défaut d’accord amiable après mise en demeure, environ 15 € par facture non conforme (plafonnés à 15 000 € par an) et 250 € par transmission manquante (e-reporting). Un droit à l’erreur neutralise le premier manquement corrigé rapidement.

Bonnes nouvelles tout de même : fin des saisies manuelles, moins d’erreurs, relances et rapprochements automatisés, délais de paiement mieux maîtrisés. La réforme est autant une opportunité de modernisation qu’une contrainte.

Checklist express avant le 1ᵉʳ septembre

Vérifier votre assujettissement à la TVA (la franchise en base n’exclut pas l’obligation de réception) ;
Sélectionner votre plateforme agréée sur l’annuaire officiel impots.gouv.fr et finaliser l’inscription ;
Mettre à jour votre solution de facturation (formats, mentions, référentiels) ;
Tester un aller-retour complet : émission → réception → intégration compta → archivage ;
Former les personnes qui facturent et celles qui traitent les factures fournisseurs ;
Sécuriser l’hébergement de vos outils de gestion et vos sauvegardes.

Easy-Hébergement : un hébergeur 100 % français pour vos outils de gestion

Cette réforme est d’abord une histoire de confiance et de données sensibles (factures, TVA, données clients). Depuis 2003, Easy-Hébergement, marque de la société française SWIIPTEL SAS, héberge sites web, boutiques en ligne et applications métier de particuliers, d’associations, d’entreprises et de collectivités — sur une infrastructure 100 % française supervisée 24h/24 et 7j/7.

Nos briques pour vous aider à franchir le pas sereinement :

Hébergement web mutualisé dès 1,19 € HT/mois — idéal pour votre site vitrine ou votre blog ;
Serveurs Cloud VDS dès 16,99 € HT/mois — pour héberger votre logiciel de facturation, votre boutique en ligne ou votre intranet, avec isolation et IP dédiée ;
Serveurs dédiés infogérés dès 79,99 € HT/mois — pour votre ERP et vos applications critiques, supervisés en continu avec garanties contractuelles ;
Serveurs Windows dès 84,99 € HT/mois — compatibilité native avec les solutions de gestion et de comptabilité du marché ;
Noms de domaine dès 8,91 € HT/an (.fr, .com, .eu…) avec adresses e-mail professionnelles.

Vos données de facturation restent en France, dans nos datacenters de Toulouse et Paris, avec sauvegardes automatiques quotidiennes. Une cohérence toute naturelle avec une réforme… pensée par l’administration fiscale française.

Et demain : notre nouveau cloud souverain Akilao arrive

Derrière Easy-Hébergement, nos équipes Swiiptel déploient depuis plus de 20 ans des infrastructures cloud pour les entreprises exigeantes. Notre nouvelle génération de plateforme, Akilao, arrive bientôt dans son offre publique. Ce que vous pourrez assembler comme des briques LEGO :

Machines virtuelles élastiques : CPU, RAM et disque évolutifs à la demande, processeurs récents ;
Stockage & sauvegardes : snapshots quotidiens, points de restauration protégés — parfait pour l’archivage longue durée exigé par la facturation électronique ;
Zones IP internes (simple, vlan, qinq) et réseaux vxlan/evpn à la demande pour fédérer vos serveurs en sécurité ;
Firewalls mutualisés ou dédiés en haute disponibilité, accès VPN WireGuard (recommandé), OpenVPN ou IPsec/IKEv2 ;
Publication sécurisée HTTPS derrière reverse proxy nginx, certificats portés par les firewalls, WAF et security headers ;
Cybersécurité intégrée : détection & réponse étendue (XDR), supervision 24/7 (Observium & Nagios), datacenters certifiés ISO 27001.

Quatre formules de migration accompagneront le passage de votre serveur physique vers le cloud Akilao, sans refonte applicative :

Formule	Pour quel besoin ?	Inclus
Option 1 — Migration à l’identique	Gagner en flexibilité, simplement	VM sauvegardée chaque nuit, élasticité totale, aucune modification applicative
Option 2 — Sécurité mutualisée	Un socle sécurisé au meilleur coût	Firewall mutualisé HA, zone IP interne dédiée, périmètre supervisé
Option 3 — Sécurité dédiée	Isolation réseau renforcée	Firewall dédié + IP WAN dédiée, zone IP interne, VLAN au choix (simple/vlan/qinq)
Option 4 — Haute disponibilité	Continuité d’activité maximale (ERP, facturation…)	2 firewalls dédiés en failover, 3 IP externes dont 1 conservée (CARP), multi-datacenter Toulouse ↔ Paris

Un socle sécurisé commun aux options 2 à 4 : reverse proxy nginx en front, VPN dédié, certificats gérés, policies de routage fines (filtrage IP sur vos back-offices d’admin, par exemple) et tickets de service suivis par nos équipes.

Offre de lancement — audit gratuit

Vous hébergez aujourd’hui votre ERP, votre logiciel de facturation ou votre serveur de gestion on-premise ? Demandez dès maintenant votre audit de migration offert : nous analysons votre environnement et vous remettons un plan de migration chiffré vers le cloud souverain Akilao — prêt pour la facturation électronique et bien au-delà.
📞 +33 9 85 60 02 40 · ✉️ contact@swiiptel.net

Questions fréquentes

Je suis auto-entrepreneur, suis-je concerné ?

Oui. Vous devez pouvoir recevoir des factures électroniques dès le 1ᵉʳ septembre 2026 via une plateforme agréée. L’obligation d’émission vous concerne au 1ᵉʳ septembre 2027.

Je suis en franchise en base de TVA, suis-je exempté ?

Non : la franchise dispense de facturer la TVA, pas d’être assujetti. Les obligations de réception s’appliquent.

Que se passe-t-il si je ne fais rien ?

Outre les amendes évoquées ci-dessus, vous risquez surtout de bloquer la chaîne de paiement avec vos fournisseurs — grandes entreprises et ETI ne pourront plus vous adresser des factures conformes « hors plateforme ».

Facture électronique et e-reporting, quelle différence ?

L’e-invoicing concerne les factures entre entreprises françaises assujetties. L’e-reporting est la transmission de données sur les autres opérations (B2C, international) à l’administration.

Pour aller plus loin

Cet article a une vocation informative et ne constitue ni un conseil fiscal ni un avis juridique. Pour votre situation précise, consultez votre expert-comptable ou l’administration fiscale.

Serveur Blue : le nouveau serveur mutualisé MariaDB 11.8 est disponible

Serveur mutualisé MariaDB 11.8 : le serveur Blue est en ligne

13 août 2026 6 min de lecture Par Équipe Easy-Hébergement

Votre boutique met un peu trop de temps à afficher une fiche produit, ou vous vous demandez si votre base de données profite encore des derniers correctifs de sécurité ? C’est justement ce que notre nouveau serveur mutualisé MariaDB 11.8, baptisé Blue, vient améliorer. Déployé sur notre infrastructure d’hébergement mutualisé, il remplace progressivement les versions plus anciennes de MariaDB encore utilisées par une partie de nos clients.

La bascule n’est pas automatique : chaque client décide s’il souhaite migrer, et selon quel calendrier. Ce guide explique ce que change concrètement MariaDB 11.8, puis détaille la marche à suivre pour demander votre migration vers Blue en toute sérénité.

Points clés

Blue est un nouveau serveur mutualisé Easy-Hébergement fonctionnant sous MariaDB 11.8.
MariaDB 11.8 est une version LTS, maintenue jusqu’en juin 2028.
La migration vers Blue se fait sur demande, elle n’est pas automatique.
Trois étapes suffisent : demande au support, export de votre base actuelle, puis import sur Blue par nos équipes.
Vérifier la compatibilité de votre CMS avant l’export évite les mauvaises surprises.

Pourquoi un nouveau serveur mutualisé baptisé Blue

Chaque serveur de notre infrastructure porte un nom, ce qui facilite le suivi technique côté support comme côté client. Blue rejoint notre parc de serveurs dédiés à l’hébergement mutualisé et a été configuré dès son installation avec la dernière version stable de MariaDB, plutôt qu’avec une version historique héritée d’un serveur plus ancien.

Ce choix répond à une réalité simple : les moteurs de base de données évoluent, et les gains obtenus entre deux versions majeures concernent autant la vitesse d’exécution des requêtes que la robustesse face aux failles découvertes après coup. Garder un serveur figé sur une ancienne version pendant des années finit par pénaliser les sites les plus actifs, notamment les boutiques en ligne à fort trafic.

Ce que change MariaDB 11.8 pour votre site

MariaDB 11.8 est une version LTS (Long Term Support), maintenue par l’éditeur jusqu’en juin 2028. Trois apports concrets ressortent pour un site hébergé chez nous.

Des requêtes plus rapides

Plusieurs optimisations internes réduisent le travail du moteur de stockage InnoDB, notamment sur l’écriture des pages et la gestion du cache d’index adaptatif. Pour un site e-commerce ou un blog à fort trafic, cela se traduit par des pages qui se chargent plus vite aux heures de pointe, sans changement de configuration à faire de votre côté.

Une base de données mieux protégée

MariaDB 11.8 embarque les correctifs de sécurité les plus récents publiés par l’éditeur, en particulier sur les mécanismes d’authentification et de réplication. Migrer vers Blue permet donc de fermer des failles déjà corrigées en amont, sans attendre une mise à jour ultérieure de votre serveur actuel. Le détail des correctifs est documenté dans les notes de version officielles de MariaDB 11.8.

Une meilleure compatibilité avec les CMS récents

WordPress, PrestaShop et la plupart des CMS modernes évoluent en visant les dernières versions de MariaDB et MySQL. Rester sur une base de données ancienne finit par limiter les mises à jour possibles de votre CMS ou de certaines extensions. Basculer sur Blue lève cette limite ; pensez toutefois à vérifier au préalable comment mettre à jour votre CMS dans de bonnes conditions.

Comment basculer votre hébergement sur le serveur Blue

La migration vers Blue se déroule en trois étapes, à votre initiative.

Faites une demande auprès de notre support. Contactez-nous en précisant le ou les hébergements concernés. Notre équipe planifie alors la migration avec vous.
Préparez un export de votre base de données actuelle. Cet export doit être réalisé avant la bascule ; notre guide sur comment transférer un site détaille la procédure d’export pas à pas.
Nos équipes importent votre base sur le serveur Blue. Une fois l’export reçu, l’import est réalisé sur MariaDB 11.8, puis vos identifiants de connexion vous sont confirmés.

Cette procédure évite toute migration forcée : votre site continue de fonctionner normalement sur son serveur actuel tant que vous n’avez pas fait votre demande.

Points de vigilance avant de migrer

⚠️

Avant de lancer l’export, vérifiez que votre CMS et ses extensions sont à jour : une version très ancienne de WordPress ou PrestaShop peut se montrer plus exigeante avec une base de données récente. Un CMS à jour limite fortement le risque d’incompatibilité au moment de l’import sur Blue. Si un doute subsiste sur une extension spécifique, autant le lever avant l’export plutôt qu’après la migration.

Envie de basculer sur le serveur Blue, ou une question sur la procédure ?
Notre support technique vous accompagne à chaque étape, de la demande à l’import final.

Questions fréquentes

Qu’est-ce que le serveur Blue ?

Blue est un nouveau serveur mutualisé de l’infrastructure Easy-Hébergement, configuré sous MariaDB 11.8. Il rejoint le parc de serveurs dédiés à l’hébergement mutualisé et vise à remplacer progressivement les serveurs sur des versions plus anciennes de MariaDB.

Quels sont les avantages concrets de MariaDB 11.8 ?

Des requêtes plus rapides grâce à plusieurs optimisations d’InnoDB, une sécurité renforcée par les derniers correctifs de l’éditeur, et une meilleure compatibilité avec les versions récentes de WordPress et PrestaShop.

Comment demander la migration vers le serveur Blue ?

Il suffit de contacter notre support en précisant l’hébergement concerné. L’équipe planifie ensuite la migration avec vous, à la date qui vous convient.

Comment préparer l’export de ma base de données ?

L’export se fait généralement depuis phpMyAdmin ou l’outil d’administration de votre CMS. Notre guide pour transférer un site détaille la marche à suivre avant l’envoi à notre support.

La migration interrompt-elle mon site ?

Votre site actuel continue de fonctionner normalement pendant que l’export et l’import sont réalisés. Une courte coupure peut survenir uniquement au moment précis du basculement final, dont la date est convenue avec vous.

Cette migration est-elle obligatoire ?

Non. Le passage au serveur Blue se fait uniquement sur demande. Votre hébergement actuel continue de fonctionner tant que vous n’avez pas sollicité la migration auprès du support.

En bref : un passage à MariaDB 11.8 sur simple demande

Le serveur Blue apporte à l’hébergement mutualisé de meilleures performances, une sécurité à jour et une compatibilité renforcée avec les CMS récents, sans imposer de migration forcée à nos clients. Trois étapes suffisent pour basculer : une demande auprès du support, un export de votre base actuelle, puis un import réalisé par nos équipes sur Blue.

Une question sur la procédure ou sur la compatibilité de votre site ? Notre support reste disponible pour vous accompagner avant, pendant et après la migration.

Campagne de phishing ciblant les clients Easy Hebergement

Depuis le début du mois de juillet 2026, une campagne de phishing d’envergure cible les clients du service Easy Hebergement. Les emails, envoyés depuis des infrastructures légitimes compromises (Amazon SES) et signés DKIM, imitent nos communications.
L’objet du message — « Au sujet de [votre-domaine] » — joue sur l’urgence : le domaine du destinataire serait sur le point d’être réservé par un tiers. Une technique classique d’ingénierie sociale qui exploite la peur de perdre un nom de domaine.

● ● ● aperçu du message reçu

Easy Hebergement

Suivi domaine

Bonjour,

Votre domaine exemple.fr risque d’être réservé par une autre personne. Renouvelez-le dès maintenant.

Référence : 28.07.2026.

exemple.fr

Notification

Référence28.07.2026

Domaineexemple.fr

Consulter

⚠ Apparence trompeuse : le logo, la charte graphique et le ton reproduisent fidèlement ceux d’Easy Hebergement. Seul le lien trahit la supercherie.

Anatomie de l’email piégé

L’email est structuré en deux parties : une version texte brut et une version HTML riche. La version HTML immite les codes visuels d’Easy Hebergement — barre sombre en en-tête, bouton d’appel à l’action arrondi, tableau de synthèse — pour inspirer confiance. L’URL de phishing est dissimulée derrière le texte du bouton « Consulter ». Voici le lien vers lequel pointe ce bouton :

URL de destination (NE PAS CLIQUER)
https://trc-click-out-c553ba-nonce-d3da5d.vercel.app/?token=cmrb1ov0b005tpvx2nklfc7dc:cms2jwk7y125bpvmtbxkxed7w:BEtRVVBeGwJD:1785118939557&dn=exemple.fr&pid=1298&sp=fr

L’URL utilise la plateforme Vercel (vercel.app), un service légitime d’hébergement serverless, ce qui lui permet de passer inaperçue aux yeux des filtres anti-spam basiques. Le jeton token contient un identifiant unique de victime, prouvant qu’il s’agit d’une campagne ciblée et non d’un envoi de masse aveugle. Les paramètres dn (domain name), pid (product ID) et sp (support language) suggèrent que l’attaquant a préparé une page de destination dynamique adaptée à chaque victime.

Des infrastructures légitimes détournées

Plusieurs éléments techniques rendent cette campagne particulièrement dangereuse. L’email transite par Amazon SES (Simple Email Service), un service d’envoi massif réputé, et les en-têtes DKIM sont correctement signés, ce qui fait que le message passe les contrôles SPF, DKIM et DMARC sans encombre. L’adresse d’expéditeur est noreply@chibakei-crm.com, un domaine qui n’a aucun lien avec Easy Hebergement. Les serveurs SMTP utilisés sont localisés en ap-northeast-1 (Tokyo), ce qui éloigne les traces des enquêteurs européens.

● ● ● en-têtes de l’email (extrait)

Return-Path: <0106019fa1…@send.chibakei-crm.com>
From: Easy Hebergement <noreply@chibakei-crm.com>
DKIM-Signature: v=1; a=rsa-sha256; … PASS
Received: from e234-51.smtp-out.ap-northeast-1.amazonses.com
Authentication-Results: dkim=pass

⚠ DKIM pass : les signatures DKIM sont valides, ce qui rend le filtrage automatique inefficace. La vigilance humaine reste le seul rempart.

Comment protéger vos clients et votre marque

Face à une campagne aussi sophistiquée, la sensibilisation est primordiale. Voici quelques réflexes à adopter :

Vérifier l’expéditeur. Easy Hebergement n’envoie jamais d’emails depuis un domaine tiers comme chibakei-crm.com. Les communications officielles proviennent toujours de @easy-hebergement.fr.
Ne jamais cliquer sur un lien par urgence. Saisissez manuellement l’URL de votre interface de gestion dans votre navigateur.
Survolez les liens (sur desktop) avant de cliquer pour vérifier la destination réelle.
Signalez tout email suspect à Easy Hebergement via leur canal officiel.

Les URLs malveillantes identifiées dans cette campagne (présentées à titre informatif, ne pas cliquer) :

URL malveillante #1
https://trc-click-out-c553ba-nonce-d3da5d.vercel.app/?token=cmrb1ov0b005tpvx2nklfc7dc:cms2jwk7y125bpvmtbxkxed7w:BEtRVVBeGwJD:1785118939557&dn=exemple.fr&pid=1298&sp=fr

URL malveillante #2 (variante observée)
https://easy-hebergement-verif.surge.sh/login.php?dn=exemple.fr&ref=28.07.2026

Easy Hebergement vous confirme qu’aucune de ces URLs ne fait partie de son infrastructure légitime.Nous recommandons à tous ses clients de changer leur mot de passe immédiatement s’ils ont cliqué sur l’un de ces liens.

Conclusion : la cybersécurité est l’affaire de tous

Cette campagne de phishing illustre une tendance de fond : les attaquants n’ont plus besoin de logiciels malveillants complexes quand un email bien conçu suffit à tromper un utilisateur pressé. L’utilisation de services légitimes (Amazon SES, Vercel) et de signatures DKIM valides rend la détection technique difficile. La meilleure défense reste la formation des collaborateurs et des clients : savoir reconnaître les signes d’un email frauduleux, résister à l’urgence artificielle, et toujours privilégier une connexion directe au site officiel. Easy Hebergement a mis en ligne une page d’information dédiée et renforcé ses dispositifs de surveillance. Restez vigilants.

Article rédigé à titre préventif. Les URLs présentées sont des exemples réels issus de la campagne en cours. Ne pas cliquer. Ne pas partager.

Comment une panne silencieuse a plongé notre réseau dans le noir

Date de l’incident : 23 juillet 2026 Durée : 3h19 (16:49 → 20:08 CEST) Impact : Perte de connectivité sur le VLAN 1234 pour les usages concernés Gravité : Moyenne

TL;DR

Un switch de coeur de réseau (QFX) est tombé en panne de manière silencieuse : ses ports restaient actifs physiquement, mais l’équipement ne répondait plus et ne transitait plus le trafic. Les routeurs voisins, n’ayant aucun mécanisme de détection de cette panne, ont continué à envoyer du trafic vers une destination qui n’existait plus. Résultat : du blackholing — le trafic partait vers le néant.

La timeline

      16:49  ── Alerte détection incident
  │
  ├── 16:55 ─── 1er ingénieur prend en main
  ├── 17:10 ─── Diagnostic : switch ne répond plus
  │              (ni console RS232, ni SSH/IP)
  ├── 17:30 ─── 2ème ingénieur mobilisé
  ├── 18:00 ─── 3ème ingénieur mobilisé
  ├── 18:15 ─── Ingénieur sur site au datacentre
  │              (vérification physique)
  ├── 18:45 ─── Identification du blackholing
  │              sur core02.pa2.par
  ├── 19:15 ─── Création de routes statiques
  │              more-specific sur core02
  ├── 19:45 ─── Trafic rétabli sur VLAN 1234
  └── 20:08 ─── Incident résolu

L’architecture (simplifiée)

Avant l’incident

                    INTERNET
                       │
                       │ BGP
                       │
          ┌────────────┴────────────┐
          │                         │
    ┌─────┴─────┐            ┌──────┴─────┐
    │ core01    │   OSPF/    │ core02     │
    │   EX      │◄──BGP────► │   EX       │
    │           │  (inactif) │            │
    └─────┬─────┘            └──────┬─────┘
          │                         │
          │                         │
    ┌─────┴─────────────────────────┴─────┐
    │              qfx32.pa2.par          │
    │                 (QFX)               │
    │            [ OK ] Actif             │
    └─────────────────┬───────────────────┘
                      │
              VLAN 1234 / 2345 / 3456
                      │
                ┌─────┴─────┐
                │  Serveurs │
                └───────────┘

Pendant l’incident

                    INTERNET
                       │
                       │ BGP
                       │
          ┌────────────┴────────────┐
          │                         │
    ┌─────┴─────┐            ┌──────┴─────┐
    │ core01    │            │ core02     │
    │  [+] OK   │            │ (!) Reçoit │
    │           │            │ du trafic  │
    └─────┬─────┘            └──────┬─────┘
          │                         │
          │                         │
    ┌─────┴─────────────────────────┴─────┐
    │          [!] qfx32.pa2.par          │
    │         (PANNE SILENCIEUSE)         │
    │      Ports UP mais ne répond plus   │
    └─────────────────┬───────────────────┘
                      │
              [XX] BLACKHOLING
              (trafic jeté dans le vide)
                      │
                ┌─────┴──────┐
                │  Serveurs  │
                │INJOIGNABLES│
                └────────────┘

Pourquoi c’est arrivé ?

1. La panne silencieuse

Le switch qfx32.pa2.par présentait un défaut rare mais critique :

Comportement	État
Ports physiques	✅ UP (LED allumées)
Console RS232	❌ Aucune réponse
Adresses IP	❌ Aucune réponse
Transit trafic	❌ Aucun
Détection par les voisins	❌ Invisible

2. Le split-brain VRRP

       core01                          core02
    ┌───────────┐                 ┌───────────┐
    │  VRRP     │                 │  VRRP     │
    │  MASTER   │ ◄── Conflit ──► │  MASTER   │
    │  (croit)  │                 │  (croit)  │
    └───────────┘                 └───────────┘
         │                              │
         └──────────┬───────────────────┘
                    │
            Les DEUX routeurs
            sont "master"
            en même temps

Normalement, le VRRP fait qu’un seul routeur est master. Ici, comme aucune interface physique n’est tombée (les ports du QFX étaient restés UP), le mécanisme de bascule ne s’est jamais déclenché.

3. Le blackholing

   core02 reçoit du trafic
           │
           ▼
   core02 cherche une route
           │
           ▼
   Route trouvée via qfx32
           │
           ▼
   qfx32 ne transite plus
           │
           ▼
   💀 Trafic jeté dans le vide

La résolution

Étape 1 : Isoler core02

On a voulu tout rediriger vers core01. Mais problème :

              core02
    ┌──────────────────────────┐
    │                          │
    │   VLAN 1234 ──► qfx32    │  ← On peut couper
    │                          │
    │   VLAN 2345 ──► machines │  ← On NE PEUT PAS couper
    │   VLAN 3456 ──► machines │  ← (machines directes)
    └──────────────────────────┘

Étape 2 : Routes statiques more-specific

# Sur core02.pa2.par
# Créer des routes /32 plus précises que la route générale
# pour rediriger le trafic vers core01

routing-options static route 192.168.1.10/32 next-hop core01.ip
...

Les enseignements

Ce qui a bien fonctionné

⏱️ Temps de réaction : 6 minutes entre l’alerte et la prise en main
👥 Mobilisation de 4 ingénieurs rapidement
🏢 Ingénieur sur site en 1h26 (région parisienne)
🔧 Résolution par routes statiques (solution temporaire mais élégante)

Ce qui a mal fonctionné

❌ Pas de détection de panne silencieuse
❌ Lien OSPF/BGP entre core01 et core02 inactif depuis le 11/03/2026
❌ VRRP en split-brain (les deux routeurs master)
❌ Architecture non réellement redondante

Le mot de la fin

La leçon principale : la redondance ne sert à rien si les mécanismes de bascule ne fonctionnent pas. Un équipement en panne silencieuse est plus dangereux qu’un équipement franchement éteint, car il est invisible aux systèmes censés le compenser.

Merci à Mediactive networks pour leur soutien pour la résolution de l’incident et pour le travail à venir. Notre objectif reste d’offrir à tous nos clients (mutualisé, infogéré, cloud) un service de qualité, stable et résilient.

Pourquoi les attaques supply-chain explosent

Le développement moderne repose aujourd’hui sur un immense écosystème open source. Frameworks JavaScript, packages npm, modules Python, images Docker, pipelines CI/CD, outils d’automatisation ou bibliothèques de sécurité : une grande partie des applications actuelles est désormais construite à partir de composants développés par des tiers.
Et dans la majorité des cas, ces composants sont intégrés en quelques secondes seulement.

npm install nomPackage

Derrière cette commande pourtant anodine se cache parfois une chaîne entière de dépendances téléchargées automatiquement.

Une application moderne ne contient plus uniquement le code écrit par son équipe de développement. Elle embarque souvent des centaines, voire des milliers de composants logiciels externes.
Certaines estimations considèrent aujourd’hui que 70 à 80% d’une application moderne repose sur du code que l’entreprise n’a pas développé elle-même.

C’est précisément ce qui rend les attaques “supply-chain” dangereuses.

La supply-chain logicielle : l’autoroute idéale des attaques modernes

Pendant longtemps, les entreprises concentraient leurs efforts de sécurité principalement sur leur propre code applicatif. Aujourd’hui, les attaquants ont compris qu’il était souvent bien plus efficace de viser directement la chaîne logicielle utilisée par des milliers de projets.

Plutôt que d’attaquer une entreprise en particulier, ils ciblent désormais les packages open source, les registries, les pipelines CI/CD, les outils de build, les images Docker ou encore les plateformes de publication.

Le problème dépasse largement le simple “package vulnérable”.
La supply-chain logicielle, c’est tout ce qui permet de construire une application : comment le package est créé, publié, récupéré, intégré dans un pipeline puis finalement exécuté dans une infrastructure de production.

Aujourd’hui, cette chaîne complète est devenue une cible majeure.

L’OWASP (Open Worldwide Application Security Project) a d’ailleurs fortement remonté les risques liés à la supply-chain logicielle dans ses principales catégories de menaces de sécurité. Et ce n’est probablement que le début !

Vos dépendances ne viennent jamais seules

Lorsqu’un développeur ajoute une dépendance à un projet Node.js ou Python, il pense généralement récupérer une simple bibliothèque.
En réalité, cette dépendance peut elle-même dépendre d’autres dépendances, qui téléchargent à leur tour d’autres composants. C’est ce que l’on appelle les dépendances transitives.

Dans l’écosystème Node.js, des commandes simples comme npm ls ou npm outdated permettent déjà de visualiser les dépendances réellement installées et les versions obsolètes présentes dans un projet.

Dans certains projets modernes, une simple application web peut ainsi embarquer plusieurs milliers de packages réels. Parmi eux, certains ne sont plus maintenus, d’autres sont très peu surveillés, certains sont utilisés par des millions de projets, et d’autres peuvent devenir malveillants du jour au lendemain.

Le plus problématique, c’est que beaucoup de développeurs n’ont plus réellement de visibilité sur l’ensemble des composants qui composent leur propre application.

EventStream : la confiance compromise

L’un des cas les plus connus reste l’affaire EventStream.

Le package était populaire, utilisé dans de nombreux projets et considéré comme fiable. Puis un jour, le mainteneur transfère simplement la propriété du package à une autre personne.
Le transfert de propriété sur certaines plateformes comme GitHub est extrêmement simple. Quelques modifications plus tard, du code malveillant est discrètement ajouté dans une nouvelle version du package.

Résultat : les développeurs mettant à jour leur dépendance téléchargent automatiquement le code malveillant dans leurs applications.

Cette attaque a marqué un tournant important parce qu’elle a montré qu’une dépendance populaire et largement utilisée pouvait devenir une porte d’entrée extrêmement efficace.

Et surtout, le problème ne venait pas d’une faille technique complexe, mais simplement de la confiance accordée à une chaîne logicielle devenue beaucoup trop opaque.

Une simple faute de frappe peut suffire !

Toutes les attaques supply-chain ne reposent pas forcément sur des scénarios sophistiqués. Parfois, une simple erreur humaine suffit.

Un développeur tape rapidement le nom d’un package dans son terminal, oublie une lettre, inverse un caractère ou remplace un zéro par un “O”. Au lieu d’installer le vrai package, il télécharge alors une version malveillante volontairement publiée pour ressembler à la bibliothèque officielle.

Cette technique porte un nom : le typosquatting.

Des cas similaires ont déjà touché des dépendances très populaires de l’écosystème JavaScript et Python. Le problème devient particulièrement dangereux dans des environnements automatisés où les installations de dépendances sont déclenchées directement dans des pipelines CI/CD.

Les pipelines CI/CD sont devenus des cibles

L’objectif d’un package malveillant n’est pas toujours de compromettre directement l’application finale. Dans certains cas, la cible réelle est l’environnement de build lui-même.

Un morceau de code injecté dans une dépendance peut récupérer des variables d’environnement, voler des clés API, exfiltrer des tokens ou accéder à des secrets CI/CD.
Et comme ces dépendances sont souvent exécutées automatiquement pendant les phases de build, les conséquences peuvent devenir extrêmement importantes.

Un simple package compromis peut parfois donner accès à des registres privés, des dépôts Git, des environnements cloud ou même des infrastructures de production entières.

Des outils intégrés comme npm audit permettent également d’identifier certaines vulnérabilités connues directement dans les dépendances utilisées par une application.

Les outils de sécurité dans le viseur

Le plus inquiétant, c’est que même les outils de sécurité eux-mêmes ne sont pas épargnés. Des attaques récentes ont notamment touché certains outils largement utilisés pour analyser les vulnérabilités ou sécuriser des infrastructures cloud.

Autrement dit, les logiciels censés protéger les applications dépendent eux aussi d’un très grand nombre de composants externes. Cela montre à quel point la confiance dans la chaîne logicielle moderne devient complexe.

Aujourd’hui, la question n’est plus seulement : “Mon application est-elle sécurisée ?”

Mais aussi : “Puis-je réellement faire confiance à tout ce qui permet de construire mon application ?”

L’IA aussi devient une cible

Avec l’explosion récente des outils liés à l’intelligence artificielle, de nouveaux risques apparaissent également. Certains modèles ou packages liés à l’IA ont déjà été ciblés via des dépendances malveillantes ou des modules empoisonnés.

L’objectif peut être multiple :

récupération de données
compromission d’environnements d’apprentissage
vol d’informations
exécution de code malveillant.

Là encore, le problème reste le même. Les développeurs et les entreprises dépendent de plus en plus de composants externes qu’ils ne maîtrisent pas complètement.

Les SBOM pour retrouver de la visibilité

Face à ces nouveaux enjeux, de nombreuses entreprises commencent à déployer des SBOM. SBOM signifie Software Bill Of Materials.

Le principe est relativement simple : générer un inventaire détaillé des composants logiciels présents dans une application. Un SBOM permet notamment de savoir quelles dépendances sont utilisées, quelles versions sont installées, quelles applications sont concernées par une faille critique ou encore quelles bibliothèques deviennent obsolètes.

Des standards comme CycloneDX ou SPDX prennent progressivement une place importante dans les environnements DevSecOps modernes.
L’objectif n’est pas uniquement de détecter des vulnérabilités. Le véritable enjeu est surtout de retrouver de la visibilité sur des applications devenues extrêmement complexes.

Aujourd’hui, plusieurs outils permettent de générer facilement ce type d’inventaire, notamment dans des projets Node.js, Python, Java ou Docker. Des solutions open source comme Syft, Trivy ou Dependency–Track sont de plus en plus utilisées pour analyser les dépendances et suivre les vulnérabilités connues dans le temps.

Concrètement, la logique est souvent la suivante :

générer un SBOM du projet
identifier les composants utilisés
analyser les vulnérabilités connues
puis surveiller les nouvelles failles au fil des mises à jour

Dans certains environnements, cette génération de SBOM est désormais directement intégrée dans les pipelines CI/CD afin de garder une vision continue des composants réellement déployés en production.

Même si ces pratiques étaient autrefois réservées aux grandes infrastructures ou aux environnements sensibles, elles deviennent progressivement accessibles et pertinentes pour la majorité des projets modernes.

La confiance devient un enjeu majeur

Le développement logiciel moderne ne consiste plus uniquement à écrire du code. Il faut désormais aussi sécuriser toute la chaîne qui permet de construire et déployer une application :

dépendances
pipelines CI/CD
registries
artefacts
images Docker
outils de build
plateformes cloud
infrastructures d’automatisation

La supply-chain logicielle est progressivement devenue l’un des sujets majeurs de cybersécurité moderne.
Et avec l’explosion de l’open source, du cloud et de l’automatisation, ce sujet devient désormais incontournable pour toutes les équipes techniques.

La sécurité des dépendances et de la chaîne logicielle devient aujourd’hui un véritable enjeu dans les infrastructures modernes, aussi bien pour les applications web que pour les plateformes cloud et les environnements d’hébergement.

Chez Easy-Hébergement, nous faisons évoluer régulièrement nos infrastructures et nos plateformes afin de proposer des environnements d’hébergement fiables, modernes et adaptés aux enjeux actuels du web, du cloud et de la sécurité.

Découvrez nos solutions d’hébergement web, cloud et infrastructures : https://www.easy-hebergement.fr/

Pour celles et ceux qui souhaitent approfondir le sujet, une conférence complète de 40 minutes sur les attaques supply-chain : https://www.youtube.com/watch?v=X5aafFca39c

PHP 8.5 disponible sur nos hébergements web

La version PHP 8.5 est désormais disponible sur les hébergements mutualisés Easy-Hébergement !

Cette nouvelle version peut être activée directement depuis votre espace client afin de profiter des dernières évolutions du langage PHP, avec des améliorations en matière de performances, de sécurité et de compatibilité applicative.

Pourquoi mettre à jour votre version PHP ?

PHP est le moteur utilisé par de nombreux sites et applications web tels que WordPress, Prestashop, Laravel ou Symfony.

Utiliser une version récente permet notamment de bénéficier :

d’une meilleure stabilité
d’exécutions plus rapides
d’améliorations de sécurité
d’une compatibilité renforcée avec les applications modernes

Maintenir une version PHP à jour contribue également à garantir la pérennité et la continuité de vos services web.

Retrouvez l’ensemble de nos solutions d’hébergement sur :
https://www.easy-hebergement.fr/

Activation simple depuis votre espace client

La sélection de la version PHP souhaitée peut être effectuée directement depuis l’interface de gestion de votre hébergement.

Quelques clics suffisent pour passer à PHP 8.5 et tester sa compatibilité avec votre environnement applicatif.

Comment activer PHP 8.5 ?

Pour basculer vers PHP 8.5, rendez-vous dans votre espace client Easy-Hébergement.

Accédez à l’onglet Gestion hébergement mutualisé
Sélectionnez votre hébergement
Dans la barre latérale, ouvrez la section Version PHP & PHP.ini
Choisissez la version PHP souhaitée dans la liste disponible
Cliquez sur Activer cette version

L’interface permet actuellement de sélectionner différentes versions de PHP, de la 5.6 jusqu’à la 8.5, afin de s’adapter aux besoins et à la compatibilité de chaque projet web.

Avant toute modification, nous recommandons de vérifier la compatibilité de votre site, CMS, thèmes ou extensions avec la version choisie.

Quelles nouveautés avec PHP 8.5 ?

PHP 8.5 apporte plusieurs améliorations destinées à moderniser le développement web et à simplifier certaines opérations courantes.

Parmi les nouveautés les plus attendues :

de nouvelles fonctions comme array_first() et array_last() permettant de récupérer plus facilement les premières et dernières valeurs d’un tableau
l’arrivée de l’opérateur pipe (|>) qui simplifie l’enchaînement de traitements et améliore la lisibilité du code
de nouveaux outils de débogage et de gestion des erreurs pour faciliter le développement et la maintenance des applications
des améliorations autour de cURL et de l’internationalisation pour les projets modernes et multilingues
plusieurs optimisations internes visant à améliorer les performances et l’expérience globale de développement

Même si cette version n’introduit pas de rupture majeure, PHP 8.5 poursuit l’évolution du langage avec des améliorations concrètes, utiles aussi bien pour les applications existantes que pour les nouveaux projets.

La documentation officielle complète des nouveautés est disponible ici :
https://www.php.net/releases/8.5/en.php

Une infrastructure mise à jour

Chez Easy-Hébergement, nous faisons évoluer régulièrement nos plateformes afin de proposer des environnements performants, sécurisés et adaptés aux standards actuels du web.

Notre objectif reste le même : garantir un hébergement fiable, moderne et accessible pour l’ensemble de vos projets web.

Pour toute question ou besoin d’accompagnement, notre support reste disponible 7j/7.

Incident de sécurité chez BookMyName, pourquoi nos services ont été temporairement suspendus

Incident de sécurité chez BookMyName

5 mai 2026 5 min de lecture Par Marcelo

Ce matin du 5 mai 2026, certains d’entre vous ont constaté que notre site et notre espace client étaient inaccessibles. Cette interruption n’est pas une panne : c’est une décision que nous avons prise délibérément, par mesure de sécurité.

La raison : un incident de sécurité a été détecté chez BookMyName, l’un de nos prestataires en charge de la gestion de noms de domaine. Face à cette situation, nous avons immédiatement suspendu nos propres services. Non pas parce que nos systèmes sont compromis mais parce que nous refusons de vous remettre en ligne sans en avoir la certitude.

Cet article vous explique ce qui s’est passé, ce que nous avons fait, et où en est la situation. Nous vous devons cette transparence.

Points clés

Le 5 mai à 08h55 CEST, une activité inhabituelle a été détectée sur le système d’information de BookMyName, notre prestataire de gestion de domaines.
Certains clients de BookMyName ont constaté des modifications de leurs informations de contact associées à leurs noms de domaine.
À ce stade, aucune modification de zone DNS ni aucun transfert de domaine sortant n’ont été détectés.
Nous avons volontairement suspendu notre site et notre espace client pour vérifier qu’aucune donnée utilisateur n’a été compromise.
La remise en ligne s’effectue de façon progressive, après vérification complète de notre environnement.
Mise à jour 15h00 : les noms de domaine enregistrés auprès de BookMyName ne présentent aucun risque identifié. Les données de contact modifiées ont été entièrement rétablies.
Mise à jour 17h30 : la cause de l’incident a été identifiée et isolée par les équipes BookMyName. Le service sera pleinement rétabli dans la soirée ; certaines fonctionnalités secondaires resteront temporairement indisponibles.

Alerte incident de sécurité informatique chronologie de l'incident BookMyName du 5 mai 2026 — Chronologie de l’incident de sécurité détecté chez BookMyName le 5 mai 2026

Ce qui s’est passé : chronologie de l’incident chez BookMyName

BookMyName est un registrar un prestataire spécialisé dans l’enregistrement et la gestion de noms de domaine. Nous lui confions la gestion de certains domaines pour le compte de nos clients.

Ce matin, leur infrastructure a été touchée par un incident de sécurité informatique. Voici la chronologie telle que nous la connaissons à ce stade :

08h55 CEST Une activité inhabituelle est détectée sur le système d’information de BookMyName.
11h11 CEST BookMyName suspend l’ensemble de ses accès publics. Les services sont indisponibles ; les équipes mènent une investigation.
13h07 CEST L’enquête est toujours en cours. Aucune information complémentaire n’a été communiquée à ce stade.

L’alerte concrète qui a déclenché notre niveau de vigilance : certains clients de BookMyName ont constaté des modifications de leurs informations de contact liées à leurs noms de domaine. Ce type de modification, même limitée aux données d’enregistrement, constitue un signal d’intrusion sérieux qui justifie une réaction immédiate.

Deux points positifs sont confirmés à ce stade : aucune modification de zone DNS n’a été observée, et aucun transfert de domaine sortant n’a été détecté. Ce sont les deux scénarios les plus critiques dans ce type d’incident et ils ne se sont pas produits.

Pourquoi nous avons suspendu nos propres services

Notre infrastructure n’est pas directement hébergée chez BookMyName. Mais ce prestataire gère des noms de domaine qui pointent vers nos serveurs. C’est suffisant pour justifier une réponse immédiate de notre part.

Face à un incident chez un acteur de la chaîne, nous avons appliqué une règle simple : la sécurité avant la continuité de service. Suspendre nos services, c’est accepter une contrainte à court terme pour éviter un risque réel.

Cette décision poursuit quatre objectifs précis :

Vérifier qu’aucune donnée de nos utilisateurs n’a été compromise coordonnées, identifiants, données de facturation.
Analyser l’impact potentiel côté Easy-Hébergement cartographier ce qui est exposé, même indirectement.
Prévenir tout risque d’exploitation ou d’effet en cascade un service maintenu en ligne pendant une investigation active peut devenir un vecteur d’attaque supplémentaire.
Protéger nos utilisateurs avant toute remise en ligne nous préférons une heure d’interruption à une remise en service précipitée.

ℹ️

À noter : Nous savons que cette indisponibilité est contraignante. Nous l’assumons pleinement et nous la préférons à toute remise en ligne sans garanties.

Ce que nos vérifications ont confirmé

Dès la détection de l’incident, nos équipes ont procédé à un audit immédiat de notre environnement.

Voici ce que nous pouvons affirmer à ce stade :

Aucune modification non autorisée n’a été détectée sur nos zones DNS.
Aucun accès anormal à nos systèmes internes n’a été relevé.
Aucun transfert de domaine n’a été initié sans notre accord explicite.
Les données de nos utilisateurs identifiants, coordonnées, informations de facturation n’ont fait l’objet d’aucun accès suspect identifié.

Ces vérifications sont en cours et se poursuivront jusqu’à la levée complète de l’incident par BookMyName. En cas de découverte d’un impact sur vos données, nous vous en informerons immédiatement et directement. Pour renforcer la protection de votre espace en parallèle, nous vous invitons à configurer un pare-feu sur votre espace client si ce n’est pas encore fait.

Rétablissement progressif : l’état de la situation

La remise en ligne de nos services s’effectue de façon progressive et contrôlée. Nous ne rétablissons un service que lorsque nous avons la certitude qu’il est sain.

Cette approche par étapes peut générer des délais supplémentaires. C’est un choix délibéré : aller vite sans garanties n’est pas une option que nous acceptons.

Nous suivons en temps réel les communications officielles de BookMyName. Dès que la situation est clarifiée de leur côté et que nos propres vérifications sont finalisées, nous vous en informerons par une mise à jour de cet article.

Nos engagements envers vous

Un incident chez un prestataire externe, même indirect, engage notre responsabilité vis-à-vis de vous. Voici ce que nous vous garantissons dans ce contexte :

Transparence : vous communiquer les faits tels que nous les connaissons, sans les minimiser ni les dramatiser.
Réactivité : mettre à jour cet article dès que de nouvelles informations sont disponibles de notre côté ou du côté de BookMyName.
Sécurité d’abord : ne remettre en ligne aucun service sans vérification préalable.
Communication directe : si un impact sur vos données venait à être confirmé, vous en seriez informé personnellement pas via un article de blog.

Des questions ? Notre équipe reste joignable via notre formulaire de contact. Nous répondrons dans les meilleurs délais.

Mise à jour 5 mai 2026, 15h00 CEST

✅

BookMyName a communiqué sur l’évolution de la situation. Voici ce que nous pouvons confirmer à ce stade de nos investigations.

Aucun risque identifié sur vos noms de domaine : les domaines enregistrés auprès de BookMyName ne présentent aucun risque à ce stade. Les modifications intervenues sur les informations de contact ont été entièrement rétablies dans leur configuration initiale.
Date de reprise inconnue : l’analyse est toujours en cours et nous ne sommes pas en mesure de vous communiquer une date de rétablissement du service pour l’heure.

Vous pouvez suivre l’évolution de la situation en temps réel sur la page de statut officielle Scaleway, dont dépend l’infrastructure BookMyName.

Mise à jour 5 mai 2026, 17h30 CEST

✅

BookMyName a communiqué une nouvelle évolution de la situation.

Cause identifiée et isolée : les équipes BookMyName ont identifié et isolé la cause de l’incident affectant les informations de contact des noms de domaine.
Rétablissement prévu ce soir : le service sera pleinement rétabli dans la soirée. Vous pourrez alors administrer vos noms de domaine normalement. Certaines fonctionnalités secondaires resteront temporairement indisponibles.
Renouvellements automatiques maintenus : compte tenu du rétablissement effectif du service ce jour, les renouvellements automatiques seront assurés sans interruption. Aucun renouvellement gracieux ne sera accordé pour les domaines arrivant à échéance le 5 mai 2026, contrairement à ce qui a pu être communiqué précédemment ces domaines seront traités selon vos modalités de facturation habituelles.

Questions fréquentes sur l’incident BookMyName

Mes noms de domaine sont-ils en danger suite à l’incident BookMyName ?

Non. À ce stade de nos investigations, les noms de domaine enregistrés auprès de BookMyName ne présentent aucun risque identifié. Aucune modification de zone DNS ni transfert sortant n’a été détecté. Les données de contact modifiées ont été entièrement rétablies dans leur configuration initiale.

Mes données personnelles chez Easy-Hébergement ont-elles été compromises ?

Non. Nos vérifications n’ont révélé aucun accès anormal à nos systèmes. Identifiants, coordonnées et données de facturation n’ont fait l’objet d’aucun accès suspect identifié. Si cela venait à changer, vous seriez informé personnellement et directement.

Quand les services Easy-Hébergement seront-ils rétablis ?

Après vérification complète de notre environnement, nous avons rétabli l’accès à nos services. Vous pouvez à nouveau vous connecter à votre espace client et administrer vos ressources normalement.

Où suivre l’évolution de l’incident BookMyName en temps réel ?

Sur la page de statut officielle Scaleway, dont dépend l’infrastructure BookMyName, et via les mises à jour de cet article. C’est la source officielle pour les annonces de rétablissement.

Faut-il changer mon mot de passe espace client Easy-Hébergement ?

Aucun accès suspect n’a été détecté sur nos systèmes. Par précaution, vous pouvez activer le pare-feu de votre espace client si ce n’est pas encore fait, et vérifier que votre adresse e-mail de récupération est bien à jour.

Mon domaine arrivait à échéance le 5 mai 2026 bénéficiera-t-il d’un renouvellement gracieux ?

Non. BookMyName ayant rétabli ses services ce jour, les renouvellements automatiques sont assurés normalement. Aucun renouvellement gracieux ne sera accordé pour les domaines arrivant à échéance le 5 mai 2026. Vos domaines seront traités selon vos modalités de facturation habituelles, sans délai supplémentaire lié à l’incident.

La situation évolue rapidement. Revenez sur cette page pour les mises à jour, ou suivez nos communications habituelles pour être informé dès que les services sont pleinement rétablis.

Dernière mise à jour : 5 mai 2026, 18h00 CEST — Auteur : Marcelo

Les erreurs qui rendent un site WordPress lent (et comment les éviter)

La performance d’un site WordPress est aujourd’hui un enjeu stratégique : expérience utilisateur, référencement naturel et taux de conversion en dépendent directement.

Pourtant, de nombreux sites souffrent de lenteurs évitables, liées à des choix techniques ou à un manque d’optimisation.

Voici les principales erreurs qui dégradent les performances d’un site WordPress, ainsi que les bonnes pratiques pour y remédier.

1. Accumulation excessive de plugins

L’ajout de plugins est souvent la réponse rapide à un besoin fonctionnel. Cependant, chaque plugin introduit :

des requêtes supplémentaires
du code exécuté côté serveur et client
des dépendances parfois mal optimisées

👉 Une surcharge de plugins entraîne mécaniquement une dégradation des performances.

Bonnes pratiques :

Auditer régulièrement les plugins installés
Supprimer les extensions inutilisées ou redondantes
Privilégier des solutions maintenues et reconnues

2. Absence d’optimisation des médias

Les images représentent une part significative du poids total d’une page.

Des fichiers non optimisés entraînent :

un temps de chargement élevé
une consommation inutile de bande passante

Bonnes pratiques :

Utiliser des formats modernes (WebP)
Adapter les dimensions aux usages réels
Mettre en place une compression systématique

3. Mauvaise gestion du cache

Sans mécanisme de cache, chaque requête utilisateur déclenche la génération complète de la page côté serveur.

👉 Cela augmente significativement le temps de réponse et la charge serveur.

Bonnes pratiques :

Mettre en place une stratégie de cache adaptée (page, navigateur, objet)
S’assurer de la compatibilité des outils de cache avec l’infrastructure
Éviter certains plugins non adaptés à des environnements spécifiques (par exemple, LiteSpeed Cache sur des serveurs Apache)

4. Utilisation de thèmes surchargés

Certains thèmes intègrent un grand nombre de fonctionnalités génériques, souvent inutilisées dans le cadre du projet.

👉 Cela se traduit par :

un volume important de ressources chargées
une complexité accrue côté front-end

Bonnes pratiques :

Sélectionner des thèmes légers et modulaires
Limiter les fonctionnalités aux besoins réels
Éviter les thèmes “tout-en-un”

5. Multiplication des ressources CSS et JavaScript

Chaque ressource supplémentaire (CSS ou JavaScript) génère des requêtes HTTP et peut bloquer le rendu de la page.

👉 Un excès de scripts impacte directement le temps de chargement.

Bonnes pratiques :

Désactiver les scripts non essentiels
Minifier et regrouper les fichiers
Charger les scripts de manière différée lorsque possible

6. Base de données non maintenue

Avec le temps, la base de données WordPress accumule :

révisions d’articles
données obsolètes
tables inutilisées

👉 Cela peut ralentir les requêtes et impacter les performances globales.

Bonnes pratiques :

Mettre en place un nettoyage régulier
Limiter le nombre de révisions
Optimiser les tables de la base de données

7. Absence de distribution des ressources (CDN)

Pour des sites à audience nationale ou internationale, la latence réseau peut devenir un facteur limitant.

👉 L’éloignement géographique entre l’utilisateur et le serveur impacte le temps de chargement.

Bonnes pratiques :

Mettre en place un CDN
Distribuer les ressources statiques via des points de présence proches des utilisateurs

8. Manque de maintenance et de mises à jour

Des versions obsolètes de WordPress, des thèmes ou des plugins peuvent entraîner :

des pertes de performance
des incompatibilités
des vulnérabilités

Bonnes pratiques :

Maintenir l’ensemble des composants à jour
Tester les mises à jour dans un environnement de préproduction
Mettre en place une stratégie de maintenance continue

Conclusion

La performance d’un site WordPress repose avant tout sur des choix techniques cohérents et une gestion rigoureuse des ressources.

Dans la majorité des cas, les gains de performance proviennent :

d’une réduction de la complexité
d’une meilleure gestion des ressources
d’une optimisation continue

👉 Une approche structurée permet d’obtenir des sites à la fois rapides, fiables et évolutifs.

Recommandation

Il est conseillé de mesurer régulièrement les performances à l’aide d’outils dédiés (Google PageSpeed Insights, Lighthouse) afin d’identifier les axes d’amélioration prioritaires.

Une démarche progressive et méthodique reste la clé d’une optimisation efficace et durable.