How to fix path traversal in embedded firmware

Path traversal (MITRE CWE-22, read 2026-10-29) happens when firmware builds a filesystem path from external input — a filename in a web UI request, an upload parameter, an exported-log name — without removing or rejecting the special sequences (../, absolute paths, encoded separators) that let that path resolve outside its intended directory. MITRE rates it a high likelihood of exploit, and its own description covers both reading files it shouldn't (confidentiality) and, in upload or import handlers, writing or overwriting files it shouldn't (integrity, and potentially code execution if an attacker can overwrite something the system later runs).

1. Detect

• Audit every firmware web-UI or API handler that accepts a filename, path fragment, or file-upload destination as a parameter: log download/export, configuration backup/restore, firmware-image upload, certificate import, captive-portal asset serving.
• For each one, trace whether the supplied name is used directly (or lightly concatenated) to build a path passed to a file-open, read, write or delete call, without a canonicalization-and-containment check afterward.
• Test with both classic traversal (../../../etc/passwd) and encoded/alternate variants (URL-encoded %2e%2e%2f, double-encoding, backslash separators, absolute paths) — a denylist that only blocks the literal ../ string will often miss these.
• Check upload and import handlers specifically for write-path traversal, which is more severe than read-path traversal because it can let an attacker place a file anywhere the process can write, including executable locations.

2. Fix

1. Canonicalize, then verify containment. Resolve the supplied path to its canonical absolute form with a built-in function (realpath() in C, or your language's equivalent) — MITRE notes this "effectively removes '..' sequences and symbolic links" — and then explicitly check that the canonical result is still inside the restricted parent directory before opening it. Reject the request if it isn't.
2. Validate the raw input with an allowlist, not a denylist. Restrict filenames to a strict character set (alphanumeric, hyphen, underscore, a single extension) and explicitly reject path separators (/, \\) in the component itself, so traversal sequences never reach the path-construction step.
3. Prefer an indirection layer over raw filenames where possible. Map a request to a file via an internal ID or lookup table (e.g. "log #3" rather than a raw filename), so user input never becomes part of a filesystem path at all.
4. Run file operations inside a sandbox or chroot/jail where feasible. MITRE lists this as an operation-phase mitigation: it won't fix the underlying bug, but it bounds the damage if a traversal check is ever missed.
5. Apply the same fix pattern everywhere the pattern repeats. Path traversal in firmware is usually a repeated handler pattern (one file-serving utility function reused across many endpoints) — fix the shared utility, then confirm every call site actually uses the fixed version.

3. Verify

• Re-test the same traversal payloads (plain and encoded) against the patched handler and confirm every one is rejected, not just the exact proof-of-concept string originally reported.
• Confirm legitimate requests (normal filenames, expected extensions) still work — an over-broad fix that breaks the intended feature is as much a problem as a missed bypass.
• Add the traversal test cases to your regression suite so a future handler added to the same code path inherits the same protection by default (ideally by calling the shared, fixed utility rather than re-implementing path handling).

4. Ship an update

Path-traversal fixes are usually self-contained to the affected handler(s); distribute the update through your normal signed-firmware channel, and use your firmware SBOM to confirm which product lines share the vulnerable file-serving utility, since it is common for the same code to be reused across several models.

5. Disclose via PSIRT

Path traversal in an unauthenticated web endpoint is frequently exploited at scale by internet-wide scanners once published, so treat disclosure timing accordingly — see KEV + EPSS prioritization. Run the advisory through your coordinated disclosure process (CVD process explained; PSIRT setup for a hardware company if you don't have one yet), and check the Cyber Resilience Act's 24-/72-hour reporting duty for EU-market products if there is evidence of active exploitation (CRA 24h/72h reporting).

SoftWSP's firmware and web-UI scanning traces exactly this pattern — user input reaching a filesystem path — across a device's firmware image: see device & firmware security.

This guide summarises public MITRE CWE guidance; it is not a substitute for a full code review, and does not constitute legal advice.