Comment corriger les failles de sécurité avant les autres

Imaginez : vous êtes de garde, et soudain une alerte arrive concernant une violation réussie d'une ancienne version de CMS que tout le monde a oubliée depuis longtemps. Un scénario désagréable, n'est-ce pas ? En pratique, la sécurité perd souvent face à la vitesse de développement, et les administrateurs ne peuvent tout simplement pas suivre le flux de nouveaux CVE. Heureusement, il y a des passionnés qui rassemblent toutes les « armes » d'attaque en un seul endroit. Aujourd'hui, nous allons examiner le dépôt PoC de l'utilisateur eeeeeeeeee-code — une archive massive d'exploits prêts à l'emploi et de scripts pour tester les vulnérabilités.

Qu'est-ce que ce projet et pourquoi en avez-vous besoin

Le dépôt est une base de données de preuves de concept (PoC) en constante évolution. À l'origine, le projet était une sauvegarde de la célèbre bibliothèque de vulnérabilités wy876, mais l'auteur a décidé de ne pas simplement stocker l'archive — il a choisi de la développer activement. C'est maintenant l'une des collections les plus récentes de scénarios d'attaque ciblant à la fois les logiciels chinois et internationaux.

Pourquoi un développeur ou un administrateur système aurait-il besoin de cela ? La réponse est simple : pour tester vos systèmes « en conditions réelles ». Au lieu de lire des descriptions arides dans les bases de données CVE, vous prenez un scénario prêt à l'emploi et vous voyez s'il fonctionne contre votre serveur. Si c'est le cas — il est temps de mettre à jour en urgence ou de fermer ce port.

Ce qu'il faut regarder à l'intérieur

Le dépôt contient des centaines de dossiers, répartis par fournisseurs et types de systèmes. Il y a de tout ici : des failles des routeurs aux bogues critiques dans les frameworks d'IA modernes comme Langflow.

Le préféré de tous : l'injection SQL

La base de données est littéralement remplie d'exemples d'injection SQL. Cela s'applique aux systèmes CRM ainsi qu'aux portails de gestion énergétique d'entreprise. Après avoir vu ces exemples, vous réalisez que les erreurs classiques de filtrage des paramètres sont encore très présentes.

Exécution de code à distance (RCE)

Les choses les plus dangereuses. La base de données contient des scénarios récents pour les systèmes Zhiyuan OA et même des bogues critiques dans Kubernetes Ingress-Nginx. Par exemple, la vulnérabilité CVE-2025-1974 démontre clairement comment une mauvaise configuration peut mener au contrôle d'un cluster.

Lecture arbitraire de fichiers

Un problème souvent sous-estimé. Les scénarios pour des systèmes comme MasterSAM ou DeepFlow montrent comment un attaquant peut extraire des fichiers de configuration avec des mots de passe de base de données en accédant simplement à un certain point de terminaison.

Valeur pratique pour l'équipe

Habituellement, ces dépôts sont utilisés par les pentesteurs, mais il y a beaucoup de choses utiles ici aussi pour une équipe de développement ordinaire.

1. Tests de régression de sécurité. Si votre entreprise utilise un logiciel spécifique (par exemple, Dify ou les systèmes Langflow), vous pouvez ajouter des vérifications de ce dépôt à vos pipelines CI/CD.
2. Apprendre des erreurs des autres. Les fichiers à l'intérieur sont d'excellents supports d'apprentissage. Vous ouvrez un dossier avec une vulnérabilité WordPress ou Grafana et vous voyez exactement où le développeur s'est trompé.
3. Vérifications rapides de l'infrastructure. Quand une nouvelle CVE dans un framework fait la une de l'actualité, un PoC fonctionnel apparaîtra probablement ici en quelques jours.

Jetez un œil au journal des mises à jour du mois dernier — il y a des dizaines d'entrées.

Quelques réflexions sur la sécurité

En travaillant avec de tels outils, il est important de se rappeler de deux choses. Premièrement, c'est une « épée à double tranchant ». Utilisez-le uniquement dans votre propre bac à sable ou sur des systèmes où vous avez une autorisation officielle pour la chasse aux bogues. Deuxièmement, le fichier README du projet est en chinois, ce qui peut légèrement compliquer la navigation, mais la structure des dossiers wpoc/VendorName/VulnerabilityName.md est intuitive.

À l'intérieur de chaque fichier .md, vous trouverez généralement une description de la vulnérabilité, les paramètres de requête et un exemple de charge utile. Tout est aussi précis que possible, sans fioritures inutiles.

Cela vaut-il la peine d'essayer

Si vous êtes responsable de la sécurité de l'infrastructure ou si vous construisez des services d'entreprise, ce dépôt mérite d'être ajouté aux favoris. Ce n'est pas juste une « liste de failles » — c'est un outil de défense active.

Le projet est activement alimenté — littéralement il y a quelques jours seulement, de nouvelles méthodes de contournement d'authentification pour les plugins WordPress et des RCE dans les serveurs SSH sur Erlang-OTP ont été ajoutées. C'est une bonne raison d'auditer vos dépendances et de vous assurer que vous n'utilisez pas de logiciels vieux de dix ans qui peuvent être craqués avec une simple requête HTTP.

Bien sûr, la documentation est parfois un peu clairsemée, et certains liens mènent à des ressources chinoises externes, mais pour un spécialiste technique, il y a plus que suffisamment de code et d'exemples de requêtes. Souvenez-vous : il vaut mieux trouver la faille vous-même en utilisant un PoC que d'en entendre parler par des hackers.