
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
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é à :
N'utilisez pas ce poc contre des cibles non autorisées
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 :
Le comportement corrigé est que ces endpoints doivent retourner 404 / aucune correspondance pour les moniteurs cachés ou inactifs.
requestsInstaller les dépendances :
python3 -m pip install requests
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 actifis_hidden = 'YES'Maintenant, exécutez le script PoC.
Si l'application est vulnérable, un ou plusieurs endpoints peuvent retourner :
Cela indique que le moniteur caché/inactif est exposé via une API publique.
Avec le filtrage approprié, la réponse devrait plutôt être :
C'est le comportement attendu après le correctif :
const monitors = await db.getMonitors({
tag,
status: GC.ACTIVE,
is_hidden: GC.NO,
});
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 à :
L'attaquant doit toutefois trouver le tag d'une manière ou d'une autre, par devinette, par bruteforce, ou par d'autres moyens.
Vérifiez que :
Assurez-vous que l'application est en cours d'exécution en local et que le port correspond :
BASE_URL=http://localhost:3000
Utilisez l'URL correcte, par exemple :
BASE_URL=https://localhost:3000
Utilisez ce PoC uniquement :
N'exécutez pas ceci contre des systèmes externes ou tiers sans autorisation.
Ce PoC vérifie si un tag de moniteur caché ou inactif est encore accessible via les endpoints publics de l'API Kener.