What is the CVSS score of CVE-2026-50889?

CVE-2026-50889 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.2%.

Which versions of LLDAP are affected by CVE-2026-50889?

LLDAP v0.6.2 contains a denial-of-service vulnerability in its HTTP refresh endpoint that remote, unauthenticated attackers can exploit to disrupt authentication services.

How to fix or mitigate CVE-2026-50889?

Within 24 hours: inventory systems running LLDAP v0.6.2 and implement rate-limiting on the refresh endpoint. Within 7 days: check upstream LLDAP project for patched versions beyond v0.6.2 and test upgrade paths. Within 30 days: complete upgrade to a patched version or establish a long-term compensating control strategy.

LLDAP CVE-2026-50889

EUVD-2026-36787 HIGH

Uncontrolled Resource Consumption (CWE-400)

2026-06-15 mitre

GHSA-6chc-gqpv-4wc5

Denial Of Service N A

7.5

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

7.5 HIGH

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

vuln.today AI

7.5 HIGH

HTTP API reachable over the network without auth or interaction; single crafted header triggers reliably, so AC:L; impact is availability-only with no scope change.

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

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 16, 2026 - 17:22 vuln.today

CVSS changed

Jun 16, 2026 - 17:22 NVD

7.5 (HIGH)

CVE Published

Jun 15, 2026 - 00:00 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

An input handling flaw in the HTTP refresh token process of LLDAP v0.6.2 allows attackers to cause a Denial of Service (DoS) via sending a crafted refresh-token header.

AnalysisAI

Denial of service in LLDAP v0.6.2 allows remote unauthenticated attackers to disrupt the authentication service by sending a crafted refresh-token header to the HTTP refresh endpoint. The flaw is a CWE-400 resource handling defect with CVSS 7.5 (availability-only impact); no public exploit is identified, though a referenced gist may contain proof-of-concept material. EPSS is low at 0.18% (8th percentile) and the issue is not on CISA KEV.

Technical ContextAI

LLDAP (Light LDAP) is a lightweight, self-hosted user-management server that exposes both an LDAP interface and an HTTP/JSON API used by its web UI and integrating applications. Session continuity in the HTTP API is handled through a refresh-token mechanism, and this vulnerability lies in how that endpoint parses or validates incoming refresh-token headers. The CWE-400 (Uncontrolled Resource Consumption) classification indicates the root cause is insufficient bounds, validation, or accounting on an attacker-controlled input - a malformed value causes the server to consume disproportionate CPU, memory, or thread resources rather than rejecting the request cheaply.

RemediationAI

No vendor-released patch identified at time of analysis - the provided references do not include a vendor advisory, release notes, or commit linking to a fixed version. Operators of LLDAP 0.6.2 should monitor the upstream nitnelave/lldap GitHub project for a release newer than 0.6.2 and upgrade once a fix is published, then verify against the NVD record at https://nvd.nist.gov/vuln/detail/CVE-2026-50889. In the interim, place the LLDAP HTTP API behind a reverse proxy that enforces strict header size limits and rate-limits the refresh-token endpoint (trade-off: legitimate bursty re-auth from many clients may be throttled), restrict network exposure of the HTTP port to trusted management networks or VPN only (trade-off: breaks any external integrations that depend on it), and ensure the LLDAP process runs under a supervisor that will auto-restart it after an availability event so outages are short. The third-party gist referenced in the input should be reviewed only in a controlled environment, as its contents are not vendor-vetted.