NetApp Trident debug logs can expose authentication secrets

Trident versions v25.02.1 through v26.06.1 are susceptible to a vulnerability that could allow an authenticated attacker with access to debug logs to view LUKS passphrases or SMB Active Directory credentials.

• NetApp Trident: affected from v25.02.1 through v26.06.1, inclusive, according to the custom version range in the record.
• The default status is recorded as unaffected outside the stated range, but the record does not establish the status of parallel or other release branches.
• No exact fixed release is provided in the solution field or in the advisory content reviewed.

The weakness is classified as CWE-215, where sensitive information is inserted into debugging code or output. In this case, Trident debug logs may contain LUKS passphrases or SMB Active Directory credentials. The attacker must be authenticated, have local access, and be able to access the debug logs; no user interaction is required. The available evidence does not identify the exact code path, log format, log storage location, or precise permissions needed to read the logs. The implementation detail that causes the secrets to appear in logging therefore remains publicly limited.

The described reachability is local and requires an authenticated attacker with access to debug logs. The attack complexity is low and no user interaction is required. The supplied record does not identify a known exploitation status or public exploit. The returned CISA enrichment currently records exploitation as none and automatable as no; this is a status assessment at that time, not proof that exploitation has never occurred.

The confirmed technical impact is disclosure of sensitive information in logs. LUKS passphrases and SMB Active Directory credentials could enable subsequent unauthorized access if they remain valid, usable, and sufficiently privileged; this is a possible consequence, not an additional confirmed attack path. The record does not show that the vulnerability directly modifies data or disrupts service availability. The practical scope depends on who can read the debug logs, how long the logs retained the secrets, and what privileges the exposed credentials provide.

Exposure of LUKS passphrases may weaken protection for data at rest if the passphrases remain valid and usable. Exposed SMB Active Directory credentials may enable unauthorized access to resources using those credentials, depending on the account's permissions and the surrounding security controls. Organizations may need to investigate access to retained logs, rotate credentials and related passphrases, and assess audit or incident-reporting obligations. The record does not confirm a specific compromise, data loss event, or service-availability impact.

1. Apply the patch or upgrade to an exact fixed release confirmed by NetApp. The record marks a patch as available, but it does not provide a fixed version; do not infer that a particular version or every later version is remediated.
2. In unfixed versions, disable debug-level logging as the documented workaround.
3. Restrict access to existing debug logs and treat them as potentially secret-bearing data. Avoid copying or retaining them in locations without appropriate protection.
4. If logs may have contained LUKS passphrases or SMB Active Directory credentials, assess and rotate those secrets through the relevant operational procedures, and review the accounts and resources that may have used them.

1. Inventory all deployments running NetApp Trident and compare their exact versions with the affected range.
2. Review operational configuration to determine where debug-level logging is enabled and which systems or users can read the logs.
3. Review retained debug logs for LUKS passphrases and SMB Active Directory credentials, and handle those logs as secret-bearing data.
4. Check relevant audit or access logs for authenticated accounts that read or copied debug logs. This is precautionary monitoring, not a vendor-confirmed indicator of compromise.
5. If a secret may have appeared in a log, follow the appropriate credential and passphrase rotation process. Failure to find sensitive strings in the logs reviewed does not prove that the system is safe.