Hi, I’m Josh Fridey, a Senior IT Manager with over 15 years of experience in the field. My work has centered around supporting companies that develop and deliver tech solutions for other businesses—especially in industries like agriculture, healthcare, construction, and petroleum—helping them grow through dependable, well-structured IT.
You can contact my best friend and food provider with this form. Suggestions, corrections, and questions are always welcome! Please also message me French fries...
All content and design elements on this website are the exclusive property of Josh Fridey and are protected by United States copyright and intellectual property laws. Unauthorized use, reproduction, or distribution of any material without prior written permission is strictly prohibited and may result in civil or criminal penalties.
This website includes third-party code, assets, or open-source libraries used under their respective licenses.
I was working in VS Code when Git showed an untracked file in my project:
Copied!
1./upload-d1337.php
That stopped me immediately.
This is a Next.js app running on Node.js. There should never be a PHP file in the root of the project.
I opened it and found a full PHP webshell. A webshell is a backdoor. If someone can access it, they can run commands on your server, browse files, and upload more malicious code.
Now this was incident response.
How It Happened
The first shell was sitting at the project root.
After that, I searched the entire directory for *.php files and found another copy here:
Copied!
1./.next/static/chunks/upload-d1337.php
That folder is generated during the Next.js build process. It should only contain static JavaScript files. Seeing a PHP file there strongly suggested the application itself had been exploited.
I ran npm audit and found a critical advisory:
Copied!
1next 10.0.0 - 15.5.92Next.js vulnerable to Remote Code Execution3https://github.com/advisories/GHSA-9qr9-h5gf-34mp
I was running version 15.5.2.
Remote Code Execution, or RCE, means an attacker can send a specially crafted request to your app and cause your server to execute code they control. In this case, that code wrote a PHP backdoor onto my server.
The Logs Confirmed It
From a single IP address, I saw this pattern:
Copied!
100:23:32 - POST / (303)200:23:34 - POST / (303)300:23:36 - POST / (500)400:23:38 - POST / (500)500:23:39 - POST / (303)600:23:41 - GET /upload-d1337.php?key=d1337 (200)
Several POST requests hit the site first. A couple caused 500 errors, which usually happens while an exploit is being tuned.
Then immediately after, there was a successful request to the PHP file that had just been written.
This was almost certainly automated scanning. Bots continuously sweep the internet looking for known vulnerabilities in popular frameworks.
What I Did Immediately
I treated it as a real compromise.
Updated Next.js to the latest patched version
Copied!
1npm install next@latest
Rebuilt and redeployed the app
Removed all discovered PHP files
Rotated API keys and secrets
Changed hosting credentials
Enabled two-factor authentication
If there is any chance code execution occurred, assume secrets may have been exposed.
Lessons Worth Keeping
Keep dependencies updated. Public vulnerabilities are actively exploited.
Run npm audit regularly. At minimum:
Before production deployments
After installing new packages
As part of your CI pipeline using --audit-level=high
The goal is not to run it obsessively. The goal is to reduce how long you stay on a vulnerable version.
A clean Git working tree makes suspicious files obvious.
Deleting the malicious file is not enough. You have to patch the vulnerability that allowed it.
Limit what lives in your .env file. The fewer sensitive values your app holds, the smaller the blast radius.
