IDOR Vulnerability in Deployment Service: Cross-Project Boundary Bypass Leading to Unauthorized State Change (BUILDING to DEPLOYING)

Vulnerability Overview Title: Cross-project deployment worker registration allows modification of another project's deployment state Description: The backend worker registration endpoint for deployments validates requests; however, the V4 deployment registration service locates the target deployment solely by its friendly ID. It does not restrict deployment lookup or subsequent state transitions to an authenticated environment or project. Consequently, a token belonging to Project A can be used to submit Project B's deployment ID to the backend worker registration endpoint. The service creates or locates a background worker under Project A's environment and links it to Project B's deployment, thereby transitioning Project B's deployment from the BUILDING state to the DEPLOYING state. Scope Affected Versions: = v4.5.0-rc.3 Severity: Critical (9.9 / 10) CVSS v3 Base Metrics: - Attack Vector: Network - Attack Complexity: Low - Privileges Required: Low - User Interaction: None - Scope: Changed - Confidentiality: Low - Integrity: High - Availability: High Remediation 1. Technical Details: - The route validates the API request and invokes . - In , the service retrieves the deployment solely by deployment ID. - Worker creation utilizes the authenticated caller's environment and an unrestricted deployment reference. - Finally, the service links the caller's worker to a deployment selected only by database ID and BUILDING status. 2. Code Example: 3. Recommended Fix: - Restrict the deployment lookup and protected state transitions by adding and/or predicates. - Apply the same boundary predicates to the final transition. - Verify that any existing linked deployment workers belong to the same project and runtime environment before returning them during late-stage branching or deployment finalization. Reproduction A focused service-level test demonstrates the boundary bypass. It initiates a victim deployment in Project B, then calls with an authenticated environment from Project A, passing Project B's deployment friendly ID. Infrastructure dependencies are mocked, but the vulnerable service method and worker creation helpers are real. Test Assertions: 1. The returned background worker belongs to the attacker's project and environment. 2. The victim deployment transitions to DEPLOYING. 3. The victim deployment's is set to the attacker's worker ID. 4. No worker is created in the victim's project. Expected Behavior Deployment worker registration requests should only locate and modify deployments belonging to the authenticated environment and project. A token from Project A submitting a deployment ID from Project B should return a "Not Found" or "Forbidden" error. Suggested Fixes Restrict the deployment lookup predicates as follows: Apply the same boundary predicates to the final transition. Verify that any existing linked deployment workers belong to the same project and runtime environment before returning them during late-stage branching or deployment finalization.

Goal Reached Thanks to every supporter — we hit 100%!

IDOR Vulnerability in Deployment Service: Cross-Project Boundary Bypass Leading to Unauthorized State Change (BUILDING to DEPLOYING)

More from this source