Shelly Pro 3EM Modbus DoS Vulnerability CVE-2025-12056 Explained

Shelly’s Pro 3EM smart DIN-rail energy meter contains a Modbus parsing bug that CISA calls an out‑of‑bounds read leading to a reboot and denial‑of‑service; the agency assigned CVE‑2025‑12056 and reported a CVSS v4 base score of 8.3, warning operators that specially crafted Modbus requests can force the device to access illegal data addresses without normal error handling and cause a reboot.

Background​

Shelly’s Pro 3EM is a three‑phase DIN‑rail energy meter that supports Wi‑Fi, Ethernet and Modbus TCP for integration with building and industrial systems; its product documentation shows Modbus is an intended feature for telemetry and integration. CISA’s advisory (published as an ICS advisory) summarizes the issue succinctly: an attacker who can reach the device’s Modbus service and send a specially crafted request can cause an out‑of‑bounds read which the firmware does not recover from cleanly — the device reboots and becomes unavailable. The advisory flags the vulnerability as leading primarily to availability impact (DoS) and reports no confirmed public exploitation at the time of publication. The advisory also notes Shelly did not respond to coordination attempts and urges users to contact the vendor and implement mitigations.
Why this matters: Modbus is widely used in OT/industrial environments and many building automation or energy-management integrations expect meters to be reachable from supervisory systems. A meter that will reboot when fed illegal register addresses represents an easy and reliable way to disrupt monitoring and any dependent automation — particularly where the meter is also used as a control signal for charging, load shedding or safety logic.

---

What the advisory specifically claims​

• Affected product: Shelly Pro 3EM — all versions (the advisory lists every Pro 3EM firmware as in‑scope).
• Vulnerability class: Out‑of‑Bounds Read (CWE‑125) triggered by a crafted Modbus TCP request.
• Primary impact: Denial‑of‑Service (device reboots). The advisory reports a CVSS v3 base score of 7.4 and a CVSS v4 base score of 8.3 (vector strings included in the advisory).
• Exploitability: The advisory describes low attack complexity; the attacker must be able to reach the Modbus service (adjacent network or via misconfiguration that exposes the device) — CISA notes the vulnerability is not exploitable remotely in the sense of Internet‑wide exploitation if proper network controls are in place, but network reachability of the Modbus port enables exploit attempts.

These are the key, load‑bearing statements an operator needs to triage risk.

---

Technical analysis — what the advisory says and what that likely means​

How the bug appears to work​

The advisory says a specially crafted Modbus request causes the meter to attempt to access an illegal data address and that the code path lacks standard error handling, causing a reboot. That description aligns with a classic out‑of‑bounds read scenario in which a Modbus register index (or count) supplied by a requester exceeds the bounds used by the device’s register table or memory map.
In practical terms:

• Modbus requests contain function codes and register addresses/counts. If the firmware accepts registers without bounds‑checking and then dereferences memory at a computed offset, an attacker can supply values that index into invalid memory.
• An out‑of‑bounds read can trigger undefined behavior (exceptions, memory corruption-handling faults, or kernel panics depending on the runtime), which on embedded systems is commonly resolved by a device restart — exactly the behavior CISA reports.

This attack is different from a classic Modbus write attack that changes operational values; instead this is an availability attack triggered by malformed read queries.

Preconditions and attack vector​

• Network reachability to the meter’s Modbus TCP listener (default port 502) or other enabled Modbus endpoints.
• Ability to send raw Modbus requests (standard Modbus clients/tools suffice).
• No authentication or network access control that prevents hostile Modbus requests from reaching the device.

CISA’s mitigation advice stresses minimizing network exposure and isolating control/networked devices behind firewalls and segmented networks — the standard ICS defensive posture for protocol‑level vulnerabilities.

Evidence and context: Shelly’s Modbus support and community observations​

Shelly’s product page confirms Modbus support for the Pro 3EM; the device exposes Modbus registers for instantaneous power, energy, voltage, current and other channels — making Modbus one of the principal integration vectors for this product. That exact feature is why a Modbus parsing issue is material. Public user forums and Shelly’s own community have previously recorded Modbus exception errors and register mapping mismatches (for benign misconfiguration cases). Those threads demonstrate both the wide use of Modbus on the Pro 3EM and how common it is for users and integrators to query registers directly — raising the odds that a misconfigured or exposed meter could be discovered and probed.

---

Verification and cross‑checks (what could be independently verified)​

• Shelly product documentation confirms the device implements Modbus TCP (product page). This validates the attack surface described in the advisory.
• Public trackers and vulnerability history show Shelly has had memory/validation issues in earlier Pro product lines (for example, CVE reports and research about earlier Pro‑line out‑of‑bounds issues), establishing precedent for this category of vulnerability against Shelly embedded firmware. That historical context raises confidence the described bug class is plausible.

