OpenWrt: Updates close security holes in router operating system

In the open-source Linux operating system OpenWrt, developers have fixed two security vulnerabilities. These flaws could potentially allow the injection and execution of malicious code as well as privilege escalation. The vulnerabilities are considered highly critical. Anyone using OpenWrt should therefore install the updated images.

The developers have fixed the vulnerabilities in OpenWrt version 24.10.4 and later. Snapshot builds since October 18, 2025, include the patches, while the ltq-ptem driver was corrected on October 15. According to the project, all older OpenWrt versions are vulnerable. However, OpenWrt versions such as 23.05 or 22.03 have reached end-of-life and therefore no longer receive security updates.

Source: OpenWRT: Updates Close Security Vulnerabilities in Router Operating System | heise online

3 Likes

@alzhao and @bruce please mark this as highest priority (critical) and update especially OP24 version, since it seems to be most affected

1 Like

Isn’t this update referring to the Vanilla openwrt?
Is gl.inet FW 4.8.3 vulnerable too?

I believe all OpenWrt routers are currently vulnerable, and unfortunately, those running version 23.05 won’t receive a fix. Only the latest OpenWrt update fully addresses and patches these security vulnerabilities.

See the description of the second issue:

The vulnerability allows attackers to break out of a ujail sandbox or other restrictions. This only affects the Lantiq build targets with support for xrx200, Danube, and Amazon SoCs (System-on-Chip) from Lantiq, Intel, and MaxLinear.

Which of the GL.iNet routers provides any of the named devices? I know none.

The GL.iNet routers supporting pppoe, but no own (V)DSL Modem. So I don't think this issue will apply here.

The first issue described a local user (aka process), that could use remote code execution.

The only external dependency I know is AdGuard Home… the GL.iNet routers are pretty closed in case of third party plugins. The advice is strongly against upgrading individual packages if you don't know what you are doing.

Yes, the issue still exists. But I want to read a vector where this issue will compromise the security about home/travel router security.

We are examining whether this security hole has any impact on gl routers.

Update:

R&D team has given a plan, the closed-source firmware will merge security patches into future firmware versions, and open-source firmware will upgrade the op version to 24.10.4.

Thank you!

4 Likes

There’s a PoC mentioned here:

I suppose you would have to contact Karsten Sperling as it’s an active exploit that can affect every version of Openwrt below 24.10.4, this include any Openwrt SDKs of lower versions.

I don't know without checking which parts of the firmware are using the ubus and are not trustworthy.

But the Fix seems to be much simpler as explaining the POC: ubusd: Fix out of bounds access in event register message · openwrt/ubus@d31effb · GitHub

I’ll try to find the POC, when I am home again.

From my understanding, the exploit affects DSL and avoiding PTM mode using Ethernet to WAN mitigates the vulnerability. Is this an accurate understanding?

As far as I read, one of the two vulnerability is targeting DSL(?) drivers. So I am afraid, the question is not if you use them, rather if they are available in the image, can be loaded and used malicious.

1 Like

If they are loaded and used maliciously then the bad actor already has enough permission on your device (likely root given how these are deployed). You have already lost at this point.

Imo, just patch it :slight_smile:

this may be not severe in the sense an attacker can remotely attack you, because it has to be used in a chain attack in order to be effective from what I readed, well you are behind a firewall so that would be one issue.

However this does not mean it is impossible, and one of the issues can be leveraged via goodcloud if one managed to get access on your account.

luci could be exploited and is therefor directly accessible to ucode and api, if they found a way to cause a heap through uhttpd, or luci api they can bypass all permissionable acl protections.

so maybe consider it as a medium issue :slight_smile:

It will not be a urgent issue because I don't see how a malicious actor could leverage it to mass compromise routers, maybe sideload with javascript that can still be a possibility.

1 Like

Read the link from the first post …

This only affects the Lantiq build targets with support for xrx200, Danube, and Amazon SoCs (System-on-Chip) from Lantiq, Intel, and MaxLinear.

I don’t see any lantiq in /lib/modules/ or /lib64/modules/ … So the module could not be loaded, so a potential attacker has no surface to attack.

root@eva251:~# ls /lib/modules/5.4.213/ | grep -i lantiq
root@eva251:~# ls /lib64/modules/5.4.213/ | grep -i lantiq

But this are only modules. Maybe the driver is compiled into the kernel? Lets check:

root@eva251:~# zcat /proc/config.gz | grep -i lantiq
# CONFIG_NET_DSA_LANTIQ_GSWIP is not set

no, it isn’t …

I agree an expert on the GL.iNet Kernel or OpenWrt should take a look as well. But I don’t see a reason to panic here, since it seems the vulnerable part isn’t even compiled into the kernel we are using.

1 Like

I understand this. I was only stating if a module existed and wasn’t loaded and an attacker loaded the module to exploit it it doesn’t make sense as an attack vector. If they already have access to a device, and have permissions needed to load a kernel module, you are already in a lot of trouble. Already, as you stated, the GL products are not listed as vulnerable. You can move on with your life now and worry about other vulns :).