ASUS Router Flaws CVE-2026-93489 and CVE-2026-75775 Explained

On 23 October 2026 ASUS fixed three High rated flaws in routers running its 3.0.0.6_102 firmware series: an authentication bypass (CVE-2026-93489) and two root command injections (CVE-2026-75775, CVE-2026-75779). No exploitation is reported and none is in CISA's KEV catalog. Update the firmware, keep the admin page off the WAN, and keep untrusted devices off the network.

ASUS did not publish a list of affected models or the build numbers that contain the fix. That gap is the most practical problem for anyone who manages these routers, and much of this post is about working around it. It is also the fifth ASUS router firmware bulletin of October 2026, so a router that was last updated at the start of the month has missed several rounds of fixes, not one.

What happened

ASUS published a security bulletin titled "Security Update for ASUS Router Firmware" on its security advisory page on Friday 23 October 2026. The bulletin's data record (entry 3127 in the advisory API) shows a publication time of 05:52:03 UTC and an update at 08:05 UTC. The ASUS RSS feed carries the same item, stamped 13:52:03 in Taipei time (UTC+8).

The bulletin lists one affected product line, "3.0.0.6_102 series", and three CVEs, all assigned by ASUS acting as its own CVE Numbering Authority:

• CVE-2026-93489, improper authentication (CWE-287). The CVE record says an unauthenticated nearby user can send an HTTP request, forge an access ticket and then perform administrator operations. CVSS 4.0 base score 8.7, High.
• CVE-2026-75775, OS command injection (CWE-78). A user on the adjacent network can run arbitrary commands with root privileges by sending crafted parameters while the router is in its factory default state. CVSS 4.0 base score 7.7, High.
• CVE-2026-75779, OS command injection combined with cross site request forgery (CWE-78 and CWE-352). If a logged in administrator visits a malicious website, the router can be made to execute arbitrary commands as root. CVSS 4.0 base score 8.6, High.

All three CVE records credit a single finder, the researcher who publishes as MrBruh. His site, checked on 25 October, lists earlier ASUS findings (including CVE-2025-3463 in ASUS DriverHub and CVE-2025-4569) and router work on other brands, but no write-up for these three CVEs. Nothing in this post about how the flaws work goes beyond what ASUS and the CVE records state.

ASUS's prose in the bulletin focuses on the authentication flaw: "an unauthenticated attacker on an adjacent network may gain administrative access to the router." It then asks all users to update to the latest firmware immediately and lists four fallback steps for anyone who cannot.

Timeline

Times are UTC, from the sources named, fetched 25 October 2026.

What NVD has not done yet matters more; see Technical details.

Five router bulletins in one month

The ASUS advisory API lists five router firmware bulletins between 1 and 23 October, covering eleven CVEs:

All are CVE-2026 IDs. Bulletin 3121 covers only the 3.0.0.4_386 and 3.0.0.4_388 lines.

Nine of the eleven touch the 3.0.0.6_102 series. Treat any router on that series not updated since 23 October as behind.

Who is affected

ASUS names a firmware series, not a list of models. The bulletin says "3.0.0.6_102 series" and the CVE records say the same (one record writes it "3.0.0.6_102 series", the other two "3.0.0.6.102 series"). The CVE records set every other version to "unaffected" by default, which tells you only that ASUS does not consider its 3.0.0.4 lines affected by these three issues.

TechPowerUp describes the affected devices as ASUS's latest Wi-Fi 7 router lineup. ASUS's own October records support that reading only in one place: CVE-2026-19396, published 7 October against the 3.0.0.6_102 series, names the RT-BE57, a Wi-Fi 7 model. We could not retrieve per model firmware listings from ASUS's support site in a form we could verify, so we are not publishing a model list. If you own an ASUS router with "BE" in its model name, or a ZenWiFi BQ or BT mesh system, check its support page and its admin interface rather than relying on any list in the press.

One more group deserves attention. ASUS's end of life list for networking products, fetched 25 October, includes the RT-BE58U for the EU market only, with the RT-BE58U V2 among the recommended replacements. A device on the end of life list is no longer updated with firmware. ASUS did not say whether that model runs the 3.0.0.6_102 series, but the general point stands: confirm your model is still supported before assuming a fix is coming.

