Remediating PowerG Crypto Flaws in IQPanel and IQHub

  • Thread Author
Johnson Controls’ PowerG radio stack and IQ family (IQPanel, IQPanel 2/2+/4 and IQHub) were disclosed as affected by multiple cryptographic and authentication weaknesses that together create a real-world risk of eavesdropping, replay, packet injection and device mis‑configuration on deployed alarm and sensor networks. The coordinated advisory set assigns four CVE identifiers for distinct failure modes — cleartext key material, nonce reuse, weak pseudo‑random number generation, and missing origin/source validation — and the vendor’s immediate guidance is a combination of firmware updates, conservative pairing procedures, and device replacement for end‑of‑life models. Practical defenders must treat this as an urgent operational patch-and‑hardening exercise: apply vendor fixes where available, isolate affected control networks from general IT and the Internet, and assume that network‑accessible PowerG radios could be weaponized for confidentiality, integrity, or availability attacks until remediated.

Neon dashboard displays firmware 4.6.1 with vulnerabilities: cleartext key exchange, nonce reuse, weak PRNG.Background / Overview​

Johnson Controls’ PowerG radio is a widely deployed wireless security protocol used in intrusion systems, environmental sensors and alarm architectures paired with IQPanel control hosts. The recent coordinated advisory set (reflected in the uploaded CSAF/ICS material) assigns four CVEs that expose fundamental issues in how PowerG sessions are established and protected:
  • CVE‑2025‑61738 — cleartext transmission of sensitive information (network key exposure).
  • CVE‑2025‑61739 — nonce reuse / key‑pair reuse allowing replay or decryption.
  • CVE‑2025‑26379 — use of a cryptographically weak pseudo‑random number generator (PRNG).
  • CVE‑2025‑61740 — origin/source validation failure enabling unauthenticated or spoofed packets.
These weaknesses affect multiple Johnson Controls products and firmware families: PowerG stacks up to certain versions, IQPanel 2 / 2+ and IQHub models (noted as end‑of‑life for some models), and IQPanel 4 prior to firmware 4.6.1. The vendor’s baseline remediation guidance is explicit: update IQPanel 4 to 4.6.1 (and use PowerG v53.05+ for PowerG+ devices), and replace EOL hardware (IQ Panel 2 / 2+, IQ Hub) with supported IQPanel 4 units running 4.6.1+ where possible.
This is not a single‑class bug. The four CVEs map to distinct cryptographic and protocol design failures that, when chained, permit attackers to read encrypted traffic, write (inject) packets that the panel will accept, replay previously captured messages, and in some cases alter device configuration or cause denial‑of‑service behavior. The practical attack surface is the PowerG radio channel and the sensor enrollment/pairing process — phases where keys and randomness are generated and exchanged.

Why these findings matter: the practical risk model​

Short, practical risk statements for operations teams:
  • Confidentiality risk (eavesdropping): If a network key or predictable session randomness is exposed, an attacker who captures radio traffic can decrypt event and telemetry packets. That can reveal sensor states (door open/closed, motion, glass break) and reveal security posture.
  • Integrity risk (injection/modification): Reused nonces or weak PRNGs allow attackers to forge valid-looking frames or replay previously recorded alarm events, enabling false alarms, masked intrusions, or remote reconfiguration.
  • Availability risk (DoS/config tampering): Origin validation failures let a remote actor send packets that the controller treats as legitimate, potentially overwriting configuration, disabling sensors, or creating persistent operational disruption.
  • Operational risk (supply and maintenance): Many affected units are deployed in commercial facilities worldwide; EOL units left in production increase the blast radius and complicate mass remediation. Vendor recommendations to replace unsupported hardware are operationally meaningful and may require budgeted capital actions.
CISA’s defensive posture for similar ICS and control‑system disclosures — minimize exposure, place devices behind segmented firewalls, avoid direct Internet access, and use secure remote access (hardened VPN/jump hosts with up‑to‑date clients) — is the immediate mitigation backbone for organizations until vendor patches are applied. These are practical stopgaps, not substitutes for firmware fixes.

Deep technical breakdown: what each CVE actually means​

CVE‑2025‑61738 — Cleartext transmission of sensitive information​

  • What it is: During pairing or some operational messages, sensitive keying material — including a network or session key — is transmitted without appropriate confidentiality protections.
  • Practical consequence: An adversary in radio range or with a receiver on the same RF channel can capture the key exchange in the clear, derive the network key, and then decrypt or craft valid PowerG frames.
  • Severity: The advisory maps this to a confidentiality impact and shows a mid‑range CVSS score (there are contextual factors such as attack complexity and whether the pairing process is physically isolated). Defenders must assume capture on local RF is practical in many deployments.

