Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
22 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/goharbor/harbor >= 2.13.0, < 2.13.5; >= 2.14.0, < 2.14.3
Fixed in
2.14.32.13.5· Vendor fix available
Issue
Impact Harbor write configuration payload to audit log when configuration change, the ldapsearchpassword and oidcclientsecret will be logged in the audit log without redacted Patches Harbor v2.15.0, v2.14.3, v2.13.5 Workarounds Disable audit log configure event in Harbor Web Console: Go to Administration - Configuration - Enable Audit Log Event Type - Uncheck "Update Configuration" and click "Save" Button.
Recommended action: Upgrade to 2.14.3 or 2.13.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.12.42.13.12.4.0-rc1.0.20250331071157-dce7d9f5cffb· Vendor fix available
Issue
Impact Administrator users on Harbor could exploit an ORM Leak (https://www.elttam.com/blog/plormbing-your-django-orm/) vulnerability that was present in the /api/v2.0/users endpoint to leak users' password hash and salt values. This vulnerability was introduced into the application because the q URL parameter allowed the administrator to filter users by any column, and the filter password=~ could be abused to leak out a user's password hash character by character. An attacker with administrator access could exploit this vulnerability to leak highly sensitive information stored on the Harbor database, as demonstrated in the attached writeup by the leaking of users' password hashes and salts. All endpoints that support the q URL parameter are vulnerable to this ORM leak attack, and could potentially be exploitable by lower privileged users to gain unauthorised access to other sensitive information. Patches No available Workarounds NA References Credit alex@elttam.com
Recommended action: Upgrade to 2.13.1, 2.12.4 or 2.4.0-rc1.0.20250331071157-dce7d9f5cffb (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In the Harbor repository information, it is possible to inject code resulting in a stored XSS issue. Patches Harbor v2.12.3 Harbor 2.11.3 Workarounds No References Credit gleb.razvitie@gmail.com
Recommended action: Upgrade to 2.13.1-rc1 (pre-release), 2.12.4-rc1 (pre-release) or 2.4.0-rc1.0.20250421072404-a13a16383a41 (pre-release) by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/goharbor/harbor >= 2.0.0, < 2.4.3; >= 2.5.0, < 2.5.2
Fixed in
2.5.22.4.3· Vendor fix available
Issue
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.
Recommended action: Upgrade to 2.5.2 or 2.4.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/goharbor/harbor < 2.9.5; >= 2.10.0, < 2.10.3
Fixed in
2.9.52.10.3· Vendor fix available
Issue
Impact Harbor fails to validate the maintainer role permissions when creating/updating/deleting project configurations - API call: - PUT /projects/{projectnameorid}/metadatas/{metaname} - POST /projects/{projectnameorid}/metadatas/{metaname} - DELETE /projects/{projectnameorid}/metadatas/{metaname} 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 individuals who closely support the project admin in maintaining the project but lack configuration management permissions. However, the maintainer role can utilize the metadata API to circumvent this limitation. It's important to note that any potential attacker must be authenticated and granted a specific project maintainer role to modify configurations, limiting their scope to only…
Recommended action: Upgrade to 2.10.3 or 2.9.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A user with an administrator, projectadmin, or projectmaintainer 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: 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 SQL should start with: Adding a delete/update operation by appending malicious content to the current SQL is impossible. Furthermore, the query result of the task is just an intermediate result, the task ID is used to locate the job log file, and the response only contains the content of the job log file. so this vulnerability can be used to execute SQL functions,…
Recommended action: Upgrade to 2.10.2, 2.9.4 or 2.8.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Under OIDC authentication mode, there is a redirecturl parameter exposed in the URL which is used to redirect the current user to the defined location after the successful OIDC login, This redirecturl 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 redirecturl: It might redirect the current user without their knowledge to a malicious site, posing a potential risk. To avoid this issue, the redirecturl should be checked if it is a local path when reading it from the original request URL. Impact When Harbor is configured with OIDC authentication and users log in via a link outside the Harbor server, it might be vulnerable to an open redirect attack. This attack only involves the OIDC Harbor user, if the current Harbor instance is not configured with OIDC auth, the redirecturl doesn't exist and the Harbor instance is not vulnerable to the open redirect attack. The following versions of Harbor are…
Recommended action: Upgrade to 2.10.1, 2.9.3 or 2.8.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In the Harbor jobservice container, the comparison of secrets in the authenticator type is prone to timing attacks. The vulnerability occurs due to the following code: https://github.com/goharbor/harbor/blob/aaea068cceb4063ab89313d9785f2b40f35b0d63/src/jobservice/api/authenticator.go#L69-L69 To avoid this issue, constant time comparison should be used. Impact This attack might be possible theoretically, but no workable proof of concept is available, and access complexity is set at High. The jobservice exposes these APIs It is used to create jobs/stop job tasks and retrieve job task information. If an attacker obtains the secrets, it is possible to retrieve the job information, create a job, or stop a job task. The following versions of Harbor are involved: <=Harbor 2.8.2, <=Harbor 2.7.2, <= Harbor 2.6.x, <=Harbor 1.10.17 Patches Harbor 2.8.3, Harbor 2.7.3, Harbor 1.10.18 Workarounds Because the jobservice only exposes HTTP service to harbor-core containers, blocking any inbound…
Recommended action: Upgrade to 2.8.3, 2.7.3 or 1.10.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/{robotid} 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 robot account permissions. Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible. Workarounds There are no workarounds available. For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Recommended action: Upgrade to 2.5.2, 2.4.3 or 1.10.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Harbor fails to validate the user permissions when updating tag immutability policies - API call: PUT /projects/{projectnameorid}/immutabletagrules/{immutableruleid} 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 as soon as possible. Workarounds There are no workarounds available. For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Recommended action: Upgrade to 2.5.2, 2.4.3 or 1.10.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/{projectnameorid}/webhook/policies/{webhookpolicyid} 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 other repositories/projects.: none;" Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible. Workarounds There are no workarounds available. For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Recommended action: Upgrade to 2.5.2, 2.4.3 or 1.10.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 soon as possible. Workarounds There are no workarounds available. For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Recommended action: Upgrade to 2.5.2, 2.4.3 or 1.10.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Harbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs - API call GET /projects/{projectname}/preheat/policies/{preheatpolicyname}/executions/{executionid}/tasks/{taskid}/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. Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible. Workarounds There are no workarounds available. For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Recommended action: Upgrade to 2.5.2, 2.4.3 or 1.10.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. This is fixed in 1.9.0-rc1.
Recommended action: Upgrade to 1.9.0-rc1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/goharbor/harbor < 2.0.5; >= 2.1.0, < 2.1.2
Fixed in
2.1.22.0.5· Vendor fix available
Issue
Impact Javier Provecho, member of the TCCT (Telefonica Cloud & Cybersecurity Tech better known as ElevenPaths) SRE team discovered a vulnerability regarding Harbor’s v2 API. The catalog’s registry v2 api is exposed on an unauthenticated path. The current catalog API path is served at the following path and it requires to be authenticated as an admin. "GET /v2/catalog" However, the authorization can be bypassed by using the following path "GET /v2/catalog/" Patches If your product uses the affected releases of Harbor, update to either version v2.1.2 or v2.0.5 to fix this issue immediately https://github.com/goharbor/harbor/releases/tag/v2.1.2 https://github.com/goharbor/harbor/releases/tag/v2.0.5 Workarounds If you cannot access a patched release, it can be mitigated by disabling that API. For example, redirecting it to a 404 sink hole in the ingress. For more information If you have any questions or comments about this advisory, contact cncf-harbor-security@lists.cncf.io View our…
Recommended action: Upgrade to 2.1.2 or 2.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/goharbor/harbor >= 1.7.0, < 1.10.3; >= 2.0.0, < 2.0.1
Fixed in
2.0.11.10.3· Vendor fix available
Issue
Impact 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. Based on the HTTP status code in the response, an attacker is then able to work out which resources exist, and which do not. This would likely be accomplished by either providing a wordlist or enumerating through a sequence an unauthenticated attacker is able to enumerate resources on the system. This provides them with information such as existing projects, repositories, etc. The vulnerability was immediately fixed by the Harbor team. Issue The following API resources where found to be vulnerable to enumeration attacks: /api/chartrepo/{repo}/prov (POST) /api/chartrepo/{repo}/charts (GET, POST) /api/chartrepo/{repo}/charts/{name} (GET, DELETE) /api/chartrepo/{repo}/charts/{name}/{version} (GET, DELETE) /api/labels?name={name}&scope=p (GET) /api/repositories?projectid={id} (GET) /api/repositories/{reponame}/…
Recommended action: Upgrade to 2.0.1 or 1.10.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Matt Hamilton from Soluble has discovered a limited Server-Side Request Forgery (SSRF) that allowed Harbor project owners to scan the TCP ports of hosts on the Harbor server's internal network. The vulnerability was immediately fixed by the Harbor team. Issue The “Test Endpoint” API, part of the functionality for ensuring a project Webhook is accessible and functional, is vulnerable to a limited SSRF attack. A malicious user that is also a project administrator can use this API for internal port scanning. Known Attack Vectors Successful exploitation of this issue will lead to bad actors identifying open TCP ports on any network that is accessible by the Harbor core services Patches If your product uses the affected releases of Harbor, update to version 2.0.1 to patch this issue immediately. https://github.com/goharbor/harbor/releases/tag/v2.0.1 Workarounds Since only project administrators (the user that created the project) are allowed to test the webhook endpoints configured…
Recommended action: Upgrade to 2.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Hidde Smit from Cyber Eagle has discovered an User Enumeration flaw 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 via the "search" functionality. Non-administrator users (such as those created via self-registration) can list all usernames and user IDs by sending a GET request to /api/users/search with parameter "username" and value "", as follows: curl -X GET "https://<host/api/users/search?username=" -H "accept: application/json" --user <user:<password The vulnerability was immediately fixed by the Harbor team and all supported versions were patched. With the patched versions of Harbor, the username is required for search and we have removed the support for querying by email. Patches If your product uses the affected releases of Harbor, update to either version 2.1.0 or 2.0.3 to fix this issue immediately…
Recommended action: Upgrade to 2.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/goharbor/harbor >= 1.7.0, < 1.8.6; >= 1.9.0, < 1.9.3
Fixed in
1.8.61.9.3· Vendor fix available
Issue
Cure53 has discovered that the Harbor web interface does not implement protection mechanisms against Cross-Site Request Forgery (CSRF). By luring an authenticated user onto a prepared third-party website, an attacker can execute any action on the platform in the context of the currently authenticated victim. The vulnerability was immediately fixed by the Harbor team and all supported versions were patched. Successful exploitation of this issue will lead to 3rd parties executing actions on the platform of behalf of authenticated users and administrators. If your product uses the affected releases of Harbor, update to version 1.8.6 and 1.9.3 to patch this issue immediately. https://github.com/goharbor/harbor/releases/tag/v1.8.6 https://github.com/goharbor/harbor/releases/tag/v1.9.3
Recommended action: Upgrade to 1.9.3 or 1.8.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/goharbor/harbor >= 1.7.0, < 1.8.6; >= 1.9.0, < 1.9.3
Fixed in
1.8.61.9.3· Vendor fix available
Issue
Cloud Native Computing Foundation Harbor prior to 1.8.6 and 1.9.3 allows SQL Injection via project quotas in the VMware Harbor Container Registry for the Pivotal Platform.
Recommended action: Upgrade to 1.9.3 or 1.8.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/goharbor/harbor >= 1.7.0, < 1.8.6; >= 1.9.0, < 1.9.3
Fixed in
1.8.61.9.3· Vendor fix available
Issue
Cloud Native Computing Foundation Harbor prior to 1.8.6 and 1.9.3 allows SQL Injection via user-groups in the VMware Harbor Container Registry for the Pivotal Platform.
Recommended action: Upgrade to 1.9.3 or 1.8.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/goharbor/harbor >= 1.7.0, < 1.8.6; >= 1.9.0, < 1.9.3
Fixed in
1.8.61.9.3· Vendor fix available
Issue
Cloud Native Computing Foundation Harbor prior to 1.8.6 and 1.9.3 has a Privilege Escalation Vulnerability in the VMware Harbor Container Registry for the Pivotal Platform.
Recommended action: Upgrade to 1.9.3 or 1.8.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.