Skip to main content

Server-Side Request Forgery (SSRF) is a critical security vulnerability that occurs when a web application fetches a remote resource without validating the user-supplied URL. Attackers weaponize SSRF to force the hosting server to make unauthorized requests, often targeting internal resources, local files, or cloud metadata services.

So, the decoded path is: fetch-url-file:/:/root/.aws/config

Inside /root/.aws/config , you will typically find plaintext settings formatted as follows:

And get:

Ensure that web applications and services run with the lowest possible privileges. A web server should never be configured to run as the root user, and it should never have file-system read permissions for the /root/ directory. 2. Avoid Static Credentials

: If they can read the .aws/config or the .aws/credentials file, they can steal identity keys, potentially gaining full control over your AWS infrastructure.

Because node-fetch (and the underlying http module) does block file:// by default, it reads the local file and returns it as a binary buffer. If the response content-type is forced to image/jpeg , the file may be corrupted, but a simple curl command will still retrieve the raw text:

Do not run your web application as root . Use a dedicated low-privilege user (e.g., www-data ). Even if an SSRF vulnerability exists, the attacker will not be able to read /root/.aws/config because the process lacks read permissions on the root’s home directory. However, they might still access other world-readable sensitive files (e.g., /etc/passwd , /proc/self/environ ). So this is not a complete solution, but it helps.

The PHP file_get_contents() happily reads /root/.aws/config and returns its content (if the web server runs as root or has read permissions). The attacker sees the AWS credentials in the HTTP response.

When fully decoded, the string translates to: fetch-url-file:///root/.aws/config Anatomy of the Targeted File

Again, encoding helps bypass filters that look for file:// .