Known vulnerabilities in OpenWrt Versions (21.02, 19.07, 18.06)

Hello once again! :wave:

This nice (newer) security page does contain lot's of useful information.

One thing that I miss (as sadly lower end hardware often doesn't get lucky being supported in a newer/supported openwrt version) is the information if their are known vulnerabilities in the (most recent) EoL OpenWrt versions.

So the general question: Are their any known vulnerabilities in 21.02, 19.07 or 18.06?

Despite the anwser it would be very nice to add this infromation to the support status tabble, maybe like this:

Support status

This lists the currently support or not supported OpenWrt versions.

Version Current status Projected EoL Known vulnerabilities
22.03 Fully supported - no
21.02 End of life EoL (May 2023) ?
19.07 End of life EoL (April 2022) ?
18.06 End of life EoL ?
17.01 End of life EoL -
15.05 End of life EoL -

I don't think there are any currently reported vulnerabilities in 21.02.7 (which was released at the same time as 22.03.5 -- the current as I write this message), but certainly for everything earlier, yes. Some bigger than others. I am not aware of a consolodated list, but you can review each of the release notes to understand what was patched. For example, the release notes for 22.03.5 mentions two CVEs patched (relative to 22.03.4 and earlier). When reviewing the release notes, some of the fixed CVEs may have been long-standing but only recently discovered while others could be more recently introduced (and then patched) as a function of the general software development process and FOSS supply chain. So a patch that was just applied to a recent version may be a fix for a vulnerability that has just come to light despite years of inclusion in the software stack, while others may only be relevant to some more recent subset of those versions.

1 Like

So at least 17.01 as known security flaws according to the wiki

Which release shall I choose?


  • 15.05
    • No. EoL, unmaintained, no security fixes since 2016. Don't even think about it.
  • 17.01
    • No. EoL, unmaintained. Has known security flaws as of November 2019 that will not be patched.

Probably all previous versions (even 22.03.4) will have some vulnerabilities, but they may or may not be significant as an attack vector. The 17.01 comment talks about Nov 2019 -- I'm not sure if that's just a general thing from 17.01 > 19.07, or if there was some specific and severe vulnerability discovered at that time.

1 Like

Just to name a few.

1 Like

Thanks. I didn't feel like figuring out which (major) vulnerabilities happened around that time... I figured KRACK was part of it, but I couldn't remember what year that was.

1 Like

…and exactly that is the biggest issue affecting all of us. Bugs are attended quickly, in the maintained branches, but no one remembers the situation for older/ unmaintained branches. The older the respective branches get, the harder this becomes - and no one is really able to keep a correct timeframe in mind.

Backporting is hard work, in keeping track of what might be affected, in evaluating if the older versions really are affected, in then doing the actual backporting of the given fix, to sources that might have changed significantly in the mean time - and then to keep the old build infrastructure working (both monetary, in terms of resources, as well as in human costs of keeping it running, hosts updated, old branches compilable on newer host systems(!)) - and it's 'boring' work (repeating what has already been fixed in the current code multiple times). Backporting might also bring new challenges, which could be potentially dangerous in itself (backporters are rarely specialists on the code they have to touch, they might miss important things when backporting a fix to an older code base, which might even open a bigger hole than the one they ought to fix) - and old issues might have been fixed silently, without anyone noticing that the changes might have fixed a potential security issue by accident - rather than 'just' being a general code improvement.
There is a reason why enterprise distributions (like Red Hat, SuSE, etc.) need to employ more staff on backporting, security and integration testing, than to develop new stuff - this it what costs real money, in chronically scarce human resources.

If your device has fallen of the cliff for minimum system requirements, you really need to plan a hardware replacement soon, very soon. In this modern age there are numerous entities from organized (cyber-) crime to state actors constantly searching for vulnerable devices to add to their botnet inventory. It's gotten 'easy' - and profitable, so it's being done, 24/7, constantly. OpenWrt does not bump the minimum system requirements just for fun, it usually follows practical deprecation of these devices and is quite slow at formally declaring insufficient system resources as being unsupported (typically those devices have been barely able to cope with at least 2+ major releases already). 4/32 devices have been very low-end by around 2012/ 2013 already, if you bought any of them after ~2015, you really only have yourself to blame. If you are still operating any of those, it's time for a replacement, not tomorrow, half a decade ago already(!) - the (only) good aspect of that, viable replacements for those are cheap (especially on the used markets). 8/64 devices are a slightly different topic for now, but you do see the writing on the wall, plan accordingly - this is still an early warning, but their time will come.

The gist of it is, you really want to run the most current -security maintained- code on your border gateway, which does the major job of shielding you from many perils on the open internet, this one does need to be secure and is worth the attention and money needed to keep it current. OpenWrt can extend the (supported) life time of your devices considerably, but there are limits to how far that goes - and those limits will bite you earlier on low-end devices, than on medium- to higher end ones (but you also paid less while purchasing it, so…), so I'd always recommend to make healthy margins to the stated minimum system requirements a buying decision (again, the used markets can be a viable alternative to get better devices for less). Keep track of these margins during the operational life time of your devices and flag anything that's getting marginal early, plan ahead and schedule potential hardware replacements well in time. With some sacrifices in functionality and adapted expectations you can usually even extend the life time of your devices with current OpenWrt quite a bit beyond formal deprecation schedules (dropping features you don't strictly need, e.g. the opkg or the webinterface), but once you hit these hard decisions, the warning bells do chime at full volume, listen to them and plan ahead.

Running older, no longer supported, versions should never be considered an option, not even as APs behind your border gateway(!), as we are constantly seeing security fixes all over the stack, from wireless- to service level vulnerabilities (and browsers/ javascript et al can even attack your devices from the inside to quite some extent) - and there is no one keeping track of the situation for deprecated releases, let alone fixing them.