asvorg/cve-2026-105030-pocUn PoC in python3 per CVE-2026-105030 Kener 4.0.0 precedente alla 4.1.6 Divulgazione di dati nascosti del monitor tramite l'API della dashboard
Questo repository contiene un piccolo proof-of-concept in Python per testare un problema di divulgazione di informazioni (CWE-200) negli endpoint pubblici dei monitor di Kener. Al momento della pubblicazione, non è stato identificato nessun altro PoC pubblico.
Le versioni di Kener interessate vanno dalla 4.0.0 alla 4.1.5, ed è risolto nella 4.1.6
https://www.rapid7.com/db/vulnerabilities/cve-2026-105030/
Il problema è associato alle ricerche dei monitor basate su tag che possono esporre monitor nascosti o inattivi quando la query non viene filtrata correttamente.
Questo PoC è destinato a:
Non utilizzare questo PoC contro target non autorizzati
Questo PoC dimostra che un monitor nascosto o inattivo può comunque essere restituito dagli endpoint pubblici quando la ricerca non applica filtri quali:
Il comportamento corretto è che questi endpoint dovrebbero restituire 404 / nessuna corrispondenza per i monitor nascosti o inattivi.
requestsInstalla le dipendenze:
python3 -m pip install requests
Se hai accesso al database, crea un monitor che non dovrebbe essere visibile pubblicamente.
Per 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()
);
Puoi anche usare un nome di tag diverso se necessario.
Assicurati che il record sia:
status = 'INACTIVE' o comunque non attivois_hidden = 'YES'Ora esegui lo script PoC.
Se l'applicazione è vulnerabile, uno o più endpoint potrebbero restituire:
Questo indica che il monitor nascosto/inattivo viene esposto tramite un'API pubblica.
Con il filtraggio appropriato, la risposta dovrebbe invece essere:
Questo è il comportamento atteso dopo la correzione:
const monitors = await db.getMonitors({
tag,
status: GC.ACTIVE,
is_hidden: GC.NO,
});
Il problema non è semplicemente la segretezza del tag. Il problema è che un endpoint pubblico non dovrebbe mai rivelare dati di monitor nascosti o inattivi. Se un attaccante scopre un tag di monitor in qualsiasi modo, potrebbe essere in grado di accedere a:
L'attaccante deve comunque trovare il tag in qualche modo, indovinandolo, tramite bruteforce o con altri mezzi.
Verificare che:
Assicurarsi che l'app sia in esecuzione localmente e che la porta corrisponda:
BASE_URL=http://localhost:3000
Usa l'URL corretto, ad esempio:
BASE_URL=https://localhost:3000
Utilizza questo PoC solo:
Non eseguirlo contro sistemi esterni o di terze parti senza autorizzazione.
Questo PoC verifica se un tag monitor nascosto o inattivo sia ancora accessibile tramite gli endpoint pubblici dell'API di Kener.