Is Open Source Router Firmware More Secure Than Stock Firmware?

Often yes, but not because the code is open. Open source router firmware such as OpenWrt is usually more secure than stock firmware on the same hardware when it gives you newer components and faster, longer security updates than the vendor does. If your vendor still ships timely updates, stock firmware with updates turned on can be just as safe. An unpatched router is the risk, whichever firmware it runs.

That is the short answer. The rest of this post explains why stock firmware so often falls behind, what the open projects actually change, what you give up by flashing, how to check whether your router is end of life or listed as exploited, how to flash and roll back without bricking anything, and a minimal secure setup that works on either kind of firmware.

The question is live: one of the most discussed Ask HN threads this month asked whether people would buy a router with DD-WRT preinstalled, and the replies became an argument about which firmware actually gets updates. We answer it here from the projects' own documentation rather than forum memory.

Key takeaways

• Update cadence matters more than license. Open source firmware is safer when, and only when, it gets you security fixes sooner and for longer than the vendor would.
• Stock firmware is often old because it is built on a chipset vendor's software kit that pins the kernel and many libraries.
• OpenWrt publishes a written support policy: a release reaches end of life one year after its first release or six months after the next major release, whichever is later. Package fixes can reach users in about two days; kernel fixes need a new point release.
• You lose things when you flash: some vendor features, sometimes hardware offload and Wi-Fi performance, sometimes warranty, and the ease of a vendor app. Some cheap hardware cannot run current open firmware at all.
• End of life routers are an active target. The FBI warned in May 2025 that criminals are compromising end of life routers with remote administration turned on and selling access to them as proxies.
• Check your model against the vendor's end of life page and CISA's Known Exploited Vulnerabilities catalog before you decide anything.
• Whichever firmware you run: admin interface on the LAN only, remote management off, a strong unique admin password, updates on, and a plan to replace the box when updates stop.

Why is stock router firmware so often old?

A consumer router is a small Linux computer. The firmware on it is a software supply chain: a Linux kernel, a C library, a busybox userland, a DHCP and DNS server, a web server for the admin page, a TLS library, Wi-Fi drivers, and the router maker's own management code on top. Almost all of it is open source. The question is how old each piece is and who is responsible for updating it.

The chipset SDK problem

Router makers rarely build firmware from upstream projects directly. They start from a software development kit supplied by the company that makes the router's main chip and Wi-Fi radios. That kit bundles a specific kernel version, patched heavily so the vendor's drivers work, plus a set of userland tools at whatever versions were current when the kit was frozen. The Wi-Fi drivers and hardware acceleration code are often closed binaries built for that exact kernel.

If the kit ships an old kernel, the router ships with it. Moving forward means a new kit from the chip vendor, porting the maker's code, retesting radios and recertifying. For a modestly priced router already off the shelves, that rarely pays, so the kernel stays put and fixes, if any, are backported one at a time.

We found no primary source measuring shipped kernel ages across the market, so read this as an incentive, not a statistic. You can check your own device: many makers publish GPL source archives that show the kernel version, and on a router with shell access uname -r tells you.

Many stock firmwares are already open source forks

A point several commenters made in the Ask HN thread is worth repeating: a fair amount of stock firmware is itself a fork of OpenWrt or an older open project. That is not a problem in itself. The problem is when the fork diverges from upstream, stops pulling in upstream security fixes, and never rebases. You end up with open source code that is years behind the project it came from. Open source in the box does not mean current open source in the box.

Libraries age too

The userland matters as much as the kernel. The admin web server, TLS library, SSH server, DNS forwarder and UPnP daemon all face the network, and any of them can be years old on a router whose kernel is patched. It is the transitive dependency problem every software team knows, frozen into flash memory and never rebuilt.

How long do vendors patch consumer routers, and what does end of life mean?

There is no common answer, which is part of the problem. Each router maker sets its own support period, and many do not publish one at all at the time of sale. Some publish end of life lists after the fact. Some stop updates quietly.

What end of life means in practice

When a router reaches end of life, the maker stops releasing firmware for it. Security flaws found after that date stay unfixed on that model forever, even when the same flaw is fixed on newer models that share the code. The FBI's May 2025 public service announcement put this plainly: manufacturers stop selling and supporting end of life devices, so those devices no longer receive security patches, and routers from 2010 or earlier are likely unpatched and open to known vulnerabilities. The same notice described a new variant of the TheMoon malware found on end of life routers that had remote administration enabled, with compromised routers sold on as proxy infrastructure so criminals can hide their real location.

