OpenWrt Release History: Versions, Targets, apk and Security Support

OpenWrt ships one major release series roughly every year, named by year and month (24.10, 25.12), followed by numbered service releases that carry fixes. As of 24 October 2026 only OpenWrt 25.12 is supported, and its latest service release is 25.12.6 from 18 October 2026. The 24.10 series reached end of life in September 2026, and everything older gets nothing.

OpenWrt is a build system as much as a distribution: firmware is produced per target and subtarget, every target ships an Image Builder and an SDK, and since 25.12 the package manager is apk rather than opkg. This post walks through where OpenWrt came from, every release since the 2018 remerge with its dates, how builds are organised, how packages and images are signed, how security fixes are published, which hardware is still realistic, and a step by step routine for checking, verifying and upgrading a router while keeping an inventory of what runs on it.

Key takeaways

• One supported series right now. The OpenWrt security page lists 25.12 as Supported with a projected end of life of "TBD", and every older branch, including 24.10, as End of Life.
• The support rule is written down. A major release moves to end of life "one year after the initial release" or "6 months after the next major release, whichever date is later". When a new major ships, the previous one drops to security maintenance until that date.
• 24.10 ended in September 2026. The 25.12.0 release notes said there would be no 24.10 security updates "after September 2026". The last 24.10 service release was 24.10.8 on 26 July 2026.
• 25.12 replaced opkg with apk. The 25.12.0 notes say "apk is still maintained; the OpenWrt opkg fork is no longer maintained." The development branch switched on the night of 10 to 11 November 2024, according to the openwrt-devel announcement. 24.10 stayed on opkg.
• Do not run a blanket package upgrade. The opkg to apk cheat sheet warns in capitals not to use apk upgrade on a router. Move between service releases with a full image through sysupgrade, owut, LuCI Attended Sysupgrade or the Firmware Selector.
• Images are signed twice. Each target directory carries sha256sums with a GnuPG (.asc) and a usign (.sig) signature. Package indexes are signed too.
• Every release target ships a CycloneDX BOM, a ready made starting point for a router SBOM.
• 4/32 hardware is gone and 8/64 is marginal. Support for devices with 4 MB flash or 32 MB RAM ended with 19.07. OpenWrt now recommends at least 16 MB flash and 128 MB RAM.

For the hardware side, read how a home router is made; for configuration, the home router security checklist; for an x86 build, a home firewall on a mini PC. The apk package manager is shared with Alpine; see the Alpine release history.

Where OpenWrt came from

2004: a Linux firmware built from a router vendor's GPL source

The OpenWrt history page says the project "started in January 2004". The first versions were built from the GPL source code a router maker released for the WRT54G, combined with a uClibc based buildroot. That origin explains a lot about OpenWrt today: it was never a general purpose distribution squeezed onto a router. It began as a way to replace one vendor's firmware with something people could rebuild, and it grew into a build system that can produce firmware for thousands of boards.

Experimental builds appeared in early 2005, and the first named release, "White Russian 0.9", is dated January 2007 in the history timeline. Drink named releases followed:

• Kamikaze, built on the "Buildroot-NG" rework done in August and September 2006 and merged in mid October 2006.
• Backfire, whose first release, "OpenWrt 10.03, was released in April 2010."
• Attitude Adjustment, "released on 25 April 2013."
• Barrier Breaker, "released in October 2014."
• Chaos Calmer, the 15.05 series. The history page notes one build was "compiled at the end of January 2016, but hardware problems delayed the release until March."

The 2018 merge announcement ended support for everything before 15.05, and 15.05 got only "a limited amount of security and bug fixes".

2016: the LEDE fork

In early May 2016 a group of core developers announced the Linux Embedded Development Environment, LEDE, as a separate project. The OpenWrt side's public reply on the LEDE development list, sent on 4 May 2016, says its authors read "about the announcement of the LEDE project yesterday" with "a great amount of surprise" (lede-dev archive). The git history still carries a tag named reboot on a commit dated 26 April 2016, which is where the LEDE tree starts.

LEDE produced one release series, LEDE 17.01, first released on 22 February 2017 according to the support table on the security page. The history page says "the final 17.01 release was 17.01.6 in September 2018"; the security page and the git tags show a later 17.01.7 in June 2019, so treat 17.01.7 as the true last release.

