CVE-2026-63092: Kirby Modules: license key disclosure via activate dialog

MEDIUM
Published July 21, 2026
CISO Take

kirby-modules, a commercial plugin for the Kirby CMS panel, lets any authenticated Panel user — even one with no administrative privileges — retrieve the plugin's full plaintext commercial license key by issuing a GET request to the modules/activate dialog endpoint, because the handler in lib/areas.php calls ModulesLicense::readKey() while gating access only on the access.system permission, which defaults to true for all non-admin roles. This is a low-severity licensing/authorization flaw (CVSS 4.3, no EPSS score, not in CISA KEV, no public exploit or scanner template) rather than a data-breach or system-compromise issue — the practical harm is licensing fraud, since a low-privilege insider or compromised account could lift the key and reuse it to activate the plugin on unauthorized third-party installations. Despite being tagged under the ml_ui AI category, this CVE has no AI/ML attack surface: kirby-modules does not appear in our tracked AI/ML package inventory, and the vulnerability class (missing authorization check, CWE-862) is generic CMS plugin hygiene, not an AI-specific exposure. CISOs running Kirby CMS with this plugin should upgrade past commit 315417e (fixed in kirby-modules through 5.5.7) and, in the interim, audit which non-admin Panel roles hold access.system and restrict it where not operationally required. No detection or compensating control is needed beyond standard Panel access-log review for unexpected activate-dialog requests from non-admin accounts.

Sources: NVD GitHub Advisory

What is the risk?

Low overall risk. Exploitation requires an existing authenticated Panel account (PR:L) but no user interaction and low attack complexity — any non-admin user can trigger it over the network. Impact is confidentiality-only (disclosure of a commercial license key), with no integrity or availability effect on the host system, no code execution, and no exposure of end-user or business data. There is no public exploit, no EPSS score, and it is not in CISA KEV, indicating no known active exploitation. The realistic worst case is license/revenue fraud against the plugin vendor, not a security incident against the operator's own systems or users.

How does the attack unfold?

Initial Access
Attacker authenticates to the Kirby Panel with any non-admin account, which by default holds the access.system permission.
Exploitation
Attacker sends a GET request to the modules/activate dialog endpoint, triggering ModulesLicense::readKey() without an administrator check.
Impact
The plaintext commercial license key is disclosed and reused to activate the plugin on unauthorized third-party installations, defrauding the vendor.

How severe is it?

CVSS 3.1
4.3 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 21% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C Low
I None
A None

What should I do?

1 step
  1. Upgrade kirby-modules to the version containing commit 315417e (or later, once a formal 5.5.8+ release is available) so the activate dialog enforces an administrator check before returning the license key. As an interim workaround, review and restrict which non-admin Panel roles are granted the access.system permission, since that default-true grant is what exposes the endpoint. Detection: audit Panel access logs for GET requests to the modules/activate dialog route originating from non-admin accounts, and rotate the plugin's commercial license key if unauthorized activations are observed on installations you do not control.

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage Plugin

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-63092?

kirby-modules, a commercial plugin for the Kirby CMS panel, lets any authenticated Panel user — even one with no administrative privileges — retrieve the plugin's full plaintext commercial license key by issuing a GET request to the modules/activate dialog endpoint, because the handler in lib/areas.php calls ModulesLicense::readKey() while gating access only on the access.system permission, which defaults to true for all non-admin roles. This is a low-severity licensing/authorization flaw (CVSS 4.3, no EPSS score, not in CISA KEV, no public exploit or scanner template) rather than a data-breach or system-compromise issue — the practical harm is licensing fraud, since a low-privilege insider or compromised account could lift the key and reuse it to activate the plugin on unauthorized third-party installations. Despite being tagged under the ml_ui AI category, this CVE has no AI/ML attack surface: kirby-modules does not appear in our tracked AI/ML package inventory, and the vulnerability class (missing authorization check, CWE-862) is generic CMS plugin hygiene, not an AI-specific exposure. CISOs running Kirby CMS with this plugin should upgrade past commit 315417e (fixed in kirby-modules through 5.5.7) and, in the interim, audit which non-admin Panel roles hold access.system and restrict it where not operationally required. No detection or compensating control is needed beyond standard Panel access-log review for unexpected activate-dialog requests from non-admin accounts.

Is CVE-2026-63092 actively exploited?

No confirmed active exploitation of CVE-2026-63092 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-63092?

Upgrade kirby-modules to the version containing commit 315417e (or later, once a formal 5.5.8+ release is available) so the activate dialog enforces an administrator check before returning the license key. As an interim workaround, review and restrict which non-admin Panel roles are granted the access.system permission, since that default-true grant is what exposes the endpoint. Detection: audit Panel access logs for GET requests to the modules/activate dialog route originating from non-admin accounts, and rotate the plugin's commercial license key if unauthorized activations are observed on installations you do not control.

What is the CVSS score for CVE-2026-63092?

CVE-2026-63092 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.28%.

What are the technical details?

Original Advisory

kirby-modules through 5.5.7, fixed in commit 315417e, contains an information disclosure vulnerability that allows any authenticated Kirby Panel user to retrieve the full plaintext commercial license key by sending a GET request to the modules/activate dialog endpoint. The plugin's activate dialog handler in lib/areas.php returns the complete key via ModulesLicense::readKey() without performing an administrator check, as the dialog is gated only by the access.system permission which defaults to true for all non-admin roles, enabling attackers to use the disclosed key to activate the plugin on arbitrary third-party installations.

Exploitation Scenario

An attacker who holds or compromises any authenticated Kirby Panel account — including a low-privilege editor role with no administrative rights — sends a simple GET request to the modules/activate dialog endpoint. Because the handler only checks the access.system permission (true by default for non-admin roles) rather than verifying admin status, it returns the full plaintext commercial license key via ModulesLicense::readKey(). The attacker then reuses that stolen key to activate the same commercial plugin on an unrelated third-party Kirby installation they control, defrauding the plugin vendor of a paid license without ever touching the victim's actual site data or infrastructure.

Weaknesses (CWE)

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Timeline

Published
July 21, 2026
Last Modified
July 23, 2026
First Seen
July 21, 2026

Related Vulnerabilities