Relative Path File Injection: Turning Benign Uploads into Persistent RCE

TLDR: Relative Path File Injection (RPFI) is a novel attack vector that exploits insecure server-side path handling to force browsers and applications to misinterpret injected content as executable code. By manipulating file types and leveraging lenient parsing, an attacker can achieve persistent code execution through seemingly harmless file uploads. Pentesters should prioritize testing for path confusion in file upload endpoints and server-side template rendering engines.

Modern web applications are obsessed with user-generated content. From profile pictures to document management systems, the ability to upload files is a standard feature. Most developers treat these uploads as static blobs, assuming that as long as they check the file extension or MIME type, they are safe. This assumption is a massive blind spot. The research presented at DEF CON 2024 on Relative Path File Injection (RPFI) proves that if your server-side path handling is sloppy, an attacker can turn a "safe" file upload into a full-blown remote code execution (RCE) chain.

The Mechanics of Path Confusion

At its core, RPFI is an evolution of Relative Path Overwrite (RPO). While traditional RPO relies on injecting CSS to hijack page rendering, RPFI takes it a step further by forcing the application to treat an uploaded file as a different, executable type. The vulnerability exists when a web server or application fails to strictly validate the path structure, allowing an attacker to inject content that the server then interprets based on its location rather than its metadata.

Consider a scenario where an application allows users to upload a PDF. If the server-side logic uses a relative path to include or serve this file, and the server is configured to execute files based on their extension or content-type headers, the game is over. By crafting a file that is valid as both a PDF and a shell script or a server-side template, an attacker can bypass standard upload filters. When the server later accesses this file via a manipulated path, it executes the payload.

Exploiting Lenient Parsers

The most dangerous aspect of RPFI is how it interacts with different file parsers. Many applications use libraries that are "lenient"—they try to be helpful by parsing files even if they are malformed or mislabeled. If you can upload a file that contains both valid PDF headers and malicious JavaScript or shell commands, you are essentially hiding your payload in plain sight.

For example, if you are testing an endpoint that processes user-uploaded files, try injecting a payload that looks like this:

# Example of a polyglot payload structure
%PDF-1.4
1 0 obj
<< /Type /Catalog /Pages 2 0 R >>
endobj
# Malicious payload follows
<script>alert(document.domain)</script>

When this file is served from a directory that the server treats as a script execution context, the parser might ignore the PDF headers and execute the script tag. This is not just about cross-site scripting (XSS); it is about forcing the server to run code it never intended to execute. During the research, it was demonstrated that even complex file formats like PDFs can be used as carriers for these payloads because they start and end with specific magic bytes, leaving the middle of the file open for arbitrary content.

Real-World Impact for Pentesters

During a penetration test, you should look for file upload endpoints that do not store files in a dedicated, non-executable storage bucket (like an S3 bucket with no execution permissions). If the application stores files on the local filesystem and serves them through a web server like Nginx or Apache, check how the server handles path requests. If you can influence the path used to retrieve the file, you can potentially trigger the RPFI condition.

This technique is particularly effective against applications that use server-side template injection (SSTI) or those that rely on client-side frameworks that fetch resources dynamically. If you can get a file onto the server, and you can control the path that the application uses to "include" or "display" that file, you have a high probability of achieving RCE. The impact is not limited to the web application; if the server is running in a containerized environment or has access to internal network resources, the pivot potential is massive.

Defensive Strategies

Defending against RPFI requires moving away from the "check the extension" mindset. First, never serve user-uploaded files from the same origin as your application code. Use a separate domain or a cloud storage service that is explicitly configured to serve files as application/octet-stream or another non-executable type. Second, implement strict path validation. If your application needs to access a file, use absolute paths and ensure that the file is located within a restricted, read-only directory.

Finally, consider the OWASP File Upload Cheat Sheet as your baseline for security. If you are using a framework that supports server-side rendering, ensure that you are not dynamically including files based on user-provided input. The goal is to make it impossible for the server to ever treat a user-uploaded file as anything other than a static, inert piece of data.

The rise of "HTML-over-the-wire" frameworks has only increased the attack surface for these types of vulnerabilities. As we continue to push more logic to the server, we must ensure that our path handling is as rigorous as our authentication. If you are hunting for bugs, start looking at how your target handles file paths—you might find that the "safe" upload feature is the most dangerous part of the entire application. Happy hunting.