End of life routers are not only a criminal problem. In January 2024, CISA and the FBI published a Secure by Design alert aimed at small office and home office router makers, written in response to the Volt Typhoon group compromising those routers and using them as launch points against US critical infrastructure. The alert asked manufacturers to eliminate exploitable defects in web management interfaces, turn on automatic updates by default, place management interfaces on LAN side ports by default, require a manual override before security settings can be removed, and disclose vulnerabilities through the CVE program with accurate weakness classifications.

Read from the buyer's side, each item describes something many routers did not do by default.

Regulation is starting to require a support period

Two regulatory changes push vendors toward stating a support period up front.

In the United States, the FCC adopted the U.S. Cyber Trust Mark in March 2024 as a voluntary cybersecurity label for consumer wireless Internet of Things products, based on NIST criteria. According to CyberScoop's report on the vote, companies using the label must disclose the minimum support period even when the product has none, and the label carries a QR code linking to a page describing the device's current security state. The program has had a rocky start: UL Solutions withdrew as lead administrator effective 19 December 2025, the FCC opened a new application window in January 2026, and Broadband Breakfast reports the FCC selected the ioXt Alliance as the new lead administrator on 13 April 2026. We could not confirm from FCC documents how routers are treated in the program's product scope, so check the label and the registry entry for any specific router rather than assuming.

In the European Union, Delegated Regulation (EU) 2022/30 under the Radio Equipment Directive switched on cybersecurity, privacy and fraud protection requirements for certain internet connected radio equipment. The European Commission says it entered into application in August 2025, and the EN 18031 series of harmonised standards gives manufacturers a route to show conformity. The Commission has since adopted Delegated Regulation (EU) 2026/339 to repeal 2022/30 with effect from 11 December 2027, the date the Cyber Resilience Act's main obligations apply, so those requirements move into the CRA. For a buyer in Europe, this means a router placed on the market since August 2025 should have been assessed against baseline security requirements, and from late 2027 the CRA's vulnerability handling and support period obligations take over.

Neither rule fixes the router you own, but both help you ask "how long will this get updates?" before buying the next one.

What do open firmware projects actually change?

Open firmware projects replace the vendor's whole software stack with their own build, usually on a much newer kernel and with userland packages built from current upstream sources. The useful differences are concrete and documented.

OpenWrt

OpenWrt is the project most people mean when they say open router firmware. Its security page sets out a written lifecycle, which is more than most router makers publish:

• Each major release is fully supported from its first release.
• When the next major release ships, the previous one moves to security maintenance, where only security problems are fixed.
• A release reaches end of life "one year after the initial release, or 6 months after the next major release, whichever date is later."

At the time of writing, OpenWrt's table showed the 25.12 series as supported (with 25.12.6 as the latest point release), 24.10 with a projected end of life in September 2026, and 23.05 at end of life since August 2025. Projected dates can move, and the table covers core packages rather than external feeds.

The same page explains how fixes reach users. Build bots rebuild packages for supported branches when changes land, so a package fix can reach users in about two days. The kernel and kernel modules cannot be updated that way, so a kernel fix needs a new point release and a reflash. OpenWrt's advisories cover only components the project maintains itself; for third party components such as the Linux kernel and OpenSSL, it monitors upstream and backports fixes to supported branches rather than issuing its own advisory for each one.

OpenWrt also runs a handful of automated checks: a weekly scan of package versions against known CVEs, weekly static analysis of components the project writes, and reproducible build checks on the main branch. Several hardening compiler options, including stack protection and RELRO, are on by default.

OPNsense and pfSense CE

OPNsense and pfSense Community Edition are firewall distributions built on FreeBSD. They run on small x86 or ARM appliances and mini PCs rather than on consumer Wi-Fi routers, and most people pair them with separate access points. They come up in the same conversations because the question is the same: who updates the code that faces the internet?

OPNsense's documentation lists Community Edition series numbered x.1 and x.7 each year. The 26.7 series was released on 15 July 2026 on FreeBSD 15.1, and its release notes show point releases roughly every two to four weeks since then, with hotfix builds in between. Those notes are specific: stored cross site scripting fixes, a WireGuard authentication fix, OpenSSL updates, and batches of FreeBSD security advisories folded into point releases.