CVE‑2025‑61739 — Reusing a nonce / key pair in encryption​

  • What it is: Proper authenticated encryption depends on never reusing nonces with the same key. This finding shows the PowerG implementation can reuse nonces or reuse key material in ways that break AEAD semantics.
  • Practical consequence: Nonce reuse enables cryptanalytic attacks and straightforward replay attacks; with repeated nonces an attacker can recover plaintext or forge valid ciphertexts for future messages.
  • Severity: This class of bug frequently yields high practical impact because it directly undermines the crypto primitive that enforces message uniqueness and authenticity. Firmware fixes or protocol changes are required.

CVE‑2025‑26379 — Weak PRNG​

  • What it is: Random numbers are used for key generation, nonces, and session values. A weak PRNG makes those values guessable or low‑entropy.
  • Practical consequence: Predictable keys/nonces make passive capture and active injection feasible without specialized cryptanalysis — attackers can enumerate likely session keys or reproduce nonce streams.
  • Severity: Weak RNGs in embedded stacks are historically among the easiest to exploit; practical weaponization follows quickly if an attacker can observe a few sample interactions. Firmware or cryptographic library replacement is required.

CVE‑2025‑61740 — Origin validation error​

  • What it is: The device fails to verify the source or origin of a received packet in certain contexts (for example, management or configuration messages).
  • Practical consequence: Spoofed frames or packets can be accepted as legitimate administrative commands or configuration updates, enabling remote tampering or DoS.
  • Severity: When combined with weak crypto or captured keys, origin validation failures facilitate persistent takeover scenarios and undermine trust in the sensor network.

What Johnson Controls is recommending (vendor fixes and immediate mitigations)​

The vendor guidance shared in the advisory set is focused and repeatable:
  • Update IQPanel 4 to firmware 4.6.1 / 4.6.1i where available.
  • Devices supporting PowerG+ should run PowerG v53.05 or later.
  • During enrollment/pairing, enter the sensor PIN code into the PIN field on the enrollment screen; ensure only authorized integrators/technicians are present during pairing to reduce the chance of intercepted or unauthorized enrolment.
  • Replace end‑of‑life hardware (IQ Panel 2, IQ Panel 2+, IQ Hub) with IQPanel 4 devices running 4.6.1 or later.
  • Follow the vendor’s Product Security Advisory JCI‑PSA‑2025‑01 for detailed procedures and firmware artifacts.
These vendor controls are the authoritative corrective actions; defenders should prioritize applying these updates after appropriate test validation and planned maintenance windows.

Immediate operational playbook (what to do in the first 72 hours)​

  • Inventory (0–8 hours)
  • Enumerate every IQPanel / IQHub / PowerG endpoint: model, serial, MAC, IP (if networked), firmware version, and pairing status.
  • If you maintain a CMDB or asset inventory, tag affected entries for emergency remediation.
  • Contain (0–24 hours)
  • Remove any direct Internet exposure for alarm management consoles or remote configuration ports.
  • Block RF‑to‑IP bridges or remote gateways from exposing raw service endpoints to untrusted networks.
  • Place alarm-management servers and controllers on a segmented management VLAN with strict ACLs and logging.
  • Mitigate during installs (immediate)
  • Enforce the vendor’s pairing guidance: require PIN entry in the enrollment UI and ensure pairing is performed in a controlled, supervised environment.
  • Where possible, conduct initial pairing in RF‑controlled rooms or use temporary RF shielding if equipment is highly sensitive.
  • Patch planning and test (24–72 hours)
  • Download vendor published firmware images and verify checksums/signatures per the Product Security Advisory before applying to production devices.
  • Test firmware on a small, representative unit. Confirm rollback procedures and physical access requirements for restoration.
  • Replace EOL devices (as feasible)
  • Schedule replacement for IQ Panel 2 / 2+ / IQ Hub units that are unsupported; maintain compensating controls (isolation, jump hosts) until replacement occurs.
  • Post‑patch validation
  • After update, confirm device firmware version, rekey where possible, rotate network/management credentials, and verify that enrollment/pairing behaves as expected.

Detection and monitoring: what to look for​

  • Unexpected enrollment events: sensor enrollments outside scheduled maintenance windows are a high‑value indicator.
  • Repeated or out‑of‑band pairing attempts: may indicate an on‑site attacker attempting to capture keys or pair malicious sensors.
  • Anomalous RF traffic: increased broadcast or replayed frames recorded by an RF sniffer could indicate replay or injection attempts.
  • Unexpected configuration changes: remotely triggered configuration updates, particularly if originating from outside known integrator IP ranges.
  • Sudden firmware rollbacks or odd version banners: these can indicate firmware tampering or unauthorized updates.
  • Correlate radio events with physical logs: door opens/unlocks that don’t match schedule or operator records can indicate manipulation.
Operational defenders should add SIEM/IDS rules to flag these behaviors, and ensure that logging from jump hosts and integrator consoles is retained for forensic analysis. If indicators appear, preserve device images and network captures and coordinate with vendor PSIRT and national authorities as appropriate.

