GHSA-PRH4-VHFH-24MJ: Information Exposure in Harbor Configuration Audit Logs

Harbor is an open-source trusted cloud native registry project that stores, signs, and scans content. It provides advanced features such as role-based access control (RBAC), auditing, and image replication. The auditing subsystem is responsible for recording user actions and system events to maintain an operational trail for security and compliance purposes.

Vulnerability GHSA-PRH4-VHFH-24MJ (CWE-532) occurs within this audit logging mechanism, specifically during configuration modifications. When administrators update system settings via the /api/v2.0/configurations endpoint, Harbor captures the request payload to generate an operation description. This payload often contains highly sensitive environment parameters, including external authentication integration secrets.

The vulnerability exposes these external directory credentials in plain text within the application's audit logs. By writing unredacted LDAP passwords and OpenID Connect (OIDC) secrets to the database, Harbor violates secure logging practices. Any user or service account with read access to the audit logs can retrieve these credentials, fundamentally compromising the security boundary between the registry and the broader enterprise identity infrastructure.

The vulnerability originates from an insecure implementation of configuration event logging in src/pkg/auditext/event/config/config.go. The audit extension utilizes a resolver struct to process incoming metadata and format it for the persistence layer. During this processing, the system attempts to sanitize the JSON payload using a predefined blacklist of sensitive attributes.

This blacklist, defined in the SensitiveAttributes array, explicitly targeted specific keys such as ldap_password and oidc_client_secret. The sanitization function iterated through the request payload, masking the values of these known keys before appending the entire serialized JSON structure into the op_desc (operation description) string field.

This approach fails due to its reliance on an incomplete, "allow-by-default" redaction strategy. Key authentication parameters, most notably ldap_search_password, were omitted from the blacklist. Consequently, when an administrator configured or updated LDAP integration settings, the bind credentials for the directory service were serialized directly into the audit log in plain text.

The structural decision to store complex, nested JSON payloads within a single string field further compounded the issue. As new configuration parameters were added to Harbor over time, the static blacklist approach required manual updates for every new sensitive field. This architectural pattern is inherently brittle and guarantees future information disclosure regressions when developers inevitably overlook adding new secret keys to the redaction list.

An analysis of the patch (commit 85e756486fc19333c5c300d7ac273e1580dc9350) reveals a fundamental shift from a blacklist-based redaction model to a strict "deny-all" approach. The Harbor maintainers determined that attempting to safely parse and redact arbitrary JSON configuration payloads was structurally flawed and unnecessary for audit purposes.

In the vulnerable implementation, the Resolve function in src/pkg/auditext/event/config/config.go actively captured the request payload, truncated it if it exceeded a size limit, and formatted it directly into the operation description:

// Vulnerable Implementation
func (c *resolver) Resolve(ce *commonevent.Metadata, evt *event.Event) error {
    // ...
    e.Payload = ext.Redact(ce.RequestPayload, c.SensitiveAttributes)
    e.OcurrAt = time.Now()
    if len(ce.RequestPayload) > payloadSizeLimit {
        ce.RequestPayload = fmt.Sprintf("%v...", ce.RequestPayload[:payloadSizeLimit])
    }
    e.OperationDescription = fmt.Sprintf("update configuration: %v", ce.RequestPayload)
    // ...
}

The patched code aggressively removes this logic. Instead of executing the ext.Redact function against ce.RequestPayload, the operation description is hardcoded to a static string. This completely isolates the audit log from the potentially sensitive contents of the user's API request:

// Patched Implementation
func (c *resolver) Resolve(ce *commonevent.Metadata, evt *event.Event) error {
    // ...
    e.OcurrAt = time.Now()
    e.OperationDescription = "update configuration"
    // ...
}

To eliminate the risk of similar flaws occurring elsewhere in the codebase, the patch completely removes the ext.Redact utility functions from src/pkg/auditext/event/utils.go. By deprecating the redaction utility entirely, the maintainers ensure that future audit events cannot accidentally reintroduce payload reflection without writing entirely new parsing logic.

Exploitation of this vulnerability requires existing authorized access to Harbor, specifically the ability to view system audit logs. This typically restricts the threat actor profile to malicious insiders, compromised administrator accounts, or attackers who have achieved secondary access through a separate vulnerability (such as a database read-only SQL injection).

The attack methodology is strictly passive. An attacker navigates to the Harbor UI or queries the database directly, filtering the audit events for "update configuration" operations. Upon locating these records, the attacker parses the op_desc field to extract the plaintext ldap_search_password or newly integrated OIDC secrets. No active exploitation tools, memory corruption techniques, or network manipulation are required.

The security impact is severe despite the moderate CVSS classification. Exposure of the ldap_search_password grants the attacker the exact bind credentials used by Harbor to query the enterprise Active Directory or LDAP server. Attackers use these credentials to enumerate the corporate directory, mapping user accounts, group memberships, and administrative hierarchies.

If the exposed LDAP account is over-privileged—a common misconfiguration in enterprise deployments—the attacker achieves vertical privilege escalation against the directory service itself. Similarly, exposed OIDC client secrets allow the attacker to spoof authentication requests or manipulate the OAuth flow, potentially establishing persistence across the organization's single sign-on (SSO) perimeter.

The primary remediation path is upgrading the Harbor instance to version 2.15.0 or a later supported security patch. This release contains the updated resolver logic that completely omits request payloads from the audit log, immediately halting the ongoing leakage of sensitive configuration data.

System administrators must execute a retrospective audit of their databases. Upgrading Harbor prevents future credential logging, but it does not sanitize historical data already present in the audit_log table. Security teams must query the database for historical update configuration events and purge or manually redact any rows containing plaintext LDAP or OIDC secrets.

Organizations utilizing Harbor with external directory integration must assume that previously configured LDAP bind passwords and OIDC client secrets are compromised. Following the application upgrade and log sanitization, these external credentials must be rotated. The new secrets should be generated, updated in the external identity provider, and subsequently applied to the newly patched Harbor instance.

As a defense-in-depth measure, administrators should ensure that the service account used by Harbor for LDAP binding operates with the principle of least privilege. The account should only possess read access to the specific organizational units (OUs) necessary for authenticating Harbor users, mitigating the potential blast radius if the credentials are ever exposed again.