Netgate's pfSense CE version table shows 2.9.0, released 20 August 2026 on a FreeBSD 16 development snapshot, and 2.8.1 from September 2025 as the supported CE releases, with every earlier CE release marked unsupported. If you run pfSense CE, the practical rule is to stay on one of the releases the table marks as supported.

These are not rankings, just the projects' own records, and they show what matters: you can see what was fixed and when.

DD-WRT

DD-WRT is the oldest of the well known projects and the one the Ask HN thread was about. Its own FAQ, as summarised in search results because the wiki blocked our automated fetch, describes its builds as beta releases with no or limited hardware testing, warns that its router database does not list the newest recommended builds, and points users to per device forum threads to find a known good build. Some commenters in the Ask HN thread argued that DD-WRT adds less security than people expect because it keeps older kernels and closed drivers on some hardware; that is a forum view we could not confirm against project documentation, so check the build notes for your specific device.

What all three have in common

What do you lose by flashing open firmware?

Vendor features. The setup app, parental controls, vendor mesh, cloud remote access and any subscription security service usually disappear. Packages replace some of it.

Hardware offload and Wi-Fi performance. Many routers rely on closed acceleration code to route at full line speed and on vendor tuned radio drivers. Open firmware may use open drivers that perform differently, or may not support the offload engine at all. On a fast fibre line, a router that routes at gigabit speed on stock firmware may route noticeably slower on open firmware. The OpenWrt device page for your exact model is the place to check.

Hardware headroom. Current open firmware needs more flash and RAM than old routers have. OpenWrt's 4/32 warning explains that devices with 4 MB of flash or 32 MB of RAM got their last release in 19.07, and it recommends 16 MB of flash and 128 MB of RAM for current releases. Flashing an underpowered router onto an old, unsupported open firmware release does not make it safer; it just changes who stopped updating it.

Warranty and support. Flashing third party firmware commonly voids the maker's warranty, and the maker's support line will not help. If your internet provider supplied the router, you may not be allowed to flash it at all, and some providers block bridge mode on their own hardware.

Ease. Stock firmware updates itself if you let it. Open firmware puts the update job on you. OpenWrt does not set a root password after installation, and its documentation notes that the LuCI web interface has no built in brute force protection. Those are reasonable defaults for a project whose users are expected to configure things, and a real risk for someone who flashes and forgets.

If you will not log in to check for updates at least monthly, a supported stock router with automatic updates on is likely safer for you than open firmware you never touch.

Is open source itself safer, or is it the update cadence that matters?

It is mostly the update cadence. Open source helps in three specific ways, and none of them is automatic.

First, visibility. When a project publishes its code, advisories and release notes, you and others can see which components it carries and when they were fixed. OpenWrt's advisories, OPNsense's release notes and Netgate's version table are all examples. With a closed firmware image, you often cannot tell which version of a library is inside without taking the image apart.

Second, the ability to rebuild. If a fix exists upstream, an open project can pick it up and ship a new build without waiting for a chipset vendor. That is the main reason open firmware usually runs a newer kernel.

Third, independence: when a maker ends support, the open project may keep building for adequate hardware.

Open source does not make the code free of bugs, and open projects have their own supply chains to protect. A good example is OpenWrt's own advisory from December 2024 about its attended sysupgrade server, the service that builds custom firmware images on request. The advisory, tracked as CVE-2024-54143, describes two flaws that together could have let an attacker get a poisoned image served to other users. According to the advisory, it was reported on 4 December 2024, the official server was stopped and a fix deployed the same day, and build logs from the previous seven days showed no sign of exploitation. That is both a reminder that open infrastructure can fail and a demonstration of what transparency looks like: a dated, public write up with commits.

So the practical test is not "is it open?" It is: who will ship the next fix for this specific device, how quickly, and for how long? Sometimes the answer is the vendor. Sometimes it is an open project. When the answer is nobody, replace the hardware.

How do you check whether your router is end of life or in a known exploited list?

This is the part most people skip, and it takes about ten minutes.

Step 1: identify the exact model and hardware revision

Look at the label on the bottom of the router. Write down the brand, the model and the hardware revision (often "Ver" or "Rev"). Two units with the same model name and different revisions can have different chips and different support status.

