OpenWrt 25.12.6

Hi,

The OpenWrt community is proud to announce the sixth service release of the OpenWrt 25.12 stable series.

Download firmware images using the OpenWrt Firmware Selector:

Download firmware images directly from our download servers:

Main changes between OpenWrt 25.12.5 and OpenWrt 25.12.6 =========================================================

Only the main changes are listed below. See the full changelog for details.

Security fixes ==============

This release fixes several remotely triggerable vulnerabilities in core network services that are enabled by default. Updating is strongly recommended.

• uhttpd (web server, enabled by default with LuCI): uhttpd was updated to a newer version that fixes five published advisories, all reachable without authentication:
• CVE-2026-102338 (High): memory-exhaustion denial of service caused by an unlimited number of HTTP request headers. https://github.com/openwrt/uhttpd/security/advisories/GHSA-vhx4-3p5q-m59q
• No CVE assigned (High): out-of-bounds write caused by a type confusion of the params field in POST /ubus/call/ requests. https://github.com/openwrt/uhttpd/security/advisories/GHSA-2mpg-6wp5-435p
• No CVE assigned (High): unlimited memory growth, because the URL path was leaked on every non-POST /ubus request. https://github.com/openwrt/uhttpd/security/advisories/GHSA-83vv-qrc6-h3hx
• No CVE assigned (Moderate): HTTP request smuggling (CL.0), because a keep-alive connection was reused while a request body was still unread. https://github.com/openwrt/uhttpd/security/advisories/GHSA-c2wg-hcff-hqrm
• No CVE assigned (Moderate): a leaked client reference on /ubus/subscribe/ could permanently block the listener. https://github.com/openwrt/uhttpd/security/advisories/GHSA-wvgh-cm54-q6f6
• No CVE assigned (High): Basic Auth realms configured for a URL prefix were not enforced for Lua and ucode handlers below that prefix. Only relevant if Basic Auth realms are configured in uhttpd. https://github.com/openwrt/uhttpd/security/advisories/GHSA-5cgm-8h9x-v28c
• Mbed TLS (default TLS library): update to 3.6.7, fixing multiple security vulnerabilities, including a remote buffer overflow in (D)TLS with ECDHE-PSK cipher suites (CVE-2026-25832, CVE-2026-35336, CVE-2026-49300, CVE-2026-50579, CVE-2026-50580, CVE-2026-50581, CVE-2026-50583, CVE-2026-50584, CVE-2026-50585, CVE-2026-50586, CVE-2026-50587, CVE-2026-50588, CVE-2026-50640, CVE-2026-50713, CVE-2026-54435, CVE-2026-54441). Mbed TLS is used by default, for example for HTTPS in uhttpd and in hostapd / wpa_supplicant.
• hostapd / wpa_supplicant (WiFi):
• No CVE assigned: fixes from the hostapd security advisory 2026-1 for missing validation when parsing multi-link (MLO, WiFi 7 / IEEE 802.11be) information. Invalid management frames sent without authentication could crash hostapd or wpa_supplicant or cause small memory corruption. In access point mode, only devices with WiFi 7 (802.11be) support are affected. In client mode, wpa_supplicant is affected in general. https://w1.fi/security/2026-1/
• No CVE assigned (Moderate, CVSS 6.5): NULL pointer dereference in the APuP (Access Point Micro-Peering) beacon handling. A nearby attacker could crash hostapd by sending beacons from many spoofed BSSIDs. Only relevant if APuP is enabled (option apup, disabled by default). https://github.com/openwrt/openwrt/security/advisories/GHSA-78g5-4g76-r6jh
• In builds using Mbed TLS, the check_cert_subject EAP server certificate check read uninitialized memory and could accept a certificate whose subject only matched as a prefix.
• rpcd (LuCI backend, enabled by default with LuCI): two privilege escalation issues were fixed. They only matter on systems with additional LuCI users with limited (delegated) permissions:
• No CVE assigned (High, CVSS 8.4): file operations followed symbolic links. A symlink in a directory covered by the user's ACL allowed reading or writing any root-owned file, such as /etc/shadow. https://github.com/openwrt/openwrt/security/advisories/GHSA-q5gr-86pq-vvwr
• No CVE assigned (High, CVSS 7.0): the session token was used as the name of a temporary UCI directory. A restricted user could read the token of a more privileged session and use it to run commands as root. https://github.com/openwrt/openwrt/security/advisories/GHSA-r2w2-q7cw-cfp2
• cgi-io (enabled by default with LuCI): No CVE assigned (Moderate, CVSS 4.3): use-after-free when decoding malformed percent-encoded POST data. https://github.com/openwrt/openwrt/security/advisories/GHSA-wvhq-qmwj-grj2
• LuCI applications and packages: several issues were fixed that let a logged-in user with limited (delegated) permissions run commands as root or store cross-site scripting (XSS) payloads. They only apply if the affected app is installed and the account/ACL in question exists:
• ser2net / luci-app-ser2net (Critical, CVSS 9.9): a newline in a UCI option could add an extra ser2net connection that runs commands as root. https://github.com/openwrt/packages/security/advisories/GHSA-w6q2-vr4f-49x3
• luci-app-lxc: path traversal and an ACL bypass allowed logged-in users without the LXC permission to get root access on the host (no advisory published).
• luci-app-ddns / ddns-scripts: delegated DDNS users could run commands as root through the date format and other DDNS settings, which were passed to the shell without quoting (no advisory published).
• luci-app-nut: delegated users could configure NUT notification commands that run as root. Write access is now limited to the admin user (no advisory published).
• luci-app-adblock-fast (Moderate, CVSS 5.4): stored XSS in the status page through blocklist names. https://github.com/openwrt/luci/security/advisories/GHSA-q335-4c83-c88h
• luci-app-https-dns-proxy (Moderate, CVSS 4.5): stored XSS in the status page through the resolver URL. https://github.com/openwrt/luci/security/advisories/GHSA-c6vf-395q-4jv6
• luci-base: the URL path and user name are now escaped when logging, so crafted login requests can no longer inject text into the system log.
• umdns (mDNS daemon, optional package): two out-of-bounds reads reachable by any host on the local network with crafted mDNS packets were fixed:
• No CVE assigned (Moderate, CVSS 5.4): out-of-bounds read in dns_query(). https://github.com/openwrt/openwrt/security/advisories/GHSA-j2f2-273j-r86h
• No CVE assigned (Moderate, CVSS 4.3): uninitialized byte and out-of-bounds read on cached TXT records. https://github.com/openwrt/openwrt/security/advisories/GHSA-fc92-h6gc-rjjx
• ead-client (Emergency Access Daemon client): No CVE assigned (Low): out-of-bounds writes when handling spoofed server replies. ead-client is not installed in the images, only the daemon is. https://github.com/openwrt/openwrt/security/advisories/GHSA-mq4v-mf82-24rr https://github.com/openwrt/openwrt/security/advisories/GHSA-8f8g-5c8x-8mhh
• Linux kernel: update to 6.12.112, pulling in the upstream 6.12.95 through 6.12.112 stable releases, which fix multiple security vulnerabilities.
• OpenSSL: update to 3.5.9, fixing multiple security vulnerabilities (CVE-2026-14456, CVE-2026-14457, CVE-2026-18798, CVE-2026-35189, CVE-2026-35191, CVE-2026-42772, CVE-2026-54872, CVE-2026-54873, CVE-2026-54874, CVE-2026-54875, CVE-2026-63072, CVE-2026-63073, CVE-2026-63074, CVE-2026-63075, CVE-2026-63076, CVE-2026-72897, CVE-2026-75803, CVE-2026-75804, CVE-2026-75805, CVE-2026-75806, CVE-2026-77696, CVE-2026-84782, CVE-2026-84784). An OpenWrt-specific patch that made AES-GCM-SIV accept forged authentication tags for zero-length messages was also corrected.
• wolfSSL: update to 5.9.4, fixing multiple security vulnerabilities (CVE-2026-6091, CVE-2026-6092, CVE-2026-6094, CVE-2026-6291, CVE-2026-6325, CVE-2026-6329, CVE-2026-6330, CVE-2026-6331, CVE-2026-6412, CVE-2026-6450, CVE-2026-6678, CVE-2026-6679, CVE-2026-6681, CVE-2026-6731, CVE-2026-7511, CVE-2026-7531, CVE-2026-7532, CVE-2026-8720, CVE-2026-10097, CVE-2026-10098, CVE-2026-10512, CVE-2026-10592, CVE-2026-11310, CVE-2026-11703, CVE-2026-11999, CVE-2026-12340, CVE-2026-55958, CVE-2026-55960, CVE-2026-55961, CVE-2026-55962, CVE-2026-55964, CVE-2026-55967 and further issues fixed in 5.9.4).

