Harbor fails to validate the user permissions when updating p2p preheat policies. By sending a request to update a p2p preheat policy with an id that belongs to a project that the currently authenticated user doesn't have access to, the attacker could modify p2p preheat policies configured in other projects.
Harbor fails to validate the user permissions when updating p2p preheat policies. By sending a request to update a p2p preheat policy with an id that belongs to a project that the currently authenticated user doesn't have access to, the attacker could modify p2p preheat policies configured in other projects.
Harbor fails to validate the maintainer role permissions when creating/updating/deleting project configurations - API call: PUT /projects/{project_name_or_id}/metadatas/{meta_name} POST /projects/{project_name_or_id}/metadatas/{meta_name} DELETE /projects/{project_name_or_id}/metadatas/{meta_name} By sending a request to create/update/delete a metadata with an name that belongs to a project that the currently authenticated and granted to the maintainer role user doesn’t have access to, the attacker could modify configurations in the current project. BTW: the maintainer role in Harbor was intended for …
A user with an administrator, project_admin, or project_maintainer role could utilize and exploit SQL Injection to allow the execution of any Postgres function or the extraction of sensitive information from the database through this API: GET /api/v2.0/projects/{project_name}/repositories/{repository_name}/artifacts/{reference}/scan/{report_id}/log The SQL injection might happen in the code: https://github.com/goharbor/harbor/blob/9b7c1a2274fbc5ea16e19a484532f86c08926577/src/pkg/task/task.go#L241 Because raw SQL executed in ormer.Raw(Sql).QueryRows() is PrepareStatement. In the driver of Postgres, one PrepareStatement must contain only ONE SQL command, see https://www.postgresql.org/docs/15/libpq-exec.html#LIBPQ-PQPREPARE. The …
Under OIDC authentication mode, there is a redirect_url parameter exposed in the URL which is used to redirect the current user to the defined location after the successful OIDC login, This redirect_url can be an ambiguous URL and can be used to embed a phishing URL. For example: if a user clicks the URL with a malicious redirect_url: https://<harbor_hostnmae>/c/oidc/login?redirect_url=https://<redirect_domain> It might redirect the current user without their knowledge to a …
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in github.com/goharbor/harbor.
Impact Harbor fails to validate the user permissions when updating a robot account that belongs to a project that the authenticated user doesn’t have access to. API call: PUT /robots/{robot_id} By sending a request that attempts to update a robot account, and specifying a robot account id and robot account name that belongs to a different project that the user doesn’t have access to, it was possible to revoke the …
Impact Harbor fails to validate the user permissions when updating tag immutability policies - API call: PUT /projects/{project_name_or_id}/immutabletagrules/{immutable_rule_id} By sending a request to update a tag immutability policy with an id that belongs to a project that the currently authenticated user doesn’t have access to, the attacker could modify tag immutability policies configured in other projects. Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade …
Impact Harbor fails to validate the user permissions to view Webhook policies including relevant credentials configured in different projects the user doesn’t have access to, resulting in malicious users being able to read Webhook policies of other users/projects. API call is GET /projects/{project_name_or_id}/webhook/policies/{webhook_policy_id} By sending the below request and specifying different Webhook policy ids in the last part of the URL, the malicious user may disclose Webhook policies related to …
Impact Harbor fails to validate the user permissions when updating tag retention policies. API call: PUT /retentions/{id} By sending a request to update a tag retention policy with an id that belongs to a project that the currently authenticated user doesn’t have access to, the attacker could modify tag retention policies configured in other projects. Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as …
Harbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs - API call GET /projects/{project_name}/preheat/policies/{preheat_policy_name}/executions/{execution_id}/tasks/{task_id}/logs By sending a request that attempts to read P2P preheat execution logs and specifying different job ids, malicious authenticatedusers could read all the job logs stored in the Harbor database.
core/api/user.go in Harbor 1.7.0 through 1.8.2 allows non-admin users to create admin accounts via the POST /api/users API, when Harbor is setup with DB as authentication backend and allow user to do self-registration. Fixed version: v1.7.6 v1.8.3. v.1.9.0. Workaround without applying the fix: configure Harbor to use non-DB authentication backend such as LDAP.
In Harbor 2.0 before 2.0.5 and 2.1.x before 2.1.2 the catalog’s registry API is exposed on an unauthenticated path.
Sean Wright from Secureworks has discovered an enumeration vulnerability. An attacker can make use of the Harbor API to make unauthenticated calls to the Harbor instance.
Harbor prior to 2.0.1 allows SSRF with this limitation: an attacker with the ability to edit projects can scan ports of hosts accessible on the Harbor server's intranet.
Harbor 1.9.* 1.10.* and 2.0.* allows Exposure of Sensitive Information to an Unauthorized Actor.
Harbor 1.9.* 1.10.* and 2.0.* allows Exposure of Sensitive Information to an Unauthorized Actor.
Cloud Native Computing Foundation Harbor allows SQL Injection via project quotas in the VMware Harbor Container Registry for the Pivotal Platform.
Cloud Native Computing Foundation Harbor allows SQL Injection via user-groups in the VMware Harbor Container Registry for the Pivotal Platform.
Cloud Native Computing Foundation Harbor has a Privilege Escalation Vulnerability in the VMware Harbor Container Registry for the Pivotal Platform.
Cloud Native Computing Foundation Harbor allows CSRF in the VMware Harbor Container Registry for the Pivotal Platform.
A User Enumeration flaw exists in Harbor. The issue is present in the /users API endpoint. This endpoint is supposed to be restricted to administrators. This restriction is able to be bypassed and information can be obtained about registered users can be obtained via the search functionality.
Harbor API has a Broken Access Control vulnerability. The vulnerability allows project administrators to use the Harbor API to create a robot account with unauthorized push and/or pull access permissions to a project they don't have access or control for. The Harbor API did not enforce the proper project permissions and project scope on the API request to create a new robot account.
core/api/user.go in Harbor allows non-admin users to create admin accounts via the POST /api/users API, when Harbor is setup with DB as authentication backend and allow user to do self-registration.