CVE-2026-24055: Langfuse Auth Bypass Vulnerability

CVE-2026-24055 Overview

CVE-2026-24055 is an Authorization Bypass vulnerability affecting Langfuse, an open source large language model (LLM) engineering platform. The vulnerability exists in the Slack OAuth integration flow where the /api/public/slack/install endpoint accepts client-provided projectId values without proper authentication or authorization checks. This design flaw allows attackers to bind unauthorized Slack workspaces to arbitrary Langfuse projects, potentially intercepting prompt management notifications and changes.

Critical Impact

Attackers can hijack Slack integrations to receive sensitive prompt management data from arbitrary Langfuse projects, enabling potential data exfiltration and manipulation of LLM prompt workflows.

Affected Products

• Langfuse versions 3.146.0 and below
• Langfuse Slack OAuth integration component
• Langfuse Prompt Management with Slack Automation features

Discovery Timeline

• 2026-01-22 - CVE CVE-2026-24055 published to NVD
• 2026-01-22 - Last updated in NVD database

Technical Details for CVE-2026-24055

Vulnerability Analysis

The vulnerability resides in Langfuse's Slack OAuth integration flow, specifically in how the application handles the projectId parameter during the OAuth installation process. The /api/public/slack/install endpoint initiates the Slack OAuth flow using a client-supplied projectId without validating whether the requesting user has legitimate access to that project.

During the OAuth flow, this untrusted projectId is preserved in the state parameter and passed through to the callback handler. When the OAuth callback processes the successful authentication from Slack, it stores the installation record based on this attacker-controlled metadata, effectively binding the attacker's Slack workspace to any target project.

This vulnerability enables two primary attack scenarios: replacing existing legitimate Prompt Slack Automation integrations with malicious ones, or pre-registering a malicious integration before legitimate users configure their own. The latter scenario requires some user interaction, as users would need to configure the integration despite visible workspace and channel indicators in the UI.

Root Cause

The root cause is a classic Broken Access Control vulnerability (CWE-284) where the application fails to implement proper authorization checks before initiating sensitive OAuth flows. The endpoint trusted client-provided input (projectId) without verifying the requester's relationship to the specified project. This violates the principle that security-critical operations should always verify authorization before proceeding.

Attack Vector

The attack is network-based and requires the attacker to craft requests to the vulnerable /api/public/slack/install endpoint with a target projectId. The attack flow proceeds as follows:

1. Attacker identifies or guesses a target Langfuse project ID
2. Attacker initiates the Slack OAuth flow via /api/public/slack/install?projectId=TARGET_PROJECT_ID
3. Attacker completes OAuth authentication with their own Slack workspace
4. The callback stores the malicious integration, binding attacker's workspace to target project
5. Attacker's Slack workspace now receives prompt management notifications intended for the legitimate project

The security patch addresses this by implementing proper authentication and authorization checks:

 } from "@langfuse/shared/src/server";
 import { logger } from "@langfuse/shared/src/server";
 import { env } from "@/src/env.mjs";
+import { getServerAuthSession } from "@/src/server/auth";
+import { auditLog } from "@/src/features/audit-logs/auditLog";
+import { prisma } from "@langfuse/shared/src/db";
 
 /**
  * SlackOAuthHandlers

Source: GitHub Commit Update

The fix adds server-side authentication validation and project access verification:

 import { handleInstallPath } from "@/src/features/slack/server/oauth-handlers";
 import { logger } from "@langfuse/shared/src/server";
 import { cors, runMiddleware } from "@/src/features/public-api/server/cors";
+import { getServerAuthSession } from "@/src/server/auth";
+import { hasProjectAccess } from "@/src/features/rbac/utils/checkProjectAccess";
 
 export default async function handler(
   req: NextApiRequest,

Source: GitHub Commit Update

Detection Methods for CVE-2026-24055

Indicators of Compromise

• Unexpected Slack workspace integrations appearing in Langfuse project settings
• OAuth installation records with unfamiliar Slack workspace IDs or channel names
• Multiple Slack installations for the same project from different sources
• Audit log entries showing Slack integration changes from unexpected IP addresses

Detection Strategies

• Review all existing Slack integrations in Langfuse Prompt Management and verify workspace ownership
• Monitor access logs for unusual patterns on the /api/public/slack/install endpoint
• Implement alerting for new Slack OAuth callback completions and correlate with legitimate user activity
• Cross-reference Slack workspace IDs in integrations against known organizational workspaces

Monitoring Recommendations

• Enable and review Langfuse audit logs for all integration-related activities
• Configure alerts for any new Slack automation configurations
• Monitor for OAuth flow initiations that don't correspond to authenticated user sessions
• Regularly audit connected Slack workspaces and remove any unrecognized integrations

How to Mitigate CVE-2026-24055

Immediate Actions Required

• Upgrade Langfuse to version 3.147.0 or later immediately
• Audit all existing Slack integrations and remove any unauthorized workspace bindings
• Review prompt management configurations for any unexpected changes or additions
• Regenerate any API keys or tokens associated with affected projects as a precautionary measure

Patch Information

Langfuse has released version 3.147.0 which addresses this vulnerability by implementing proper authentication and authorization checks on the Slack install endpoint. The fix uses getServerAuthSession to verify user authentication and hasProjectAccess from the RBAC utilities to confirm the requesting user has legitimate access to the specified project before initiating the OAuth flow.

For detailed patch information, see the GitHub Release v3.147.0 and the GitHub Security Advisory GHSA-pvq7-vvfj-p98x.

Workarounds

• Disable Slack integration functionality entirely until patching is possible
• Implement network-level access controls to restrict access to the /api/public/slack/install endpoint
• Use a web application firewall (WAF) to block unauthenticated requests to OAuth endpoints
• Monitor and manually approve all new Slack integrations through administrative review

# Example: Block access to vulnerable endpoint via nginx until patched
location /api/public/slack/install {
    # Temporarily disable the endpoint
    return 403 "Endpoint temporarily disabled for security maintenance";
    
    # Alternative: Restrict to known admin IPs
    # allow 10.0.0.0/8;
    # deny all;
}