CVE-2026-100618 in Capgo
Summary
by MITRE • 09/26/2026
Capgo (capgo.app) is affected by an authorization flaw in the app icon update path. The PUT /app/:id endpoint accepts a user-controlled `icon` value, normalizes it, and stores it in public.apps.icon_url without verifying that the image path belongs to the target app's own image namespace (e.g. org/{owner_org}/{app_id}/...). Updating apps.icon_url fires the on_app_update trigger, whose worker reads record.icon_url and calls cleanStoredImageMetadata(), which runs with service-role credentials (supabaseAdmin()) and downloads and re-uploads the referenced storage object with upsert: true. As a result, an authenticated holder of an app-limited write API key can cause the privileged worker to rewrite an out-of-scope private image object (for example an organization logo) that the key cannot read or write directly under Supabase Storage RLS. All versions are affected; no patched version was available at the time of the advisory.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Capgo represents a critical authorization bypass within the application icon update mechanism, specifically targeting the PUT /app/:id endpoint. This flaw stems from an insufficient verification process where the system accepts user-controlled input for the image path without validating that the referenced resource resides within the authorized namespace of the target application. In secure architectures, particularly those utilizing role-based access control and row-level security as seen in Supabase environments, it is imperative to enforce strict boundary checks between different organizational or project scopes. Here, the normalization of the icon value allows an attacker to supply a path pointing outside the expected directory structure, such as org/{owner_org}/{app_id}/..., thereby circumventing standard access controls that would normally restrict visibility and modification rights to specific data partitions.
The operational impact is significantly amplified by the backend processing logic associated with app updates. When the apps.icon_url field is modified, it triggers an on_app_update event which invokes a worker process running under elevated service-role credentials via supabaseAdmin(). This privileged context executes cleanStoredImageMetadata(), a function responsible for downloading and re-uploading storage objects using upsert operations. Because this worker operates with administrative privileges that bypass standard row-level security restrictions, the system effectively allows an authenticated user possessing only limited write access to their own app configuration to manipulate arbitrary private images stored within the same Supabase project. This includes sensitive assets such as organization logos or other proprietary media files that are not accessible via direct API calls due to strict RLS policies designed to isolate tenant data.
From a technical perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-913 Improvement of Control Over Resource Management by Untrusted Controller. The core issue lies in the failure to validate that the resource identifier provided by the client corresponds to an object owned or permitted for modification by the requesting entity's context. Furthermore, this attack vector can be mapped to MITRE ATT&CK techniques involving privilege escalation and unauthorized data access, specifically leveraging trusted processes to perform actions outside their intended scope. The exploitation does not require authentication bypass but rather abuses existing valid credentials with limited privileges to trigger a privileged action that affects resources beyond the user's authorized domain.
Mitigation strategies must focus on implementing rigorous input validation and authorization checks at multiple layers of the application stack. First, the PUT /app/:id endpoint should enforce strict path normalization and verification to ensure that any provided icon URL points exclusively to objects within the specific app or organization namespace associated with the authenticated user's API key. Second, the privileged worker process executing cleanStoredImageMetadata() must implement additional authorization checks before performing storage operations, ensuring that even under service-role credentials, it only processes resources explicitly permitted for modification by the initiating request context. Finally, adopting a principle of least privilege for background workers and auditing all external resource references during update cycles can prevent similar bypasses in future iterations until a patched version is released.