Security

See Security old for the old page.

This page lists the processes, tools, and mechanisms the OpenWrt project uses for the security of OpenWrt. This policy covers the OpenWrt distribution with the official package feeds hosted at https://github.com/openwrt/ and also the OpenWrt specific tools hosted at https://git.openwrt.org/ such as procd, ubus, and libubox.

Security bugs should be reported in confidentiality to contact@openwrt.org, please see Reporting security bugs and High-level security incident response handling process for additional details.

Note that the contact@openwrt.org mail box is not always monitored and we may not notice when you send a mail to this mail address. If you do not get an answer or the vulnerability is severe, please contact our public mailing list openwrt-adm@lists.openwrt.org with a brief statement that a vulnerability has been reported to contact@openwrt.org and a general description of its severity. Please avoid providing detailed information on the public mailing list that would aid exploitation, such as the vulnerable component and exploit details. Note that the mailing list email does not accept formatted HTML emails, so make sure that your mail client allows sending plaintext emails.

This only lists security advisories for components directly maintained by the OpenWrt project. This does not list fixed security problems in third-party components used by OpenWrt which may also affect the security of OpenWrt. We do not list known security problems in the Linux kernel, openssl, and other third-party components even when they affect use cases relevant to OpenWrt. The OpenWrt project monitors the upstream projects and backports security fixes for components used in the OpenWrt core repository to supported OpenWrt versions. For example 159 CVEs were assigned for the Linux kernel in 2021 alone, OpenWrt regularly updates the minor Linux kernel version to get these recent fixes.

This table lists the support status of various OpenWrt releases:

The listed Version numbers reference the code base and the support status applies to the the latest minor release of that branch:

• Supported: The OpenWrt project will provide updates for the core packages fixing security and other problems we are aware of.
• Security Maintenance: The OpenWrt project will fix only security problems in this release, existing bugs will remain.
• End of Life: The OpenWrt project will NOT provide any updates, even for severe security vulnerabilities, please update to a more recent version.

A major release will be Supported after its initial release.

When the next major release is published, the previous version will move into Security Maintenance status.

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.

This timeline only covers core OpenWrt packages and not the external package feeds hosted on GitHub.

Some package feed maintainers do not support all OpenWrt versions that are still supported by the OpenWrt project.

For the best security support we strongly suggest that every device is upgraded to the most recent stable version.

The Projected EoL date may be subject to change depending on circumstances, such as the timing of the next release.

The OpenWrt project uses multiple tools to identify potential security problems. This information is normally available to everyone and we appreciate fixes for problems reported by these tools from everyone.

The uscan report shows the version number of all packages from the base and the package repository and compares it against the recent upstream released versions. In addition the tool which generates this page also checks for existing CVEs assigned to the packages based on the Common Platform Enumeration (CPE) which is listed in the PKG_CPE_ID variable of many packages. That page is updated weekly for master and the active release branches.

OpenWrt uses the commercial Coverity Scan tool which is available for free to open source projects to do static code analyses on the OpenWrt components. This scans one OpenWrt build per week and reports the problems found in the components developed in the OpenWrt project like procd and ubus, but not on (patched) third party components.

The reproducible builds project checks that OpenWrt master is still reproducible. This proves that the produced releases really match the delivered source code and no backdoors were introduced in the build process.

OpenWrt operates multiple build bot instances which are building snapshots of the master and the supported release branches.

When a change to a package is committed to the OpenWrt base repository of package feed, the build bots are automatically detecting this change and will rebuild this package. The newly built package can then be installed with opkg or be integrated with the image builder by users of OpenWrt. This allows us to ship updates in about 2 days to the end users.

The kernel is normally located in its own partition and upgrades are not so easily possible. Therefore this mechanism currently does not work for the kernel itself and kernel modules and a new minor release is needed to ship fixes to end users.

OpenWrt activates some build hardening options in the build configuration at compile time for all package builds. Note that individual packages and/or targets may ignore or otherwise not respect these settings.