future OpenWrt security support
Hauke Mehrtens
hauke at hauke-m.de
Sat Oct 31 13:04:10 PDT 2026
Hi,
I would like to send this OpenWrt announcement to the announcement
mailing list:
-----
OpenWrt: Changes to the Security Support Policy
The OpenWrt project is reducing the security support period for stable
releases.
Previous policy: Each major release was supported for at least one year,
or six months after the next major release, whichever was later.
New policy: Each major release will be supported until the next major
release is published.
This means OpenWrt will provide security maintenance for the main
development branch and only one stable release series at a time.
Impact on existing releases
OpenWrt 17.01, 18.06, 19.07, 21.02, 22.03, and 23.05 have been End of
Life for a long time and contain many known, unpatched security
vulnerabilities.
OpenWrt 24.10 reached End of Life in September 2026 and no longer
receives security fixes. This remains unchanged.
OpenWrt 25.12 is the currently supported stable release and will receive
security fixes until the next major release is published.
All users running OpenWrt 24.10 or older should upgrade to OpenWrt 25.12
as soon as possible. If your device is no longer supported by OpenWrt
25.12, we recommend replacing it with hardware that supports a
maintained release.
The detailed policy is available at:
https://openwrt.org/docs/guide-developer/security
Security advisories
We will also stop maintaining the Security Advisories list in the
OpenWrt wiki. Security fixes may instead be documented in release notes
or GitHub Security Advisories.
Not every security fix receives a CVE identifier. Many vulnerabilities
discovered internally are fixed without one. Tracking or backporting
only CVE-related fixes is therefore insufficient to keep a release secure.
Why this change?
Maintaining older releases requires significant effort. OpenWrt release
management is handled by a small group of volunteers in their spare time.
By reducing the number of supported releases, we can focus our limited
resources on properly maintaining current versions.
We want to be transparent about these limitations rather than create a
false sense of security by promising support we cannot reliably provide.
We strongly encourage all users to keep their OpenWrt installations up
to date.
Have fun!
The OpenWrt Community
-----
On 10/3/26 15:24, Hauke Mehrtens wrote:
> Hi,
>
> This is a continuation of the "Handling of security reports" discussion
> we had some months ago. Not much has changed since then:
> https://lists.openwrt.org/pipermail/openwrt-adm/2026-June/003018.html
>
> Providing security support for older releases is a lot of work.
> Currently it looks to me like there is not much interest in security
> support from the OpenWrt committers or from the community around OpenWrt.
>
> We have 24 security advisories in triage state on the GitHub main
> repository alone; it was 33 a week ago. Most of them are very low
> severity in most use cases. I took care of some of them, but in general
> it looks like not many people are taking care of them. Some other
> OpenWrt projects also have security advisories in triage state.
> Private list of GitHub security advisories: https://github.com/openwrt/
> openwrt/security/advisories
>
> There are also some reports which we received via contact at openwrt.org in
> FreeScout: https://freescout.openwrt.org/
>
> The list of advisories in the wiki is not up to date: https://
> openwrt.org/docs/guide-developer/security Many others, including severe
> ones, are not listed there. I think I listed all of them in the last
> release notes.
>
> Some are published on GitHub nowadays, but I am only publishing the
> report and do not want to invest the time to describe in more detail who
> is affected and so on: https://github.com/openwrt/openwrt/security/
> advisories?state=published
>
> Not all security fixes get advisories or CVEs. Just because a fix got a
> CVE does not mean it is more important than one that didn't get one. A
> lot of security problems we found internally did not get a CVE. The CVE
> score is also more or less arbitrary; it highly depends on your use
> case. If you want to build a secure product on top of OpenWrt, you must
> use the most recent minor release of a supported release series or a
> recent snapshot. Otherwise you have to go through all commits and
> evaluate whether they are relevant for you.
>
> Managing and backporting all these changes to older versions is a lot of
> work. This is all done by people in their free time; there seems to be
> no commercial interest in OpenWrt security.
>
>
> Our current security policy says this:
> > A major release will move into End of Life status one year after the
> initial release, or 6 months after the next major release, whichever
> date is later. The project aims to do a final minor release at the end
> of the support cycle.
> https://openwrt.org/docs/guide-developer/security#support_status
>
> End of Life status means we will not backport any security fixes
> anymore, not even severe ones.
>
> OpenWrt 25.12 is now the only supported OpenWrt series. OpenWrt 24.10
> and all older versions are End of Life and will not get any security
> fixes anymore, not even for severe issues. All users of OpenWrt 24.10
> and older versions *must* upgrade if they care about security.
>
> See the discussion about current versions here: https://
> lists.openwrt.org/pipermail/openwrt-devel/2026-September/045085.html
>
>
> To reduce the load on the OpenWrt team and to bring the promised
> security support closer to reality, I am suggesting the following changes:
>
> 1. Reduce the support period for OpenWrt releases to:
> > A major release will move into End of Life status when the next major
> version is released.
> This means that OpenWrt will stop providing security updates for OpenWrt
> 25.12 when OpenWrt 26.XX has its final release.
>
> 2. Publish security advisories when nobody has taken care of them for 30
> days.
> If nobody has replied to an email with a security report sent to
> contact at openwrt.org, or commented on the security advisory on GitHub,
> someone from the project can simply publicly publish it, even without a
> fix, if that person is not currently interested in fixing it themselves.
> Finding security vulnerabilities is not hard anymore; bad actors will
> find many, including in OpenWrt, and they do not need such advisories.
> Publishing it will allow others to provide a fix.
>
>
> * If you are not an OpenWrt committer, you can help us by creating PRs
> with backports that fix security problems. I am monitoring the GitHub
> PRs for the stable releases and will merge the changes fixing security
> problems:
> https://github.com/openwrt/openwrt/pulls?
> q=is%3Apr+state%3Aopen+label%3Arelease%2F25.12
>
> * If companies are interested in longer OpenWrt support, building
> something like the Debian LTS organization would be very nice:
> https://www.freexian.com/lts/debian/
> Maybe security support will become more important for companies in the
> future with the EU Cyber Resilience Act (CRA).
>
> * Help with writing security advisories would also be appreciated.
>
>
> When we have a conclusion, I would like to send a mail to the
> announcement mailing list to inform the general public too. I will send
> the draft here first.
>
> Hauke
>
> _______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm
More information about the openwrt-adm
mailing list