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

Ce dépôt contient un petit proof-of-concept Python pour tester un problème de divulgation d'informations (CWE-200) dans les endpoints publics de moniteurs de Kener. Au moment de la publication, aucun autre PoC public n'a été identifié.

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

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

Le problème est lié 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 local
• des tests de sécurité autorisés
• la vérification du 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 renvoyé par les 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 renvoyer 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. Lancez votre application Kener en local
2. Créez un moniteur de test masqué 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 balise si nécessaire.

Assurez-vous que l'enregistrement est :

• status = 'INACTIVE' ou sinon inactif
• is_hidden = 'YES'

Exécutez maintenant le script PoC.

Build vulnérable

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

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

Cela indique que le monitor masqué/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 la correction :

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

Pourquoi cela compte

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 monitor masqué ou inactif. Si un attaquant découvre un tag de monitor par n'importe quel moyen, il peut potentiellement accéder à :

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

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

Dépannage

L'endpoint renvoie 404 alors qu'il devrait renvoyer 200

Vérifiez que :

• le monitor existe
• le tag correspond exactement
• le monitor est masqué/inactif comme prévu

Aucune réponse / connexion refusée

Assurez-vous que l'application est en cours d'exécution localement 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 ce PoC contre des systèmes externes ou tiers sans autorisation.

Résumé

Ce PoC vérifie si une balise de moniteur masquée ou inactive reste accessible via les points de terminaison publics de l'API Kener.

• Comportement vulnérable : l'API publique révèle les données de moniteurs masqués/inactifs
• Comportement corrigé : seuls les moniteurs actifs et non masqués sont renvoyés
• Objectif : vérifier le correctif de sécurité dans un environnement contrôlé