The people with most to do are home office and small business users who set a router up once and never look again, remote workers whose home router carries corporate traffic, managed service providers holding admin credentials for many client sites, and anyone setting up a new, reset or refurbished unit, because CVE-2026-75775 applies to the factory default state.

How the three flaws work, in plain language

None of the three has a public proof of concept, and ASUS has not published technical detail beyond the CVE text. What follows explains the conditions each one needs, which is what decides your exposure. It does not describe how to trigger them.

CVE-2026-93489: the authentication bypass

Routers like these hand a session token, which ASUS's CVE text calls an "access ticket", to a browser or companion app after a successful login. The router then trusts requests that carry a valid ticket as coming from the administrator. CVE-2026-93489 means someone who can reach the router's web service from the local side can produce a ticket the router accepts without knowing the password, and then act as the administrator.

The CVSS 4.0 vector is AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H. Read in order: the attacker must be on the adjacent network (the LAN or Wi-Fi), the attack is not complex, there are no special preconditions, no privileges or user interaction are needed, and the impact on the router's confidentiality, integrity and availability is high. That makes it the most serious of the three for any network where you do not fully trust every connected device. A guest on your Wi-Fi, a compromised smart TV or a malware infected laptop all sit on the adjacent network.

CVE-2026-75775: command injection in the factory default state

This one lets a user on the adjacent network run commands as root by sending crafted parameters, but only while the router is in its factory default state. The vector reflects that: AT:P (attack requirements present) is the only difference from CVE-2026-93489's opening terms, and it lowers the score to 7.7.

Why does a factory default state matter? A router is in that state when it is new out of the box, after a reset button press, after a "Restore" to factory defaults in the admin page, and often when it comes back from repair or is sold refurbished. In that window the router is waiting for someone to run its setup wizard, and the setup service has to accept requests before any admin password exists. The CVE text does not go further than that, and neither will we. The defender's lesson is simple: the minutes between unboxing or resetting a router and finishing its setup are a period of exposure, so do them on a network you control.

There is an awkward interaction with ASUS's own guidance here. ASUS's firmware update FAQ recommends restoring factory defaults after a firmware update. Doing that after you have installed the fixed firmware is fine, because the fixed firmware is what runs during the second setup. Doing it before you update, or setting up a new unit whose factory firmware predates 23 October, is exactly the window this CVE describes.

CVE-2026-75779: cross site request forgery into command injection

This is the only one of the three that is reachable from the internet in the CVSS sense (AV:N), but it needs an administrator who is logged in to the router's web interface and who then visits a malicious website (UI:A, active user interaction). The router fails to check that a request really came from its own admin page, which is the cross site request forgery part, and the request reaches code that passes input to the operating system shell, which is the command injection part. The result is commands running as root on the router.

The practical defence is the same as for most router CSRF bugs: do not browse other sites while you are logged in to the router, log out when you are done, and use a separate browser profile for device administration. The real fix is the firmware.

Why "adjacent" does not mean "safe"

Two of the three need adjacency. It is tempting to read that as low risk, and TechPowerUp notes that the adjacent condition "somewhat mitigates the threat". That is fair for a single person at home with no guests. It is less fair for:

• Offices with guest Wi-Fi that is not isolated from the management network.
• Shared buildings where a neighbour can join a weak Wi-Fi password.
• Any network with one already compromised device, because malware on a laptop or IoT device is adjacent by definition.
• Remote workers' homes, where family devices share the network with a work laptop.

A router compromised from the inside can change DNS settings, open ports, add VPN or remote access configuration and watch traffic. Those are the reasons ASUS's mitigations include removing unrecognised linked devices and companion app sessions.

Technical details

This section collects the specifics published by ASUS, CVE.org and NVD, as fetched on 25 October 2026. Every value here comes from those records.

CVE records

Two details in this table matter for tooling:

1. The version string is not consistent. One record uses an underscore (3.0.0.6_102) and two use a dot (3.0.0.6.102). ASUS's admin pages and download files typically show firmware as dotted numbers. If you write a detection rule or an inventory query that string matches the affected version, match both forms.
2. There is no fixed version in any record. The records list an affected series and nothing else. A scanner that relies on a "fixed in" field will have nothing to compare against.

