Kener's default secret signed everyone's session: CVE-2026-116747
Kener, the self-hosted status-page platform, fell back to a hardcoded placeholder secret when its signing key was unset. That one default let an attacker forge a valid admin session. Fixed in v4.1.10.
Kener, the open-source status page platform with 5,222 stars on GitHub, had a problem that a lot of self-hosted software shares: when you forgot to set the secret key, it quietly signed everything with a placeholder.
The placeholder was a string. The string was DUMMY_SECRET. And it worked, because a JWT signed with a known secret is a valid JWT.
How the bypass works
Kener signs its session tokens and HMACs with the value of KENER_SECRET_KEY. In versions 3.0.0 through 4.1.9, if that variable was empty or unset, every signing call fell back to the hardcoded literal DUMMY_SECRET (the pre-fix code sat at commonController.ts L44-55 in v4.1.9, per the vendor's own disclosure).
That fallback turned a missing configuration into an authentication bypass. An attacker who knew the literal could sign a kener-user cookie that the server would accept, reaching /manage/api with full administrative privileges. The same key could forge password-reset tokens, so it was not only an admin-login problem.
The fix landed in v4.1.10 on 2026-10-26: commit ff63648, "fix(auth): drop the hardcoded fallback secret and warn on example secrets (#872)". The release removes the fallback and adds a warning when example secrets are in use.
The disclosure timeline
A researcher opened vendor issue #871 on 2026-10-09, and the maintainer closed it the same morning the fix shipped, 2026-10-26 at 08:31 UTC. Eighteen days from report to patch. The GitHub Security Advisory (GHSA-7973-f655-53vh) followed on 2026-10-27, and the NVD record (CVE-2026-116747) was published 2026-10-26.
The same issue #871 reported two more high-severity problems that did not get CVEs:
- API keys with no expiry and no scope enforcement. Any key in the ACTIVE state works on every protected route, indefinitely.
- SSRF in monitor configuration. The
url,proxy,headers, and redirect targets reach Axios with no check against loopback, private, link-local, or cloud-metadata destinations.
Those two have no CVSS scores and no separate advisory, so they are context here, not confirmed findings with their own gate. But for anyone running Kener, they sit in the same codebase as the auth bypass, and the fix release does not name them.
Severity, with the qualifier
The scores disagree, and the article should not pick one silently. The GHSA labels the advisory critical. The NVD carries a secondary CVSS v4.0 score of 9.2 (CRITICAL, sourced from [email protected]) and a primary CVSS v3.1 score of 8.1 (HIGH, AC:H). The v3.1 score is lower because the attack complexity is rated high: the attacker needs a deployment where KENER_SECRET_KEY was never set.
As of 2026-10-27 there is no KEV listing and no exploitation evidence. The CISA KEV feed (1,758 entries) has no row for CVE-2026-116747. How many deployments actually ran with the key unset is unknown, and the brief does not claim a prevalence.
What to do if you run Kener
- Upgrade to v4.1.10 or later.
- Set
KENER_SECRET_KEYto a real, unique value. The fix warns on example secrets, but the warning is the new behavior, not the old one. - Rotate any API keys you created. The same report found that keys never expire and are not scoped, so a key that was valid before the fix is still valid after it.
- Review monitor URLs and proxy settings for anything pointing at internal or metadata addresses.
The default-fallback pattern is worth a second look in other self-hosted tools. A placeholder that works in production is a backdoor that ships in the release. Kener's fix is the right shape: drop the fallback, warn on the example value, and make the missing configuration a loud failure instead of a quiet one.
Sources
- GitHub Security Advisory GHSA-7973-f655-53vh
- NVD record CVE-2026-116747
- Vendor disclosure issue rajnandan1/kener#871
- Fix commit ff63648 and v4.1.10 release
- Kener repository
This article was drafted with AI/LLM assistance and reviewed by a human before publication. All factual claims were checked against the public sources cited above. The feature image was generated with AI. See How we use AI for the full workflow.