CVE-2026-92770: 
Harbor vulnerability analysis and mitigation

CVE-2026-92770 is a scanner credential disclosure vulnerability in Harbor (the open source cloud native container registry) affecting all versions through 2.15.2. The flaw allows project administrators to recover scanner adapter authentication secrets (HTTP Basic, Bearer tokens, or API keys) character-by-character via a boolean oracle in the q query parameter. It is classified as an incomplete fix for CVE-2025-30086 (GHSA-h27m-3qw8-3pw8), as the prior patch failed to blocklist the AccessCredential column in the scanner registration model. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, Feedly).

The root cause is CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), stemming from Harbor's generic list API translating the q query parameter into ORM WHERE clauses. A field is filterable unless its struct definition carries the filter:"false" tag; the prior CVE-2025-30086 fix added this tag to user passwords, salts, robot secrets, and registry access keys, but omitted Registration.AccessCredential (access_cred column) in src/pkg/scan/dao/scanner/model.go:51. An attacker with project administrator privileges calls GET /api/v2.0/projects/{project_name_or_id}/scanner/candidates?q=access_cred=~<substring> and observes the X-Total-Count response header as a boolean oracle — a non-zero count confirms the substring is present in the stored credential. By iterating over the character set one position at a time, the full secret can be reconstructed without the credential ever appearing in the response body (Researcher Write-up, Harbor Source).

A project administrator — a low-privilege tenant role requiring only ownership of a single project — can exfiltrate the authentication credential of any globally registered scanner adapter (e.g., Trivy or Clair) without any system-administrator rights and without the credential appearing in any API response body. The leaked secret (Basic auth base64-encoded username:password, Bearer token, or API key) can be decoded and used to authenticate directly to the scanner adapter service, potentially granting access to scan internals, vulnerability data, or enabling credential reuse against other systems. There is no integrity or availability impact; the risk is entirely a confidentiality breach crossing a privilege boundary between project-level and system-level configuration (GitHub Advisory, Researcher Write-up).

No public proof-of-concept exploit code has been released, and there is no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the researcher's write-up includes detailed pseudocode demonstrating the character-by-character extraction technique, lowering the barrier for exploitation by any authenticated project administrator (Researcher Write-up).

1. Authenticate as a project administrator: Obtain credentials for any Harbor user account that holds the projectAdmin role on at least one project (no system-admin rights required).
2. Confirm the oracle is active: Send a baseline request to verify the scanner candidate endpoint responds with a non-zero count: GET /api/v2.0/projects/myproj/scanner/candidates — note the X-Total-Count header value.
3. Probe for known credential prefix: Send GET /api/v2.0/projects/myproj/scanner/candidates?q=access_cred=~Basic%20 — if X-Total-Count: 1, a Basic auth credential exists.
4. Iterate character-by-character: For each position in the credential, iterate over the character set (A-Z, a-z, 0-9, +, /, =, space) and send GET /api/v2.0/projects/myproj/scanner/candidates?q=access_cred=~<known_prefix><candidate_char>. A response of X-Total-Count: 1 confirms the character; X-Total-Count: 0 eliminates it.
5. Reconstruct the full credential: Concatenate confirmed characters until no further character extends the match, yielding the complete access_cred value (e.g., Basic YWRtaW46U3VwM3JTM2NyZXQh).
6. Decode and use the secret: Base64-decode the credential: echo YWRtaW46U3VwM3JTM2NyZXQh | base64 -d → admin:Sup3rS3cret!. Use these credentials to authenticate directly to the scanner adapter service (Researcher Write-up).

• Network: Repeated GET requests to /api/v2.0/projects/<project>/scanner/candidates with varying q parameters containing access_cred=~<substring> patterns from the same source IP or user account.
• Logs: Harbor access logs showing a high volume of requests to the scanner candidates endpoint with incrementally varying q parameter values (e.g., access_cred=~B, access_cred=~Ba, access_cred=~Bas, etc.) from a single authenticated session.
• Logs: Requests returning alternating X-Total-Count: 0 and X-Total-Count: 1 values in rapid succession from the same user, consistent with a binary search or linear scan pattern.
• Behavioral: A project administrator account making an unusually large number of API calls to scanner-related endpoints outside of normal administrative activity windows (Researcher Write-up).

Upgrade Harbor to a version newer than 2.15.2, which should include the fix of adding filter:"false" to the AccessCredential field in src/pkg/scan/dao/scanner/model.go (GitHub Advisory). As a broader architectural remediation, the researcher recommends switching the q filter from a per-column blocklist to an explicit per-model allowlist of filterable columns, so newly added sensitive columns are not exposed by default. Additionally, audit other non-blocklisted sensitive columns (oidc_user.token, oidc_user.subiss, user.reset_uuid, user.password_version) for the same treatment. Until patched, consider restricting network-level access to the Harbor API to trusted administrators only, and monitor for anomalous query patterns on scanner registration endpoints (Researcher Write-up).

The vulnerability was reported to the Harbor maintainers on 20 June 2026 via email, with no response received. The researcher then opened a private GitHub security advisory (GHSA-9c86-xf3m-pxvx) on 17 August 2026, again receiving no response, and ultimately disclosed publicly on 14 September 2026 after the 90-day window elapsed. The disclosure highlights a pattern of incomplete security fixes in Harbor's ORM query filtering mechanism, as this is the second instance of the same vulnerability class following CVE-2025-30086 (Researcher Write-up).