Kener Docs
llms.txt
Search Documentation
Search through all documentation pages
v4.x

v4.1.7 Changelog

See what's new in Kener v4.1.7, including a security fix for stored OIDC and captcha secrets and fixes for hidden monitors

Release date: October 7, 2026

Important

This release fixes a security issue in v4.1.3 to v4.1.6. Upgrade, then check whether you need to rotate your OIDC client secret and captcha secret key. See Security.

Security

Stored OIDC and captcha secrets were readable with read-only access

Field Value
Affected versions v4.1.3 to v4.1.6
Fixed in v4.1.7
Severity Medium, CVSS 3.1 score 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Weakness CWE-200 (Exposure of Sensitive Information), CWE-522 (Insufficiently Protected Credentials)

The site-data read endpoints returned two stored secrets in plain text: the OIDC client_secret (stored since v4.1.3) and the Secret Key of the hCaptcha, reCAPTCHA, and Turnstile providers (stored since v4.1.5).

  • The dashboard API (POST /manage/api) returned them from the getAllSiteData and getSiteDataByKey actions. These actions need only the settings.read permission. All three built-in roles have it, including Member.
  • The REST API returned them from GET /api/v4/site and GET /api/v4/site/{config_key} to any valid API key.

A user who reads the OIDC client secret can act as your Kener OIDC client toward your identity provider.

Kener now masks both secrets in every response, for example **********************1234. When you save a form that still shows the masked value, Kener keeps the stored secret. OIDC sign-in and captcha checks still use the real secret.

What to do:

  1. Upgrade to v4.1.7.
  2. If anyone outside your administrators had a role with settings.read, or held an API key, treat both secrets as exposed. Create a new client secret in your identity provider and a new secret key in your captcha provider.
  3. Save the new values under Manage → OpenID Connect and Manage → Captcha Providers.

Note

API clients now get the masked value from GET /api/v4/site. A PATCH /api/v4/site/{config_key} that sends the masked value back keeps the stored secret, and its response shows the saved value masked.

Bug fixes

  • Hidden monitors no longer show on the public incident page. /incidents/{id} listed every monitor linked to the incident, including monitors set to Hidden in Status Page. Anyone who opened the incident saw the hidden monitor's name, image, and description. The page now leaves hidden monitors out, the same as the maintenance page. Inactive monitors that are not hidden still show.
  • The Live Events embed lists global events again. /embed/events/live dropped a global incident or maintenance that had no linked monitor or only hidden monitors. The embed now lists these events and leaves hidden monitors out of their monitor list. With tags= in the URL, an event shows only when it links to a requested monitor that is not hidden.
  • /rss.xml keeps maintenance events whose monitors are all hidden. With forceExclusivity off, the root feed dropped a non-global maintenance event when all of its monitors were hidden, but the root events page kept it. The feed now lists the event without an "Affected:" line.

Documentation

  • The new Monitor Visibility page explains how status, is_hidden, page membership, forceExclusivity, and the sharing options decide where a monitor shows up publicly. It covers two surprises: a monitor that is on no page is still public through its monitor page, badges, and embeds, and turning off sharing only hides the share buttons.
  • RSS Feed now gives the hidden-monitor rules for each feed.