2018: the remerge under the OpenWrt name

On 4 January 2018, Hauke Mehrtens posted to the LEDE list that both projects were "happily announcing the unification of both projects under the OpenWrt name". The announcement set out the terms that still shape the project:

• The merged project uses the former LEDE codebase, with OpenWrt patches that met LEDE's quality bar folded in.
• It is governed under the rules the LEDE project had written.
• Source lives at git.openwrt.org with a synchronised mirror on GitHub.
• It is legally represented by Software in the Public Interest, a US 501(c)(3) nonprofit that manages the trademark and donations.
• The project would aim for "frequent minor releases to address critical bugs and security issues".

The reunited project's first release was 18.06.0 on 31 July 2018. Its release notes say that "with this release, the re-merged OpenWrt project attempts to define a baseline for future development", and that upgrades from OpenWrt 15.05 or LEDE 17.01 were supported through sysupgrade. Every release since has followed the same YY.MM pattern.

How the version scheme and support policy work

YY.MM series and service releases

An OpenWrt version has three parts. 25.12 is the series, named for the year and month the release branch was cut. 25.12.0 is the first stable release of that series, preceded by release candidates such as 25.12.0-rc1 through 25.12.0-rc5. 25.12.1, 25.12.2 and so on are service releases: rebuilt firmware and packages carrying bug fixes and security fixes from the same branch, without new features or major version changes.

The branch name and the release date are often far apart: 24.10.0 shipped on 6 February 2025 and 25.12.0 on 6 March 2026. "24.10" on a router names the branch, not the month the firmware was built.

There is also a development branch, main, published as nightly snapshots. The releases page describes OpenWrt as having a stable "Release" branch and a "Development" branch, with some development builds later declared release candidates.

The support levels

The security page defines three support levels:

A new major release starts as Supported. When the next major release arrives, the previous one moves to Security Maintenance. It reaches End of Life one year after its own first release, or six months after the next major release, whichever is later. The page notes that projected dates "may be subject to change."

Two limits on that promise are easy to miss. First, the timeline covers core OpenWrt packages only. The page says external package feeds hosted on GitHub are not covered, and some feed maintainers do not support every version the core project still supports. Second, the support status is about the source branch. A router only benefits when someone actually builds and installs the newer image on it.

A worked example of the rule

Take 23.05. Its first release was 13 October 2023, so the one year mark was October 2024. The next major, 24.10.0, came out on 6 February 2025, and six months after that is August 2025. The later of the two is August 2025, which matches the end of life listed for 23.05. The last service release, 23.05.6, came out on 20 August 2025.

For 24.10, one year after 6 February 2025 is February 2026. 25.12.0 arrived on 6 March 2026, so six months later is September 2026. September wins, and that is the end of life on the table and in the 24.10.8 release notes, which said the series was "in security maintenance (only security problems are fixed), with end of life (EoL) projected for September 2026."

For 25.12, the one year mark is March 2027. Whether the end of life lands then or later depends on when the next major release ships, which is why the table says TBD. If the next major arrives after September 2026, 25.12 lives until six months after it.

Older branches ran a little past the formula: 22.03 would have ended in April 2024, but its last release, 22.03.7, came on 25 July 2024. Plan around the formula and check the table for the final word.

Every release series since LEDE 17.01

The table below combines the support table on the security page with the release notes for each first release. Release dates are the dates the project lists; the corresponding git tags were created one to three days earlier, which is normal for a release that is tagged, built, uploaded and then announced.

There is no 20.xx series; after 19.07 came 21.02.

What each series changed

18.06 reset the baseline after the remerge: Spectre and Meltdown mitigations and x86 microcode loading, a LuCI auto rollback that reverts configuration changes if you lose access, and the removal of old targets such as adm5120 and xburst.

