CVE-2026-48508 is a high-severity incorrect authorization vulnerability in lemur (pip), affecting versions <= 1.9.0. It is fixed in 1.9.1.
Summary StrictRolePermission and AuthorityCreatorPermission in lemur/auth/permissions.py call flaskprincipal.Permission.init() with zero Needs when their config flags are unset. Both flags defaulted to False in code prior to the fix, so this was the state of any Lemur install that hadn't explicitly opted in. Flask-Principal's Permission.allows() returns True whenever self.needs is empty. The .can() gate therefore passes for every authenticated identity, including the lowest-privilege role Lemur ships (read-only). A user holding only read-only can create root Certificate Authorities, create and edit notifications (an SSRF sink), create domain entries, and upload arbitrary certificates. These classes are the sole authorization check on those endpoints. Root Cause flaskprincipal.Permission.allows() (upstream, v0.4.0): When self.needs == set(), the first guard is falsy and is skipped. excludes is also empty, so allows() returns True for any identity. AuthenticatedResource (the parent class for these views) sets methoddecorators = [loginrequired], which checks authentication only, no role. So the permission .can() is the only authorization layer in front of these endpoints. Affected Endpoints Views whose only authorization check is StrictRolePermission().can() or AuthorityCreatorPermission().can(): | Method | Path | Source | |----------|-------------------------------------------|-----------------------------------------| | POST | /api/1/authorities | lemur/authorities/views.py:231 | | POST | /api/1/certificates/upload | lemur/certificates/views.py:651 | | POST | /api/1/pendingcertificates/\<id>/upload | lemur/pendingcertificates/views.py:545 | | POST | /api/1/notifications | lemur/notifications/views.py:227 | | PUT/DEL | /api/1/notifications/\<id> | lemur/notifications/views.py:370,384 | | POST | /api/1/domains | lemur/domains/views.py:131 | POST /api/1/authorities is gated by AuthorityCreatorPermission().can() and StrictRolePermission().can(); both have empty Needs by default. The other rows are gated by StrictRolePermission().can() alone. Note on scope: PUT /api/1/authorities/<id> also references StrictRolePermission, but its gate is AuthorityPermission(...).can() and StrictRolePermission().can(). AuthorityPermission is constructed with non-empty Needs (RoleNeed("admin") plus authority-scoped needs), so that endpoint is not bypassable by a read-only user and is excluded from this report. Impact A user holding only the read-only role can: Create root Certificate Authorities. CA cert and private key are persisted in Lemur's DB with the attacker as owner. Any internal trust store that pins Lemur-managed roots can now be signed against by the attacker. Upload arbitrary certificates via /certificates/upload, including attacker-supplied keys with destinations such as AWS push. Create or modify notifications, which reach an SSRF sink (see related finding F3, Slack notification webhook). Mark arbitrary domains as sensitive, manipulating Lemur's domain registry and the cert-issuance approval path. Combined with any low-privilege credential leak (phished employee, leaked SSO token) or insider access, this is a pivot from "any authenticated identity" to control of the PKI issuance plane. Remediation The config flag defaults for ADMINONLYAUTHORITYCREATION and LEMURSTRICTROLEENFORCEMENT were changed from False to True. Restrictive role enforcement is now active on all default installs without requiring explicit configuration. Note: The opt-out branches (empty Needs) remain in the code. Operators who explicitly set ADMINONLYAUTHORITYCREATION = False or LEMURSTRICTROLEENFORCEMENT = False in their config will reintroduce the bypass. These flags should be left unset or set to True.
The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.
CVE-2026-48508 has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment.
A fixed version is available (1.9.1). Upgrading removes the vulnerable code path.
pip
lemur (<= 1.9.0)lemur → 1.9.1 (pip)Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.
Kodem's runtime-powered SCA identifies whether CVE-2026-48508 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-48508 is reachable in your applications. Get a demo
Already deployed Kodem? See CVE-2026-48508 in your environment →Upgrade lemur to 1.9.1 or later to resolve this vulnerability.
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
CVE-2026-48508 is a high-severity incorrect authorization vulnerability in lemur (pip), affecting versions <= 1.9.0. It is fixed in 1.9.1. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
CVE-2026-48508 has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
lemur (pip) versions <= 1.9.0 is affected.
Yes. CVE-2026-48508 is fixed in 1.9.1. Upgrade to this version or later.
Whether CVE-2026-48508 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
Upgrade lemur to 1.9.1 or later.