Caveat: searches of public CVE/NVD and vendor trackers at the time of writing did not return a fully detailed MITRE/NVD entry for CVE‑2025‑12056 with vendor-supplied enrichment (this sometimes occurs when CNAs or CISA publish first and MITRE/NVD entries lag or are queued). Operators should therefore treat the advisory text as authoritative for now but monitor MITRE/NVD and vendor pages for canonical CVE metadata and any subsequent vendor firmware advisory. If you maintain vulnerability inventories, record the advisory details and update when CVE/NVD entries are published.

---

Risk evaluation — who should care, and how urgently​

• Operators who use the Pro 3EM as a local telemetry meter feeding energy dashboards, EV charger controllers, or automation rules should treat this as high priority for containment. The meter’s unavailability (reboot loops or DoS) can disable automated load‑shaving, EV charge control, or protective automation that relies on continuous power/energy telemetry.
• Industrial and commercial installers who expose meters to supervisory networks or allow vendor portals to reach meters remotely have an elevated risk profile.
• Residential customers that expose the device to the Internet (e.g., through remote management, cloud bridging or misconfigured NAT rules) are at risk if the device’s Modbus port is reachable.

Severity summary:

• Impact: Availability (DoS) — high for systems relying on continuous telemetry.
• Exploit complexity: Low — Modbus clients/tools suffice if the port is reachable.
• Exploit requirements: Network reachability; not necessarily authenticated access if Modbus is enabled without further controls.

---

Practical mitigation and hardening checklist (operational playbook)​

Use this checklist to rapidly reduce exposure and buy time while waiting for vendor fixes or further guidance.
Immediate (hours)

• Block Modbus TCP (port 502) at the perimeter for any segments that include Pro 3EM devices unless explicit, vetted host‑to‑host access is required.
• If devices are Internet‑reachable, remove public exposure immediately (terminate NAT rules, move devices behind a firewall).
• For devices in critical paths (EV chargers, grid‑tie automations), put temporary controls in place to avoid dependence on a single meter (e.g., fallback to manual control or alternate telemetry source).

Short term (days to 2 weeks)

• Inventory: Identify every Pro 3EM in your estate (model variants, IP addresses, firmware versions, CT types). This single step reduces uncertainty and enables targeted containment.
• Segment: Move Pro 3EM units into a dedicated OT meter VLAN with strict ingress/egress rules; allow only known supervisory hosts to query Modbus.
• Implement allow‑lists for Modbus clients: only authorized engineering hosts should be permitted to talk to the meter’s Modbus port.
• Enable logging/monitoring: ensure flows to/from the meter are logged and that Modbus protocol anomalies generate alerts in your IDS/SIEM.

Medium term (weeks to months)

• Vendor coordination: Contact Shelly support and request an official vendor advisory or firmware patch schedule. Track CVE/NVD updates and vendor bulletins.
• Firmware management: Plan a controlled firmware update process for meters once Shelly publishes a patch; stage and test upgrades on a small set before wide rollout.
• Detection: Deploy Modbus‑aware IDS/IPS rules to detect malformed Modbus requests (unexpected function codes, extreme register counts, or illegal addresses). Leverage OT intrusion detection tools where available.
• Operational fallback: Add redundancy where the meter is mission‑critical — a second telemetry path (MQTT, cloud reports, or a parallel meter) reduces single‑point availability risk.

Technical notes for Windows/IT admins

• If supervisory servers (SCADA, HMI, building automation controllers) run on Windows and query meters directly, restrict which Windows hosts have Modbus client software installed and which can reach the meter VLAN. Treat engineering workstations with Modbus tools as high‑risk endpoints and apply endpoint controls (application whitelisting, STRONG AV, host firewall rules).
• Where remote access to OT management is needed, prefer jump hosts with MFA and strict access control rather than direct RDP/VPN access from unmanaged endpoints.

---

Detection and monitoring recommendations​

• Watch for repeated Modbus exception responses and connection resets to the Pro 3EM IPs. Reboot chains and repeated connection attempts preceding a device restart should be treated as high‑severity alerts.
• Implement Modbus function‑level logging if the device or gateway supports it, and configure SIEM correlation rules for:
• Abnormally high counts of Modbus read requests.
• Requests with register addresses outside documented ranges.
• Unexpected Modbus function codes.
• Network flow (NetFlow/NetMon) rules: flag repeated short bursts of TCP sessions to port 502 destined for meters, especially from unknown or external addresses.

---

Vendor posture and disclosure status — what to watch for​

CISA’s advisory states that Shelly did not respond to CISA’s coordination attempts; the agency therefore recommends defensive mitigations rather than relying on vendor fixes. That said, vendor engagement and firmware updates can appear after initial advisories. Operators should monitor: Shelly’s official product/security pages, the CISA ICS advisory feed, and MITRE/NVD for CVE record enrichment.
At time of writing, the advisory text and CISA notice provide the authoritative detail for CVE‑2025‑12056; searches for a populated MITRE/NVD entry for that CVE may return no or delayed enrichment — continue to check the canonical trackers for vendor remediation and the final CVE/NVD metadata.

