CVE-2026-61833 in zot
Summary
by MITRE • 09/18/2026
zot is a container image and artifact registry based on the Open Container Initiative Distribution Specification. Prior to 2.1.18, the bearer authentication handler in pkg/api/authn.go maps every HTTP method other than GET and HEAD to the push action, so DELETE requests are not checked for the distinct delete permission. Bearer-authenticated requests also bypass the fine-grained DistSpecAuthzHandler path in pkg/api/authz.go, while DeleteManifest and DeleteBlob perform no independent delete-permission check. A remote attacker with a bearer token limited to pull and push actions can therefore delete manifests and blobs within the token's repository scope, making images unavailable and allowing repository history to be altered despite the token lacking delete authorization. This issue is fixed in version 2.1.18.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in Zot prior to version 2.1.18 represents a critical authentication and authorization bypass within the container image registry's API layer, specifically affecting the handling of HTTP DELETE requests under bearer token authentication schemes. The core technical flaw resides in the interaction between the authentication handler located at pkg/api/authn.go and the authorization logic defined in pkg/api/authz.go. In standard Open Container Initiative Distribution Specification implementations, distinct permissions are required for different operations such as pulling images versus pushing or deleting them. However, the implementation in Zot incorrectly mapped every HTTP method other than GET and HEAD to the push action permission set. This design oversight meant that when a client issued an HTTP DELETE request, the system did not evaluate whether the presented bearer token possessed explicit delete permissions. Instead, it treated the deletion attempt as a standard push operation or simply failed to apply any restrictive authorization checks specific to destructive actions.
This architectural deficiency allows for significant operational impact by enabling unauthorized data destruction and integrity compromise within the registry scope governed by the attacker's credentials. A remote adversary possessing only pull and push privileges can exploit this logic error to delete manifests and blobs from repositories where they are not authorized to perform deletions. By removing these artifacts, an attacker can render specific container images unavailable to legitimate users, effectively causing a denial of service for those particular resources. Furthermore, the ability to alter repository history by deleting older layers or manifest entries undermines the immutability guarantees that container registries typically provide. This manipulation can disrupt CI/CD pipelines, obscure audit trails, and potentially facilitate supply chain attacks if an attacker replaces deleted artifacts with malicious versions in a subsequent push operation, although the primary immediate impact is the unauthorized removal of data.
The vulnerability also highlights a failure to enforce fine-grained access control as intended by the DistSpecAuthzHandler path. Bearer-authenticated requests were observed bypassing this specialized authorization handler entirely for certain operations, further compounding the lack of permission verification. The functions responsible for deleting manifests and blobs, DeleteManifest and DeleteBlob respectively, lacked independent checks to verify delete permissions before executing the removal logic. This absence of a secondary validation layer means that once the initial authentication step is passed with any valid token, the system proceeds with destructive actions without confirming if those actions are permitted under the current security context.
From a classification perspective, this issue aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, as the application fails to enforce proper access control policies for specific user roles or token scopes. In terms of adversary tactics, this vulnerability facilitates actions consistent with ATT&CK technique T1490 Inhibit System Recovery, where an attacker deletes data to disrupt availability, and potentially T1565 Data Manipulation if the deletion is part of a broader strategy to alter system state for malicious purposes. The lack of distinct permission checks for destructive operations against read-write credentials represents a fundamental flaw in privilege separation principles within the registry's security model.
To mitigate this vulnerability, organizations running Zot registries must upgrade immediately to version 2.1.18 or later, where these authorization logic errors have been corrected. In environments where upgrading is not immediately feasible, administrators should implement strict network-level controls such as firewall rules or API gateways that restrict DELETE methods at the infrastructure layer rather than relying solely on application-level authentication checks. Additionally, adopting a principle of least privilege for all service accounts and tokens ensures that even if an authorization bypass occurs, the scope of potential damage is limited by restricting token permissions to only those actions strictly necessary for their function. Regular auditing of registry access logs can also help detect anomalous deletion patterns indicative of exploitation attempts before significant data loss occurs.