CVE-2026-100614 in Capgo
Summary
by MITRE • 09/26/2026
Capgo before 12.244.1 contains a cross-tenant integrity vulnerability in the metadata-cleaning worker that trusts image object keys from mutable database rows without validating ownership. An authenticated attacker can place a victim tenant's image key in a row they control, causing the service-role worker to download and re-upload that object with sanitized metadata. Attackers can silently modify metadata in cross-tenant image objects by supplying known victim keys during authorized row updates, bypassing storage access controls through the confused-deputy metadata worker.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified as a cross-tenant integrity flaw within Capgo versions prior to 12.244.1 stems from an insecure trust relationship between application logic and cloud storage services. Specifically, the metadata-cleaning worker operates under elevated privileges via a service role that grants access to object storage buckets containing data for multiple tenants. The core technical deficiency lies in the failure of this worker to validate ownership or authorization context when processing image object keys retrieved from mutable database rows. Instead of verifying that the authenticated user initiating the row update is also the legitimate owner of the referenced image, the system blindly trusts the key provided by the application layer. This architectural oversight creates a classic confused deputy scenario where an actor with limited permissions can leverage higher-privileged components to perform actions outside their intended scope.
An authenticated attacker who controls specific database rows can exploit this flaw by inserting or modifying entries to reference image object keys belonging to other tenants within the same system. When these modified rows are processed, the metadata-cleaning worker retrieves the victim tenant's image from storage using its elevated service credentials. The worker then proceeds to sanitize and re-upload the object back into the bucket. During this process, because the integrity check is absent, an attacker can manipulate the input parameters or exploit side channels associated with the sanitization logic to silently alter metadata fields such as content type, cache control headers, or custom tags on behalf of the victim tenant. This effectively allows unauthorized modification of critical object attributes without triggering standard storage access controls that would normally block direct writes by non-owners.
The operational impact of this vulnerability is significant for data integrity and multi-tenant isolation guarantees. By altering metadata, an attacker can potentially cause application-level confusion or denial of service if the modified headers interfere with legitimate client requests. For instance, changing content type information could lead to browsers misinterpreting file formats, while manipulating cache control directives might result in stale or corrupted content being served to users. Furthermore, this breach undermines the fundamental principle of multi-tenancy where data and configuration must remain strictly isolated between different organizational units sharing the same infrastructure. The ability to silently modify metadata also poses a risk for audit trails and compliance reporting, as changes made through this vector may not be properly attributed or logged in standard application logs that rely on direct user actions rather than background worker activities.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management due to the misuse of elevated service credentials by an unauthorized actor. It also maps closely to CWE-807 Reliance on Untrusted Inputs in a Security Decision because the system fails to verify ownership before acting on user-supplied data. In terms of offensive security tactics, this behavior is consistent with ATT&CK technique T1534 Internal Spearphishing or more accurately T1606 Supply Chain Compromise if viewed as compromising trust boundaries, but most directly it reflects privilege escalation through confused deputy patterns often seen in cloud-native architectures where identity context is not properly propagated to downstream services.
To mitigate this vulnerability, organizations must implement strict ownership validation within the metadata-cleaning worker logic before any storage operations are initiated. The service role should be scoped with least-privilege principles, ensuring that background workers cannot access objects they do not explicitly own or have been granted permission to modify by an authorized administrator. Additionally, implementing cryptographic signing of object keys in database rows can prevent tampering with references to external resources. Application-level checks must verify that the authenticated user initiating a row update has administrative rights over the specific image resource being referenced. Regular security audits focusing on cross-service identity propagation and cloud storage access policies are essential to detect similar architectural flaws where trust boundaries between application layers and infrastructure services are blurred.