Slican IPx CVE-2026-35088

Exploitation requires two concrete prerequisites: (1) access to one of the affected Slican firmware binaries to extract the static hardcoded symmetric key (trivial once any copy of the device or firmware is available, since the key is shared across installations), and (2) a position to capture the encrypted TCP/IP communications of the target exchange (passive sniffing or MITM on the management/signalling network). The limiting factor is the traffic-capture requirement (reflected as AT:P in the CVSS 4.0 vector), not the cryptography itself. For the IPx series, upgrading to version 6.62.0100 removes the condition; for the EOL models CCT-1668, MAC-6400, and CXS-0424 no software remediation exists and a hardware upgrade (via the vendor's service department) is required, so the condition persists indefinitely for those deployments.

This is a cryptographic weakness (CWE-326) rooted in a hardcoded symmetric key embedded in multiple Slican firmware binaries, allowing decryption of TCP/IP communications. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H) is consistent with the description: no authentication is required (PR:N) and confidentiality impact is high (VC:H), but the AT:P flag correctly signals that exploitation is not turnkey - the attacker must both obtain the key-bearing binaries and be positioned to capture the encrypted traffic. The composite 8.2 (High) score is therefore driven almost entirely by a confidentiality-only impact (VI:N/VA:N); there is no code execution, tampering, or availability loss. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so by the precision rules this is 'no public exploit identified at time of analysis' - meaning the real-world urgency is lower than the 8.2 headline suggests. The practical risk is concentrated in the three End-Of-Life models (CCT-1668, MAC-6400, CXS-0424) which cannot be patched in software and require a hardware upgrade; the IPx series is remediated in 6.62.0100. Note a limitation: the input gives only a CVSS 4.0 vector (no 3.1 vector, no EPSS, no POC/KEV signals to cross-reference), so exploitation likelihood is inferred from the vector and description rather than confirmed by exploitation telemetry.

An attacker extracts the shared hardcoded symmetric key from a Slican firmware binary (obtainable from any copy of the affected device or its firmware) and uses it to passively decrypt previously captured or intercepted TCP/IP traffic to/from the telephone exchange, exposing confidential signalling and call-management data. Because the key is static across devices, one extraction compromises all affected deployments. No public exploit code was identified in the provided data; the barrier is traffic-capture positioning, not cryptographic difficulty.