Integrator and procurement recommendations​

  • Contractual assurances: require vendors and integrators to provide signed firmware images, a published security lifecycle, and a clear patching SLA for security fixes.
  • Handover checklist for installations:
  • Disable embedded web servers and management interfaces that are not required for normal operations.
  • Replace factory default credentials and ensure integrator accounts use unique, strong credentials and MFA where supported.
  • Require a documented pairing procedure that includes supervised enrollment with PIN entry and on‑site verification.
  • Procurement preferences: prioritize devices with active security support, cryptographically modern stacks (strong RNGs, AEAD constructions, nonce management), and a vendor transparency program (PSIRT, advisory feed).

Strengths in the disclosure and remaining risks​

Notable strengths:
  • The vendor published actionable firmware updates and explicit version thresholds to remediate the disclosed issues, giving organizations a clear path to reduce risk.
  • Coordinated disclosure amplified via government ICS channels reinforces the urgency and provides standard mitigations for operators.
Remaining risks and caveats:
  • Version mapping and CVE granularity can be confusing in multi‑document disclosures; organizations must confirm the exact firmware build string and SHA before declaring remediations complete. Failure to do so risks marking assets incorrectly as patched.
  • EOL devices present a long‑tail problem: where replacement is impractical, compensating network and operational controls must be maintained indefinitely.
  • Operational disruption: firmware updates on alarm panels often require coordinated maintenance windows and physical access, so remediation programs must be planned and communicated to avoid unintended availability impacts.
Where claims were not fully verifiable
  • Some advisory packets and CSAF metadata can include vendor‑assigned CVE strings or internal identifiers that may not immediately appear in canonical public CVE/NVD indexes; organizations that rely on CVE/NVD mappings for compliance must validate canonical assignments against vendor PSAs and public registries before closing tickets. Treat vendor-assigned CVEs in advisory text as authoritative for remediation actions but confirm publicly for compliance evidence.

Hardening checklist: beyond the patches​

  • Segmentation: isolate physical security and alarm devices on a tightly controlled VLAN; restrict management ports to a small set of hardened jump hosts.
  • Least privilege: limit who can perform firmware updates, manage pairings, or enable Pro/maintenance modes. Require dual authorization for bulk changes where possible.
  • Certificate and key hygiene: prefer host‑supplied certificates from a managed PKI rather than device defaults; rotate keys and certificates after remediation or suspected compromise.
  • Physical security: secure controller enclosures, lock serial console ports, and ensure that maintenance closets are access controlled.
  • Monitoring: log and alert on enrollment events, firmware‑update attempts, configuration pushes, and unusual RF characteristics. Feed these events into your SOC/IR playbooks.

For incident responders: containment and forensic steps​

  • Preserve volatile evidence: capture RF traces, device configuration dumps, and any network pcaps before rebooting or reimaging affected devices.
  • Isolate affected units: remove network and gateway exposure, place units behind a management bastion or air‑gap where possible.
  • Rebuild and verify: where compromise is suspected, reimage management hosts and restore controllers from vendor‑signed images; verify checksums and cryptographic signatures.
  • Coordinate with vendor PSIRT and national authorities: report suspected exploitation, share indicators and preserved evidence, and request signed images or special remediation guidance if needed.

Closing assessment​

The PowerG / IQPanel / IQHub advisory set is an important reminder that embedded cryptographic correctness — correct nonce usage, robust randomness, origin validation and the avoidance of cleartext key exchange — is not academic: failures are practical to exploit and directly undermine the trust that alarm systems provide. The vendor’s published firmware updates and pairing‑time mitigations are the right short‑term actions; however, real operational risk reduction requires a layered response: apply the firmware fixes, enforce network isolation and pairing discipline, replace EOL hardware, and bake these controls into procurement and integrator SLAs.
Security teams should prioritize:
  • Confirming vulnerable inventory, applying vendor firmware updates (IQPanel 4 → 4.6.1 / PowerG v53.05+ where applicable), and replacing unsupported IQ Panel 2/2+/IQ Hub units where feasible.
  • Enforcing pairing procedures (PIN entry, supervised enrollment), network segmentation, and strict jump‑host access control for any remote management.
  • Enhancing monitoring for replay/injection indicators and implementing a validated incident response path with vendor coordination.
These actions materially reduce the practical attack surface and remove low‑complexity exploitation paths. Failure to act, or to validate firmware and CVE mappings carefully, risks leaving alarm and sensor networks exposed to eavesdropping, tampering and operational disruption at scale.

Technical readers and operations teams should treat this advisory cycle as an immediate item in the maintenance backlog and ensure firmware validation, patch testing, and coordinated deployment plans are executed with facilities and integrators present during enrollments and upgrades. The combination of vendor fixes, process hardening, and network segregation will close the most straightforward attack paths; continued monitoring and a replacement plan for unsupported hardware will reduce longer‑term risk.

Source: CISA Johnson Controls PowerG, IQPanel and IQHub | CISA
 

Back
Top