本仓库包含一个小型 Python 概念验证（PoC），用于测试 Kener 公共监控端点中的信息泄露（CWE-200）问题。在发布之时，未发现其他公开的 PoC。
受影响的 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：
未经许可，请勿针对外部或第三方系统运行此 PoC。
此 PoC 检查隐藏或未激活的 monitor 标签是否仍可通过公开的 Kener API 端点访问。