What breaks when upload filenames are not sanitised in workflow automation?

Why This Matters for Security Teams

Filename sanitisation looks like a simple input-validation problem, but in workflow automation it becomes an identity and execution boundary issue. A filename is often reused by multiple steps, including file movers, parsers, archive jobs, and privileged runners. If that value can carry path separators or traversal sequences, a single upload can redirect writes into trusted locations and turn a routine automation path into code or configuration manipulation. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this kind of input handling as part of secure processing and least privilege, not just application hygiene.

For NHI-heavy pipelines, the risk is sharper because downstream jobs frequently run with service account credentials, API keys, or privileged filesystem access. The same weakness that writes a file can also stage a secret, replace a task definition, or plant persistence for later execution. NHIMG’s research on the Ultimate Guide to NHIs shows how often organisations still struggle with NHI visibility and control, which makes filename abuse more dangerous once automation fans out across systems. In practice, many security teams encounter the impact only after a workflow has already overwritten a config or dropped a key into a trusted path, rather than through intentional review of the upload logic.

How It Works in Practice

In a workflow engine, the uploaded object usually enters one component and is later consumed by others that assume the name is trustworthy. If sanitisation is missing, an attacker can submit names such as ../../.ssh/authorized_keys or similar path traversal payloads, and the automation may resolve that into a write outside the intended upload directory. The result depends on what later nodes do with that path: extract an archive, rename a file, mount it into a container, or pass it to a shell command.

Good handling is not just stripping characters. Security teams should treat the filename as untrusted metadata and separate it from the storage path entirely. That usually means assigning a random internal object name, storing the original name only for display, and validating any later re-use at each trust boundary. Where files trigger follow-on actions, the workflow should also enforce least privilege on the runner, so a compromised filename cannot reach sensitive filesystem paths or adjacent secrets stores. The NIST guidance on secure configuration and access control is directly relevant here, as is the pattern shown in the GitHub Action tj-actions Supply Chain Attack, where automation blast radius matters as much as the initial foothold.

• Use server-side path normalisation and reject any path that escapes the upload root.
• Map uploads to internal object IDs, not user-controlled filenames.
• Validate again before every downstream file write, extract, rename, or move.
• Run workflow steps with minimal filesystem and secret access.

These controls tend to break down when workflows span multiple runtimes or mount the same storage volume into privileged jobs, because one unsafe consumer can bypass the safeguards of the original upload service.

Common Variations and Edge Cases

Tighter filename handling often increases operational friction, requiring teams to balance usability, compatibility, and security. That tradeoff shows up when legitimate users expect spaces, Unicode, long paths, or duplicate names, while the automation layer needs deterministic storage and safe routing. Current guidance suggests allowing the user-facing name for display but never for filesystem control; there is no universal standard for this yet, so implementations vary by platform and language.

Edge cases matter in archives, sync jobs, and hybrid file-processing chains. A filename may be safe in the upload service but unsafe after decompression, template rendering, or cross-platform translation from Linux to Windows path rules. Extension checks alone are weak because attackers can hide traversal or shell metacharacters in unexpected encodings. The most reliable pattern is still: normalise early, store separately, and revalidate at each handoff. NHIMG’s Schneider Electric credentials breach is a reminder that once trusted automation is abused, the damage often extends well beyond the initial file operation.

For teams building workflow automation around NHI credentials, the practical lesson is that filename safety is not a cosmetic input filter. It is part of preventing arbitrary write primitives from becoming secret exposure, persistence, and lateral movement.

Related resources from NHI Mgmt Group

• What is the main risk when automation systems store ServiceNow credentials?
• What breaks when an MCP tool is compromised inside an automation workflow?
• What breaks when workflow automation is not tied to auditability?
• What breaks when offboarding is handled manually instead of through workflow automation?