Many optional packages in the packages feed were also updated to new versions with security fixes, among them curl 8.22.0, OpenSSH 10.6p1, unbound 1.26.1, BIND 9.20.29, OpenVPN 2.7.7, strongSwan 6.0.7, HAProxy 3.2.21, expat 2.8.4, nghttp2 1.70.0, libssh 0.12.2, c-ares 1.34.8, Tor 0.4.9.13, Knot DNS 3.5.7, PowerDNS 4.9.17, PowerDNS Recursor 5.2.13, Exim 4.100.1, Python 3.13.15, Node.js 22.23.2, xz 5.8.3 and rsync 3.5.1. These packages are not part of the default images; update the installed packages to get these fixes.

Beyond the issues listed above, this release fixes a number of further security problems for which no CVE number or dedicated advisory was assigned. We strongly recommend upgrading to the latest OpenWrt release and installing all available package updates.

Important changes =================

WiFi: GCMP-256 and SAE-EXT-KEY are no longer offered by default

OpenWrt 25.12.0 to 25.12.5 offered the GCMP-256 pairwise cipher and, in some configurations, the SAE-EXT-KEY key management (SAE with a group-dependent hash, also called SAE-GDH) on WPA3 networks with WiFi 6 (HE) or WiFi 7 (EHT), but not in the way the Wi-Fi Alliance "WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide" describes it. This configuration caused connection problems, for example with Pixel 10 phones (https://github.com/openwrt/openwrt/issues/21486) and with 802.11r Fast Transition (https://github.com/openwrt/openwrt/issues/22200).

The WPA3 specification makes GCMP-256 and SAE-EXT-KEY mandatory for WiFi 7 and recommends them otherwise. When the configuration recommended by the Wi-Fi Alliance was enabled in the OpenWrt development branch, it turned out that about 15% of the client devices in use are not compatible with it. For example:

• Some clients cannot connect when GCMP-256 is offered, already on WiFi 6, for example Nanoleaf devices, a Motorola/Unisoc phone and Linux laptops using iwd.
• With 802.11r Fast Transition enabled, FT-SAE-EXT-KEY prevents some clients from connecting (for example a Samsung Galaxy Tab S10 FE) or makes them reboot shortly after connecting (for example a Poco X6).

See the discussion on the hostap mailing list (https://lists.infradead.org/pipermail/hostap/2026-July/045277.html) and pull request #23009 (https://github.com/openwrt/openwrt/pull/23009) for details.

Starting with 25.12.6, GCMP-256 and SAE-EXT-KEY are no longer offered by default in WPA3-Personal (sae) and WPA2/WPA3 mixed (sae-mixed) mode; only CCMP and plain SAE are offered. The old rsn_override option was removed.

We recommend using WPA3-Personal (sae) or WPA2/WPA3 mixed mode (sae-mixed). If some clients have problems with these modes, use the new WPA3-Personal Compatibility Mode (sae-compat, "WPA2-PSK/WPA3-SAE Compatibility Mode" in LuCI): WPA2 clients see a normal WPA2 network, while clients that support RSN overriding use WPA3.

Only enable GCMP-256 and SAE-EXT-KEY if you need them and if they do not cause problems with your clients. In LuCI, they are on the "Wireless Security" tab of the wireless network as "GCMP-256 pairwise cipher" and "SAE-EXT-KEY (SAE-GDH)". On the command line (replace default_radio0 with the name of your wifi-iface section):

uci set wireless.default_radio0.gcmp256='1'
uci set wireless.default_radio0.sae_ext_key='1'
uci commit wireless
wifi reload

gcmp256 offers GCMP-256 in addition to CCMP, but only if the WiFi driver supports GCMP-256. sae_ext_key offers SAE-EXT-KEY, and also FT-SAE-EXT-KEY when 802.11r is enabled.

DHCP client: the client identifier can be selected

Since OpenWrt 25.12.0, every device generates a random, UUID-based DUID on first boot and stores it in network.globals.dhcp_default_duid. The DHCPv6 client uses it as its DUID, and the DHCPv4 client sends it together with an interface-specific IAID as client identifier (DHCP option 61). This default follows the recommendation of RFC 4361 (https://www.rfc-editor.org/rfc/rfc4361) that DHCPv4 clients use the same DUID as DHCPv6, so the device is identified in the same way for DHCPv4 and DHCPv6. The UUID-based DUID format is defined in RFC 6355 (https://www.rfc-editor.org/rfc/rfc6355). OpenWrt 24.10 sent no client identifier with DHCPv4 and used a DUID-LL derived from the MAC address for DHCPv6. Some DHCP servers, including servers of some ISPs, do not work correctly with the new client identifier, and until now there was no way to go back to the old behavior.

OpenWrt 25.12.6 adds the new per-interface option sendclientid:

• auto (default): use the client ID configured with the clientid option, else the default DUID of the device, else the MAC address. This is the behavior of 25.12.0 to 25.12.5 and follows RFC 4361.
• global: always use the default DUID of the device, even if clientid is set.
• hardware: use the MAC address of the interface (DHCPv4) or a DUID-LL derived from it (DHCPv6).
• none (DHCPv4 only): do not send a client identifier at all.

We recommend keeping the default auto, which matches the behavior of OpenWrt 25.12.5. Only if the DHCP server of your ISP does not work with it, switch back to the behavior of OpenWrt 24.10 by setting none on the DHCPv4 interface and hardware on the DHCPv6 interface:

uci set network.wan.sendclientid='none'
uci set network.wan6.sendclientid='hardware'
uci commit network
service network reload

In LuCI, the option is called "Preferred client ID" and is on the "Advanced Settings" tab of the interface (Network Interfaces Edit). Select "None" for the DHCPv4 interface (wan) and "Hardware address" for the DHCPv6 interface (wan6). Note that the DHCP server sees a changed client identifier as a new client, so you may get a different IPv4 address or IPv6 prefix.