21.02 raised the floor on both security and hardware. The 21.02.0 notes say "all packages necessary to provide WPA3 are installed by default", that TLS support and Mozilla's trusted CA certificates now ship by default, and that "LuCI is now available over HTTPS in addition to HTTP". The automatic redirect to HTTPS was off on fresh installs but on after an upgrade from 19.07. It added initial DSA (Distributed Switch Architecture) support "which replaces the swconfig system", made SELinux a build option that was "not activated by default", and stated that "devices now need at least 8 MB of flash and 64 MB of RAM to run a default build". Kernel 5.4.143, musl 1.1.24, gcc 8.4.0.

22.03 changed the firewall. The 22.03.0 notes say "Firewall4 is used by default, superseding the iptables-based firewall3 implementation", which means nftables underneath and no legacy iptables utilities in default images. More targets moved from swconfig to DSA, LuCI gained a dark mode, and the move to musl 1.2.x made time_t 64 bit on 32 bit systems, which removes the year 2038 overflow. Over 1,580 devices were supported.

23.05 switched TLS libraries and added Rust. The 23.05.0 notes say "OpenWrt has transitioned its default cryptographic library from wolfssl to mbedtls", noting that mbedtls 2.28 at the time did not support TLS 1.3. It added Rust support in the package infrastructure, new targets for Qualcomm IPQ807x and MediaTek Filogic, and an armsr target replacing armvirt. Over 1,790 devices. One footnote is relevant for anyone verifying old images: the notes say 23.05.0 was signed with snapshot keys and a later service release would use a different key.

24.10 was the last opkg release. The 24.10.0 notes describe over 5,400 commits and "over one year" of development, a jump from kernel 5.15 to 6.6, TLS 1.3 in default images through mbedtls 3.6, POSIX ACLs and security attributes on large flash targets, initial Wi-Fi 7 support, and support for over 1,970 devices. New targets included d1 (Allwinner D1 RISC-V), loongarch64, starfive and stm32; ipq807x was renamed qualcommax; ath25, bcm63xx, octeontx and oxnas were removed. The notes are explicit that "APK packages are not supported" in 24.10. Toolchain: musl 1.2.5, gcc 13.3.0.

25.12 is the current series. The 25.12.0 notes give the build as r32713-f919e7899d with the codename "Dave's Guitar". Headline changes: apk replaces opkg; the LuCI Attended Sysupgrade app "is now installed by default"; shell history is kept in RAM by default; the Wi-Fi scripts were rewritten in ucode; kernel 6.12.71 with wireless drivers from 6.18.7. Over 2,200 devices are supported, more than 180 new, with new targets for Siflower SoCs and Microchip LAN969x switches and more Realtek switch chips. Toolchain: musl 1.2.5, gcc 14.3.0.

Service releases are where the security work lands

The 24.10.8 notes list fixes across odhcpd (the DHCPv6 and router advertisement server, including two issues rated critical), uhttpd (the web server behind LuCI), rpcd, cgi-io, several LuCI apps, umdns, dropbear, musl, OpenSSL 3.0.21, dnsmasq 2.93 and kernel 6.6.144. The 25.12.6 notes list Mbed TLS 3.6.7, OpenSSL 3.5.9 and wolfSSL 5.9.4 updates, more uhttpd, rpcd and cgi-io fixes, a critical issue in the ser2net package, and kernel 6.12.112.

Both notes add that feed packages outside the default image, such as curl and OpenSSH, "must be updated manually".

How OpenWrt builds are organised

Targets, subtargets and profiles

OpenWrt firmware is not one image per release. It is organised in three levels:

• Target: a family of SoCs or platforms that share a kernel configuration, such as ath79, mediatek, ramips, qualcommax, x86 or bcm27xx. The 25.12.6 release has 42 target directories on downloads.openwrt.org.
• Subtarget: a narrower split inside a target. ath79 has generic, mikrotik, nand and tiny; mediatek has filogic among others.
• Profile: one specific board, which produces its own image files. Profiles are listed in each subtarget's profiles.json and by the Image Builder's make info.

Packages are built per CPU architecture rather than per target. The 25.12.6 package tree has directories such as aarch64_cortex-a53, mips_24kc, arm_cortex-a7_neon-vfpv4 and x86_64, each with feeds named base, luci, packages, routing, telephony and video. Kernel modules are the exception: they are tied to the exact kernel build, so they live under each target in a kmods/ directory.

What sits in a target directory