NVD status

NVD received all three CVEs at 08:16:55 UTC on 23 October and marked them "Awaiting Analysis". As of 24 October 04:18 UTC, NVD shows only the CNA's CVSS 4.0 vectors (as a secondary source), the single ASUS reference and no CPE configurations. Without CPE configurations, tools that map devices to CVEs through NVD product identifiers will not flag any ASUS router for these CVEs until analysis is complete. That is a common blind spot for network device CVEs and a good reason not to wait for a scanner to tell you about them.

Known exploited status and exploitation

The CISA KEV catalog version 2026.10.23, released at 19:30 UTC on 23 October with 1,756 entries, does not include CVE-2026-93489, CVE-2026-75775 or CVE-2026-75779. It also does not include any of the eight other October ASUS router CVEs. KEV does list three older ASUS entries: CVE-2021-32030 (router improper authentication, added 2 June 2025), CVE-2023-39780 (RT-AX55 command injection, added 2 June 2025) and CVE-2025-59374 (Live Update, added 17 December 2025).

ASUS does not report exploitation of the three new CVEs, and none of the sources we fetched does either. A security vendor's CVE database page listed an EPSS score of 0.19 percent for CVE-2026-93489 on 24 October, which is low, but EPSS on a two day old CVE with no public details mostly reflects how little is known.

The older entries are the useful warning. CVE-2021-32030 is also an ASUS router authentication flaw, and it reached KEV years after disclosure because attackers kept finding unpatched devices. We covered it in CVE-2021-32030 and ASUS routers in the KEV catalog.

What ASUS publishes and what it does not

There are no indicators of compromise, hashes, domains or IP addresses in any primary source for these CVEs. Anyone offering IOCs for them on 25 October is guessing.

The October 3.0.0.6_102 picture

Six earlier October CVEs also name the 3.0.0.6_102 series. From the CVE records:

Several of the earlier flaws need an authenticated session. CVE-2026-93489 removes that requirement for anyone on the local network. No source says they have been combined. The defensive reading: a bypass makes every "authenticated" bug on the same firmware more urgent, so install the latest build.

ASUS mitigations, side by side

Fallback advice differs between bulletins (ASUS advisory API):

The 7 October bulletin also warns against untrusted links and untrusted configuration backups; 20 October adds guest isolation, disabling unused FTP and end of life guidance.

The 23 October bulletin is the first to tell users to review linked devices and companion app sessions. That fits an authentication flaw: if someone obtained admin access, a linked session is one way they might keep it.

What to do now

Work through this list in order. Steps 1 to 4 apply to everyone; the later steps are for people who manage more than one router.

For anyone with an ASUS router

1. Find your firmware version. As ASUS's firmware FAQ shows, connect to the router by cable or Wi-Fi, open its LAN IP or http://www.asusrouter.com, sign in, and go to Administration, then Firmware Upgrade. Note the firmware version listed there. If it begins 3.0.0.6.102, this bulletin applies to you. If it begins 3.0.0.4.386 or 3.0.0.4.388, the 1, 7 and 20 October bulletins apply instead.
2. Install the latest firmware. ASUS's update FAQ describes three methods: automatic upgrade on a schedule (Administration, Firmware Upgrade, Auto Firmware Upgrade), the "Update now" prompt in the admin page, and a manual upload of a file downloaded from the model's support page. If the router reports it cannot reach the ASUS server, use the manual method. Do not power the router off during the upgrade.
3. Reboot, then review linked devices and app sessions. ASUS asks for a reboot after updating. Then open the router's list of connected clients and any section listing linked companion app devices, and remove anything you do not recognise.
4. Turn off remote access from the WAN unless you have a specific need for it. The setting is in the Administration area of the admin interface. If you must manage remotely, use a VPN into your network rather than exposing the admin page.
5. Set a new admin password if the current one is short, reused or the original one written on a sticker. ASUS asks for at least 10 characters with uppercase letters, numbers and symbols. Do the same for the Wi-Fi password if guests or former tenants may know it.
6. Separate guests. Put visitors and IoT devices on the guest network with access to the local network turned off, so they are not on the same adjacent network as the admin interface.
7. Turn on automatic firmware upgrades if you are comfortable with the router restarting at a scheduled time. Five bulletins in a month is a strong argument for it.