---

Why this looks like a textbook ICS attack surface issue (and what that implies)​

• Modbus is a decades‑old protocol historically designed for trusted industrial networks. Devices that export Modbus without rigorous bounds checking or without network isolation remain high‑value, easy targets. Shelly’s Pro 3EM is an example of a device that straddles both consumer/prosumer markets and light industrial usage; when devices cross those boundaries, integration convenience can increase attack surface.
• CISA’s mitigation list reflects the usual ICS playbook: minimize network exposure, segment networks, and use more secure remote access methods (VPNs and jump hosts), while recognizing those are stopgaps not substitutes for proper vendor fixes.

---

What defenders should document and communicate internally​

• Create a short incident‑response playbook specific to Pro 3EM: identification, isolation, temporary access controls, contact vendor, and firmware update plan.
• Add CVE‑2025‑12056 (per CISA advisory) to your vulnerability and patch backlog; mark devices that cannot be patched as candidates for hardware replacement or stricter isolation.
• Inform operational stakeholders (facilities, energy managers, EV charging operations) that loss of meter telemetry could cause automated systems to degrade or stop, and that manual contingency procedures should be prepared.

---

Strengths and limitations of the advisory — critical analysis​

Strengths

• The advisory gives clear, actionable mitigations: reduce exposure, segment, and monitor. Those are practical, effective in the short term, and do not rely on vendor patch availability.
• CISA supplied both CVSS v3 and v4 vectors and explicitly described the attack class and impact (DoS via reboot), enabling defenders to triage severity and map to enterprise risk models.

Limitations and risks

• The advisory states “Pro 3EM: all versions” are affected — blanket statements like this are cautious but create operational strain because organizations must treat every deployed unit as vulnerable until vendor patch notes identify fixed builds. That can drive wide, urgent changes to network architecture in short windows.
• Vendor non‑response to coordination is a real problem: it prevents defenders from getting a timeline for a patch and from receiving vendor‑specific detection or workaround guidance. In such cases, the only durable mitigation is network isolation or device replacement.
• At the time of publication, canonical CVE/NVD listings were not fully visible or enriched via the usual public trackers. This can complicate automated vulnerability management systems that rely on NVD feeds for assignment and scoring. Defenders should therefore treat the advisory itself as the authoritative record until trackers are updated.

---

Recommended communications to vendors, integrators and customers​

• Contact Shelly support with the meter serials and request a firmware status update and any recommended temporary configuration changes (e.g., disable Modbus if feasible). Record all vendor tickets for compliance.
• Inform integrators and facilities teams that any automation depending on Pro 3EM telemetry must have a fallback manual control procedure activated until devices are patched or isolated.
• If third‑party monitoring or cloud services integrate with the meter, notify those providers to confirm they are not querying Modbus in ways that could unintentionally trigger crashes and to coordinate safe polling patterns.

---

Final assessment and practical next steps​

This advisory is a reminder that even seemingly low‑risk peripheral devices like energy meters can become operational single points of failure. The combination of a widely used protocol (Modbus), low attack complexity, and devices used in automation paths makes the Shelly Pro 3EM bug a material operational security problem for any site that relies on these meters for automated control.
Action steps (summary)

• Immediately verify that no Pro 3EM devices are reachable from untrusted networks; block Modbus/TCP (502) at perimeter firewalls.
• Inventory all Pro 3EM units and move them to a segmented, monitored VLAN with strict host allow‑lists.
• Implement Modbus anomaly detection and log all Modbus traffic to the SIEM.
• Contact Shelly for patch status and prepare for staged firmware upgrades or device replacement.
• Treat the advisory as authoritative and continue to monitor MITRE/NVD for CVE‑2025‑12056 enrichment and vendor bulletins.

For technical operations teams responsible for Windows supervisory hosts or jump servers that interact with these meters, prioritize network controls and endpoint hardening: restrict Modbus client tools to known, managed hosts; require strong host controls on engineering machines; and use bastion/jump hosts with MFA for any required remote access to OT systems.
The vulnerability is fixable from a vendor‑patch perspective, but until Shelly publishes and operators apply a fix, defense‑in‑depth and network controls are the only reliable ways to avoid service disruption. For organizations that cannot isolate affected meters quickly, consider planned maintenance windows to replace or remove exposed units — the operational risk of an uncontrolled reboot chain can be greater than the cost of temporary manual operation.

---

Shelly’s product documentation confirms Modbus is a core integration mechanism for the Pro 3EM, which explains why this specific parsing flaw is impactful; earlier Shelly product CVEs and community Modbus observations establish precedent for both the attack surface and the kinds of firmware parsing errors that lead to denial‑of‑service. Operators must assume exposure until proven otherwise, apply the containment measures laid out above, and track vendor and national vulnerability feeds for a definitive patch and remediation timeline.

---

Source: CISA Shelly Pro 3EM | CISA