Firmware-update: OpenWrt 25.12.1

OpenWRT logo (79 pix) Versie 25.12.1 van OpenWrt is uitgekomen. OpenWrt is alternatieve opensourcefirmware voor een groot aantal verschillende routers en embedded devices. Door middel van het apk-packagemanagementsysteem is er de mogelijkheid om zelf te bepalen wat de router allemaal wel en niet kan. Ook op GoT zijn er diverse mensen actief mee bezig: zie daarvoor dit topic. Bijwerken van de versie kan met een Attended Sysupgrade, handmatig met een voorgecompileerde firmwareversie van het apparaat dat je gebruikt of compileer je eigen variant met de firmwareselectie. De changelog voor deze uitgave kan hieronder worden gevonden.

Security fixes

OpenWrt components (Trail of Bits audit, February 2026):

LuCI:

Additional hardening from the same Trail of Bits audit (no CVE assigned):

  • odhcpd: fix stack buffer overflow in DHCPv6 Identity Association logging
  • procd: fix out-of-bounds write in cgroup path building and cgroup rule application
Device support
  • airoha: fix EN7581 PCIe initialization and add x2 (2-lane) link support — improves PCIe reliability and unlocks full bandwidth for affected devices
  • ath79: TP-Link RE355 v1, RE450 v1/v2: fix partition alignment to prevent configuration loss on sysupgrade
  • ipq40xx: Devolo Magic 2 WiFi next: enable device support
  • ipq40xx: re-enable MeshPoint.One target
  • ipq806x: AP3935: fix U-Boot NVMEM layout
  • lantiq: fix GPIO expander clock (gpio-stp-xway) — restores correct LED and GPIO behaviour on affected devices
  • lantiq: fix missing WAN MAC address assignment on some devices
  • mediatek: Cudy M3000: add support for hardware variant with Motorcomm YT8821 PHY (previously only the Realtek PHY variant was supported)
  • mediatek: TP-Link BE450: fix 10GbE PHY reset timing that caused intermittent boot stalls, add missing WLAN toggle button, fix reported memory size
  • microchipsw: Novarq Tactical 1000: fix swapped SFP I2C buses for ports 1 and 3 — fixes SFP EEPROM read failures
  • ramips: Keenetic KN-1910: fix sysupgrade functionality
  • realtek: RTL838x-based switches: fix non-functional reboot
  • treewide: Linksys devices: fix MAC address assignment
