Kener Hidden Monitor Information Disclosure PoC

This repository contains a small Python proof-of-concept for testing an information disclosure (CWE-200) issue in Kener's public monitor endpoints. At the time of publication, no other public PoC was identified.

The Kener versions affected are 4.0.0 through to 4.1.5, and it is fixed in 4.1.6

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

The issue is associated with tag-based monitor lookups that can expose hidden or inactive monitors when the query is not properly filtered.

This PoC is intended for:

• local development environments
• authorized security testing
• verifying the patch/fix in a controlled environment

Do not use this poc against unauthorized targets

Scope

This PoC demonstrates that a hidden or inactive monitor may still be returned by public endpoints when the lookup does not enforce filtering such as:

• status = ACTIVE
• is_hidden = NO

The fixed behavior is that these endpoints should return 404 / no match for hidden or inactive monitors.

Prerequisites

• Python 3.9+
• requests package
• A local or test instance of Kener
• Access to the database for creating a test monitor

Install dependencies:

python3 -m pip install requests

Quick Start

1. Start your Kener app locally
2. Create a test monitor that is hidden and inactive
3. Run the PoC script
4. Compare behavior with the fixed release

Create a Test Monitor

If you have database access, create a monitor that should not be publicly visible.

For 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()
);

You can also use a different tag name if needed.

Make sure the record is:

• status = 'INACTIVE' or otherwise not active
• is_hidden = 'YES'

Now run the PoC script.

Vulnerable Build

If the application is vulnerable, one or more endpoints may return:

• HTTP 200
• JSON or HTML indicating a monitor exists
• monitor metadata such as name, uptime, latency, status, timestamps

This indicates the hidden/inactive monitor is being exposed via a public API.

Fixed Build

With the proper filtering, the response should instead be:

• HTTP 404
• or an empty result
• or a generic "Monitor not found"

This is the expected behavior after the fix:

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

Why This Matters

The issue is not merely the secrecy of the tag. The problem is that a public endpoint should never reveal hidden or inactive monitor data. If an attacker learns a monitor tag by any means, they may be able to access:

• uptime details
• latency charts
• maintenance windows
• incident history
• operational metadata

The attacker still has to find the tag somehow, by guessing, by bruteforce, or by other means.

Troubleshooting

Endpoint returns 404 when it should be 200

Check that:

• the monitor exists
• the tag matches exactly
• the monitor is hidden/inactive as expected

No response / connection refused

Make sure the app is running locally and the port matches:

BASE_URL=http://localhost:3000

The app has HTTPS enabled

Use the correct URL, for example:

BASE_URL=https://localhost:3000

Legal and Ethical Use

Use this PoC only:

• on your own test instance
• in a local development environment
• on systems you are explicitly authorized to test

Do not run this against external or third-party systems without permission.

Summary

This PoC checks whether a hidden or inactive monitor tag is still accessible through public Kener API endpoints.

• Vulnerable behavior: public API reveals hidden/inactive monitor data
• Fixed behavior: only active, non-hidden monitors are returned
• Goal: verify the security patch in a controlled environment