Topic starter
18/08/2026 2:14 pm
TL;DR: Arbitrary file writes are often treated as low severity, but Ethiack shows that exploitability depends on path control, content control, and knowledge of what the target will later execute. The security gap is reconnaissance, because once the runtime and filesystem are profiled, a write primitive can become code execution.
Editorial analysis by NHI Mgmt Group, based on content published by Ethiack: “Write Once, Shell Everywhere: Turning Arbitrary File Writes into RCE”.
Key questions
Q: What breaks when arbitrary file writes reach reloadable runtime paths?
A: A file write becomes far more dangerous when the target process later reads the file as code or configuration.
Q: Why do filesystem write errors help attackers profile the target?
A: Because different error codes can reveal whether a path exists, whether a component is a file or directory, and whether the attacker can traverse or write there.
Q: What are the signs that a write primitive is close to RCE?
A: Look for deterministic reload behaviour, writable worker or template directories, and files that are re-read by a service without a restart.
Practitioner guidance
- Separate writable data from executable paths Keep uploads, caches, and runtime scratch spaces outside any directory that a process, worker, or template engine may later execute or reload.
- Normalise filesystem failure responses Return a generic error for write failures so attackers cannot use errno differences to infer path existence, directory structure, or permission boundaries.
- Harden container and process startup Run non-root, avoid shell-based entrypoints, and make the root filesystem read-only so common AFW-to-RCE destinations disappear.
Bottom line: Arbitrary file write findings become materially more severe when the written path is later consumed by a runtime, worker, or template engine.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:05 pm
Path predictability is the real control failure: arbitrary file write becomes materially dangerous when the attacker can map a writable path to a later execution path. The vulnerability is not the write alone, but the combination of predictable runtime layout and a process that re-reads files from disk. Practitioners should treat deterministic path resolution as part of the attack surface, not an implementation detail.
A question worth separating out:
Q: Should teams prioritise filesystem hardening over payload filtering for AFW issues?
A: Yes, because payload filtering does not fix the core problem when a writable path is later executed or reloaded. Read-only roots, non-root runtime users, separated data and code paths, and consistent error handling reduce the exploitability of the primitive itself, which is the real control objective.
👉 Read our full editorial: Arbitrary file writes become RCE when runtime paths are predictable