Skip to main content

CVE-2026-33053

HIGH
Authorization Bypass Through User-Controlled Key (CWE-639)
2026-03-18 https://github.com/langflow-ai/langflow GHSA-rf6x-r45m-xv3w
8.8
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
8.8 HIGH
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

3
Analysis Generated
Mar 18, 2026 - 13:15 vuln.today
Patch released
Mar 18, 2026 - 13:15 nvd
Patch available
CVE Published
Mar 18, 2026 - 12:58 nvd
HIGH 8.8

DescriptionGitHub Advisory

Detection Method: Kolega.dev Deep Code Scan

AttributeValue
Locationsrc/backend/base/langflow/api/v1/api_key.py:44-53
Practical ExploitabilityHigh
Developer Approverfaizan@kolega.ai

Description

The delete_api_key_route() endpoint accepts an api_key_id path parameter and deletes it with only a generic authentication check (get_current_active_user dependency). However, the delete_api_key() CRUD function does NOT verify that the API key belongs to the current user before deletion.

Affected Code

@router.delete("/{api_key_id}", dependencies=[Depends(auth_utils.get_current_active_user)])
async def delete_api_key_route(
    api_key_id: UUID,
    db: DbSession,
):
    try:
        await delete_api_key(db, api_key_id)
    except Exception as e:
        raise HTTPException(status_code=400, detail=str(e)) from e
    return {"detail": "API Key deleted"}

Evidence

In crud.py lines 44-49, delete_api_key() retrieves the API key by ID and deletes it without checking if the key belongs to the authenticated user. The endpoint also doesn't pass the current_user to the delete function for verification.

Impact

An authenticated attacker can enumerate and delete API keys belonging to other users by guessing or discovering their API key IDs. This allows account takeover, denial of service, and disruption of other users' integrations.

Recommendation

Modify the delete_api_key endpoint and function: (1) Pass current_user to the delete function; (2) In delete_api_key(), verify api_key.user_id == current_user.id before deletion; (3) Raise a 403 Forbidden error if the user doesn't own the key. Example: if api_key.user_id != user_id: raise HTTPException(status_code=403, detail='Unauthorized')

Notes

Confirmed IDOR vulnerability. The delete_api_key_route endpoint at line 44-53 accepts an api_key_id and calls delete_api_key(db, api_key_id) without passing the current_user. The CRUD function delete_api_key() at crud.py:44-49 retrieves the API key by ID and deletes it without verifying ownership (api_key.user_id current_user.id). Compare this to the GET endpoint at lines 17-28 which correctly filters by user_id, and the POST endpoint at lines 31-41 which correctly associates the key with user_id. An authenticated attacker can delete any user's API keys by guessing/enumerating UUIDs. Fix: Pass current_user to delete_api_key and verify api_key.user_id current_user.id before deletion, returning 403 if unauthorized.

Developer Review Notes

Does not accept current_user as a parameter. Allowing deletion of any user's API keys even without permissions.

AnalysisAI

An Insecure Direct Object Reference (IDOR) vulnerability exists in the Langflow API key deletion endpoint that allows any authenticated user to delete API keys belonging to other users. The delete_api_key_route() function in langflow version prior to 1.7.2 fails to verify ownership of API keys before deletion, enabling attackers to enumerate and delete arbitrary API keys by manipulating the api_key_id UUID parameter. A patch is available from the vendor as of version 1.7.2, addressing this authentication bypass that could lead to account takeover and denial of service.

Technical ContextAI

This vulnerability affects the Langflow Python package (pkg:pip/langflow) and represents a classic implementation of CWE-639 (Authorization Bypass Through User-Controlled Key). The flaw exists in src/backend/base/langflow/api/v1/api_key.py where the DELETE endpoint at lines 44-53 uses the get_current_active_user dependency for authentication but fails to implement authorization checks. The endpoint calls delete_api_key() without passing the current_user context, and the corresponding CRUD function in crud.py deletes API keys based solely on the api_key_id parameter without verifying that the api_key.user_id matches the authenticated user's ID. This contrasts with properly implemented GET and POST endpoints in the same file that correctly filter by user_id and associate keys with the authenticated user. The vulnerability leverages UUID enumeration to target API keys across user boundaries in a multi-tenant environment.

RemediationAI

Upgrade Langflow to version 1.7.2 or later, which includes the fix implemented in commit fdc1b3b1448ff3317d73d3e769a6c4a1717f74d7 available at https://github.com/langflow-ai/langflow/commit/fdc1b3b1448ff3317d73d3e769a6c4a1717f74d7. The patch modifies the delete_api_key_route endpoint to pass the current_user context to the delete_api_key CRUD function and adds ownership verification (api_key.user_id == current_user.id) before allowing deletion, returning HTTP 403 Forbidden for unauthorized attempts. Release notes are available at https://github.com/langflow-ai/langflow/releases/tag/1.7.2. Until patching is completed, implement compensating controls such as API gateway request validation to verify user ownership before forwarding delete requests, enable comprehensive audit logging for all API key operations to detect enumeration attempts, and consider temporarily restricting API key deletion functionality to administrative users only through role-based access control modifications.

Share

CVE-2026-33053 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy