Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Shared hard-coded key is network-reachable (AV:N) but needs a MITM position and an admin connecting (AC:H, UI:R); credential and session compromise gives C:H/I:H, no availability effect (A:N).
Primary rating from Vendor (icscert).
CVSS VectorVendor: icscert
Lifecycle Timeline
5DescriptionCVE.org
The affected Watchfire Controller Software contains self-signed hard-coded RSA private keys and corresponding X.509 certificates used for authenticating and encrypting HTTPS/TLS connections to the controller's built-in web management interface. These keys are embedded in plaintext within the application patch binaries in the firmware directly from Watchfire's Remote Support filestore.
AnalysisAI
Hard-coded shared RSA private keys and their matching X.509 certificates in Watchfire digital billboard controller software (BC550, BC750, BC760, BC760DC) let an attacker who extracts them decrypt and impersonate the controller's built-in HTTPS/TLS web management interface. Because the keys ship in plaintext inside the firmware patch binaries - retrievable from Watchfire's Remote Support filestore - any attacker with the same firmware can recover the identical keys used across all deployed units. This is an information-disclosure/authentication-bypass class flaw (CWE-321) reported through CISA ICS-CERT; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Technical ContextAI
The affected component is the TLS/HTTPS layer protecting the web-based management console embedded in Watchfire outdoor LED sign controllers (CPEs cpe:2.3:a:watchfire:bc550/bc750/bc760/bc760dc). TLS authentication and confidentiality depend on the secrecy of the server's RSA private key; here the private key and certificate are not device-unique but are compiled into the application patch binary that Watchfire distributes to every unit. CWE-321 (Use of Hard-coded Cryptographic Key) is the root cause: a single static key protecting many devices means the secret is effectively public, collapsing both the authentication guarantee (an attacker can present the legitimate certificate) and the confidentiality guarantee (traffic can be decrypted). Because the material sits in plaintext in a downloadable firmware/patch artifact, key recovery requires only firmware access, not cryptanalysis.
RemediationAI
Consult CISA advisory ICSA-26-211-09 (https://www.cisa.gov/news-events/ics-advisories/icsa-26-211-09) for the vendor's fixed firmware release; an exact patched version was not provided in the available data, so verify the fix version directly in that advisory before deploying. The durable fix must replace the shared hard-coded key/certificate with a device-unique key pair generated on first boot, so upgrading is only effective if the update regenerates per-device keys - confirm this with Watchfire. As compensating controls until patched: place the controller's web management interface on an isolated management VLAN or behind a firewall and restrict access to a small set of trusted administrator hosts (limits the man-in-the-middle opportunity, at the cost of remote-management convenience); disable or block remote/Internet exposure of the HTTPS interface entirely where feasible; and, where the platform allows, install an organization-generated replacement TLS certificate and private key to invalidate the shared hard-coded pair (side effect: management clients must trust the new certificate). Also revoke and rotate any credentials that may have transited the interface, since they could have been exposed.
Same weakness CWE-321 – Use of Hard-coded Cryptographic Key
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-51313
GHSA-5qvx-vvgc-3mv8