Just to let the userbase know, the HTTP nginx server it uses, it's very old and has a few CVEs Vulnerabilities in nginx 1.17.7
Thanks for the info. Very meta.
A qualified security alert should at least mention the platform (used hardware and GL.iNet firmware version).
What vulnerability does bugs you the most? Maybe we can help to explain the use case here.
Let's pick CVE-2019-9511 as example.
[...]
Published: 2019-08-13
Updated: 2024-08-04
Title: Some HTTP/2 implementations are vulnerable to window size manipulation and stream prioritization manipulation, potentially leading to a denial of service
[...]
The nginx of GL.iNet router is not exposed to WAN and Guest in default configuration. So some device at your LAN side could send manipulated HTTP/2 packages to du a DDOS.
And now? You really should ban this LAN device. But I don't see much harm here.
What CVE do you want to have analyzed?
1 Like
Every CVE since 1.17.7 release, I bet no one that owns a router in general reads every nginx CVE patch and thinks: "Mhh, has my router updated in the background nginx service ?"
It's just better for a user to know that their router (fundamental part of their network) is being updated regularly to patch vulns that may seem harmless but then may get exploited without the owner knowing.
And as a potential customer I would prefer a router which takes updates seriously, ask the community if they want a router with many potential harmful CVEs or an updated one ;), this could also harm their sales
Most CVEs are not harmful mostly.
DDoS for example is not harmful. It will stop service and might annoy - but harmful for consumers? Nah.
Sorry, but besides the fact nginx has vulnerabilities...
Even normal routers when they are updated they have counts of vulnerabilities and don't let me start about ancient SDKs in where some vendors don't backport anything yup some isps give them as consumer equipment lol, but often it doesn't mather because firewall blocks it, it will be more risky if the CVE was remotely.
I mean it is kinda ironic, but i never saw a log which kind of vulnerabilities are patched from other routers only if the vulnerability was in their own logic, but never targeted to their packages directly maybe only a generic message that some vulnerabilities are patched but nothing to a CVE site, and that is my point.
And if security is so important why using root 
, see that is why you should never place a router without firewall, doesn't mather if its full openwrt or not, it's not a server.
Do i think there needs a update?, sure but not for every CVE, but i also agree some packages are out of date or became even incompatible.
Do you want to answer my question or keep vague generalisations?
Else you don't need to read further. I am out of this discussion.
'There is a vulnerability' causes a CVE. But not every CVE is matching for my use case.
We are talking about embedded devices. If you are upgrading a service you need to make sure all dependencies are matched. As the Web interface is your "Monitor" all the users who never heard of CVE will be disappointed to see a 404, 500 or service unavailable. But you are happy, because no service, no vulnerability...
If you don't want network equipment with open CVE, I doubt you will ever find a vendor.
But: If you could provide a CVE with a real world example hor it will affect the security, I am sure the GL.iNet Team will take this very serious and finds a solution.
Even for older versions, often Backport fixes exist. Nice generalisation, isn't it?
Edit: But I am just a user. Maybe the GL.iNet stuff agrees to you and analyses every CVE. See for example: GLDDNS Google Indexing - #20 by alzhao
2 Likes