Can you trust your router? GL.iNet, OpenWrt, and where it can go wrong

Can you trust your router? GL.iNet, OpenWrt, and where it can go wrong

Who this guide is for

For readers considering (or already using) a GL.iNet router who are wondering whether “runs OpenWrt” is the same thing as “safe.” Also relevant if you’ve come across a cheap OpenWrt-style travel router on AliExpress and aren’t sure how to judge it. This guide is about how to evaluate trust in a brand, not “which brand is bad.”

What this guide solves and doesn’t

This isn’t a final verdict on GL.iNet, and not a blacklist of brands. No router is risk-free, and nobody can prove hardware or firmware trust with absolute certainty. What this guide does do: show which questions actually matter, what you can check yourself, and why “Chinese brand” or “runs OpenWrt” are both too simple to rely on alone.

The practical default

For most readers, GL.iNet remains the reasonable choice in its price class — not because it’s risk-free, but because it’s the most transparent option that’s also usable and affordable. The rest of this guide explains why, and where the honest limits of that recommendation sit.

Why “it runs OpenWrt” isn’t a guarantee

“This router runs OpenWrt” often gets treated as the end of the conversation: open source, therefore safe. That’s a misconception. OpenWrt is the software layer — but a router has more layers than that:

• The application layer (the management UI, cloud features, extra tooling) — this is where a vendor most easily adds something you don’t want.
• The WiFi chip firmware — almost always closed source, regardless of which OS runs above it.
• The hardware itself — what’s actually on the board, regardless of what software you put on it.

A router can be OpenWrt-based and still unsafe, and a router can run closed firmware and still be fine — it depends on what happens in each layer, not the label. This is also the exact conclusion of our earlier look at the US router-ban debate: flag and brand name are weak shortcuts, behavior and control tell you more.

GL.iNet as a case study: what argues for trust

GL.iNet is an established company (since roughly 2015/2016), sold through official channels with real support — not an anonymous storefront-only name. A few concrete signals that matter:

• A public security-advisory program. GL.iNet publishes its own CVEs with dates and detail — recently including an unauthenticated remote code execution via SID bruteforce, missing input validation, and command injection. That sounds alarming, but it’s actually a good sign: issues get disclosed and patched rather than hidden. A brand with zero ever-reported CVEs is more often unaudited than perfectly secure.
• Firmware based on OpenWrt, with their own layer on top — not a fully closed fork nobody can inspect.
• Years of community scrutiny — but per model, not automatically for every new product. This isn’t a vague signal: SRLabs, a respected German security research firm, builds and maintains blue-merle, a real anonymity-hardening package (IMEI/MAC/BSSID randomization, forensic log wiping) specifically for GL.iNet’s older 4G Mudi (GL-E750). That’s serious, named independent scrutiny, not just hobbyist chatter. But the newest flagship — the Mudi 7 (GL-E5800), only a couple of months on the market — hasn’t had that depth of attention yet: there’s an open, unresolved GitHub issue asking whether SRLabs will extend blue-merle to the Mudi 7 too. Community trust is real for GL.iNet as a track record, but it builds up per model — a brand-new product simply hasn’t had that scrutiny yet.

The honest complication

Two things that shouldn’t be glossed over:

• GL.iNet is a Chinese company (Hong Kong/US presence), which puts it under China’s National Intelligence Law — which can legally compel companies to cooperate with state security requests. That’s not theoretical, and it applies to any Chinese hardware brand, not specifically to GL.iNet.
• An old, never-resolved OpenWrt forum thread alleged that GL.iNet firmware was leaking DNS requests to Chinese domains (chinauos.com/uniontech.com), even with DNS-over-TLS and a VPN active. Nobody ever produced reproducible proof, and GL.iNet never issued a clear public response. That’s not a confirmed leak — but it’s not a debunked claim either. Unresolved, not disproven.

Can you verify this yourself?

Yes, to a degree — through layered methods, none of which is conclusive on its own:

1. Hash the WiFi firmware blob and compare it against the chip vendor’s own official release (for example via the linux-firmware project, which OpenWrt itself pulls from). If the hash matches exactly, you’re now trusting the chip vendor (Qualcomm/MediaTek) instead of GL.iNet — that narrows the trust surface, it doesn’t eliminate it.
2. Monitor network traffic from a separate device on the same network segment, with every OpenWrt-side feature disabled. This catches active “phone home” behavior, not something waiting for a trigger.
3. Physical teardown / PCB inspection, ideally against a published schematic or reference unit — hobbyists have already done this for GL.iNet hardware.
4. Years of unpaid community scrutiny (see above) — not a technical test, but a real signal.

The honest epistemic point: you can never prove the negative. There’s no way to cryptographically prove a backdoor doesn’t exist — you can only stack independent layers of evidence until the residual doubt is small enough to act on. That fits this site’s core conclusion: no brand is flawless, some brands just handle flaws better.

Could a backdoor come through the WiFi firmware, even without GL.iNet’s own software?

