Un hacker n’a pas toujours besoin d’un exploit sophistiqué. Parfois, il lui suffit d’une application de test oubliée en ligne. Or, ces « labs » de cybersécurité, utiles pour s’entraîner, deviennent un raccourci vers le cloud. Et, selon plusieurs enquêtes publiées le 21 janvier 2026, des hackers s’en servent déjà pour viser des entreprises du Fortune 500.
Hacker : ces applis de test ouvrent un accès direct au cloud des entreprises

En date du 21 janvier 2026, l’alerte est claire : des hackers exploitent des applications de formation ou de pentest, exposées sur Internet, afin d’atteindre des environnements cloud d’entreprises majeures. Le signal n’est pas celui d’un bug isolé, mais celui d’une hygiène numérique qui craque au mauvais endroit. Le risque naît d’un mélange explosif : d’abord une appli volontairement vulnérable, ensuite un accès trop ouvert, toutefois des identifiants et des rôles trop puissants, et enfin une progression discrète du hacker jusqu’aux ressources critiques.
Hacker et entreprises : quand l’outil d’entraînement devient une rampe d’accès
Le scénario décrit par les chercheurs est presque banal, et c’est précisément ce qui le rend dangereux. Une entreprise déploie une application de test pour former ses équipes, puis, parce qu’il faut aller vite, elle la laisse accessible, et donc, tôt ou tard, un hacker la découvre. Ensuite, ce hacker exploite une faiblesse attendue, car l’application est conçue pour être cassable, toutefois l’environnement réel autour ne l’est pas, et pourtant il reste connecté. L’essentiel n’est pas l’application elle-même, mais ce qui l’entoure : identifiants, secrets, et droits cloud trop larges, autant de leviers qu’un hacker peut tirer sans bruit.
Les chiffres donnent l’ampleur du phénomène, tout en rappelant que l’exposition est souvent involontaire. 1 926 applications actives et vulnérables étaient accessibles sur Internet, réparties sur 1 626 serveurs uniques, et environ 60 % (974 applications) tournaient sur des infrastructures « enterprise-owned » sur AWS, Azure ou Google Cloud. Autrement dit, le hacker ne tape pas seulement sur des environnements d’école, mais bien, d’abord, sur des machines reliées aux entreprises, ensuite sur des comptes qui vivent dans le cloud, toutefois avec des permissions parfois trop généreuses, et enfin sur une surface d’attaque que personne ne surveille comme une production.
Hacker et cloud : l’escalade silencieuse via les identifiants et les rôles surdimensionnés
Le point de bascule, dans ces attaques, tient souvent à une mécanique très concrète : la récupération d’identifiants, puis l’abus de privilèges. L’application « vulnérable » n’est qu’un marchepied, et le hacker cherche rapidement autre chose : des clés, des tokens, des mots de passe, ou une configuration qui lui ouvre une API. 109 ensembles d’identifiants exposés ont été observés, associés à des identités ou noms de rôles uniques, et souvent liés à des privilèges IAM surdimensionnés. Ensuite, le hacker n’a plus besoin de forcer une porte ; toutefois, il peut simplement utiliser les droits déjà accordés ; et donc, il agit « comme un compte légitime », enfin jusqu’à toucher des services sensibles.
Cette dynamique est d’autant plus risquée que le cloud accélère les effets de levier. Dès lors qu’un hacker met la main sur un rôle trop puissant, il peut pivoter vers des services qui, dans une entreprise, concentrent la valeur : stockage d’objets, gestionnaires de secrets, registres de conteneurs. Ces chemins d’accès existent précisément parce que des identifiants et des secrets se retrouvent dans des environnements de démo, tandis que des rôles cloud sont attachés sans principe de moindre privilège. Et comme ces environnements « ne comptent pas », d’abord ils échappent aux inventaires, ensuite ils échappent aux audits, toutefois ils restent connectés au cloud, et enfin ils offrent au hacker une progression à faible friction.
Hacker et cloud des entreprises : une menace déjà exploitée, et pas seulement en théorie
Là où l’alerte change de niveau, c’est quand elle sort du « risque potentiel » pour entrer dans l’attaque observée. Pentera insiste sur ce point. En clair, des hackers ne se contentent pas de scanner : ils exploitent, puis ils installent, et enfin ils monétisent. Des artefacts typiques ont été observés sur des systèmes compromis, notamment des crypto-mineurs, des webshells et des mécanismes de persistance, ce qui signale des opérations de hacker déjà en cours.
Le détail le plus parlant est peut-être celui des mauvaises pratiques « par défaut », parce qu’il renvoie à une réalité opérationnelle. Dans l’exemple de DVWA, une application d’entraînement très connue, Pentera rapporte avoir découvert 616 instances dans l’échantillon, et 334 accessibles avec des identifiants par défaut, soit 54 %. Ensuite, il devient facile pour un hacker de passer du test à l’abus, toutefois la responsabilité n’est pas dans l’outil, mais dans son déploiement, et donc dans l’entreprise. « En résumé : une seule application d’entraînement mal configurée, avec un rôle IAM trop privilégié, peut mener à une compromission complète du cloud », a expliqué Noam Yaffe. Cette phrase résume le risque : le hacker n’a pas besoin d’un « zero day » ; il a besoin d’un oubli.