WiFi fixes and improvements
  • mac80211: fix crash triggered by Channel Switch Announcement (CSA) when AP VLAN interfaces are in use
  • mt76: add MT7990 firmware support (new MediaTek WiFi 7 chipset)
  • mt76: mt7915: fix power save mode handling
  • mt76: mt7921/MT7902: add MT7902e MCU and DMA layout support
  • mt76: mt7996/mt7992: fix crash in transmit path, fix out-of-bounds access during hardware restart, improve MLO/CSA and radar detection support
  • wifi-scripts: fix incorrect VHT160 capability advertisement — was incorrectly set on non-160 MHz AP configurations, degrading station upload speed (#22435)
  • wifi-scripts: fix malformed wpa_supplicant config when 802.1X EAP credentials (identity, password, certificates) contain spaces (#22212)
Web interface (LuCI) and system fixes
  • luci-mod-network: fix XSS vulnerability in WiFi scan modal (CVE-2026-32721)
  • ustream-ssl (OpenSSL variant): fix use-after-free crash causing uhttpd (the LuCI web server) to crash under high load (#19349)
Networking and system fixes
  • firewall4: set as the preferred firewall package over the legacy firewall package
  • iptables: prefer the nftables-backed variants (iptables-nft, ip6tables-nft) when iptables is pulled in as a dependency
  • kernel: CAKE QoS scheduler fixes — avoid unnecessary synchronization overhead when running without a rate limit, fix DiffServ rate scaling
  • kernel: SFP: improve Huawei MA5671a module support — module is now accessible even when no fiber is connected
  • odhcpd: fix segfault when disabling a DHCP interface, fix DHCPv4 lease tree corruption, fix truncated field in DHCPv6 lease queries, fix DNS search list padding
  • ppp: fix potential memory safety issue (undefined behavior in memcpy with overlapping buffers); remove the MRU limit patch for PPPoE connections (#573)
Package manager (apk)
  • apk: update to version 3.0.5 with several OpenWrt-specific bug fixes
  • apk: add --force-reinstall option to reinstall already-installed packages without requiring a version change
Core component updates
  • apk: update from 3.0.2 to 3.0.5
  • jsonfilter: update from 2025-10-04 to 2026-03-16 (fixes CVE-2026-30873)
  • libubox: update from 2026-02-13 to 2026-03-13 (ABI version stabilized for 25.12 stable series)
  • Linux kernel: update from 6.12.71 to 6.12.74
  • odhcpd: update from 2026-01-19 to 2026-03-16
  • omcproxy: update from 2025-10-04 to 2026-03-07
  • procd: update from 2026-02-20 to 2026-03-14 (fixes CVE-2026-30874)
  • umdns: update from 2025-10-04 to 2026-02-06 (fixes CVE-2026-30871, CVE-2026-30872)
  • ustream-ssl: update from 2025-10-03 to 2026-03-01

OpenWrt 19.07

Versienummer 25.12.1
Releasestatus Final
Website OpenWrt
Download https://firmware-selector.openwrt.org
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

18-03-2026 • 14:09

24

Submitter: topper007

Bron: OpenWrt

Update-historie

Reacties (24)

Sorteer op:

Weergave:

Ik ben de ontdekker van CVE-2026-32721: Possible XSS attack via malicious SSID in LuCI WiFi scan modal. Ik heb een proof of concept gemaakt die hiermee een persistent remote root shell geeft. Mits je in range bent, met twee custom SSIDs, op het moment dat de admin de scan-pagina opent: https://mxsasha.eu/posts/openwrt-ssid-xss-to-root/
Tof werk van je! Ook leuk om te lezen dat OpenWRT in één dag na je melding je fix had opgenomen. Fijn dat je schrijft deze samenwerking als makkelijk prettig hebt ervaren. Zo hoort het (y)

Thnx voor het veiliger maken van OpenWRT.
Wellicht kun je dat aanvullen hier:
https://openwrt.org/advisory/2026-03-18-5

Deze pagina heeft namelijk geen content.
Het was de enige link waarop ik klikte in het overzichtr van OpenWRT.
Dat was de enige interessante CVE die potentieel extern gevaarlijk is.
Dank voor het identificeren van het gevaar.
Ik vind het wel knap dat mensen hiermee durven te werken. Zelf ben ik daar toch wat terughoudender in. Vaak denk ik: waarom zou je een alternatieve firmware zoals OpenWrt gebruiken als er al iets standaard op je router staat? Die drempel zit voor mij vooral in het gevoel dat je iets “kapot” kunt maken. Niet zozeer hardwarematig, maar softwarematig, dat je router ineens niet meer opstart en je daar zit met een soort digitale baksteen. En dan ben je weer uren bezig om het recht te zetten.

Aan de andere kant snap ik het ook wel: OpenWrt geeft je meer controle, langere ondersteuning en vaak betere beveiliging. Het is eigenlijk de “pro mode” van je router. Maar ja… dat betekent ook dat jij ineens degene bent die alles moet snappen, fixen en onderhouden. En daar moet je maar net zin in hebben (en de tijd).

Ik was al trots toen ik band-steering ontdekte en apparaten een beetje kon sturen naar de juiste band 😄 Laat staan dat ik firmware ga flashen alsof ik een netwerkengineer ben.
Vaak denk ik: waarom zou je een alternatieve firmware zoals OpenWrt gebruiken als er al iets standaard op je router staat?
Meer functionaliteit uit bestaande hardware halen. Langere ondersteuning. Een uniforme managementinterface, zelfs met hardware van verschillende fabrikanten. Ik draai OpenWRT met name op access points en managed switches. Als het geen OpenWRT ondersteunt, dan ben ik niet geïnteresseerd. Voor serieuze routers gebruik ik OPNsense.
Die drempel zit voor mij vooral in het gevoel dat je iets “kapot” kunt maken.
Iets slopen is de eerste stap naar leren hoe je dingen kan repareren. De meeste bricks zijn te herstellen d.m.v. een low-level firmware recovery procedure, soms via TFTP, soms via UART (direct op de SoC gebaseerd op ROM code, dus robuust). Als dat niet kan, dan kan je terugvallen op andere zaken, zoals een flash chip direct benaderen met een testclip en iets als een Raspberry Pi.

[Reactie gewijzigd door The Zep Man op 18 maart 2026 15:11]

Ik ben dezelfde mening en ervaring toegedaan. Ik draai al jaren OpenWRT, LEDE en daarna weer OpenWRT op mijn routers. Er is een goede wiki met veel uitgewerkte onderwerpen en er is een zeer actieve community die elkaar helpt.

Ik heb veel geleerd door fouten te maken. Backups zijn eenvoudig te maken en terug te zetten. Met de juiste hardware (die is populair binnen de community) is een softbrick eenvoudig te herstellen. Ik heb inmiddels een goedkoop Intel (x86) micro Pc-tje als OpenWRT router in gebruik en de nodige tweedehands routers als access point. Ik had ook een Unifi/Ubiquiti setup kunnen kiezen, maar daar hangt een ander prijskaartje aan. Een aantal routers met OpenWRT als access point heeft me veel kennis gebracht.

Docker is bijvoorbeeld ook prima te draaien op OpenWRT. En die continue doorontwikkeling in functionaliteit en beveiliging spreekt me zeer aan.
nieuws: Odido-router stuurde analyticsdata naar Turks AI-bedrijf - update

Is al reden genoeg om je 'standaard' provider-router het raam uit te gooien en te vervangen met een router waar je OpenWRT op kan zetten.
Inderdaad. Opnsense VM hier en OpenWRT, precies om dit soort onzin.

Overigens is de 25.12.1 aangekondigd. Hij is nog niet te downloaden of te upgraden. Zal morgen wel worden. Voor eenieder die foutmeldingen op de attended upgrade service of firmware builder krijgt.

[Reactie gewijzigd door __fred__ op 18 maart 2026 14:49]

Is morgen (de 19e) inderdaad.
Wel slordig dat je vandaag al de melding in OpenWrt zelf krijgt.
Ook leuk om te weten, de standaard routerfirmware van de T-56 support 802.11r doodleuk niet. Met OpenWRT kun je daar wel gebruik van maken.
Je hoeft de 'standaard' provider-router van Odido niet uit het raam te gooien.

Via deze guide kan je openwrt op je Zyxel t56 in dual boot installeren.
Soms wordt de firmware van de fabrikant niet meer gesupport. Met Openwrt kan dan toch een veilig stuk hardware neergezet worden.
Mijn TP Link router was erg onstabiel. Met OpenWRT draait het ding al jaren lang probleemloos.
Ik zou zeggen, probeer het eens. De documentatie van OpenWrt is normaal gesproken prima en de uit-de-doos settings zijn goed (en veilig) voor normaal thuisgebruik.

Meestal kan je voor weinig wel een ondersteunde router op Marktplaats of iets vinden.

Even checken in de Table of Hardware en gaan... ;)
https://openwrt.org/toh/views/toh_available_16128_ax-wifi
Ik ga zelf ook niet solderen aan een router als dat nodig is voor het kraken, en ik heb ook de skills en de apparaten niet om via een seriële bus de router te unlocken. Tegelijkertijd: we zitten op Tweakers, dus een beetje tweaken zou voor de meesten hier niet gek moeten zijn.

Dat gezegd hebbende:
  • Op de meeste routers upload je gewoon een firmwarebestand via de update-interface van de fabrikant. Vervolgens is er een web-interface van OpenWRT die zich grotendeels vanzelf wijst voor het gebruik van 90% van de mensen
  • De router van mijn provider ga ik inderdaad niet flashen: die moet nog terug. Ik heb dus voor een paar tientjes een extra apparaat gekocht. Nu hoef ik bij het wisselen van provider niet elke keer mijn netwerk opnieuw in te stellen. Dan kun je dus ook rustig vooraf doen, en dan pas in je netwerk hangen. Geen haast, geen paniek als het niet in 1x goed gaat.
  • "alles moet onderhouden". OpenWRT heeft ongeveer 6 releases per jaar die je kunt installeren. Ik installeer ook updates op mijn laptop en op mijn telefoon.

[Reactie gewijzigd door marcieking op 18 maart 2026 15:19]

In veel gevallen krijg je door OpenWRT te plaatsen op een "oude" maar goede router als resultaat een BETERE router dan zeker een nieuwe goedkope router, dus waarom niet :)

Veel merken houden hun meer geavanceerde functie's voor hun "dure" modellen, alhoewel de hardware van een goedkopere dat ook allemaal zou kunnen, met zaken zoals OpenWRT en Gargoyle unlock je alle power van je router waar je voor betaald hebt.
Out of the box werkt OpenWrt al prima als standaard router. Updaten is niet lastiger dan bij commerciële routers. De extra functionaliteit kun je gebruiken maar hoeft niet. Daar tegenover staat langere ondersteuning, geen backdoors en geen dataverzameling zonder dat je het weet.
Je kan het ook zo zien: een keer dat je openwrt onder de knie hebt, moet je bij een nieuwe router nooit meer wennen aan hoe je iets moet instellen. En het flashen is vaak heel eenvoudig, hangt wel af van het model. Ook de recovery in het geval dat het mis zou gaan kan lastiger zijn met jtag of serieel...maar ik heb het nog niet nodig gehad en toch al tiental verschillende types op Openwrt omgeflashed.

[Reactie gewijzigd door Clemens123 op 18 maart 2026 19:34]

Je kan OpenWRT testdraaien op een RPI. (die heeft ook Wifi die als AP gebruikt worden).
OpenWRT bevat daarnaast ook een safeguard wanneer je tricky settings aanpast (zoals het IP van het device): als je niet binnen de 2 minuten op het nieuwe adres inlogt, dan springt het ding automatisch terug naar de oude settings. Ook de reset butten werkt ;).

Als je heel erg veilig wilt spelen, kan je altijd een device kiezen met een seriele poort, (zoals RPI via de pinheaders). Zo kan je ook zonder IP access zien wat er mis is en de settings opnieuw fixen. De openwrt wiki bevat een lange lijst van apparaten die ondersteund zijn.
Ik heb OpenWRT naar volle tevredenheid draaien op twee TP-Link Archer C7 (v2.0). Eentje als router en de ander als accesspoint.

Tip 1: Zet "Software flow offloading" aan, de doorvoersnelheid wordt hierdoor een stuk hoger.
Deze instelling kun je vinden onder Network > Firewall.

Tip 2: De volgende twee instructie videos van OneMarcFifty laten je veel informatie zin over hoe OpenWRT in te stellen (een complexere setup met meerdere VLANs):
How to configure OpenWrt as Firewall for your home network and Guest Wifi and IPTables explained
extend a guest wifi on second access point with OpenWrt using VLANs
FYI: om meerdere VLANs en WIFI SSIDs op meerdere apparaten te configureren heb ik ook een tooltje gemaakt:
https://github.com/rubenbe/opensoho/

Het helpt je in het makkelijk configureren van meerdere APs. (Al is 2 echt wel het minimum waar het nuttig wordt ;) )
LET OP!

