Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

FluxContactConfidentialité© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
Outils/GitHubGitHub/asvorg/cve-2026-105030-poc
Scanners de Vulnérabilités WebAnalyse des VulnérabilitésExploitationCollecte d'InformationsSécurité WebTests d'IntrusionSécurité des API
GitHubasvorg/cve-2026-105030-poc

CVE-2026-105030-poc

Un PoC python3 pour CVE-2026-105030 Kener 4.0.0 avant 4.1.6 Divulgation de données de surveillance masquées via l'API du tableau de bord

Voir le dépôt
il y a 19h 13mPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

PoC de divulgation d'informations sur les moniteurs cachés de Kener

Ce dépôt contient un petit proof-of-concept en Python pour tester un problème de divulgation d'informations (CWE-200) dans les endpoints publics de moniteurs de Kener.

Les versions de Kener affectées sont de 4.0.0 à 4.1.5, et le problème est corrigé dans la 4.1.6

https://www.rapid7.com/db/vulnerabilities/cve-2026-105030/

Le problème est associé aux recherches de moniteurs basées sur les tags qui peuvent exposer des moniteurs cachés ou inactifs lorsque la requête n'est pas correctement filtrée.

Ce PoC est destiné à :

  • des environnements de développement locaux
  • des tests de sécurité autorisés
  • la vérification du patch/correctif dans un environnement contrôlé

N'utilisez pas ce poc contre des cibles non autorisées

Périmètre

Ce PoC démontre qu'un moniteur caché ou inactif peut encore être retourné par des endpoints publics lorsque la recherche n'applique pas de filtrage tel que :

  • status = ACTIVE
  • is_hidden = NO

Le comportement corrigé est que ces endpoints doivent retourner 404 / aucune correspondance pour les moniteurs cachés ou inactifs.

Prérequis

  • Python 3.9+
  • Le paquet requests
  • Une instance locale ou de test de Kener
  • Un accès à la base de données pour créer un moniteur de test

Installer les dépendances :

python3 -m pip install requests

Démarrage rapide

  1. Démarrez votre application Kener en local
  2. Créez un moniteur de test qui est caché et inactif
  3. Exécutez le script PoC
  4. Comparez le comportement avec la version corrigée

Créer un moniteur de test

Si vous avez accès à la base de données, créez un moniteur qui ne devrait pas être visible publiquement.

Pour Postgres :

INSERT INTO monitors (
  tag, name, description, status, is_hidden,
  category_name, monitor_type, cron, default_status,
  created_at, updated_at
) VALUES (
  'internal-secret-monitor',
  'Internal Secret Monitor',
  'Hidden/inactive monitor used for PoC',
  'INACTIVE',
  'YES',
  'Home',
  'HTTP',
  '* * * * *',
  'UP',
  NOW(),
  NOW()
);

Vous pouvez également utiliser un autre nom de tag si nécessaire.

Assurez-vous que l'enregistrement est :

  • status = 'INACTIVE' ou autrement non actif
  • is_hidden = 'YES'

Maintenant, exécutez le script PoC.

Build vulnérable

Si l'application est vulnérable, un ou plusieurs endpoints peuvent retourner :

  • HTTP 200
  • du JSON ou du HTML indiquant qu'un moniteur existe
  • des métadonnées de moniteur telles que le nom, l'uptime, la latence, le statut, les horodatages

Cela indique que le moniteur caché/inactif est exposé via une API publique.

Build corrigé

Avec le filtrage approprié, la réponse devrait plutôt être :

  • HTTP 404
  • ou un résultat vide
  • ou un générique « Monitor not found »

C'est le comportement attendu après le correctif :

const monitors = await db.getMonitors({
  tag,
  status: GC.ACTIVE,
  is_hidden: GC.NO,
});

Pourquoi c'est important

Le problème n'est pas simplement le secret du tag. Le problème est qu'un endpoint public ne devrait jamais révéler les données d'un moniteur caché ou inactif. Si un attaquant découvre un tag de moniteur par n'importe quel moyen, il peut potentiellement accéder à :

  • des détails d'uptime
  • des graphiques de latence
  • des fenêtres de maintenance
  • l'historique des incidents
  • des métadonnées opérationnelles

L'attaquant doit toutefois trouver le tag d'une manière ou d'une autre, par devinette, par bruteforce, ou par d'autres moyens.

Dépannage

L'endpoint retourne 404 alors qu'il devrait retourner 200

Vérifiez que :

  • le moniteur existe
  • le tag correspond exactement
  • le moniteur est caché/inactif comme prévu

Aucune réponse / connexion refusée

Assurez-vous que l'application est en cours d'exécution en local et que le port correspond :

BASE_URL=http://localhost:3000

L'application a HTTPS activé

Utilisez l'URL correcte, par exemple :

BASE_URL=https://localhost:3000

Utilisation légale et éthique

Utilisez ce PoC uniquement :

  • sur votre propre instance de test
  • dans un environnement de développement local
  • sur des systèmes que vous êtes explicitement autorisé à tester

N'exécutez pas ceci contre des systèmes externes ou tiers sans autorisation.

Résumé

Ce PoC vérifie si un tag de moniteur caché ou inactif est encore accessible via les endpoints publics de l'API Kener.

  • Comportement vulnérable : l'API publique révèle les données d'un moniteur caché/inactif
  • Comportement corrigé : seuls les moniteurs actifs et non cachés sont retournés
  • Objectif : vérifier le correctif de sécurité dans un environnement contrôlé
Télécharger l’outil