Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-09-26T14:16:42.600Z",
  "pubdate": "2026-09-26T14:16:42.600Z",
  "executiveSummary": "Capgo (capgo.app) contains an authorization flaw within its application icon update mechanism, categorized as an Improper Authorization vulnerability.\nThe vulnerability allows an authenticated attacker possessing an app-limited write API key to perform unauthorized file operations on out-of-scope Supabase storage objects.\nBy manipulating the icon update path, an attacker can trick a privileged backend worker, running with service-role credentials, into overwriting private assets, such as organization logos, that are otherwise protected by Row-Level Security (RLS).\nThis represents a significant security risk, as it bypasses standard access control enforcement, potentially leading to unauthorized data modification or logical corruption of internal organizational resources.\nThe vulnerability affects all versions of the product, as no patch was available at the time of discovery.",
  "technicalDetails": "The root cause of this vulnerability lies in an insecure implementation of the PUT /app/:id endpoint. The backend fails to validate that the user-provided 'icon' path corresponds to the target application's authorized storage namespace (i.e., org/{owner_org}/{app_id}/...). Instead, the system normalizes the user-supplied string and directly updates the public.apps.icon_url column with this unsanitized input.\nThe vulnerability is triggered by a backend workflow associated with the on_app_update trigger. When an update to the icon_url occurs, a privileged background worker is invoked. This worker executes the cleanStoredImageMetadata() function, which operates using elevated service-role credentials (supabaseAdmin()). Because the worker operates with administrative privileges, it ignores standard Supabase Storage RLS policies.\nThe attack flow proceeds as follows: 1) An attacker authenticates with an app-limited API key, which grants them write access to their specific application context. 2) The attacker issues a PUT request to /app/:id, providing a path to a sensitive, out-of-scope storage object in the 'icon' field. 3) The backend updates the database record with the attacker-controlled path. 4) The on_app_update trigger fires, executing cleanStoredImageMetadata(). 5) The privileged worker retrieves the object specified by the malicious path and performs an upsert: true operation. 6) The target, out-of-scope private object (e.g., an organization logo) is overwritten by the content of the attacker's chosen file.\nBecause the function uses 'upsert: true', the attacker can systematically overwrite sensitive files by referencing their paths, effectively bypassing access controls that would normally prevent an app-limited key from reading or modifying these assets. This exploitation method demonstrates a classic privilege escalation pattern where a lower-privileged user leverages a backend process running with higher-level service tokens to perform restricted administrative actions."
}