Arbitrary file writes become RCE when runtime paths are predictable

At a glance

What this is: This analysis shows that arbitrary file writes become far more dangerous when attackers can infer execution paths, runtime type, and reload behaviour.

Why it matters: For IAM and security teams, the lesson is that exposed write primitives intersect with identity, secret, and privilege boundaries when they can alter runtime code, configuration, or credential-related files.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Ethiack's analysis of arbitrary file writes turning into remote code execution

Context

Arbitrary file write is a filesystem control problem first and an RCE problem only when the attacker can land bytes in a path that will later be read, reloaded, or executed. In practice, that means the impact depends on runtime layout, process privileges, and whether the application runs in a traditional host, container, or framework that re-imports code from disk.

The identity angle is real because many of the highest-value write targets are configuration files, secret-bearing files, and code paths that influence authentication, privilege, or execution flow. When an attacker can reach those files, the boundary between application compromise and identity compromise starts to collapse.

This starting position is typical of modern cloud-native applications, where the file system is narrower than in legacy servers but the consequence of a successful write can still be severe.

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. In that case, the attacker is no longer storing data on disk. They are shaping future execution. The break occurs at the trust boundary between writable storage and executable runtime state, especially when service accounts can write into package or config directories.

Q: Why do arbitrary file writes matter more in containerised environments?

A: Containers remove many legacy execution sinks such as cron, SSH, and interactive logins, but they do not remove runtime reload points or writable application paths. That means exploitability depends on whether the attacker can find a deterministic file the platform will re-read. The smaller runtime can reduce risk, but it also makes path discipline and identity scoping more important.

Q: How can security teams tell whether a file write is becoming an RCE risk?

A: Look for three signals: the write path is predictable, the target file is later re-read or executed, and the writing identity has access to a runtime directory rather than a disposable data folder. If those conditions line up, the primitive should be treated as an execution risk, not a low-grade integrity issue.

Q: What should teams do when a write primitive exists in a production app?

A: Contain the blast radius before attackers can profile the environment. Reduce writable paths, make filesystem errors uniform, remove write access from deployment and service identities, and keep code, templates, and configuration on read-only mounts wherever possible. The goal is to make the write unable to influence any file that a process will later execute.

Technical breakdown

Why arbitrary file writes are really path and reload problems

An arbitrary file write only becomes useful when the attacker understands where the bytes land and when the target reads them again. In legacy systems, that often meant cron, init, SSH, shell profiles, or dynamic linker hooks. In containers and stripped runtimes, most of those sinks disappear, which is why the same primitive can be trivial on one host and useless on another. The decisive factors are write location, file format, and whether the process or supervisor reloads from disk.

Practical implication: classify the sink by reload behaviour before you classify the vulnerability severity.

How filesystem errors become a discovery oracle

Path resolution leaks information through error handling. If a write fails with ENOENT, EACCES, EISDIR, or EROFS, the application is revealing whether a path exists, whether it is traversable, and whether it is writable. That turns a failed write into a probing tool that can map the filesystem and reduce guesswork. In black-box testing, this matters because each failed attempt can teach the attacker more about OS layout, containerisation, and application structure.

Practical implication: normalise filesystem errors so the response does not disclose path existence or permission state.

Why deterministic runtime paths are the most dangerous

The most reliable RCE chains do not require guessing an application-specific path at all. They rely on deterministic locations inside runtimes or libraries, such as worker entrypoints, template caches, or framework config files that are resolved from the installed package layout. If the attacker can overwrite a file that a runtime will later load from disk, execution follows the platform’s own control flow rather than an attacker needing a shell.

Practical implication: protect runtime-owned paths and package directories as high-risk assets, not ordinary writable storage.

Threat narrative

Attacker objective: The attacker wants to turn a single write primitive into code execution by placing malicious content in a deterministically executed path.

1. Entry begins with an arbitrary file write that gives the attacker control over both the destination path and the file contents.
2. Escalation follows when the attacker uses filesystem probing and runtime fingerprinting to identify a file that a process will later read, reload, or execute.
3. Impact occurs when the overwritten file becomes active, converting the write primitive into remote code execution or privilege-altering behaviour.

NHI Mgmt Group analysis

AFW-to-RCE is a reconnaissance problem, not just a file-writing problem. The article shows that impact depends on how much the attacker can learn about the target before choosing a sink. That changes the governance conversation from isolated bug severity to runtime exposure management, because the same primitive can be informational in one environment and catastrophic in another. For practitioners, the real control question is whether filesystem writes can be correlated with execution paths before damage occurs.