For one subtarget, for example releases/25.12.6/targets/mediatek/filogic/, a release publishes:

The sysupgrade CLI guide says to use images ending in -sysupgrade.bin on most devices, and "combined" images on x86, armsr and loongarch. Use ubus call system board on the router to read the board_name, target and rootfs_type before picking a file.

Image Builder

The Image Builder is "a pre-compiled environment suitable for creating custom images without the need for compiling them from source." It takes prebuilt packages from the release feeds and assembles a flashable image with your package selection, your own files and services disabled as you choose. It runs only on 64 bit Linux and should be used as a non root user. The documentation is clear that its images "are not identical to official images" because they pull pre generated packages, so a package updated in the feed after the release will be picked up.

tar --zstd -xvf openwrt-imagebuilder-*.tar.zst
cd openwrt-imagebuilder-*/
make info
make image \
  PROFILE="profile-name" \
  PACKAGES="pkg1 pkg2 -pkg3" \
  FILES="files" \
  DISABLED_SERVICES="svc1 svc2"

A package name prefixed with a minus sign removes it from the default set.

SDK

The SDK is "a stripped-down buildroot" with a precompiled toolchain. It compiles individual packages for one release and target: your own software, a newer version of an existing package, or a package with your own patches. It is not meant to rebuild the whole firmware; for that you use the full build system from the git tree.

./scripts/feeds update -a
./scripts/feeds install <packagename>
make menuconfig
make package/<packagename>/compile

In short: different stock packages on a supported board, use the Image Builder; one extra or patched package, the SDK; an unsupported board or changed kernel, the full source build.

Package managers: from opkg to apk

opkg, through 24.10

From the early days until 24.10, OpenWrt used opkg, a lightweight package manager that installs .ipk files. On a 24.10 router the feeds have a Packages index, Packages.gz, and two signatures: Packages.sig (usign) and Packages.asc (GnuPG). The 24.10.8 target package directory also carries Packages.bom.cdx.json, a CycloneDX file for the feed itself.

The signature on the index is only useful if the client actually checks downloaded packages against it. The 2020 opkg advisory, CVE-2020-7982, describes a parsing bug that meant opkg did not properly check the SHA-256 checksums from the signed index, so downloaded packages were not effectively verified. Because opkg runs as root, a network attacker between the router and the mirror could have substituted a package. It affected LEDE 17.01.0 to 17.01.7, OpenWrt 18.06.0 to 18.06.6 and 19.07.0, and was fixed in 18.06.7 and 19.07.1. The lesson is general: a signed index is a chain, and every link from signature to checksum to file has to be checked.

apk, from 25.12

The development branch moved to apk, the package manager from Alpine Linux, in November 2024. Paul Spooren's 30 October 2024 message on openwrt-devel explains two choices. OpenWrt uses apk's newer v3 index format, "while Alpine Linux sticks with v2 (for now)", and the plan was to "branch 24.10 soonish and then make APK the default in the main branch." On 9 November he wrote "We plan to do the switch on Monday!", and on 11 November: "We switched last night and I see the first targets being build with APK as package manager." 24.10 kept opkg, and 25.12.0 became the first stable release with apk.

On a 25.12 router:

• Repository definitions live in /etc/apk/repositories.d/.
• Each feed has a packages.adb index with packages.adb.asc and packages.adb.sig alongside it.
• The signatures page says apk keys use the NIST P-256 curve and sign the apk indexes, and it publishes the PEM public key for "unattended OpenWrt 25.12 builds".
• apk refuses unsigned packages by default. The cheat sheet notes that apk "wants you to provide valid signatures for all packages", unlike opkg, which skipped checks for local files. For your own builds, --allow-untrusted overrides this, which is exactly why it should be rare.

Command mapping

The cheat sheet maps the commands people use most:

The important difference is not a command. The cheat sheet says "DO NOT USE apk upgrade to update your packages!", because missing conflicts and incomplete dependencies in packages such as hostapd-* and wpad-* can brick a device. The same advice applied informally to opkg upgrade for years. On OpenWrt, the supported way to move to a newer service release is a new image, with your extra packages rebuilt into it.

How security fixes are published and how they reach routers

