Workers silently accepts leading whitespace in secret variable names

[mikulabc]

What versions & operating system are you using?

Wrangler 4.118.0
Node.js 24.14.1
npm 11.11.0
Linux Docker container
Windows host with PowerShell 7.6.4

The affected secret was originally created through the "Workers & Pages" dashboard under "Settings" → "Variables and Secrets".

Please provide a link to a minimal reproduction

N/A

Describe the Bug

The Workers dashboard accepts secret variable names with accidental leading or trailing spaces.

For example, FIREBASE_SERVICE_ACCOUNT_JSON is deployed as a different binding from FIREBASE_SERVICE_ACCOUNT_JSON, without any warning.

This is difficult to notice and causes the expected env binding to be undefined.

Please trim surrounding whitespace automatically, or reject the name with a clear validation message before deployment.

Please provide any relevant error logs

$ npx wrangler secret list

[
  {
    "name": " FIREBASE_SERVICE_ACCOUNT_JSON",
    "type": "secret_text"
  },
  {
    "name": "OTHER_AUTH_SECRET_WITHOUT_WHITESPACE",
    "type": "secret_text"
  }
]

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #71

Summary

Secret variable names with accidental leading/trailing whitespace are accepted silently (e.g. FIREBASE_SERVICE_ACCOUNT_JSON becomes a distinct binding from FIREBASE_SERVICE_ACCOUNT_JSON), causing the expected env binding to be undefined. The reporter asks wrangler to trim the whitespace automatically or reject the name with a clear validation message before deployment.

Classification

• Type: Bug
• Component: packages/wrangler
• Severity: Medium
• Has Reproduction: No (repro link marked N/A, but symptoms and wrangler secret list output are clearly documented and reproducible)
• Quality: Complete

Findings

• Created: not available in fetched context (metadata truncated)
• Author: mikulabc (Mikula Beutl)
• Version: Wrangler 4.118.0, Node.js 24.14.1, npm 11.11.0 (Linux Docker container, Windows/PowerShell 7.6.4 host)
• Labels: not available in fetched context
• Comments: 1 (an automated advisory triage report posted by the workers-devprod bot — not a maintainer or reporter response)

Analysis

• Component: This concerns the wrangler secret surface and how secret binding names (keys) are handled. Secret command handling lives in packages/wrangler, so this maps cleanly to that package.
• Quality: The report is well-formed against the bug template — it includes versions, OS, a precise description, and wrangler secret list output demonstrating the problem. The only gap is the missing minimal reproduction link, but the failure is trivially reproducible (create a secret whose name has a leading space).
• Root of the problem: The offending secret was created via the dashboard, which accepted the whitespace-prefixed name. Wrangler surfaces (secret put / bulk upload / secret list) do not appear to trim or warn on surrounding whitespace in the name, so the mismatch propagates silently and the env binding shows up under an unexpected key.
• Severity is Medium: This is a silent misconfiguration footgun that makes a binding resolve to undefined, which can be very hard to debug. However, there is a clear workaround (recreate the secret with a trimmed name) and it is not a crash or data loss.
• Not closeable: No spam, no duplicate reference, no reporter/maintainer confirmation of resolution, not stale, and the request is a legitimate, actionable improvement rather than user error — the reporter's underlying complaint is that the tooling accepts an invalid/ambiguous name without any signal.

Note: The pre-fetched context.json line is truncated at 2000 characters, so created/updated dates, labels, and issue state could not be read. The recommendation below does not hinge on those fields, but a maintainer should confirm current labels/state before acting.

Recommendation

Status: KEEP OPEN

Reasoning: This is a valid, clearly-described bug/enhancement: wrangler should not silently accept secret names with surrounding whitespace. A small, self-contained fix (trim the name and/or emit a validation warning) would prevent a confusing class of undefined-binding failures.

Action: Triage as a packages/wrangler bug. Decide on the desired behavior — either (a) trim surrounding whitespace from secret names on secret put/bulk upload, or (b) reject/warn on names containing leading or trailing whitespace — and add validation on the wrangler side. Consider whether the same validation belongs on the dashboard/API side (which originally accepted the name); if so, route that portion to the appropriate team. A maintainer should also confirm current labels and add the relevant component/product labels.

Suggested Labels: (none — repository labels could not be verified from the truncated context; omitting rather than guessing)

Suggested Comment

Thanks for the detailed report! You're right that a secret name with leading/trailing whitespace (e.g. FIREBASE_SERVICE_ACCOUNT_JSON) resolving to a separate binding — with no warning — is a confusing footgun. As a workaround for now, you can delete the mis-named secret and recreate it without the surrounding space so the binding resolves under the expected key.

We'll look into adding validation on the wrangler side so that surrounding whitespace in a secret name is either trimmed or rejected with a clear message before deployment. Note that the original secret was created through the dashboard, so part of this may also need a fix on the dashboard/API side — we'll follow up internally on that.

Structured summary (JSON)

{
  "issueNumber": 15019,
  "title": "Secret variable names with leading/trailing whitespace are accepted silently, causing undefined env bindings",
  "githubUrl": "https://github.com/cloudflare/cf-platform-issues/issues/71",
  "recommendation": "KEEP OPEN",
  "difficulty": "easy",
  "reasoning": "Valid, clearly-described bug: wrangler silently accepts secret names with surrounding whitespace, producing a distinct binding and an undefined env value. A small fix to trim or warn on whitespace in secret names would resolve it.",
  "suggestedAction": "Triage as a packages/wrangler bug; add validation to trim or reject secret names with leading/trailing whitespace, and confirm whether the dashboard/API side also needs a fix.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[stareezy-1]

Root cause: the Workers dashboard accepts secret names with accidental leading/trailing whitespace, producing a binding that is silently inaccessible as env.<name> (the expected env binding is undefined). Wrangler faithfully echoes and deploys those names.

The focused fix validates secret names in wrangler secret put, secret bulk, versions secret put, and versions secret bulk, rejecting leading/trailing whitespace with a clear error before anything reaches the API (bulk deletes are exempt so legacy whitespace-prefixed secrets can still be removed), with regression tests for put and bulk.

PR incoming.

[dario-piotrowicz]

Thanks for the issue @mikulabc 🙂

I'll look into implementing a fix in the dashboard

This is internally tracked as UI-9203