If you are setting up a new, reset or refurbished router

Because CVE-2026-75775 applies in the factory default state:

1. Set it up with a single computer connected by cable and nothing else attached, Wi-Fi clients included.
2. Before connecting other devices, update to the latest firmware for your model, either through the setup wizard's update step or a manual upload.
3. If ASUS's FAQ advice leads you to reset to factory defaults after updating, repeat the same isolated setup; you are now running the fixed firmware.
4. Only then connect the rest of the network and set the admin and Wi-Fi passwords you will keep.

For IT and security teams

1. Look for ASUS routers you do not know about. Check DHCP leases and network discovery tools for devices whose MAC address vendor is ASUS and whose role is a gateway. For remote workers, ask; most of these devices are bought personally.

2. Check for exposed admin interfaces from outside. From an external host, test whether any public address you own answers on the router admin ports. For example, against your own address ranges only:

   nmap -Pn -p 80,443,8080,8443 --open 203.0.113.0/28
   curl -skI https://203.0.113.10:8443/ | head -5
   

   Replace the documentation addresses with your own ranges. A login page from an ASUS router on a public address means remote access from the WAN is on.

3. Do not wait for your vulnerability scanner. NVD had not assigned CPE configurations as of 24 October, so CPE driven scanners may not report these CVEs on ASUS devices yet. Track them manually against the firmware versions you recorded.

4. Write it into policy. For home office routers that carry corporate traffic, set a minimum expectation: supported model, automatic updates on, no WAN administration, guest isolation on. Publish it with a short how to.

5. Track the device as an asset. Record model, firmware version, owner and last update date for every router you are responsible for, so the next bulletin takes minutes to assess.

If you suspect the router was already tampered with

There are no published indicators of compromise for these CVEs. General signs that a router's configuration was changed include unfamiliar DNS servers, port forwarding rules or DMZ settings you did not create, VPN server or client profiles you do not recognise, remote access from the WAN switched on, and unknown linked app devices. If you see these, update the firmware first, then restore factory defaults and set the router up again by hand rather than restoring a configuration backup that may carry the changes. ASUS's 7 October bulletin warns against restoring backups from untrusted sources for a related reason. Change the passwords of accounts used from that network afterwards if you believe traffic may have been intercepted.

What to ask ASUS or your reseller

Fair questions for ASUS support or your distributor:

• Which models run the 3.0.0.6_102 series, and which build for each model contains the fixes for CVE-2026-93489, CVE-2026-75775 and CVE-2026-75779?
• Do those builds also contain the fixes from the 1 and 7 October bulletins?
• What firmware ships on units currently in the channel, and will new stock carry the fixed build?
• Will ASUS publish release notes that map CVEs to builds in future bulletins?
• Is the model you use on the end of life list in your region, and when does support end?

What changed since first reports

• Severity wording. Headlines on 24 October called the issue "critical". ASUS rates all three High (7.7, 8.6 and 8.7). The October CVEs ASUS rated Critical are CVE-2026-14157 (9.4), CVE-2026-14911 (9.3) and CVE-2026-19386 (9.3), from the 1 and 7 October bulletins.
• Which CVE is the bypass. Notebookcheck's 24 October story attributes the "admin access without authentication" description to CVE-2026-75775. The CVE records say that description belongs to CVE-2026-93489; CVE-2026-75775 is the factory default command injection.
• Count of bulletins. Some coverage counted three ASUS router bulletins in October. The advisory API shows five, two of them on 1 October.

Open questions

• Which models are affected, and which builds contain the fix? ASUS has not said.
• Does the fix for CVE-2026-75779 apply to one model only? Its CVE record describes "an ASUS router model".
• Will the researcher publish details, and on what schedule? His site had no write-up on 25 October.
• Will NVD's analysis add CPE configurations that list specific models?
• Are routers sold through ISPs or in other regions on the same series and the same fixes?

What would have helped

