
CVE-2026-105030 Kener 4.0.0 ~ 4.1.6 버전의 Dashboard API를 통한 숨겨진 모니터 데이터 노출 취약점에 대한 python3 PoC
이 저장소에는 Kener의 공개 모니터 엔드포인트에서 발생하는 정보 노출(CWE-200) 문제를 테스트하기 위한 작은 Python 개념 증명(proof-of-concept)이 포함되어 있습니다.
영향을 받는 Kener 버전은 4.0.0부터 4.1.5까지이며, 4.1.6에서 수정되었습니다.
https://www.rapid7.com/db/vulnerabilities/cve-2026-105030/
이 문제는 쿼리가 적절히 필터링되지 않을 때 숨겨진 또는 비활성 모니터를 노출할 수 있는 태그 기반 모니터 조회와 관련이 있습니다.
이 PoC는 다음을 위해 작성되었습니다:
승인되지 않은 대상에 대해 이 PoC를 사용하지 마십시오.
이 PoC는 조회 시 다음과 같은 필터링이 적용되지 않을 때 숨겨진 또는 비활성 모니터가 공개 엔드포인트에서 여전히 반환될 수 있음을 보여줍니다:
수정된 동작은 이러한 엔드포인트가 숨겨진 또는 비활성 모니터에 대해 404 / 일치 없음을 반환해야 한다는 것입니다.
requests 패키지의존성 설치:
python3 -m pip install requests
데이터베이스 접근 권한이 있다면 공개적으로 표시되지 않아야 하는 모니터를 생성하십시오.
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()
);
필요한 경우 다른 태그 이름을 사용할 수도 있습니다.
레코드가 다음 조건을 충족하는지 확인하십시오:
status = 'INACTIVE' 또는 그 외 활성 상태가 아님is_hidden = 'YES'이제 PoC 스크립트를 실행하십시오.
애플리케이션이 취약한 경우, 하나 이상의 엔드포인트가 다음을 반환할 수 있습니다:
이는 숨겨진/비활성 모니터가 공개 API를 통해 노출되고 있음을 나타냅니다.
적절한 필터링이 적용되면 응답은 대신 다음과 같아야 합니다:
이것이 수정 후 기대되는 동작입니다:
const monitors = await db.getMonitors({
tag,
status: GC.ACTIVE,
is_hidden: GC.NO,
});
문제는 단순히 태그의 비밀성에 있는 것이 아닙니다. 문제는 공개 엔드포인트가 숨겨진 또는 비활성 모니터 데이터를 절대 노출해서는 안 된다는 것입니다. 공격자가 어떤 수단으로든 모니터 태그를 알게 되면, 다음에 접근할 수 있을 수 있습니다:
공격자는 여전히 추측, 무차별 대입 또는 다른 수단을 통해 태그를 어떻게든 찾아내야 합니다.
다음을 확인하십시오:
앱이 로컬에서 실행 중이고 포트가 일치하는지 확인하십시오:
BASE_URL=http://localhost:3000
올바른 URL을 사용하십시오. 예를 들어:
BASE_URL=https://localhost:3000
이 PoC는 다음의 경우에만 사용하십시오:
허가 없이 외부 또는 제3자 시스템에 대해 이 PoC를 실행하지 마십시오.
이 PoC는 숨겨진 또는 비활성 모니터 태그가 공개 Kener API 엔드포인트를 통해 여전히 접근 가능한지 확인합니다.