NextStack

harbor v2.15.3

patch PublishedOct 6, 2026 Sourcegoharbor/harbor

harbor v2.15.3

[!WARNING] Breaking change: webhooks to internal addresses are blocked by default

The fix for GHSA-2phj-cp9f-qq6w blocks webhook and Slack delivery to private, loopback, link-local and other non-public addresses. That includes hostnames that resolve to them, such as *.svc.cluster.local. After you upgrade, existing webhooks to internal endpoints fail to deliver, and new ones are rejected.

To allow them again, set the opt-out on both core and jobservice:

  • harbor.yml: network.allow_private_network_access: true, then ./prepare and restart
  • Helm: add {name: HARBOR_ALLOW_PRIVATE_NETWORK_ACCESS, value: "true"} to both core.extraEnvVars and jobservice.extraEnvVars

This disables the protection entirely. Only use it if you trust all project admins, and block 169.254.169.254 at the network level.

[!WARNING] Breaking change: signing unsigned images fails when content trust is enforced

The fix for GHSA-wrw5-gmvj-gf23 removes the User-Agent based exemption that let cosign and notation pull unsigned images. In projects that only allow signed images, cosign sign and notation sign on a new, unsigned image now fail with 412 Precondition Failed. Images that already have a signature are not affected.

To allow signing clients again, set CONTENT_TRUST_LEGACY_SIGNER_PULL_ENABLED=true on core. The value must be exactly true.

  • Helm: add it to core.extraEnvVars
  • harbor.yml installs: there is no harbor.yml option. Add it to common/config/core/env and restart. Re-running ./prepare overwrites that file.

The exemption still trusts the client’s User-Agent, but only for users or robots with push permission on the project. Projects that block vulnerable images have no opt-out: a signing client can no longer pull an image that the vulnerability policy blocks.

[!WARNING] Known Issue: Push Replication Fails for Specific Registries such as AWS ECR (GHSA-wjpm-hv5w-gxr6 Regression)

The security fix for GHSA-wjpm-hv5w-gxr6 strictly validated upload Location headers against the statically configured registry endpoint (c.url). Because the AWS ECR adapter configures the API control-plane endpoint (https://api.ecr..amazonaws.com) while requests are rewritten to the data-plane host (.dkr.ecr..amazonaws.com), ECR’s response Location header is rejected as a cross-origin target.

Workaround / Resolution:

A fix has been provided in PR #24113 and will be released in the upcoming patch release. If your environment depends on push replication, we recommend postponing the upgrade until the next patch release or applying the patch directly.

What’s Changed

Security Advisories 🔒

Component updates ⬆️

Bump Component Version 🤖

Other Changes

Full Changelog: https://github.com/goharbor/harbor/compare/v2.15.2…v2.15.3


Source goharbor/harbor · v2.15.3 · 2026-10-06 · upstream release

Mirrored verbatim for indexing. All rights belong to the upstream project.

Release notes are published by the upstream project and mirrored here for indexing. All rights belong to their authors.