None of this is about blame. Router vendors ship firmware into millions of homes they cannot see, and users have good reasons not to think about their router. The practices below are what any team can put in place before the next bulletin.

Practices any team can use

• An inventory that includes network edge devices. Model, firmware version, owner, location and support status for every router and gateway you are responsible for, including those in branch offices and, where policy allows, home offices. When a bulletin names a firmware series instead of models, an inventory keyed on firmware version answers "are we affected?" directly.
• Automatic firmware updates where the device supports them. ASUS routers can update on a schedule. For small sites without on site IT, a scheduled update overnight beats a perfect manual process nobody runs.
• No management interfaces on the internet. Remote access from the WAN was a fallback mitigation in three of October's five bulletins. Manage through a VPN or a vendor's cloud console instead of an open admin page.
• Segmentation of the adjacent network. Guest isolation and separate networks for IoT reduce who counts as "adjacent". Two of the three new CVEs need adjacency.
• Setup hygiene for new and reset devices. A checklist for unboxing and resets: wired, isolated, update first, then connect. CVE-2026-75775 is a reminder that the factory default state is part of a device's attack surface.
• A lifecycle policy. Replace devices that leave support; ASUS's end of life list includes recent models in some regions.
• Manual tracking for CVEs without CPE data. Assign someone to read vendor advisories for the edge devices you own. Many network device CVEs arrive with no product identifiers, so scanners that depend on them stay quiet.

Where Safeguard fits

Safeguard does not analyse router firmware, does not scan ASUS routers or other network devices, and would not have detected or prevented these flaws. It cannot push firmware to a router or tell you which ASUS models are affected. If your question is "which of my routers is vulnerable?", the answer comes from your network inventory and ASUS's support pages, not from Safeguard.

Where Safeguard does help is in the software you build and ship, and in the governance around suppliers:

• The software you build. safeguard scan --dir . inventories a source repository, safeguard scan --image <name> does the same for a container image, and safeguard scan --sbom <file> loads an SBOM you already have. Components are matched against vulnerability databases and results land as JSON under ./output. Reachability analysis helps rank which vulnerable code paths your application actually calls.
• Finding a component across projects. The platform shows which projects contain a given component and version, so "do we ship this library anywhere?" becomes a search.
• Policies and gates. Policies and gates evaluated in the platform can stop a release that carries a known vulnerable version.
• SBOMs you receive. If a network or device supplier gives you an SBOM for its firmware, you can load it with --sbom and keep it alongside your own projects. That shows the open source components the supplier declared; it does not test the firmware itself.
• Supplier records. The compliance suite includes a Vendors area and questionnaires, so you can record a network equipment supplier and track its answers to questions like those in the "What to ask" section above.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. ASUS router firmware is proprietary vendor firmware, which is outside what it covers, so it has no bearing on these CVEs.

Gold Open Source at gold.safeguard.sh is free and needs no login. It gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version for open source packages. It does not track proprietary router firmware builds, and for these three CVEs ASUS has published no fixed version for anyone to show.

The habit that carries over is the general one: pull patched components from a curated source and rebuild quickly, so the open source parts of your own products are never the slow link when a fix exists.

Common mistakes

• Treating "adjacent" as "harmless". A guest, a neighbour on a weak Wi-Fi password or one infected device is enough.
• Updating once and stopping. Five ASUS router bulletins landed in October. One update on 2 October did not cover the later fixes.
• Resetting before updating. A factory reset on old firmware opens the exact window CVE-2026-75775 describes. Update first.
• Waiting for the scanner. Without NVD CPE data, many tools will not flag these CVEs on ASUS devices yet.
• Trusting a model list from a forum or headline. ASUS has not published one. Check your own device's version.

FAQ

Which ASUS routers are affected by CVE-2026-93489?

ASUS says routers on the 3.0.0.6_102 firmware series and has not published a model list. Check the firmware version in your router's admin page. If it begins 3.0.0.6.102, treat it as affected until it runs the latest firmware for your model.

Is CVE-2026-93489 being exploited?

No exploitation is reported by ASUS or any source we checked, and the CVE is not in CISA's KEV catalog as of the 23 October 2026 catalog release. No public proof of concept exists. That can change once technical details become public, so update now rather than waiting.

