Security researchers publish hardware teardowns all the time. Compliance teams rarely read them. They should.

A recent write-up walked through a full hardware-hacking workflow on a Mercusys MB115-4G — at the time of the research, the best-selling router on Amazon Spain — from a root shell over the serial interface and a firmware extraction to a pre-authentication stack buffer overflow. The researcher followed coordinated disclosure, the 90-day window elapsed, and the vendor issued a patch. As security research, it is careful, well-documented work.

At Kokobo we read findings like these through a different lens. In the EU, a pre-auth overflow in a connected product is not just a CVE — it is a compliance event. This particular device sits at the intersection of two regulatory regimes: the Radio Equipment Directive’s cybersecurity requirements, implemented through the EN 18031 standards, and the Cyber Resilience Act (CRA). The same handful of findings looks quite different depending on which regime you hold them up against. Here is why a device in this state would face real questions under both.

This analysis is based on publicly published security research and is written to illustrate regulatory exposure. It is not a formal conformity determination, and the manufacturer has since remediated the reported vulnerability.

The findings that matter for compliance

Three observations from the research carry regulatory weight:

• A pre-authentication stack buffer overflow reachable on the device’s management interface — memory corruption reached before any login.
• An unauthenticated root shell exposed over the UART (serial) interface, which is how the firmware was pulled off the device.
• Confusing firmware versioning on the vendor’s download page, with no clear indication of which release was actually current.

A 4G/Wi-Fi router is radio equipment and a product with digital elements, so both EU regimes are in play at once.

The EN 18031 / RED angle — the one that bites today

The RED cybersecurity requirements — Article 3.3(d), (e) and (f), activated by Delegated Regulation (EU) 2022/30 — have been mandatory for radio equipment placed on the EU market since 1 August 2025. The harmonised standards that grant a presumption of conformity, the EN 18031 series, were cited in the Official Journal in January 2025, with restrictions.

For a router carrying user traffic, two parts apply: EN 18031-1 (network protection, Article 3.3(d)) and EN 18031-2 (privacy and personal data, Article 3.3(e)). Mapping the findings against them:

• The pre-auth overflow fails several EN 18031-1 mechanisms simultaneously — the Access Control Mechanism (it is bypassed before authentication is ever reached), resilience, and the general expectation that equipment ship without known exploitable vulnerabilities and with a minimised attack surface. More fundamentally, Article 3.3(d) exists to stop radio equipment being turned against the network it connects to. A pre-auth remote code execution turns the router into precisely that.
• The open root UART is an access-control finding on a debug interface. Physical-access scoping gives a manufacturer some room to argue severity, but an unauthenticated root console is the kind of thing that needs a justification most budget devices cannot supply.
• The versioning confusion undermines the Secure Update Mechanism narrative: if you cannot establish which firmware is current, you cannot demonstrate that units leave the shelf on a secure, patched version.

Two points make this sharper than an ordinary bug list. First, one EN 18031 restriction removes the presumption of conformity outright if a product lets the user operate without setting a password — a common shortcut on inexpensive routers. If that is the case here, the presumption is lost on its own, no overflow required, and the product is pushed toward a Notified Body assessment. Second, a presumption of conformity is rebuttable: a demonstrated pre-auth RCE is exactly the kind of evidence that rebuts it, and market surveillance authorities can respond with corrective action, withdrawal or recall. Because RED applies to units placed on the market from August 2025, a device still selling in volume today is exposed now — not at some future date.

The CRA angle — the one that is coming

Under the Cyber Resilience Act, a consumer router is not a default-tier product. Annex III lists “routers, modems intended for the connection to the internet, and switches” as Class I important products, drawing no line between consumer and professional models. That classification has teeth: a Class I product may only take the lighter self-assessment route if harmonised standards fully cover the essential requirements. A device shipping with a pre-auth overflow is not one where that claim holds up — which points toward third-party conformity assessment.

Held against the CRA’s Annex I essential requirements, the same findings read as a secure-development-lifecycle miss: products must be placed on the market without known exploitable vulnerabilities, must protect against unauthorised access, and must minimise their attack surface. A pre-auth memory-corruption bug is close to the textbook example of what those requirements exist to prevent.

There is a genuine bright spot, and it belongs under the CRA. The vendor ran a coordinated disclosure and shipped a fix — which is exactly the vulnerability-handling behaviour the CRA’s Article 13 will require. It is worth being precise, though: finding and patching a bug through disclosure does not trigger the CRA’s ENISA reporting clock. That obligation — the nearest hard CRA deadline, arriving in September 2026 — is for actively exploited vulnerabilities and severe incidents, not for every researcher finding. The CRA’s full product obligations do not apply until December 2027, so nothing here is a present-day CRA breach. It is a preview of the failure mode the regulation is built to catch.

Where the two regimes diverge

The instructive part is the contrast. RED is a point-in-time regime: conformity is assessed when the product is placed on the market. The CRA is a lifecycle regime: it reaches secure development, ongoing vulnerability handling, and reporting across the product’s supported life. That is why the single fact “the vendor patched it” does two different things. Under the CRA, it counts in the manufacturer’s favour. Under RED, it changes nothing about whether the units already sold conformed at the moment they were placed on the market.

The takeaway for device makers

The lesson here is not about one router. It is that “cheap and connected” is no longer a reason security can slide. In the EU, both regimes now gate market access, and they gate it at different moments — RED at the shelf today, the CRA across the whole product life from 2027. A finding a researcher can publish in an afternoon is, in regulatory terms, a rebuttable presumption of conformity and a market-surveillance question waiting to happen.

The manufacturers who come through this transition well are the ones who build conformity in early: architecture and threat modelling up front, essential-requirement mapping before the CE mark goes on, and a vulnerability-handling process that is real rather than nominal. That is the work we do at Kokobo — and cases like this one are a useful reminder of why it is worth doing before a product ships, not after a blog post lands.

 

Kokobo helps device manufacturers navigate EU RED (EN 18031) and Cyber Resilience Act compliance — from scoping and threat modelling through to the technical file and ongoing vulnerability handling. If you build radio-enabled or connected hardware for the EU market, we can help you get ahead of both regimes.