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.

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