Gal Goldstein

**Name of the Vulnerable Software and Affected Versions** Go versions prior to the fixed version **Description** The issue concerns the ReverseProxy in Go, which includes raw query parameters from the inbound request, including unparsable parameters rejected by net/http, potentially permitting query parameter smuggling when a Go proxy forwards a parameter with an unparsable value. After the fix, ReverseProxy sanitizes the query parameters in the forwarded query when the outbound request's Form field is set after the ReverseProxy Director function returns, indicating that the proxy has parsed the query parameters. Proxies that do not parse query parameters continue to forward the original query parameters unchanged. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Harbor versions prior to 2.5.2 **Description** The issue allows malicious users to view, update, and delete Webhook policies of other users due to a failure in validating user permissions. This can be exploited through the API endpoint "GET /projects/{project name or id}/webhook/policies/{webhook policy id}" by specifying different Webhook policy IDs. The attacker could modify Webhook policies configured in other projects. **Recommendations** For Harbor versions prior to 2.5.2, upgrade to Harbor v2.5.2 or later as soon as possible. As a temporary workaround, consider restricting access to the API endpoint "GET /projects/{project name or id}/webhook/policies/{webhook policy id}" to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Harbor versions prior to 2.5.2 **Description** The issue arises from the failure to validate user permissions when updating a robot account that belongs to a project the authenticated user doesn’t have access to. By sending a request to update a robot account and specifying a robot account id and robot account name that belongs to a different project, it was possible to revoke the robot account permissions. This can be achieved through the API endpoint "PUT /robots/{robot id}" by specifying the `robot id` of a robot account in a project the user doesn’t have access to. **Recommendations** For Harbor versions prior to 2.5.2, upgrade to Harbor v2.5.2 or later as soon as possible to fix the issue. As a temporary workaround, consider restricting access to the "PUT /robots/{robot id}" API endpoint to prevent unauthorized updates to robot accounts until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Harbor versions prior to 2.5.2 **Description** The issue arises from Harbor's failure to validate user permissions when updating tag immutability policies. This can be exploited by sending a request to update a tag immutability policy with an id belonging to a project that the currently authenticated user doesn’t have access to, allowing the attacker to modify tag immutability policies configured in other projects. The API endpoint `PUT /projects/{project name or id}/immutabletagrules/{immutable rule id}` is involved in this issue. **Recommendations** For Harbor versions prior to 2.5.2, upgrade to Harbor v2.5.2 or later as soon as possible to fix the issue. As a temporary workaround, consider restricting access to the `PUT /projects/{project name or id}/immutabletagrules/{immutable rule id}` API endpoint to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Harbor versions prior to 2.5.2 **Description** Harbor fails to validate user permissions when updating tag retention policies. 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. This can be achieved by sending a request to the "PUT /retentions/{id}" API endpoint. **Recommendations** For Harbor versions prior to 2.5.2, update to version 2.5.2 or later to secure your system. As a temporary workaround, consider restricting access to the "PUT /retentions/{id}" API endpoint until a patch is applied. Avoid using the `id` parameter in the affected API endpoint with projects that the currently authenticated user doesn’t have access to, until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Harbor versions prior to 2.5.2 **Description** The issue arises from Harbor's failure to validate user permissions when reading and updating job execution logs through the P2P preheat execution logs. By sending a request to read or update P2P preheat execution logs and specifying different job IDs, malicious authenticated users could read all the job logs stored in the Harbor database. This can be achieved by sending a request to the "GET /projects/{project name}/preheat/policies/{preheat policy name}/executions/{execution id}/tasks/{task id}/logs" API endpoint. **Recommendations** For Harbor versions prior to 2.5.2, upgrade to Harbor v2.5.2 or later as soon as possible to fix the issue. As a temporary workaround, consider restricting access to the "GET /projects/{project name}/preheat/policies/{preheat policy name}/executions/{execution id}/tasks/{task id}/logs" API endpoint to minimize the risk of exploitation.