Security Resilience

CVE-2024-26138

Access Control in Xwiki Application Licensing 1.0 – 1.24.2

Published
21 February 2024
Modified
17 June 2026
Patch / advisory
CVSS Score v3.1 5.3
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
EPSS Score 0.0049 41th percentile
Risk Priority 44 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2024-26138 is a medium-severity Missing Authorization (CWE-862) vulnerability in Xwiki Application Licensing. Its CVSS base score is 5.3 (Medium).

Operationally, ranked at the 41th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to AC-24 (Access Control Decisions) and AC-25 (Reference Monitor) — see the control section below for these in your framework.

OWASP Top 10 for Web (2025)

EU & UK References

Vulnerability Data

The XWiki licensor application, which manages and enforce application licenses for paid extensions, includes the document `Licenses.Code.LicenseJSON` that provides information for admins regarding active licenses. This document is public and thus exposes this information publicly. The information includes the instance's…

more

id as well as first and last name and email of the license owner. This is a leak of information that isn't supposed to be public. The instance id allows associating data on the active installs data with the concrete XWiki instance. Active installs assures that "there's no way to find who's having a given UUID" (referring to the instance id). Further, the information who the license owner is and information about the obtained licenses can be used for targeted phishing attacks. Also, while user information is normally public, email addresses might only be displayed obfuscated, depending on the configuration. This has been fixed in Application Licensing 1.24.2. There are no known workarounds besides upgrading.

CWE(s)

Related Threats

CVEs Like This One

CVE-2025-46557Same vendor: Xwiki
CVE-2024-31987Same vendor: Xwiki
CVE-2024-31981Same vendor: Xwiki
CVE-2024-31983Same vendor: Xwiki
CVE-2025-23025Same vendor: Xwiki
CVE-2025-46554Same vendor: Xwiki
CVE-2025-32973Same vendor: Xwiki
CVE-2024-31997Same vendor: Xwiki
CVE-2024-37898Same vendor: Xwiki
CVE-2024-55876Same vendor: Xwiki

Affected Assets

xwiki
application licensing
1.0 — 1.24.2

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

AC-3 directly requires enforcement of authorization decisions on every access request, structurally eliminating missing authorization checks.

AC-24 mandates that access control decisions are applied to each request, preventing bypass of authorization logic.

AC-25 requires a tamperproof, always-invoked reference monitor that ensures authorization checks cannot be omitted.

AC-6 reduces the set of actions reachable without proper authorization, limiting blast radius of missing checks.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

blocks

Requiring formal authorization of every access request before rights are granted ensures that checks for required permissions are performed, preventing missing authorization checks from being introduced.

blocks

A.5.18's provisioning, review, revocation and activation steps (incl. owner approval, SoD, timely removal on role/termination change) directly stop exploitation of missing authorization checks by ensuring no actor receives or retains rights to resources they should not access; the bounded remainder is that it cannot stop missing-authorization defects inside the enforcement mechanism itself once rights have been granted (e.g. flawed code that ignores the rights table).

finds

By requiring competent outsiders to verify that every function enforces the need-to-know principle, the control lowers the likelihood that missing authorization checks persist undetected.

blocks

A.5.8 integrates risk assessment, requirements elicitation and governance into the project lifecycle so that authorization needs can be identified and specified; it does not itself perform or enforce authorization checks, so the missing-authorization weakness can still be present and exploitable.

blocks

Security checkpoints and explicit authorization requirements in the design phase ensure that every sensitive function is paired with an access-control check, reducing missing-authorization defects.

blocks

A.8.27 mandates security-by-design principles (least privilege, default deny, security architecture integration, zero-trust never-trust/always-verify, dynamic access control) plus design reviews that directly specify and enforce authorization checks before access; this stops most missing-authorization cases from being exploitable, with a bounded remainder in non-architectural or legacy components where the principles were documented but not fully applied.

Hardening callouts derived

DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.

  • No fine-grained STIG row for CWE-862, a class-level weakness, and none of its children carries one either.

References