Alta

Lemur has an authorization bypass in StrictRolePermission / AuthorityCreatorPermission

  • Publicada: 25.06.2026
  • Actualizado: 11.10.2026 14:17

Summary

StrictRolePermission and AuthorityCreatorPermission in lemur/auth/permissions.py call flask_principal.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

python
# lemur/auth/permissions.py
class AuthorityCreatorPermission(Permission):
    def __init__(self):
        requires_admin = current_app.config.get("ADMIN_ONLY_AUTHORITY_CREATION", False)
        if requires_admin:
            super().__init__(RoleNeed("admin"))
        else:
            super().__init__()              # empty Need set

class StrictRolePermission(Permission):
    def __init__(self):
        strict_role_enforcement = current_app.config.get("LEMUR_STRICT_ROLE_ENFORCEMENT", False)
        if strict_role_enforcement:
            needs = [RoleNeed("admin"), RoleNeed("operator")]
            super().__init__(*needs)
        else:
            super().__init__()              # empty Need set

flask_principal.Permission.allows() (upstream, v0.4.0):

python
def allows(self, identity):
    if self.needs and not self.needs.intersection(identity.provides):
        return False
    ...
    return True

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 method_decorators = [login_required], 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/pending_certificates/<id>/upload lemur/pending_certificates/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:

  1. 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.
  2. Upload arbitrary certificates via /certificates/upload, including attacker-supplied keys with destinations such as AWS push.
  3. Create or modify notifications, which reach an SSRF sink (see related finding F3, Slack notification webhook).
  4. 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 ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT were changed from False to True. Restrictive role enforcement is now active on all default installs without requiring explicit configuration.

python
class AuthorityCreatorPermission(Permission):
    def __init__(self):
        requires_admin = current_app.config.get("ADMIN_ONLY_AUTHORITY_CREATION", True)
        ...

class StrictRolePermission(Permission):
    def __init__(self):
        strict_role_enforcement = current_app.config.get("LEMUR_STRICT_ROLE_ENFORCEMENT", True)
        ...

Note: The opt-out branches (empty Needs) remain in the code. Operators who explicitly set ADMIN_ONLY_AUTHORITY_CREATION = False or LEMUR_STRICT_ROLE_ENFORCEMENT = False in their config will reintroduce the bypass. These flags should be left unset or set to True.

Software afectado

Haz clic en una tecnología para ver todas sus vulnerabilidades.

PlataformaPaqueteVersiones vulnerablesCorregida en
Python (PyPI) lemur < 1.9.1 1.9.1

Referencias

Puntuación CVSS 8.8/10
Vector CVSS
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Debilidad (CWE)
CWE-863
Plataforma
Python (PyPI)
Paquete
lemur
Publicada
25.06.2026
Actualizado
11.10.2026 14:17

Fuentes y licencias

OSV / GitHub Advisory Database - PYSEC-2026-2588 - PyPA Advisory Database; CC BY 4.0

OSV / GitHub Advisory Database - GHSA-qcqw-jwxc-2hqg - CC BY 4.0

Historial de vulnerabilidades: lemur

Todas las vulnerabilidades publicadas de este paquete (Python (PyPI)), de la más reciente a la más antigua. Muestra si es un fallo aislado o un paquete que hay que vigilar.

Todas (18) en el archivo
Entradas en total
18
Primera → última
08.2017 08.2026
Sin corrección
0
Explotada en ataques
0

Distribución por gravedad

  • Crítica 1
  • Alta 9
  • Media 8

Divulgaciones por año

  1. 2017: 1
  2. 2018: 0
  3. 2019: 0
  4. 2020: 0
  5. 2021: 0
  6. 2022: 0
  7. 2023: 1
  8. 2024: 0
  9. 2025: 0
  10. 2026: 16
Gravedad:
  1. Lemur has an authorization bypass in StrictRolePermission / AuthorityCreatorPermission esta entrada
    Alta · 8.8 CVE-2026-48508 < 1.9.1 1.9.1
  2. Alta · 7.5 CVE-2023-30797 < 1.3.2 1.3.2
  3. Alta · 7.5 CVE-2015-7764 < 0.1.5 0.1.5

Identifica las vulnerabilidades de tu aplicación

Con la integración de DockRay y el inventario de software activado, DockRay compara las versiones notificadas de los componentes con las vulnerabilidades conocidas y avisa de las coincidencias confirmadas. La cobertura depende de la tecnología compatible y de los avisos disponibles.

Conectar tu aplicación
Newsletter DockRay

La seguridad de tus aplicaciones en tu correo

Vulnerabilidades importantes, recomendaciones concretas y consejos prácticos para tus aplicaciones. Elige tus tecnologías y sigue lo que importa para tu proyecto.

  • Un resumen diario de nuevas vulnerabilidades, también las críticas.
  • Avisos sobre actualizaciones importantes.
  • Consejos prácticos sobre seguridad y monitorización de aplicaciones.

Déjalo vacío para recibir avisos de todas las tecnologías.

Suscripción gratuita. Date de baja con un clic en cualquier correo.