Reviewing Three High-Severity n8n Secrets Alerts

On October 29, 2026, we reviewed a repository-level Plexicus result set for n8n. It contained 110 secrets-category alerts: three labeled high and 107 medium. A reader could interpret that summary as evidence of leaked credentials. The detailed records did not support that conclusion.

We inspected all three high-severity records and compared their reported locations with public source at the repository’s requested immutable snapshot. Two locations identify mocked credential-name constants. The third identifies a credential-type declaration. None of those three inspected locations establishes a usable credential exposure. The missing association between each finding and its actual scanned commit also prevents a definitive scanner false-positive verdict.

What the three records actually establish

The returned records were labeled “Use of Hard-coded Credentials.” They included a file path and line number, but their source-code, scanner-report and description fields were empty. Their false-positive flag was false. That stored flag is a workflow state, not independent proof that a credential exists.

The credential configuration test, page deletion test and attachment deletion test are public, immutable source references. We publish only the identifiers needed to explain the review. We do not reproduce credential values, private finding IDs or raw API responses.

The commit gap changes the verdict

The Open Source Explorer record requested snapshot 447fc866bb0a841decfa5e8a29fba06057bfc5bc. We could retrieve those source files from upstream at that exact SHA. However, the available finding records did not identify their scan run or actual scanned commit. Repository-level counts can include records from another point in the repository’s history.

That distinction matters when line numbers move. A returned line that currently contains a harmless declaration cannot prove what a scanner matched in an earlier revision. Equally, a severity label cannot repair missing source evidence. The narrow outcome is therefore: no credential exposure established by the available three records and their requested-snapshot source context. This is not a claim that n8n has no secrets anywhere or that every alert is incorrect.

Original review model. The diagram describes the evidence required for a verdict; it does not depict a reproduced leak.

A test file is context, not an automatic exemption

Real credentials can appear in tests, fixtures and examples. Excluding every test directory would hide genuine leaks. The useful question is what the reported value does: is it a secret, a credential-type name, a deliberately synthetic marker or a reference to another object?

For the two Confluence locations, the visible code assigns a credential-name constant inside a mocked module and replaces the API function with a test double. At the third location, the visible line begins a typed configuration object. Those observations justify asking for the original matched bytes and rule explanation before requesting credential rotation or announcing a breach.

If the original match later establishes a real credential, sanitize the public report and follow the provider’s revocation process. We did not try to authenticate with any value or send a candidate credential to an external service.

Keep the evidence packet attached to the decision

For each alert, retain the scanner and rule version, matched commit, source range, redacted match, credential category and reviewer reasoning. Record whether the value can authenticate, whether that has been established safely, and who owns remediation. A blocked check or missing payload stays unresolved.

Our Proof-Driven AppSec workflow connects an alert to a reviewable outcome. The remediation playbook explains the handoff to a reviewed change. Deep Code Analysis discusses why source context matters beyond a pattern match.

Plexicus exposes the alert metadata used in this review. The source inspection and qualification described here were an editorial investigation, not evidence that an automated product feature already made this decision. The remediation workflow and AI Swarm Pentest describe other scoped product workflows; neither turns these three records into confirmed leaks.

What to do with this result

Request the original scanner match and the actual scan revision. Reconcile the line mapping before marking the alerts confirmed or false positive. Preserve the requested-snapshot links and this limited review outcome so a later analyst can complete the record. No n8n patch, credential revocation or successful exploitation is established by this review.

Sources

• n8n source snapshot
• OWASP Secrets Management Cheat Sheet

Need help turning scanner output into an engineering decision? Contact Plexicus with the repository revision and a sanitized evidence packet.