Then find the firmware version on the router's status page. If you have shell access on OpenWrt:

cat /etc/openwrt_release
ubus call system board
uname -r

On OPNsense, the console or an SSH session can show the installed version:

opnsense-version

On pfSense CE, the dashboard shows the version and whether an update is available.

Step 2: check the maker's support status

Search the maker's site for "end of life" or "end of support" plus your model. Many makers publish end of life lists. If the newest firmware on the support page is more than a year old and there is no statement either way, treat the device as unsupported until you learn otherwise.

Step 3: check CISA's Known Exploited Vulnerabilities catalog

CISA's KEV catalog lists vulnerabilities that have been exploited in the wild, and it is offered as CSV and JSON. The web page lets you filter by vendor and search by keyword. To search the JSON from a terminal (replace the vendor name with your router's maker as it appears in the catalog):

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[]
      | select(.vendorProject | test("YourRouterBrand"; "i"))
      | [.cveID, .product, .dateAdded, .shortDescription] | @tsv'

Then read each matching entry's product field against your model. KEV entries for routers often name a product family rather than every model, so open the linked vendor advisory to see whether your model and firmware version are in scope. If a KEV entry covers your model and the vendor marks it end of life, there will be no fix. That is the strongest possible signal to replace the device.

Step 4: check the open firmware project's status for your model

For OpenWrt, look up the device in the project's table of hardware and read the device page: whether current releases build for it, any notes about Wi-Fi or offload support, and installation instructions. If the device only appears with an old release, or is listed under the 4/32 warning, open firmware will not give it a supported future.

Step 5: decide

Safe flashing and rollback basics

Flashing is where most people get hurt, usually by skipping steps. The basics below use OpenWrt as the example because its documentation is the most complete; always follow the device page for your exact model and hardware revision.

Before you flash

1. Confirm the exact model and hardware revision matches the image you download. A wrong image is the most common cause of a brick.
2. Download the stock firmware for your model from the maker's site and keep it. You may need it to go back.
3. Read the device page for any special installation method, such as a vendor recovery mode, a TFTP recovery, or a serial console requirement.
4. Write down your internet provider settings (connection type, VLAN tag if any, login details) so you can get back online.
5. Use a wired connection and do it at a time when losing internet for an hour is acceptable.

Use the right image and verify it

OpenWrt offers two image types for most devices. The "factory" image is for the first installation from stock firmware. The "sysupgrade" image is for upgrading a router already running OpenWrt. Using the wrong one is a common mistake.

Verify the checksum before flashing. On a computer:

sha256sum openwrt-*-squashfs-factory.bin
# compare against the sha256sums file published next to the image

On a router already running OpenWrt, the project's command line upgrade guide downloads the image and the checksum file into RAM backed storage and checks them together:

cd /tmp
wget "$DOWNLOAD_LINK"
wget "$SHA256SUMS"
sha256sum -c sha256sums 2>/dev/null | grep OK

If the line for your file does not say OK, stop.

Upgrading an OpenWrt router from the command line

# keep a backup of your configuration first, on another machine
free                       # confirm free RAM is at least twice the image size
sysupgrade -v /tmp/openwrt-*-sysupgrade.bin
# add -n to discard old settings and start clean

The guide warns that the image must be in /tmp, that power cycling during an update can soft brick the device, and that you should wait about five minutes before a hard power cycle if the router does not come back. After the upgrade, reinstall any extra packages you had added and compare any new default config files against yours. The guide recommends the LuCI web interface for less experienced users and points to the owut tool for an assisted command line upgrade.

If it goes wrong: failsafe mode and factory reset

OpenWrt's failsafe mode boots the router with basic defaults so you can repair a bad configuration. Per the project's documentation, you press any button during a short window in early boot (about four seconds on 24.10 and later, two seconds on 23.05 and earlier), set your computer to a static address in 192.168.1.0/24, connect by cable and reach the router at 192.168.1.1. From there:

mount_root          # mount the overlay so you can fix settings
firstboot           # or reset all settings to defaults
reboot

Failsafe cannot fix faulty hardware or a broken kernel. A soft factory reset from a working system is firstboot && reboot, and holding the reset button for about ten seconds on devices that have one does a hard reset.

Going back to stock

Returning to stock is model specific (recovery mode, a stripped image or TFTP), so follow the device page and keep the stock image you saved earlier.

