There’s currently an NGINX CVE: NVD - CVE-2026-42945
Is OpenOnDemand affected by it?
I don’t think so. We use rewrites, but I don’t think we chain them.
And even so, from the announcement:
This may cause a heap buffer overflow in the NGINX worker process leading to a restart
You’re restarting your own Nginx. I.e., your Per User Nginx (PUN). So even if you can, you’re only impacting yourself, never another user.
Thanks for the feedback, last week or so caution has gone significantly up.
We’re still keeping our OOD instance in maintenance, because of the ssh-keysign issue.
I’ll add that, from the announcement, it may be worth verifying if ASLR is enabled.
cat /proc/sys/kernel/randomize_va_space
A value of 2 is safe, it means that it is globally enabled
Most likely all our systems have it enabled, but if they don’t and the Nginx instance is vulnerable because it uses chained rewrites, that allows for RCE.
Just for completeness in this thread, I felt it would have been worth including some “off topic”.
@jeff.ohrstrom Sorry to add to this, but there are also these other NGINX CVEs:
Is OOD affected by these?
- CVE-2026-40701
- No we don’t use
ngx_http_ssl_module.
- No we don’t use
- CVE-2026-42934
- No we don’t use
ngx_http_charset_module
- No we don’t use
- CVE-2026-42946
- No we don’t use
scgi_passoruwsgi_passdirectives.
- No we don’t use
But even so, a lot of these rely nginx serving multiple clients. Ours don’t. You have your own per user nginx, which only you can communicate with. They also rely on unauthenticated users, which would require root access on the machine to communicate with the socket file of your PUN. Which at that point wouldn’t matter if they had vulnerabilities or not, the user has root access.
Thanks for clarifying, Jeff! 
Thanks for the questions, @james-s-willis and @camarocico!