The advisory index

OpenWrt publishes advisories at openwrt.org/advisory, with IDs in the form YYYY-MM-DD-N. The index lists 24 advisories from November 2019 to December 2025. The most recent are a Dropbear privilege escalation (2025-12-16-1), an ltq-ptm privilege escalation (2025-10-22-2) and a ubusd heap overflow (2025-10-22-1). Earlier entries cover LuCI, uhttpd, opkg, libubox, ppp, dnsmasq, wolfSSL, the mac80211 wireless stack and the Attended Sysupgrade server. One entry, 2021-01-17-1, records a break in to the OpenWrt forum rather than a software flaw.

Advisories cover components the project maintains directly. Fixes for third party software such as OpenSSL, dnsmasq or the kernel appear in the service release notes instead, so read both.

Security bugs are reported confidentially to the project's contact address. The page warns that the mailbox "is not always monitored" and suggests a brief public notice without exploit details on the admin list if there is no reply.

The Attended Sysupgrade advisory

One advisory is worth understanding in detail because it concerns the update path itself. In December 2024 the Attended Sysupgrade server advisory, CVE-2024-54143, described two weaknesses in the service that builds custom images on demand. Build requests were identified by a SHA-256 hash truncated to 12 characters, which made collisions practical, and package names from requests reached build commands without enough sanitisation. Together they could let a crafted request cause a poisoned image to be served for someone else's request.

It was reported at 02:56 UTC on 4 December 2024 and the fix, using the full hash and validating input, was deployed at 09:42 the same day; build logs for the previous seven days showed no evidence of exploitation. The lesson for any build service: cache keys need the full cryptographic hash, and request fields must never reach a shell.

How fixes reach routers whose owners never log in

OpenWrt has no automatic update service that installs new firmware on its own. A fix reaches a router only when someone:

1. Reads that a service release exists.
2. Fetches a matching image, or asks the Attended Sysupgrade server to build one.
3. Runs sysupgrade, which flashes the new image and reboots.

The tooling has made step 2 and 3 much easier. 25.12 installs the LuCI Attended Sysupgrade app by default, so the web interface can check for a newer release and build an image that keeps your extra packages. owut, the command line client, is preinstalled on most 25.12 devices with enough flash. But someone still has to start it. A router flashed with OpenWrt in 2022 and never touched again is running 22.03 with no fixes since July 2024, regardless of how good the project's process is.

OpenWrt is only as current as the person or script responsible for it.

Hardware: what is supported and what is realistic

The Table of Hardware

The Table of Hardware lists "all devices that are supported by OpenWrt". You can filter by brand or model fragment and switch to a view limited to devices supported by current releases. The flash column is the "total size of the flash chip(s)"; on devices with dual firmware partitions the space actually available for packages can be much lower. Each entry links to a device page with install instructions, and those pages are where hardware revisions are distinguished. Router makers often reuse a model name across board revisions with different chips, so match the revision printed on the label, not just the name on the box.

4/32 and 8/64

The 4/32 warning page defines 4/32 devices as those with at most 4 MB flash and/or at most 32 MB RAM, and says "OpenWrt support for those devices has been end with the 19.07 release." There are no newer images for them. The 21.02 notes moved the default minimum to 8 MB flash and 64 MB RAM.

The 8/64 warning page goes further. It says 8 MB flash "is barely enough", that 64 MB RAM "may have some issues with stability", and that owners "should expect that support for the device may be dropped in future." It recommends "16/64 as a minimum for any device, with at least 128 MB of RAM being preferred", and more than 32 MB flash for anything beyond basic routing. The same page tracks firmware growth on one old board, from 2,816 KB in 12.09 to 6,976 KB in 25.12.2.

The apk switch itself made small devices tighter. The 30 October 2024 openwrt-devel message acknowledged "concerns about the size increase" and said "right now APK is not as tiny as OPKG."

Attended Sysupgrade

Attended Sysupgrade, or ASU, is a server at sysupgrade.openwrt.org that "coordinates several OpenWrt ImageBuilders" to build an image containing your installed packages for your board, and caches the results. Clients are the LuCI app, owut (described as "generally considered the best CLI option now"), auc for 23.05 and earlier, and the web Firmware Selector. The LuCI app, auc and owut verify the image's SHA-256 checksum before installing; the Firmware Selector does not, so you verify manually. The owut page warns that a first boot init script is sent to the build server, so keep secrets out of it.