A minimal secure setup, either way

Whether you stay on stock firmware or flash open firmware, these settings do most of the work. They track the FBI's May 2025 advice and the CISA and FBI Secure by Design alert.

On any firmware

1. Update first. Install the latest firmware before you do anything else, and turn on automatic updates if the firmware offers them.
2. Admin interface on the LAN only. The web admin page and SSH should not be reachable from the internet. Turn off remote management, remote administration and cloud remote access unless you have a specific need and understand how it is protected.
3. Strong unique admin password. The FBI recommends unique, random passwords of 16 to 64 characters. Change the default admin password even if the router printed a "unique" one on its label.
4. Turn off what you do not use. WPS, UPnP, remote management, guest access you never use, and any file sharing or media server features. Each one is more code facing the network.
5. WPA2 or WPA3 for Wi-Fi with a long passphrase. Use WPA3 where all your devices support it.
6. Separate the house. Put work laptops on one network and smart TVs, cameras and guests on another. Many routers call this a guest network.
7. Watch for signs of compromise. The FBI lists overheating, connection problems and settings you did not change. If you see them, update the firmware, change passwords and reboot; if the device is end of life, replace it.
8. Put a replacement date in your calendar. When the vendor's or project's support ends, the router has to go.

Extra steps for OpenWrt

passwd                                  # set a root password; none is set after install
uci show dropbear                       # review SSH settings
uci set dropbear.@dropbear[0].Interface='lan'
uci set dropbear.@dropbear[0].PasswordAuth='off'   # after you add an SSH key
uci commit dropbear
/etc/init.d/dropbear restart
uci show uhttpd | grep listen           # confirm the web UI listens where you expect

Only turn off password logins after you have added your SSH public key and confirmed you can log in with it. Because LuCI has no built in brute force protection, keep it off the WAN entirely rather than relying on a strong password alone.

Check from the outside

From a phone on mobile data (not your home Wi-Fi), try to open your public IP address in a browser on ports 80, 443 and 8080. You should get nothing. If you see a login page, remote administration is on somewhere, possibly on a provider supplied modem in front of your router.

Where Safeguard fits, and where it does not

Router firmware is a software supply chain problem: old open source components frozen into a device. That makes the thinking behind supply chain security useful here, but Safeguard's direct fit for a home router is limited, and it is better to say so plainly.

Safeguard does not analyse router firmware images, does not flash or update routers, and does not tell you whether a specific home router is safe.

What it can do is narrower. If a device maker provides a software bill of materials (SBOM) for a product, Safeguard can analyse that SBOM, track the components and versions it lists, and match them against vulnerability databases so you can see which known vulnerabilities affect those components over time. From the CLI that is safeguard scan --sbom vendor-sbom.json, with results written as JSON under ./output, and the platform shows which of your products contain a given component and version. That is most useful for a small business or IT team buying network equipment from vendors who publish SBOMs, which few consumer router makers do today. The Cyber Trust Mark asks labelled products to say whether an SBOM is included, so this may become more common.

For a home user the fit is indirect: the habits carry over (know what is inside, know who ships the next fix, replace what nobody will fix), but the tool does not. Our guides on firmware supply chain security and SBOMs for firmware and IoT devices go deeper on devices.

Common mistakes

• Flashing the wrong hardware revision. Same model name, different chip. Always match the revision on the label to the device page.
• Using the factory image to upgrade, or the sysupgrade image to install. They are not interchangeable on most devices.
• Flashing an underpowered router onto an old open release. If the newest open firmware for your model is itself end of life, you have not gained anything. OpenWrt 19.07 was the last release for 4/32 devices.
• Flash and forget. Open firmware without updates ages exactly like stock firmware without updates. Package updates on OpenWrt also do not update the kernel; you still need point releases.
• Leaving the OpenWrt root password unset. No password is set after installation. Set one immediately.
• Exposing LuCI or SSH to the WAN "just for a minute". Scanners find it within that minute.
• Ignoring the provider's modem. Your router can be locked down while a provider supplied modem in front of it has remote management on. Check both.
• Keeping an end of life router because it "still works". The FBI's May 2025 warning is about exactly those routers.

FAQ

Is OpenWrt safer than my router's stock firmware?