What firmware version fixes these CVEs?

ASUS does not name one. Its guidance is to install the latest firmware for your model from the router's update page or the ASUS support site. Record the version you install so you can compare it with any build numbers ASUS publishes later.

Are these flaws critical?

ASUS rates all three High: CVE-2026-93489 at 8.7, CVE-2026-75779 at 8.6 and CVE-2026-75775 at 7.7 under CVSS 4.0. Some headlines used "critical". The October ASUS router CVEs rated Critical are three different ones from 1 and 7 October.

Can someone on the internet exploit these?

CVE-2026-93489 and CVE-2026-75775 need the attacker on the adjacent network, meaning your LAN or Wi-Fi. CVE-2026-75779 is network reachable but needs a logged in administrator to visit a malicious site. Turning off remote access from the WAN and logging out of the admin page reduce exposure further.

Why does the factory default state matter for CVE-2026-75775?

The flaw only applies while the router is waiting to be set up: new out of the box, after a reset, or refurbished. Set up such devices with one wired computer and nothing else connected, and update the firmware before you connect other devices.

My router is on 3.0.0.4_386 or 3.0.0.4_388. Am I safe?

Not from October's other bulletins. ASUS published fixes for those lines on 1, 7 and 20 October. These three CVEs do not list them, but the update advice is the same: install the latest firmware for your model.

Does Safeguard detect these ASUS router flaws?

No. Safeguard does not analyse router firmware or scan network devices. It inventories and matches the software you build, the container images you ship and the SBOMs you hold. For ASUS routers, use your network inventory and ASUS's support pages.

Fix it without waiting for upstream

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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.

See how Safeguard would have helped

None of these demos shows an ASUS router, and Safeguard cannot update router firmware. They show the workflows that apply to the software side of an incident like this one: the code and configuration your team owns.

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, and runs npm install and npm test with approval, pushing nothing. For this incident, the same loop fits a repository where your team keeps network device standards or provisioning scripts: you could ask it to add a check that flags any ASUS router record whose firmware begins 3.0.0.6.102 and was last updated before 23 October.

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

The runner demo shows setting up the Safeguard runner on your own machine, approving it with its device code, and scanning from the terminal. If you build software that runs on network equipment, or receive SBOMs from a device supplier, an internal build host is where you would scan those images and SBOMs and read the JSON under ./output.

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

The Claude demo shows connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. On a busy bulletin week like this one, a security lead could ask Claude which projects in the platform carry a given component and version, so the software side of the review takes minutes while the network team works through the routers.

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

To try it on your own builds, download Safeguard and follow the CLI docs. For related reading, see CVE-2021-32030 and ASUS routers in the KEV catalog, edge device zero-days in October 2026, the edge device access broker campaign and WPSplinter, the Broadcom WPS router flaw with no CVE.

Quick check

Sources

• ASUS Security Advisory page
• ASUS security advisory API: bulletins 3127 (23 Oct), 3121 (20 Oct), 3120 (7 Oct), 3119 and 3118 (1 Oct)
• ASUS security advisory RSS feed
• CVE.org: CVE-2026-93489
• CVE.org: CVE-2026-75775
• CVE.org: CVE-2026-75779
• NVD: CVE-2026-93489
• NVD: CVE-2026-75775
• NVD: CVE-2026-75779
• CVE.org: CVE-2026-13313
• CVE.org: CVE-2026-14157
• CVE.org: CVE-2026-14911
• CVE.org: CVE-2026-16528
• CVE.org: CVE-2026-19386
• CVE.org: CVE-2026-19396
• CVE.org: CVE-2026-17518
• CVE.org: CVE-2026-75753
• CISA Known Exploited Vulnerabilities catalog (JSON feed)
• ASUS FAQ: How to update the firmware of your router to the latest version (Web GUI)
• ASUS Networking End-of-Life product list
• MrBruh's blog (credited researcher)
• TechPowerUp: ASUS rushes out Wi-Fi 7 router firmware update (24 Oct 2026)
• Notebookcheck: Asus rushes out router firmware update (24 Oct 2026)
• CVE database page with EPSS for CVE-2026-93489

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.