Yes — and this is the less obvious, more serious risk. Research from Google Project Zero (“Over The Air,” 2017) showed that Broadcom WiFi chips could write directly into the host’s RAM over PCIe — bypassing the operating system entirely, with no ASLR protection. That means a compromised WiFi firmware blob isn’t just “the radio is untrustworthy” — it can mean full device compromise, invisible to anything OpenWrt itself can see.

This is exactly why flashing vanilla OpenWrt doesn’t close this gap — the blob stays, regardless of what runs on the main chip.

Flashing vanilla OpenWrt: a real middle step, not a fix

Many GL.iNet models officially support flashing “vanilla” (unmodified) OpenWrt instead of their own firmware. That removes GL.iNet’s own application layer — the layer most likely to carry a backdoor or unwanted telemetry — and replaces it with firmware built through the OpenWrt project’s own, publicly reviewable process.

This doesn’t hold automatically for every model. The Mudi 7 specifically — 5G plus WiFi 7, both on Qualcomm Dragonwing silicon — currently has no official upstream OpenWrt support. The OpenWrt forum itself confirms this depends on whether Qualcomm ever releases open drivers, with no committed date. Newer, more complex combo devices (5G + WiFi 7 in one chip family) are a genuinely different situation from a simpler, longer-established model — check per model, not per brand, whether vanilla OpenWrt is actually available.

What it doesn’t fix: the WiFi driver on GL.iNet hardware is closed source, and stays that way after flashing vanilla OpenWrt — the OpenWrt community itself notes there’s no guarantee the open driver is even stable, let alone auditable. On models with a 4G/5G modem, the same applies to the modem firmware.

Conclusion: a real, meaningful improvement — not a way to bring the risk to zero.

The red flags: unbranded AliExpress routers

The bigger practical risk isn’t GL.iNet — it’s the anonymous “OpenWrt-style” travel routers sold on AliExpress under shifting brand names. Concretely, watch for:

• No findable company behind the name — no real website, no support channel, just an AliExpress storefront.
• No security advisory ever published — not because the brand is flawless, but because nobody’s ever checked, or the brand reports nothing.
• Unverifiable firmware claims — “based on OpenWrt” with no source, no build process, no way to check.
• No accountable jurisdiction — if something goes wrong, there’s nobody to hold responsible.
• Store rating isn’t a security signal — a 4.8-star AliExpress storefront tells you about shipping speed and customer service, nothing about firmware safety. This matches a real, documented pattern: research into counterfeit network hardware has repeatedly found hardcoded credentials and undocumented remote access in cheap, unbranded gear.

A real EU alternative already exists: Turris

If the question is “could a European company solve this by rebranding GL.iNet” — the answer is: rebranding alone is cosmetic unless the company also builds and controls the firmware itself. But the stronger model already exists, and goes further than rebranding: Turris, made by CZ.NIC (the Czech Republic’s national domain registry — not an anonymous vendor, but an established, publicly accountable organization).

• Hardware actually manufactured in the Czech Republic, not just designed in the EU and built in China.
• Firmware (Turris OS, OpenWrt-based) fully open source on GitHub.
• Pen-tested by the Czech national CSIRT, no critical vulnerabilities found.
• Its own transparently-disclosed CVE history (a Qualcomm WiFi chip flaw, an OpenSSL bug) — the same “real issues, disclosed properly” signal as GL.iNet, now backed by actual EU jurisdiction and EU manufacturing.

The honest limitation: Turris only makes home/business routers (Omnia, Omnia NG, the modular MOX line) — no compact travel router, and pricing sits clearly above GL.iNet’s entry tier. For travel use, there currently isn’t a full EU-made equivalent in the same price class — a real, still-unfilled gap, not something to paper over.

The practical checklist

Applicable to any brand, including one neither of us has checked yet:

• Is there a findable company with a track record behind the name?
• Does the brand ever publish security advisories/CVEs, or is it silent?
• Is the firmware (partly) open source and checkable?
• Does the device support flashing independent firmware?
• Is there years of independent community scrutiny for this specific model?
• Where is it manufactured, and does that change the trust chain for your situation?

When the stronger setup is worth it

For most home users, GL.iNet with stock firmware, a strong password, and unnecessary cloud features disabled (see the network threat profile guide) is more than enough. Consider the step to vanilla OpenWrt or Turris if:

• you have a specific, concrete reason to distrust a given vendor (e.g. a profession with a real geopolitical threat model)
• you already have the technical skill and interest to flash and maintain your own firmware
• Turris’s higher price and lack of a travel form factor aren’t a problem for your use case

For most readers, this is overkill — and that’s a perfectly valid conclusion to land on.

Next step

Want to go further?

• Network threat profile guide — what level of network security actually fits your situation
• GL.iNet Beryl 7 review — a practical pick within GL.iNet’s lineup
• What this router ban reveals about real router security — the broader brand-vs-behavior discussion