It usually is when OpenWrt supports your model on a current release and you install updates, because it tends to carry a newer kernel and gets package fixes in about two days. If your maker still ships timely updates and you have them on, stock firmware can be just as safe. The deciding factor is who updates the code, and how often.

Is DD-WRT still safe to use in 2026?

It can be, on hardware where current builds are maintained, but check the build notes for your specific device. DD-WRT's FAQ describes its builds as betas with limited hardware testing and says its router database is not a reliable guide to recommended builds. Some forum users argue that older kernels persist on some devices; we could not confirm that against project documentation.

Does flashing open source firmware void my router's warranty?

Often it does, and the maker's support team will not help with a flashed device. Read the warranty terms first. If the router came from your internet provider, check whether you are allowed to flash it at all.

How do I know if my router is end of life?

Search the maker's support site for "end of life" plus your model and hardware revision. If no firmware has been released for over a year and the maker says nothing, treat it as unsupported. Then check the model in CISA's Known Exploited Vulnerabilities catalog.

Should I replace my router if it is in CISA's KEV catalog?

If your model and firmware are covered by a KEV entry and the maker has released a fix, install the fix now. If the maker has marked the router end of life and there is no fix, replace it. Until you do, turn off remote management and any internet facing features.

What router settings matter most for security?

Up to date firmware, remote management off, the admin page reachable only from your local network, a long unique admin password, WPS and UPnP off unless you need them, and a separate network for smart home devices and guests.

Does the Cyber Trust Mark mean a router is secure?

It means the product met a baseline set of NIST based criteria and disclosed things such as its minimum support period. It is voluntary, it does not guarantee a device has no flaws, and we could not confirm from FCC documents exactly how routers fit its scope. Use the support period on the label to plan when to replace the device.

Can I go back to stock firmware after installing OpenWrt?

Usually, yes, but the method is model specific. Some devices accept the vendor image through recovery mode; others need a special image or a TFTP recovery. Keep the stock firmware file you downloaded before flashing, and follow the device page.

Fix it without waiting for upstream

A router is a case where you mostly do have to wait for upstream, because the fix has to come from the maker or the firmware project. The software you build and ship is different. The same old open source components that sit frozen in router firmware also sit in your applications and container images, and there you do not have to wait.

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.

Related reading

• Home router security checklist for remote developers
• How to pick a Wi-Fi router for working from home securely
• D-Link end of life routers: command injection and buffer overflow
• Is it safe to self host apps on the internet?

If you want to try the scanning side on your own code or on an SBOM a vendor has given you, you can download Safeguard and read the CLI documentation.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install it, open the interactive terminal with safeguard, 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 your approval, prints a summary and pushes nothing. Nothing here touches a router; it shows the fix loop for software you build, the part of the supply chain you can patch yourself.

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

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. If a vendor has handed you an SBOM for a device or appliance, this is the kind of setup you would scan it from, with the file staying on hardware you control.

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 shows how you choose which Safeguard tools Claude can use. It is useful when you want to ask plain language questions about components and vulnerabilities in SBOMs you have already uploaded, without opening the dashboard.

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

Quick check

Sources

• OpenWrt: Security (support periods, advisories and update process)
• OpenWrt: Advisory 2024-12-06-1, attended sysupgrade server, CVE-2024-54143
• OpenWrt: Upgrading from the command line with sysupgrade
• OpenWrt: Failsafe mode, factory reset and recovery
• OpenWrt: 4/32 devices warning
• OPNsense documentation: Support tiers
• OPNsense documentation: Releases
• OPNsense documentation: 26.7 release notes
• Netgate: pfSense software versions
• DD-WRT: Firmware FAQ
• CISA and FBI: Secure by Design Alert, security design improvements for SOHO device manufacturers
• CISA: Known Exploited Vulnerabilities Catalog
• FBI IC3: Cybercriminal services target end of life routers (PSA, 7 May 2025)
• FCC Public Notice DA 26-18: Cyber Trust Mark lead administrator filing window
• CyberScoop: FCC approves the U.S. Cyber Trust Mark
• Broadband Breakfast: FCC picks ioXt Alliance to head Cyber Trust Mark program
• European Commission: Radio Equipment Directive (RED)
• Ask HN: Do you want a router that has DD-WRT pre-installed?

Last reviewed: 23 October 2026. Firmware support tables and regulatory programmes change; check the linked project pages and regulators for current status.