Live › vulnerability › CVE-2026-116747
Go to dashboardKener 3.0.0 before 4.1.10 falls back to a hardcoded DUMMY_SECRET signing key when KENER_SECRET_KEY is empty or unset. An unauthenticated attacker who knows an administrator's email can sign a kener-user cookie and reach /manage/api with full admin rights, or forge password-reset tokens.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 22:25 UTC. All times on this page are UTC.
Deployments running Kener from 3.0.0 up to 4.1.10 where KENER_SECRET_KEY is empty or unset, so the hardcoded DUMMY_SECRET fallback is used for signing. Exposed instances that serve the management interface on a network reachable by attackers are the main concern. Installations on 4.1.10 or later, or with a strong KENER_SECRET_KEY set, are not affected by this flaw.
No product ranges from the sources yet.
KENER_SECRET_KEY is set and non-empty in the Kener environment (for example in the Docker compose file, .env, or the host's environment).3.0.0 up to but not including 4.1.10.4.1.10 or later.KENER_SECRET_KEY to a long random value, and rotate any sessions or reset tokens issued while it was empty.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Kener 3.0.0 before 4.1.10 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge session tokens by using the hardcoded DUMMY_SECRET fallback key. When KENER_SECRET_KEY is empty or unset, attackers knowing an administrator email can sign a kener-user cookie to access /manage/api with full administrative privileges or forge password-reset tokens.
This page as .md · .json · in your agent: get_signal("CVE-2026-116747")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.