Vendor firmware, OpenWrt stable and snapshots compared

OpenWrt can extend the useful life of a supported device long after the vendor stops shipping fixes, but it does not remove the need for someone to apply updates. Stable with an owner beats stock without one, and stock with automatic updates beats OpenWrt that nobody upgrades.

Walkthrough: check, verify, upgrade and inventory a router

The steps below assume a router already running OpenWrt and a Linux or macOS workstation. Commands that run on the router are shown with the router as the host; commands for the workstation are labelled.

Step 1: identify the board, target and release

On the router:

ubus call system board
cat /etc/openwrt_release

ubus call system board prints the board_name, the release and the target (for example mediatek/filogic). Write these down. They decide which image you download, and a mismatch is the most common way to brick a device.

Step 2: check the device and the support status

Look up the exact model and hardware revision in the Table of Hardware and open its device page. Confirm three things: the device is supported in the current release, any special upgrade notes for your board (the 24.10 and 25.12 notes list boards that need a config wipe or interface renames), and the flash and RAM figures. Then check the release you are on against the support table on the security page. Anything other than 25.12 is end of life as of this writing.

Step 3: take a backup and an inventory before touching anything

On the router, save a configuration backup and the list of installed packages.

sysupgrade -b /tmp/backup-$(date +%Y%m%d).tar.gz

# 25.12 and snapshots
apk list --installed > /tmp/packages-installed.txt

# 24.10 and older
opkg list-installed > /tmp/packages-installed.txt

Copy both files off the router with scp (add -O with OpenSSH 9 or newer if needed). On 25.12, owut list prints only the packages you added on top of the defaults, which is the list you want to carry forward.

Step 4: download and verify the image (workstation)

Download the image, the checksum file and both signatures from the same directory. Replace the release, target and subtarget with yours.

BASE=https://downloads.openwrt.org/releases/25.12.6/targets/mediatek/filogic
curl -O "$BASE/sha256sums"
curl -O "$BASE/sha256sums.asc"
curl -O "$BASE/sha256sums.sig"
curl -O "$BASE/<your-board>-squashfs-sysupgrade.bin"

# GnuPG signature over the checksum list
gpg --with-fingerprint --verify sha256sums.asc sha256sums

# Checksum of the image you downloaded
sha256sum -c --ignore-missing sha256sums

The release signatures guide says the GnuPG output must report a good signature and the fingerprint must match the one on the signatures page. Import the release key from that page first, and compare fingerprints yourself rather than trusting whatever key the signature names. The 25.12.6 signature we checked identifies itself as "OpenWrt Build System (Nitrokey3)".

To check the usign signature as well, save the release's usign public key from the signatures page to a file, confirm its fingerprint, then verify. By default usign looks for the signature in the message file name plus .sig.

usign -F -p openwrt-release.pub
usign -V -m sha256sums -p openwrt-release.pub

Step 5: upgrade with sysupgrade, keeping configuration

Warning: sysupgrade rewrites the router's flash and reboots it. Flashing an image built for a different board, or interrupting power during the write, can leave the device unbootable and needing serial or JTAG recovery. Before running it, repeat the device check.

