Harbor (audit log redaction, LDAP password and OIDC client secret): CREDENTIAL DISCLOSURE VIA THE AUDIT TRAIL: Harbor

Impact

CREDENTIAL DISCLOSURE VIA THE AUDIT TRAIL: Harbor records the LDAP bind password and the OIDC client secret into its audit log without redaction. The audit log is by design a widely-readable artifact — it is shipped to SIEM, retained long, and read by compliance and platform staff who are deliberately not granted registry admin. So the identity-provider credentials for the registry end up in the one store an operator has consciously made broadly accessible. An LDAP bind credential typically reaches far beyond Harbor into the rest of the directory, and an OIDC client secret allows impersonating the registry integration to the identity provider. For a cluster operator this is a lateral-movement seed sitting in a low-suspicion location, and its lifetime is set by log retention rather than by patching.

Who can reach it

Local / log access: anyone able to read Harbor audit logs directly or via downstream aggregation. No registry privileges are required beyond audit-log visibility.

What to do

Upgrade Harbor to a release carrying the redaction fix and restart the components. Then rotate the LDAP bind password and the OIDC client secret, since patching does not retract what is already written. Purge or expire affected audit-log ranges in your SIEM and archives, and re-check which roles can read Harbor audit data.

References