pattern·published·2 exhibits

Unauth Write To Execution Path

No auth required to write a file into a path the server executes. Webroot upload, CGI drop, etc.

There is a class of vulnerability where the exploit is a single unauthenticated request that writes a file into a directory the server later executes. Not shellcode. Not memory corruption. Not deserialization cleverness. A file write, into a path the web server is configured to run, by a caller who did not authenticate.

The bug is almost too plain to take seriously until you see how often it lands. It is an architectural shape: the web server has a writable directory, the writable directory is on the execution path, and the write endpoint does not check who is writing. Three decisions, each reasonable in isolation. Together, the three decisions add up to remote code execution for anyone who can reach the HTTP port.

Mechanism

The stack looks like this. A server product exposes a web interface. The web interface has endpoints that accept file uploads: maybe for profile pictures, maybe for configuration, maybe for document import, maybe for certificate management. The uploaded files get stored somewhere on disk. The web server is configured to execute scripts from a directory tree that includes, or can reach, the upload location. An unauthenticated caller uploads a script. The server stores it. The server executes it on the next request to its path.

Each step is documented. Each step is working as designed. The vulnerability is the composition: the write path and the execute path overlap, and the overlap is reachable without credentials.

What makes this specific is the ABSENCE of exotic primitives. No memory safety bugs. No complex parser confusion. No cryptographic weakness. The exploit is a normal HTTP POST. The payload is a normal file. The defender reading the advisory is looking at an attack that could have been prevented by any of: requiring auth on the upload, storing uploads outside the execution root, denying execute on the upload directory, filtering file extensions. All four defenses exist. All four were omitted.

The recurrence is what puts this in a pattern library. New instances appear every quarter in products that have been shipping for decades. The design shape keeps producing CVEs because the shape keeps getting built. Someone chooses to store uploads where the web server runs. Someone forgets that the upload path is reachable without auth. Someone adds a new endpoint that bypasses the auth check in the rest of the app. The result is always the same: one POST to root.

Exhibits

CrushFTP CVE-2025-31161: MFT Is the Target Now. Managed file transfer is, architecturally, a product whose entire purpose is accepting files from the outside. CrushFTP's pre-auth CVE reduced to a request path that wrote an uploaded file into a directory the admin interface later read as code. The MFT product category has spent the last three years establishing that it is structurally the target: MOVEit, Cleo, GoAnywhere, CrushFTP. Each advisory is a new instance of the same shape. The write endpoints and the execution paths are close together because the product's business is moving files, and the business keeps expecting the product's shape to be different this time.

SAP NetWeaver CVE-2025-31324: When CVSS 10.0 Means What It Says. An unauthenticated endpoint in NetWeaver that accepts a file upload, stores it under the web application root, and serves it on subsequent requests. The CVSS 10.0 is not hype. The exploit is a curl command. The remediation is a patch that belatedly adds auth to the endpoint. The architectural mistake is that the endpoint existed as a write path reachable without auth into a directory that the web server is configured to execute from.

Boundaries

Not every file upload bug. If the upload endpoint requires authentication, it is still a bug (post-auth RCE), but it is a different pattern. Unauth-write-to-execution-path specifically requires that the caller did not have to authenticate. The missing auth is the essential feature. Add auth, and the bug becomes an insider-threat vulnerability, which belongs in a different conversation.

Not every webshell upload. Once an attacker has any code execution or any authenticated write into an exec-path directory, they can upload a webshell. That is a post-exploitation step. Unauth-write-to-execution-path describes the initial access vector: the exploit that got them to the first execution. Conflating the two makes the pattern look like it is everywhere, which flattens the specific architectural signal.

Not general deserialization. Deserialization RCEs work by smuggling attacker-controlled object graphs through serialization boundaries. Those attacks require specific gadget chains and specific library versions. Unauth-write-to-execution-path works with a plain file. The distinction matters for detection: deserialization attacks have characteristic traffic shapes; unauth-write-to-execution-path usually looks exactly like a normal file upload until the stored file runs.

Defender playbook

For every web-facing service in your fleet, enumerate the intersection of its upload paths and its execute paths. If the two touch, that is your exposure. The audit can be mechanical: list the directories the web server is configured to execute from, list the directories that receive user-uploaded content, compute the intersection. A non-empty intersection is the pattern.

Check which upload endpoints are reachable without authentication. The answer is never zero. Every product has a login page, an account recovery flow, a support channel, a health check. Some of those accept POST bodies. Some of those write those bodies somewhere. Map the actual HTTP surface, not the documented one.

Disable execution on upload directories, structurally, not by configuration that can be undone in the next deploy. If the directory is on a filesystem mounted noexec, no subsequent config drift will re-enable it. Defense-in-depth here means making the simple mistake impossible to make again.

Treat file extensions as untrustworthy input. The server should not decide how to execute a file based on the file's extension. That assumption produced the pattern's first generation. Modern exploits layer on it: polyglot files, extension confusion through URL encoding, server-specific path parsing quirks. The correct answer is not better extension filtering. The correct answer is not executing from the write path at all.

Log every unauthenticated write. If your logs cannot tell you which endpoints accepted writes from unauthenticated callers in the last hour, you are operating blind on the attack surface this pattern needs. The log question is not "who logged in," it is "who wrote a file without logging in."

Kinship

Design Debt Driver. Products that produce unauth-write-to-execution-path CVEs repeatedly are design-debt-drivers in this specific shape. MFT, SAP, legacy web applications, anything with "shared filesystem between upload and execute" as an architectural assumption. The instances differ. The substrate is the same.

Disclosure After Exploitation. Unauth-write-to-execution-path CVEs in enterprise products are frequently first known through in-wild exploitation. The attackers scanning for these products find them before the researchers do, because the exploits are cheap to weaponize and the products are directly internet-exposed. The CVE lags the exploitation.

Trust Inversion. A successful exploit of this pattern converts an unauthenticated network peer into code running inside the server's trust boundary. The server's trust in its own execution path becomes the attacker's foothold. From there, the attacker inherits everything the server could do.

One POST to root. The attack is as old as CGI and as young as the latest MFT advisory.