The recently published advisory for the Shelly Pro 4PM — tracked as CVE‑2025‑11243 — warns that a malformed JSON request to the device’s RPC endpoints can cause the internal JSON parser to over‑allocate memory, trigger a reboot, and produce a denial‑of‑service (DoS) condition; CISA’s advisory assigns a high availability impact and calculates a CVSS v4 base score of 8.3 (attack vector: adjacent network; attack complexity: low), and recommends immediate defensive steps plus firmware updates.
Shelly’s Pro 4PM is a DIN‑rail smart four‑channel switch with built‑in power metering and LAN/Wi‑Fi management features, commonly used in residential, commercial and light industrial automation. The device family has on‑device web APIs and RPC endpoints that enable integrations, local scripting and cloud management — features that make the product powerful for integrators but also expand the attack surface for malformed or malicious network traffic. The advisory marks the vulnerability as an allocation of resources without limits or throttling issue (memory overallocation in the JSON parsing path), producing a reliable crash/reboot when the device processes a specially crafted request. CISA’s write‑up assigns CVE‑2025‑11243 to the finding and reports a low attack complexity with an adjacent‑network attack vector (an attacker needs IP reachability on the same L2/L3 segment or via a routed management network, not a purely Internet‑wide attack). The report also notes the researcher credited for reporting the issue. The vendor’s response and coordination status are inconsistent in the public material: CISA reported that Shelly did not respond to coordination attempts; Shelly’s own public changelog shows firmware activity in 2025 with a 1.6.0 rollout, but the advisory’s fixed‑version references contain an apparent version‑string inconsistency that defenders should treat carefully when planning upgrades.
Important nuance: while CISA assigns a high availability impact, the attack vector is adjacent, not Internet‑direct. That means an attacker typically needs IP reachability on the device’s management network — but real exposures (misconfigured NAT, open management ports on firewalls, or vendor cloud integrations that reverse‑connect) can change that assumption and put devices at Internet risk.
CVE‑level advisories like CVE‑2025‑11243 are a reminder that embedded device parsers are frequent sources of availability faults. The technical fix path is straightforward — validate and apply the vendor firmware patch — but the operational controls and continual inventory discipline are what prevent a local parser bug from becoming a broader operational incident. Act now to inventory and isolate, verify the vendor fix for your exact firmware string, and instrument visibility and alerts so that the next abnormal reboot is caught and contained before it affects critical operations.
Source: CISA Shelly Pro 4PM | CISA
Background / Overview
Shelly’s Pro 4PM is a DIN‑rail smart four‑channel switch with built‑in power metering and LAN/Wi‑Fi management features, commonly used in residential, commercial and light industrial automation. The device family has on‑device web APIs and RPC endpoints that enable integrations, local scripting and cloud management — features that make the product powerful for integrators but also expand the attack surface for malformed or malicious network traffic. The advisory marks the vulnerability as an allocation of resources without limits or throttling issue (memory overallocation in the JSON parsing path), producing a reliable crash/reboot when the device processes a specially crafted request. CISA’s write‑up assigns CVE‑2025‑11243 to the finding and reports a low attack complexity with an adjacent‑network attack vector (an attacker needs IP reachability on the same L2/L3 segment or via a routed management network, not a purely Internet‑wide attack). The report also notes the researcher credited for reporting the issue. The vendor’s response and coordination status are inconsistent in the public material: CISA reported that Shelly did not respond to coordination attempts; Shelly’s own public changelog shows firmware activity in 2025 with a 1.6.0 rollout, but the advisory’s fixed‑version references contain an apparent version‑string inconsistency that defenders should treat carefully when planning upgrades. What CISA says in plain terms
- Vulnerability class: Allocation of resources without limits or throttling (CWE‑770).
- Impact: Denial‑of‑service — device reboots and becomes unavailable to control or monitor local loads.
- Affected product: Shelly Pro 4PM (device families identified in the advisory).
- Exploitability: Adjacent‑network (AV:A) — not remotely exploitable from arbitrary Internet hosts unless the device’s management interfaces are directly exposed or reachable via misconfiguration.
- Severity: CVSS v4 = 8.3 (high); CISA also reports CVSS v3.1 = 7.4.
- Mitigation summary: Isolate and update — minimize network exposure, place devices behind firewalls, use VPNs for remote access, and install vendor firmware updates; audit exposed RPC endpoints and add layered controls.
- Coordination note: CISA states Shelly did not respond to coordination attempts. This advisory therefore emphasizes compensating controls while defenders confirm vendor updates.
Why this matters to Windows/IT and OT teams
Shelly Pro devices frequently appear on the edge of building automation and light industrial environments where Windows servers, engineering workstations, SCADA/UIs, and management consoles interface with OT devices. Availability problems on the Pro 4PM can cascade:- Local device reboots interrupt automation (lighting, HVAC contactors, motor starters), which may trigger alarm storms on Windows‑hosted monitoring systems.
- Repeated device failures create noise in logging/monitoring and increase operational toil for Windows‑based management consoles and ticketing teams.
- Unsegmented networks let an attacker or misbehaving host reach management APIs. Many organizations still allow management VLANs or jump hosts insufficiently restricted; that increases the real‑world exploit surface. General ICS hardening guidance stresses the same mitigations CISA repeats: segmentation, least‑privilege access and restricted remote access.
Technical analysis: how the flaw works (concise, non‑editorial)
At a high level the exploit chain is straightforward:- Shelly’s firmware exposes RPC endpoints that accept JSON payloads (used by the local web UI, scripts, and integrations).
- A crafted JSON payload (for example, containing pathological sizes, deeply nested structures or manipulated length fields) triggers the device’s JSON parser to miscompute memory needs.
- The parser over‑allocates (or otherwise corrupts heap metadata), which either exhausts available RAM or causes an unrecoverable state that forces a device reboot.
- The reboot causes a denial‑of‑service because the relay(s) and reporting are unavailable until the device returns online.
Important nuance: while CISA assigns a high availability impact, the attack vector is adjacent, not Internet‑direct. That means an attacker typically needs IP reachability on the device’s management network — but real exposures (misconfigured NAT, open management ports on firewalls, or vendor cloud integrations that reverse‑connect) can change that assumption and put devices at Internet risk.
Conflicting version information — verify before you update
The advisory text circulated with CISA contains an apparent version mismatch that defenders must not ignore:- One part of the advisory describes the affected Pro 4PM as “prior to v1.63.2.”
- Elsewhere, CISA’s mitigation text suggests versions later than 1.6.0 are not vulnerable.
Practical remediation checklist (prioritized, operational)
- Inventory first — find every Shelly Pro 4PM:
- Query management systems, DHCP leases, and switch port maps.
- Check the Shelly app / cloud and local device web UIs for device model strings and firmware versions.
- Log each device IP, MAC, model (V1 vs V2), firmware string, and physical location.
- Immediately reduce exposure:
- Block all inbound connections from untrusted networks to Shelly management ports.
- Ensure Pro 4PM units are not reachable from the public Internet (no port‑forwarding, no exposed cloud management gateways unless strictly controlled).
- Move devices to a dedicated management VLAN and implement access control lists (ACLs) that permit only jump hosts and vetted engineering workstations.
- Apply the vendor update once you confirm the fixed firmware:
- Use the Shelly web UI or Shelly app to confirm the current firmware string and the vendor‑published fixed version.
- If the advisory’s fixed version appears ambiguous, contact Shelly support and request the exact release tag that remediates CVE‑2025‑11243.
- Test firmware updates on a small set of representative devices before mass rollout (power devices down/up and validate device behavior post‑update).
- Harden network and RPC access:
- Restrict access to RPC endpoints to a small set of known management hosts (firewall/ACL).
- Where possible, disable unused protocols (for example, remote cloud or exposed RPC) until the risk is mitigated.
- Require management actions to be performed from bastion hosts or jump boxes with strong logging and multifactor authentication.
- Instrument detection and monitoring:
- Add probes that track device uptime, reboot counts and telemetry anomalies.
- Configure NMS/monitoring (SNMP, syslog, HTTP health checks) to alert on sudden reboots or repeated watchdog resets.
- Deploy IDS/IPS rules tuned to suspicious, unusually large or deeply nested JSON RPC payloads targeting Shelly devices (tune to avoid false positives against legitimate automation traffic).
- Post‑remediation validation:
- Validate each updated device remains responsive and that power switching and metering functions operate as expected.
- Run sanity tests for scheduled triggers, local scripts, and integrations (Home Assistant, MQTT clients, cloud connectors).
- Keep rollback images and a maintenance window plan in case of widespread firmware regression.
Detection and forensic guidance for Windows teams
- Look for sudden flurries of alerts from Windows‑hosted monitoring systems (Nagios/PRTG/Zabbix) indicating device offline/unreachable status for Shelly IPs.
- Search firewall logs and proxy logs for anomalous RPC payloads or repeated HTTP POST requests to web‑UI/RPC endpoints from a single host.
- If a device is repeatedly rebooting, capture the device’s serial console, syslog stream, and any system‑dumps available after a crash (if the firmware exposes them).
- Preserve network packet captures around the observed event window; crafted JSON payloads that cause memory overallocations can be analyzed to extract the triggering pattern (useful for IDS rule creation).
- On Windows management hosts, examine integration logs (Home Assistant connectors, MQTT clients, custom scripts) for repeated failed API calls or timeouts correlated with device reboots.
- Ping the device and monitor RTT and packet loss over time to detect transient reboots.
- Use a web browser to confirm the device web UI is reachable and record the firmware version as displayed.
- For advanced users: query local RPC endpoints if documented by the vendor (for example, Shelly devices provide local RPC endpoints used by their web UI). Examples of RPC calls are commonly used by integrators but check vendor docs before invoking them in production.
Risk and attack surface assessment
- Attack complexity: Low. The advisory and CVSS vectors indicate an exploit does not require special privileges or complex steps once an attacker has IP reachability.
- Attack vector: Adjacent (AV:A). Under default, non‑exposed deployments this limits remote exploitation from arbitrary Internet hosts; however, operational misconfigurations (open management ports, lax VPNs, cloud reverse tunnels) can convert adjacent attacks into remotely reachable ones.
- Impact: Availability (device restarts, interrupted automation) with potential operational disruption where Shelly units control critical loads. In multi‑device deployments these reboots can produce correlated outages and complicate incident response.
- Likelihood of exploitation: As of the advisory snapshot there were no confirmed reports of in‑the‑wild exploitation, but the low complexity and ubiquitous use of Shelly devices in building automation make proactive mitigation prudent. If your environment exposes device management interfaces, treat the risk as urgent.
Cross‑verification, gaps and cautionary notes
- Vendor changelog evidence: Shelly’s public product and firmware pages show the 1.6.0 family rollout and active 1.6.x beta activity in 2025; these entries establish that Shelly has been releasing Gen2/Gen3 firmware updates in that timeframe. Use the device’s exact firmware string (as reported in the web UI) to match the vendor’s published fixed build.
- Advisory source and verification: The core technical summary used here derives from the advisory text under CVE‑2025‑11243; organizations should verify the advisory text against the official CISA posting and the Shelly vendor release notes before applying large‑scale changes. Attempts to retrieve the CISA advisory programmatically can encounter web access controls; if you cannot directly fetch the CISA page, rely on the advisory copy provided via your vendor coordination channels and confirm with vendor support.
- Independent corroboration: At the time of writing, public independent writeups or exploit PoCs for CVE‑2025‑11243 are not widely available in public vulnerability aggregators beyond the coordination material; if additional technical analysis from security vendors (e.g., ICS‑focused vendors) or public exploit code appears, update detection signatures and re‑evaluate risk. When similar CWE‑770 cases have appeared in industrial components, other vendors’ advisories consistently recommend the same mitigations: network isolation, firmware updates, input throttling and monitoring.
What to tell management and operations (executive summary for decision makers)
- Severity: High for availability of devices on local control networks (CVSS v4 8.3 reported).
- Immediate ask: authorize a short maintenance window to inventory Pro 4PM units, isolate them from non‑management networks, and validate firmware versions.
- Operational controls: restrict management access to a narrowly defined bastion host and block all direct Internet access to device management ports.
- Long‑term: incorporate Shelly device firmware monitoring into patch management and asset inventory systems; ensure remote access uses hardened jump hosts and audited VPN sessions.
Final recommendations (short checklist)
- Inventory every Pro 4PM in your network and log firmware strings.
- If a device is reachable from untrusted networks, block or isolate it immediately.
- Confirm Shelly’s vendor advisory and obtain the exact patched firmware build string; test and deploy the update.
- Implement monitoring for device reboots and unusual RPC/JSON activity; create alerts for repeated reboots.
- Harden network segmentation and enforce allow‑lists for management traffic; prefer jump hosts and MFA for remote access.
CVE‑level advisories like CVE‑2025‑11243 are a reminder that embedded device parsers are frequent sources of availability faults. The technical fix path is straightforward — validate and apply the vendor firmware patch — but the operational controls and continual inventory discipline are what prevent a local parser bug from becoming a broader operational incident. Act now to inventory and isolate, verify the vendor fix for your exact firmware string, and instrument visibility and alerts so that the next abnormal reboot is caught and contained before it affects critical operations.
Source: CISA Shelly Pro 4PM | CISA
