Technique et prévention · 8 min · publié le 14 août 2026

Adminer ou phpMyAdmin accessible publiquement

Une interface SQL sur le web est une cible. Restreignez-la par IP ou retirez-la. Si elle était ouverte pendant l'incident, partez du principe que la base a pu être lue — puis constatez, sans accuser le seul mot « Adminer ».

Réponse directe

Une interface SQL sur le web est une cible. Restreignez par IP ou retirez. Si elle était ouverte pendant l'incident, partez du principe que la base a pu être lue.

adminer public phpmyadmin ouvert interface sql exposée

Pourquoi c'est encore là, dix ans après

Adminer tient en un fichier. Un prestataire le pose « pour gagner du temps », l'oublie. phpMyAdmin entier se décompresse dans `/pma/`. Les bots les cherchent par nom, par hash, par chemins connus. Ce n'est pas une mode 2014. C'est encore dans les constats 2026.

L'interface SQL n'est pas un CMS. Elle est un accès direct aux tables, si le mot de passe base est faible, réutilisé, ou déjà dans un `.env` public. Deux oublis qui s'additionnent.

Nous ne publions pas de listes de CVE ni de chemins d'attaque. Le geste : cette UI n'a rien à faire ouverte sur l'internet. Panel hébergeur, tunnel, IP allow, ou rien.

Public, « caché », et vraiment restreint

Public : `https://vous.fr/adminer.php` en 200, pas d'auth, ou auth faible. « Caché » : `/db-x7k.php` — les scanners ont aussi ces habitudes, et les referer / logs trahissent. Vraiment restreint : VPN, IP du bureau, auth du panel hébergeur (hors votre vhost).

Un htpasswd sur Adminer est un cran, pas une architecture. Mieux que rien en urgence. Moins bien que l'absence du fichier. htpasswd.

Après un vol de mot de passe CMS, l'attaquant n'a pas besoin d'Adminer. Après un Adminer ouvert, il n'a pas besoin du CMS. Distinguez les portes dans le constat.

Pendant l'incident : que faire ce soir

Retirez le fichier / le dossier du DocumentRoot, ou coupez le vhost de cette UI. Copiez avant si vous voulez dater (nom, date). Tournez le mot de passe de la base — surtout s'il était le même que le panel ou le CMS. Secrets distincts.

Ne « laissez pas Adminer le temps du nettoyage, c'est pratique ». Le nettoyeur passe par le panel, un dump, un SFTP. Accès prestataire.

Si phpMyAdmin est celui du panel (o2switch, Plesk) derrière le login hébergeur, ce n'est pas « public sur le site ». C'est le panel. Tournez le panel, 2FA. Ne le confondez pas avec `/pma/` dans votre domaine vitrine.

  • Fichier / dossier : hors web.
  • Mot de passe base : rotation.
  • Journaux : tentatives de login sur cette UI, si elles existent.

La base a-t-elle été lue ? Le plausible

Ouverte + mot de passe faible ou déjà fuité : plausible haut. Ouverte + mot de passe long unique + pas de traces de login : plausible plus bas, pas zéro (0-day, brute force discret). On écrit le plausible, on ne jure pas « aucune lecture ».

S'il y a eu lecture, le volet données s'aligne sur les tables (clients, commandes, hash). Un défacement sans cette UI n'implique pas la même phrase.

Les exports « download SQL » depuis Adminer : cherchez des `.sql` publics, même passe. Zip / sql.

phpMyAdmin chez l'hébergeur, ce n'est pas la même chose

Le phpMyAdmin du manager, derrière le compte client, avec 2FA, c'est l'outil prévu. On ne le « désinstalle » pas. On protège le compte. On n'en fait pas un lien depuis la vitrine.

Un phpMyAdmin que VOUS avez uploadé dans `public_html/phpmyadmin` est le problème. Même logiciel, autre exposition.

Certains hébergeurs proposent Adminer intégré, IP-restreint. Lisez leur doc. S'il est ouvert au monde, ticket : ce n'est pas votre métier de le patcher, c'est le leur — et votre `.fr` qui trinque.

Remplacer le besoin, pas le fichier

Besoin d'un SELECT : dump local, client SQL en SSH / tunnel, panel. Besoin d'un prestataire : un dump, pas une UI permanente. Le « on ne sait pas faire sans Adminer » est un besoin de formation, pas une exception de sécu.

Les plugins WordPress « run SQL in admin » sont cousins. Après incident, ils sortent. Trop de pouvoir dans wp-admin.

Woo / Presta : les exports natifs suffisent souvent au constat (commandes). Pas besoin d'une UI SQL publique pour un CSV.

Après : zéro outil SQL dans le DocumentRoot

Règle d'équipe, écrite. Revue après chaque mission. Surveillance : `adminer.php` / `phpmyadmin` qui réapparaissent. Surveillance.

Les versions « latest adminer » se périment. Même restreintes, elles se mettent à jour ou elles sortent. Un Adminer de 2018 IP-allow n'est pas un trophée.

Documentez dans le constat : trouvé / retiré / base tournée. Utile pour l'assureur.

Même passe que phpinfo et `.env`

Une liste de chemins, une heure. phpinfo, `.git`. Le malware PHP à la racine est un autre item de la même liste.

Ne mélangez pas avec une refonte de boutique. Sortez l'UI, tournez, fermez l'entrée CMS. Refonte.

Déclarer : « Adminer était à la racine » oriente le volet base. Dites-le dès le premier message.

Questions fréquentes

Adminer « latest » est-il sûr s'il est à jour ?

+
À jour et ouvert au monde reste une cible (bruteforce, 0-day un jour). À jour et restreint IP / VPN, c'est un compromis d'ops. À jour et oublié à la racine, c'est le cas que l'on traite. Préférez zéro fichier.

Je m'en sers une fois par mois. Je le remets après ?

+
Non. Vous ouvrez le panel, ou un tunnel, le jour J, vous refermez. Le fichier permanent est le problème, pas le SQL.

L'attaquant a eu Adminer. Tous les clients sont fuités ?

+
Pas automatiquement. Plausible plus haut, constat (journaux, volume, tables). Pas de mail de masse le soir même sans analyse. Fuite.

phpMiniAdmin, AdminerEvo, des forks : pareil ?

+
Oui : UI SQL dans le webroot. Même décision. Le nom commercial ne change pas l'exposition.

Plesk / cPanel embarquent phpMyAdmin. Je le désactive ?

+
Vous durcissez le compte panel (2FA, mot de passe). Vous ne posez pas un second PMA dans le site. Deux produits, deux expositions. Ne les fusionnez pas dans la panique.
À lire ensuite
phpinfo() encore en ligne Fichier .env exposé Injection SQL : signes Fuite de données Premiers gestes Déclarer mon site