Capgo Missing Row-Level Security Policy in build_requests Table

Executive Summary

This vulnerability exists in Capgo versions before 12.128.2, where there is a missing UPDATE row-level security policy on the build_requests table.

Because of this missing policy, API-key and anonymous users cannot persist builder status updates.

Attackers can exploit this to cause build status and error details to remain unpersisted, resulting in build_requests rows being stuck in a pending state with null last_error values.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability causes build_requests rows to remain stuck in a pending state with null last_error values, despite the /build/status endpoint returning the correct builder status and error details.

To detect this issue, you can query the build_requests table in your Capgo database to identify rows where the status is 'pending' but the last_error field is null, indicating that updates are not being persisted correctly.

• Run a SQL query such as: SELECT * FROM build_requests WHERE status = 'pending' AND last_error IS NULL;

Additionally, monitoring API responses from the /build/status endpoint and comparing them with the database state can help detect discrepancies caused by this vulnerability.

Useful 0 Not Useful 0

Impact Analysis

The impact of this vulnerability is that build status updates and error details may not be saved correctly.

This can cause build requests to remain indefinitely in a pending state without proper error information.

As a result, it may lead to confusion, delays, or failures in build processes that rely on accurate status reporting.

Useful 0 Not Useful 0

Compliance Impact

The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation involves adding an UPDATE row-level security (RLS) policy for the build_requests table to allow authorized users or API keys to persist builder status updates.

Alternatively, perform updates to the build_requests table using a service role that has the necessary permissions to bypass the missing RLS policy.

• Add an RLS policy permitting UPDATE operations on build_requests for authorized users.
• Use a service role with sufficient privileges to perform the required updates until the RLS policy is fixed.

These steps will ensure that build status and error details are correctly persisted, preventing rows from being stuck in a pending state with null last_error values.

Useful 0 Not Useful 0