# On the router: confirm the board matches the image you are about to flash
ubus call system board | grep -E '"board_name"|"target"'
ls -l /tmp/*.bin
free

The sysupgrade guide says to proceed only with at least twice the image size free in RAM, and the image must be in /tmp, because sysupgrade unmounts flash during the upgrade. Then:

sysupgrade -v /tmp/<your-board>-squashfs-sysupgrade.bin

-v lists the configuration files being kept. Add -n only when the release notes for your board say configuration cannot be carried over (for example a swconfig to DSA change); -n discards network settings too, so have console or wired access ready.

On 25.12 you can let owut do the build, download and checksum steps for you, keeping your extra packages:

owut check
owut upgrade

owut upgrade --version-to 25.12 selects a branch explicitly. Since 24.10 to 25.12 is the jump most people still have to make: the 25.12.0 notes say this upgrade "should be transparent on most devices", while upgrades from 23.05 straight to 25.12 are "not officially supported". Go through 24.10 first if you are further behind.

Step 6: confirm and record the result

After the reboot:

cat /etc/openwrt_release
apk list --installed > /tmp/packages-after.txt

Compare the package lists, reinstall anything missing with apk add, and keep both lists. For a fleet, the per release CycloneDX file in the target directory gives you a machine readable list of the default image's components and versions, and your own package list covers what you added. Together they are a reasonable router SBOM.

What a community release model means for SBOMs and small office fleets

Each OpenWrt router in a small office is a Linux system with a kernel, a C library, a TLS library, DHCP and DNS, SSH and a web interface. Treat it like a server.

Know what each router is running. Record board, target, release and installed packages for every unit. The release's .manifest and .bom.cdx.json describe the default image; your apk list --installed output describes the actual device. The 25.12.6 BOM for mediatek/filogic lists 135 components including kernel 6.12.112, busybox 1.37.0, dnsmasq 2.93, dropbear 2025.89 and musl (as libc) 1.2.5, and gives 48 of them CPE identifiers such as cpe:/a:thekelleys:dnsmasq:2.93. CPEs are what most vulnerability databases key on, so those 48 can be matched directly. The others, including OpenWrt's own components like uhttpd, odhcpd, rpcd and ubus, have no CPE and are versioned by date and commit hash, so you match them against the advisory index and service release notes by hand.

Know the support date of each release. Put the end of life month next to each router in your inventory. When a new major release ships, you have at least six months on the old one, and the clock is public.

Know who upgrades. Decide whether routers are upgraded by a person with LuCI, by a script with owut, or by rebuilding images centrally with the Image Builder and pushing them. Whatever you pick, write it down and test it on one unit first.

Watch the packages outside the image. The release notes are explicit that feed packages such as curl or OpenSSH must be updated separately. An inventory that lists only the release version misses them.

Decide when hardware retires. 8/64 devices are on notice; budget their replacement now.

Common mistakes

• Running a blanket apk upgrade or opkg upgrade. OpenWrt's own documentation says this can brick a device on 25.12. Upgrade by image.
• Treating the branch number as a build date. A router on 24.10 is not "from October 2024"; it could be 24.10.0 from February 2025 or 24.10.8 from July 2026. Always record the full service release.
• Staying on an end of life series because it works. 23.05 has had no fixes since August 2025 and 24.10 none since September 2026, even for severe issues.
• Skipping signature checks because the download is over HTTPS. HTTPS protects the transfer from the mirror, not the content on the mirror. Check the GnuPG or usign signature on sha256sums, then the checksum.
• Using the Firmware Selector without checking the checksum. The ASU guide says the Firmware Selector does not validate checksums for you, unlike LuCI, owut and auc.
• Flashing an image for the wrong hardware revision. Same model name, different board. Match board_name and the label revision before every flash.
• Jumping two majors at once. Sysupgrade between adjacent majors is supported "in many cases"; skipping one is "not officially supported".
• Forgetting packages outside the default image. A new image refreshes the defaults; extra packages need their own updates.

FAQ

What is the latest version of OpenWrt?

As of 24 October 2026 the latest stable release is OpenWrt 25.12.6, a service release dated 18 October 2026 with kernel 6.12.112. 25.12 is the only supported series.

Is OpenWrt 24.10 still supported?

No. The 24.10.8 notes projected end of life for September 2026, and the security page now lists 24.10 as End of Life. 24.10.8, released on 26 July 2026, was the last service release listed. Upgrade to 25.12.

How long is an OpenWrt release supported?

Until one year after its first release or six months after the next major release, whichever is later. In practice that has been about 18 to 22 months per series, with the final service release sometimes landing a month or so after the computed date.

When did OpenWrt switch from opkg to apk?

The development snapshots switched on the night of 10 to 11 November 2024. The first stable release using apk was 25.12.0 in March 2026. 24.10 and older still use opkg.

Can I use apk upgrade on OpenWrt?

The project says not to. Its cheat sheet warns that apk upgrade can brick a device because of missing conflicts and dependencies in some packages. Use sysupgrade, owut, LuCI Attended Sysupgrade or the Firmware Selector.

How do I verify an OpenWrt firmware image?

Download sha256sums and sha256sums.asc from the same directory as the image, run gpg --with-fingerprint --verify sha256sums.asc sha256sums and compare the key fingerprint with the signatures page, then run sha256sum -c --ignore-missing sha256sums.

What are OpenWrt targets and subtargets?

A target is a family of SoCs or platforms that share a kernel configuration, such as ath79 or mediatek. A subtarget narrows it further, such as mediatek/filogic. A profile is one specific board within a subtarget. 25.12.6 has 42 targets.

Does OpenWrt update itself automatically?

No. OpenWrt does not install new firmware on its own. The LuCI Attended Sysupgrade app and owut make it easy to check for and build an update, but a person or a script has to start the upgrade.

Can I still run OpenWrt on a 4 MB flash router?

Not with current releases. Support for 4/32 devices ended with 19.07, which reached end of life in April 2022. Anything still running it is unsupported.

OpenWrt's own packages get their fixes from the OpenWrt developers through service releases, and nothing below replaces flashing a newer image. But a router running OpenWrt is a Linux system assembled from open source components, and the same components (OpenSSL, mbedtls, dnsmasq, busybox, the kernel) also sit inside the container images and applications your team builds. Safeguard does not scan routers or firmware, but the dependency hygiene below applies directly to the software you build and ship next to them.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

To be clear about the fit: Safeguard does not log in to routers, flash firmware or analyse firmware images, and the OpenWrt upgrade itself stays with the steps above. Where it does help is with the SBOM files you collect. OpenWrt publishes a CycloneDX file for every release target, and Safeguard can scan an SBOM file and match its components against vulnerability databases, the same way it handles the SBOMs of your own software.

The first demo shows setting up the Safeguard runner on your own machine, approving it with its device code and running scans from the terminal. The same safeguard scan --sbom <file> flow works on the .bom.cdx.json you download from an OpenWrt target directory, keeping the file on your machine.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session: install, open the interactive terminal, and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. That approval at every step is the same discipline the router walkthrough asks for: check, confirm, then change.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude may use. Once connected, you can ask about the vulnerabilities in projects and SBOMs already in your account, such as the router BOMs you have uploaded, without opening the dashboard.

Click through it at your own pace, or open it full screen.

To try the CLI yourself, download it from safeguard.sh/download and read the CLI documentation.

Quick check

Sources

• OpenWrt releases
• OpenWrt security page and support status table
• OpenWrt security advisories index
• Advisory 2024-12-06-1: Attended SysUpgrade server
• Advisory 2020-01-31-1: opkg checksum verification
• OpenWrt history
• OpenWrt 18.06.0 release notes
• OpenWrt 21.02.0 release notes
• OpenWrt 22.03.0 release notes
• OpenWrt 23.05.0 release notes
• OpenWrt 24.10.0 release notes
• OpenWrt 24.10.8 release notes
• OpenWrt 25.12.0 release notes
• OpenWrt 25.12.6 release notes
• OpenWrt release downloads
• OpenWrt 25.12.6 targets
• OpenWrt 25.12.6 mediatek/filogic target directory
• OpenWrt 25.12.6 mediatek/filogic CycloneDX BOM
• OpenWrt 24.10.8 mediatek/filogic package feed
• OpenWrt git tags (GitHub mirror)
• opkg to apk cheat sheet
• OpenWrt signing keys
• Verifying OpenWrt release signatures
• usign key generation and use
• Sysupgrade from the command line
• Attended Sysupgrade
• owut
• Image Builder
• Using the SDK
• Table of Hardware
• 4/32 devices warning
• 8/64 devices warning
• OpenWrt and LEDE merge announcement, 4 January 2018
• OpenWrt response to the LEDE announcement, 4 May 2016
• openwrt-devel: APK switch planned, 9 November 2024
• openwrt-devel: APK switched, 11 November 2024

Last reviewed: 24 October 2026. OpenWrt support dates and service release numbers change with each release; check the security page support table and the release notes before planning an upgrade.