Hi,

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

Download firmware images using the OpenWrt Firmware Selector:

• https://firmware-selector.openwrt.org/?version=25.12.2

Download firmware images directly from our download servers:

• https://downloads.openwrt.org/releases/25.12.2/targets/

Main changes between OpenWrt 25.12.1 and OpenWrt 25.12.2

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

Device support

• airoha: rename kernel module kmod-pwm-an7581 to kmod-pwm-airoha — users with this module explicitly installed need to reinstall under the new name
• apm821xx: fix U-Boot environment definitions for NETGEAR WNDR4700, Western Digital MyBookLive, Meraki MR24 and Meraki MX60; fix PCIe boot failure on Meraki MX60
• ath79: fix initramfs boot for Huawei AP5030DN and AP6010DN
• ath79: fix VLAN CPU port tagging on 2-CPU-port devices (affects several dual-CPU switch configurations)
• ath79: remove incorrectly included WiFi packages from Mikrotik RB750r2 (device has no WiFi hardware)
• ipq40xx: fix ART partition name for Linksys Velop WHW03 V1 — restores correct WiFi calibration data access
• ipq40xx: fix MAC address reading for Linksys devices using eMMC-based NVMEM
• lantiq: xrx200: fix failsafe mode on BT HomeHub 5A — LAN ports 1 & 2 now work correctly in failsafe (#22480)
• mediatek: Bananapi BPI-R4: fix SFP+ electric module support — modules that stopped working after a snapshot upgrade are now functional again (#19878)
• ramips: fix kernel decompress error that bricked ELECOM WRC-X1800GS on 25.12.0 (#22270)
• ramips: fix initramfs kernel load address for TP-Link EAP615-Wall v1
• ramips: fix MAC address assignment for Xiaomi Mi AC2100
• realtek: fix D-Link fan control script

WiFi fixes and improvements

• wifi-scripts: fix 160 MHz channel width configuration — hostapd was not correctly configured for 160 MHz, preventing its use (#22481)
• wifi-scripts: fix SU beamformee antenna count — incorrect count was passed to the driver
• hostapd: fix memory leak in Radio Resource Management (RRM) ubus interface
• mac80211: ath12k: add thermal sensor support for QCA/IPQ devices
• mac80211: ath9k: fix GPIO mask handling from device tree
• mt76: fix severe WiFi latency regression (up to multiple seconds) on 2.4 GHz introduced in 25.12.1 — affected many MediaTek devices including OpenWrt One, Zyxel EX5601, ASUS RT-AX53U, Xiaomi AX3000T/AX6000, Cudy WR3000/X6, GL Flint 2 and others (#22491)
• mt76: multiple further stability fixes for MediaTek WiFi chipsets (MT7615/MT7915/MT7996/MT7992/MT792x):
  • add per-link beacon monitoring for MLO (Multi-Link Operation)
  • fix MT7996/MT7992 link handling during MLO station add/remove
  • fix scan work requeue race with spinlock

Upgrading to 25.12.2

Upgrading from 24.10 to 25.12 should be transparent on most devices, as most configuration data has either remained the same or will be translated correctly on first boot by the package init scripts.
For upgrades within the OpenWrt 25.12 stable series, Attended Sysupgrade is also supported, which allows preserving the installed packages.

• Sysupgrade from 23.05 or earlier to 25.12 is not officially supported.

• Cron log level was fixed in busybox. system.@system[0].cronloglevel should be set to 7 for normal logging. 7 is the default now. If this option is not set, the default is used and no manual action is needed. fc0c518

• Bananapi BPI-R4: Interface eth1 was renamed to sfp-lan or lan4, and interface eth2 was renamed to sfp-wan to match the labels. You have to upgrade without saving the configuration. cd8dcfe

• TP-Link RE355 v1, RE450 v1 and RE450 v2: The partition layout and block size changed in this release to fix configuration loss on sysupgrade. Users upgrading from OpenWrt 25.12.0 or earlier must use sysupgrade -F to force the upgrade. The image must not exceed 5.875 MB (6016 KiB).

• Meraki MX60: Direct sysupgrade to 25.12.2 is not possible without manual preparation — meraki_loadaddr must be changed before upgrading, as the default value is insufficient to boot OpenWrt 25.12+. See the device wiki page for instructions.

Known issues

• Zyxel EX5601-T0: the WAN interface was renamed from eth1 to wan — check and update your network configuration after upgrading.
• Pixel 10 phones have problems connecting to WPA3-protected WiFi 6 APs. #21486
• 802.11r Fast Transition (FT) causes connection problems with some WiFi clients when WPA3 is used. #22200
• SQM CAKE MQ (cake_mq): throughput may be unexpectedly low on some configurations after the scheduler fixes in this release. #22344

Full release notes and upgrade instructions are available at
https://openwrt.org/releases/25.12/notes-25.12.2

In particular, make sure to read the known issues before upgrading:
https://openwrt.org/releases/25.12/notes-25.12.2#known_issues

For a detailed list of all changes, refer to
https://openwrt.org/releases/25.12/changelog-25.12.2

To download the 25.12.2 images, navigate to:
https://downloads.openwrt.org/releases/25.12.2/targets/
Use OpenWrt Firmware Selector to download:
https://firmware-selector.openwrt.org?version=25.12.2

As always, a big thank you goes to all our active package maintainers, testers, documenters and supporters.

Have fun!

The OpenWrt Community

To stay informed of new OpenWrt releases and security advisories, there
are new channels available:

• a low-volume mailing list for important announcements:
  https://lists.openwrt.org/mailman/listinfo/openwrt-announce

• a dedicated "announcements" section in the forum:
  https://forum.openwrt.org/c/announcements/14

• other announcement channels (such as RSS feeds) might be added in the
  future, they will be listed at https://openwrt.org/contact

Backups are one of those quiet, powerful features: when they work, you don’t notice them, but when you need them, they’re everything. We’ve evolved Home Assistant’s built-in backup format over the years to keep it safe and secure, especially when backing up to remote locations. As modern cryptography has advanced, we needed to build a system to match. SecureTar v3 is a purpose-built library for creating and reading password-protected Home Assistant backups with modern cryptography and safer, stronger defaults.

To help us get this right, we commissioned Trail of Bits, a leading security engineering firm, to independently audit our work. Their review found that SecureTar v3 follows best-in-class practices for core security algorithms, such as hashing and encryption. They also identified three areas for improvement, which they confirmed were resolved in their follow-up review. This audit was paid for by the Open Home Foundation so we could invest in improvements that protect users’ privacy, security, and control.

Your backups will start using this new encryption automatically, beginning with the release of version 2026.4 on April 1, 2026. Please note old backups will still work and be readable after this change (see Recommended next steps below). For more technical details, please read on…

A bit of history

Home Assistant backups have always been encrypted by default, and use a high entropy key, to help ensure your data is safe. When we introduced backups, early formats (v1 and v2) used the same AES-128 encryption variant, along with a simple key derivation (the code that turns your passphrase into the actual key used for encryption). Sam Gleske brought to our attention that the key-derivation step was no longer up to modern standards.

It’s worth stressing an important point: Home Assistant’s passphrase generator already produces long, high-entropy passphrases. This means that backups created previously were difficult to break if using this feature. To demonstrate this, we calculated that a brute force passphrase attack (where attackers try many passwords rapidly) on the backups would take more time than the average lifespan of a person to be successful.

Still, because it was possible to manually generate an insecure passphrase for advanced users, and the library’s internal cryptographic primitives could be improved, we decided to overhaul SecureTar to use best-in-class algorithms, and to have that work validated by an external audit.

What we changed and why

The goals were simple: choose modern, well-studied algorithms, avoid design mistakes that could weaken confidentiality or integrity, and make v3 the secure default.

Highlights of the SecureTar v3 design:

• Modern key derivation: SecureTar v3 uses Argon2id for password-based key derivation. Argon2id is a memory-hard algorithm that makes brute-force attacks much more costly.
• Modern encryption and authentication: Encryption is provided by the libsodium secretstream API (exposed in Python via PyNaCl), which implements a robust streaming authenticated-encryption construction using XChaCha20-Poly1305. That combination gives both confidentiality (nobody can read your data) and integrity/authentication (nobody can tamper with it without detection).
• Safer defaults and parsing: We set safer defaults so new backups use v3, and we fixed parsing logic to avoid silently treating corrupt data as valid legacy backups.

We made these choices to ensure that SecureTar is resilient to modern attacks and easier to reason about from a security perspective.

Independent audit by Trail of Bits

After implementing SecureTar v3, we commissioned Trail of Bits to perform the focused security assessment and fix review. Here is what the review found:

1. Timing side-channel in a validation comparison (informational): The audit pointed out a minor coding issue in how we checked a validation key. It wasn’t a security risk (the value is stored openly in the file header), but we updated the check to a safer form so security tools stop flagging it.
2. Insecure fallback to legacy protocol version (informational): Header parsing logic could be confused by corrupted data; we updated the logic so corrupted headers raise an error instead of silently falling back.
3. Supply-chain risk in GitHub Actions workflow (medium): Workflow steps were not pinned to specific commit hashes and used broad permissions, opening the build process to possible supply-chain attacks. We pinned actions to specific commit hashes and tightened permissions.

Crucially, Trail of Bits’ post-fix review confirmed all three findings were resolved. This shows we have not only adopted modern cryptography, but also closed the gaps the audit exposed.

You can read more about the audit and the fixes in the Trail of Bits report.

How you help support this work

Security work (especially external audits and specialist engineering) costs money. The Open Home Foundation provides the structure and finances that let us do this work. That money comes, in part, from people who buy official Home Assistant or ESPHome products from the foundation’s commercial partners, and merchandise from the Open Home Foundation Store: we really appreciate your support!

Because of this, we were able to commission experts, invest engineering time, and validate the fixes. That investment protects users’ backups (which often contain configurations, passwords and API keys, integrations, and automations) and keeps Home Assistant a trustworthy, secure platform for everyone.

Recommended next steps

• Ensure Home Assistant is updated to the latest version. The 2026.4 release includes SecureTar v3.
• Any encrypted backup created after updating to 2026.4 will use v3’s improved format.
• Existing backups are still secure, as Home Assistant’s generated passphrase is strong. That said, for extra security, you can regenerate the encryption key in your backup settings (use the Change encryption key option at the bottom of the backup settings page).
• If you use the ha backup CLI command, or the hassio.backup_full or hassio.backup_partial actions to create backups, and you’ve used a short/low entropy password, you should choose a new password.

For the curious: technical summary

• Key derivation: Argon2id (memory-hard), using separate sub-keys for each backup part.
• Encryption / AEAD: XChaCha20-Poly1305 via libsodium secretstream (PyNaCl) with 256-bit key size. AEAD means your data is not only encrypted, but also authenticated (validating the data is unchanged/not tampered with).
• Audit: Trail of Bits: 3 findings (2 informational, 1 medium), all resolved.
• Build hardening: GitHub Actions pinned to commit SHAs and narrower permissions to reduce supply-chain risk.

Looking for more? Check out the SecureTar repository on GitHub.

Final note

Security is iterative, and this latest work has helped build a stronger foundation for Home Assistant backups, and a clearer path forward for maintaining that security over time.

If you want to read about similar past efforts, see some of our other posts:

• One of our past security audits
• The upcoming release notes for Home Assistant 2026.4

By keeping Home Assistant secure, we make the platform safer, more trusted, and more enjoyable for the whole community. Thank you.