Ik heb vandaag al mijn OpenWRT devices geupgrade. De access points gingen probleemloos maar mijn router (helaas) niet, kreeg geen WAN IP adres meer toegewezen vanuit mijn ISP (Odido).

Na even zoeken blijkt dit een groter issue te zijn met OpenWRT 25.12. Bij DHCP wordt nu een client ID meegestuurd. Dit zou optioneel moeten zijn volgens de standaarden, is niet uit te schakelen en levert problemen op met sommige DHCP servers die daar niet mee om kunnen gaan. Gelukkig is er wel een workaround beschikbaar (daarvoor moet je zelf een wijziging doorvoeren in /lib/netifd/proto/dhcp.sh).

Zie ook deze pagina's:
https://forum.openwrt.org/t/no-internet-after-25-12-upgrade/247491/15
https://github.com/openwrt/openwrt/issues/21671#issuecomment-3864793680

[Reactie gewijzigd door [BoSS] op 20 maart 2026 12:35]

Ja, ik las het ook inderdaad. Mijn Flint2 (GL-MT6000) kan ik helemaal niet upgraden.

Ik krijg de melding dat het image corrupt is en dat er geen diskspace beschikbaar is. Helaas ben ik niet de enige, maar dat een upgrade een issue gaf is voor mij echt lang geleden. Ik heb zelf een image gemaakt, maar eigenlijk was dat niet nodig. 25.10.0 was prima voor mij, en op het vlak van CVEs was er voor mij persoonlijk niet veel belangrijks te fixen.

Om te kunnen reageren moet je ingelogd zijn