Predictable runtime paths create an identity-adjacent control failure. When applications reload code, templates, or configuration from disk, the file system becomes part of the trust boundary that governs execution and privilege. That is especially relevant for service accounts and deployment identities with write access to package directories, secret stores, or config roots. The lesson for IAM and PAM teams is to treat writable runtime paths as privileged surfaces, not just application folders.

Filesystem error handling is part of the attack surface. If an application distinguishes ENOENT from EACCES or EISDIR, it is helping an attacker map the environment. That is a form of control-plane leakage that many security reviews miss because it sits below the usual authz discussion. The named concept here is write-oracle exposure: a failed write that doubles as an environment probe. Practitioners should treat error uniformity as a security requirement, not a cosmetic one.

Container hardening reduces the number of viable sinks, but it does not eliminate the problem. The article’s catalog makes clear that many legacy execution paths disappear in distroless or read-only deployments, yet deterministic reload points and writable application directories can still be abused. This is why application teams need filesystem policy, runtime hardening, and identity-scoped write permissions together. For readers, the governing principle is to shrink both the write surface and the set of files that are ever re-read as code or configuration.

What this signals

Write-oracle exposure is the governance gap most teams overlook, because error responses can disclose enough filesystem state to turn a weak primitive into a reliable exploit path. If your platform already exposes secrets in code or config files, the attack surface is not just the file write itself but the identities and deployment paths that can reach those files.

The operational signal is simple: if a runtime can re-read code or configuration from disk, then file-write permissions are equivalent to partial execution rights. That is why the combination of service account scope, writable directories, and reload behaviour deserves the same scrutiny as elevated login access. Identity teams should map those paths explicitly and remove unnecessary write privilege before attackers do.

This is also a reminder that container hardening and identity governance have to be aligned. Read-only filesystems, tighter deployment identities, and uniform error handling reduce the chances that an AFW becomes a code execution chain, but only if they are enforced together rather than as separate hygiene tasks.

For practitioners

• Tighten write permissions around runtime-owned paths Restrict service accounts and deployment identities so they cannot write into package directories, config roots, template caches, or reloadable code paths.
• Normalise filesystem failure responses Return the same generic error for ENOENT, EACCES, EISDIR, EROFS, and related write failures so attackers cannot use errors as a path oracle.
• Use read-only filesystems for application containers Make the root filesystem read-only and expose only minimal tmpfs locations for scratch space, which removes many of the common AFW-to-RCE sinks.
• Separate writable storage from executable code Keep uploads, cache directories, and runtime write locations outside any path that a process can later import, interpret, or reload as code.
• Audit identity access to file-write sinks Review which human, service, and deployment identities can write to files that influence execution, then revoke unnecessary access before exploitation paths exist.

Key takeaways

• Arbitrary file write becomes a serious issue only when the attacker can identify a file the platform will later execute or reload.
• Filesystem errors can leak enough information to turn failed writes into environment reconnaissance and shrink the attacker's guesswork.
• The strongest defensive pattern is to remove writable access from runtime paths, normalise errors, and keep code and secrets off writable storage.

Key terms

• Arbitrary File Read: An arbitrary file read is a flaw that lets an attacker read files they should not access on the target system. In NHI environments, the impact often goes beyond information disclosure because the files may contain session secrets, database contents, or keys that enable impersonation or escalation.
• Write Oracle: A failure response that reveals useful information about a filesystem path, such as whether it exists, is writable, or is a directory. Attackers use it to reduce guessing and map the target environment before choosing an exploit path.
• Reloadable Runtime Path: A file or directory that an application, library, or supervisor reads again during normal operation. If an attacker can write to one of these paths, they may influence configuration, code loading, or execution flow on the next reload or request.
• Deterministic Execution: A repeatable operational pattern where the same input leads to the same governed outcome, with no hidden decision branches. For identity teams, deterministic execution matters because auditability depends on being able to reproduce and explain each access change after the fact.

What's in the full article

Ethiack's full blog post covers the exploit catalog and platform-specific mechanics this analysis intentionally leaves at the source:

• Path-by-path examples for OS, runtime, and framework sinks that can convert file writes into execution
• Fingerprinting techniques that use write failures as a filesystem oracle before choosing a payload
• Specific container and framework cases such as template caches, reloadable configs, and worker entrypoints
• Defender-side mitigations for read-only filesystems, error normalization, and runtime hardening

👉 Ethiack's full post maps the runtime sinks, fingerprinting steps, and exploitation paths in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It helps practitioners connect file-write exposure to the privilege and credential paths that make exploitation possible.