CVE-2026-85544

Executive Summary

CVE-2026-85544 is an improper encryption configuration vulnerability in unspecified Hikvision intercom products that, per the CNA-supplied description, "could allow attackers to forge M1 cards." The flaw permits an attacker with physical proximity to the credential-side of an affected access-control deployment to create unauthorized RFID credentials that are accepted by the intercom/reader hardware, thereby defeating the physical access-control boundary. Because the CNA withdrew this record before an authoritative technical analysis was published, vendor, product, and version details are not available, no patch or workaround exists, and there is no public PoC, Nuclei template, or exploit code; impact is therefore assessed at the vulnerability-class level.

Technical Analysis

The vulnerability class described is an improper cryptographic configuration on an RFID credential system, specifically one that accepts M1 (MIFARE Classic 1K/4K family) cards as access tokens. MIFARE Classic is a proprietary NXP radio-frequency identification protocol operating at 13.56 MHz. Its Crypto-1 stream cipher and key management scheme are documented in public academic literature as cryptographically broken and susceptible to key-recovery, cloning, and card-emulation attacks. The CNA description for CVE-2026-85544 states only that Hikvision intercom products contain an "Improper Encryption Configuration Vulnerability" that "could allow attackers to forge M1 cards." It does not specify which configuration parameter is insecure, which key(s) are affected, or how the reader derives its verification decision from the card. No function names, endpoints, file paths, or API parameters are provided in the source data, and none are inferred here.

What can be stated at the vulnerability-class level: when a physical access-control reader and the backend management platform use static, default, or weakly derived M1 sector keys rather than per-credential diversified keys with mutual authentication, an attacker in possession of valid keys (whether obtained by publication of default values, by side-channel key recovery, or by extraction from any single legitimately issued card) can compute the necessary authentication values and write a valid UID and sector data to a blank or re-writable M1 card. The reader, performing only a UID/sector-key check, cannot distinguish the forged card from an issued one. This is consistent with CWE-326 (Inadequate Encryption Strength), which is the closest applicable class; no official CWE mapping was published.

Attack surface: the RFID interrogation zone of the intercom/reader (nominally a few centimeters), the card enrollment/management workflow, and any backend that stores or transmits sector keys. No network-facing attack surface is established by the description.

CVSS v3.1 impact confirms the physical-access framing: AV:P (Physical) means exploitation requires physical interaction with the target component; AC:L and PR:N mean no special conditions or privileges are required beyond that physical presence; C:H reflects full compromise of credential confidentiality (keys and credential data are recoverable); I:L reflects the ability to write/forge a credential; A:N reflects no availability impact.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred strictly from the vulnerability class and the CVSS physical-vector characteristics. It does not reference any function, file, or endpoint that is not present in the supplied data.

1. Reconnaissance / target identification. The attacker establishes physical proximity to the intercom's credential reader, e.g., as a visitor, contractor, or tailgater at a facility entrance. Target identification is limited to confirming that the unit is a Hikvision intercom/access product and that M1-family cards are in use for that site. Open-source tooling (e.g., generic NFC/RFID research platforms) supports passive field detection of MIFARE-family cards. Because CVSS AV:P applies, remote identification is not assumed.

2. Triggering the flaw class. The improper encryption configuration means the reader/backend will accept a card whose cryptographic material was produced by the attacker rather than by the issuing system. The attacker either (a) acquires the relevant M1 sector key(s) through known weaknesses in the M1/Crypto-1 scheme or through weak/default key configuration, or (b) captures the exchange between a legitimately issued card and a reader and reuses the resulting authentication material. No specific implementation detail of the Hikvision reader is claimed here.

3. Payload / execution. Using standard, publicly documented MIFARE card-writing techniques, the attacker writes the recovered/derived keys, access bits, and credential data to a blank or re-writable M1 card. The result is a forged M1 card that presents the same verifiable material the reader expects.

4. Post-exploitation impact. Presenting the forged card to the intercom yields authenticated physical entry, because the reader cannot distinguish the clone/forgery from a legitimately issued credential. The accessed zones are those governed by the compromised reader. Additional abuse may include credential circulation to third parties, since a single recovered key set may be reproducible across numerous forged cards, and any credential revocation performed only against the original UID will not neutralize copies of a cloned credential.

Impact Assessment

Business impact centers on loss of integrity of a physical access-control boundary. The CVSS v3.1 base score is 5.2 (Medium) with vector CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N. The high confidentiality subscore reflects full compromise of card/reader secret material; the low integrity subscore reflects write-level alteration and forging of credentials; absence of availability impact reflects the operational nature of the attack. Blast radius depends on deployment: an affected door frequently governs a room containing physical assets; where multiple doors share the same key scheme, a single recovered key set can compromise all of them simultaneously.

Affected systems: Hikvision-brand intercom products that use M1 (MIFARE) cards for access control. Exact models, firmware builds, and version ranges are not identified in the source data, so a site inventory is required to determine exposure. No OSV package data is available; this is an embedded hardware/firmware vulnerability, not a software-package vulnerability.

CISA KEV: NO. EPSS: not scored by FIRST.org — no probability estimate is available and none is fabricated here. No known exploitation in the wild has been reported in association with this CVE.

Detection Guidance

Because the vulnerability is exploitable only through physical proximity to the reader, network-layer detections are indirect by nature; they target anomalous management-platform, enrollment, and logging behavior rather than exploitable packets. Sigma, Suricata, Elastic, Splunk, and Wazuh rules below are therefore behavioral/telemetry detections for products that log access-control events. Field and field-names below are presented at the schema level because no vendor-specific field names are available.

Sigma Rule

title: Repeated Access-Control Denials Followed by Success from Same Credential - Possible Forged M1 Card
id: 4c1a7e0d-3b62-4f8e-9d21-0b6f7a2c8554
status: experimental
description: Detects a possible forged M1 card presentation at a Hikvision intercom/access reader. Tuned for ACL systems exporting to a SIEM.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-85544
author: valtersit.com
date: 2026/01/01
logsource:
  product: hikvision
  service: access_control
detection:
  selection_failed:
    event_action: 'access_denied'
  selection_success:
    event_action: 'access_granted'
  timeframe: 15m
  condition: >-
    selection_failed | count() by credential_id > 5
    and selection_success
fields:
  - timestamp
  - reader_id
  - credential_id
  - door_id
falsepositives:
  - Legitimate cards with damaged sectors retried by users
  - Reader firmware faults generating alternating grant/deny
level: medium

YARA Rule

rule CVE_2026_85544_Hikvision_M1_Credential_Default_Key_Artifact
{
    meta:
        author      = "valtersit.com"
        description = "Heuristic detection of files/dumps containing default or hardcoded MIFARE Crypto-1 key material associated with Hikvision intercom credential provisioning. High false-positive risk in any RFID toolchain."
        reference   = "https://nvd.nist.gov/vuln/detail/CVE-2026-85544"
        date        = "2026-01-01"
        hash        = "na"
    strings:
        $k1 = { FF FF FF FF FF FF }          // default Key A / Key B material
        $k2 = { A0 A1 A2 A3 A4 A5 }          // common factory default pattern
        $m1 = "Hikvision" ascii wide nocase
        $ic = "Intercom" ascii wide nocase
    condition:
        filesize < 64KB and
        ($k1 or $k2) and
        ($m1 or $ic)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-85544 Possible Hikvision Intercom Access-Credential Forging / Bulk Enrollment Activity"; flow:established,to_server; http.method; content:"POST"; http.header; content:"Intercom" nocase; http.header; content:"Hikvision" nocase; threshold: type both, track by_src, count 20, seconds 300; classtype:attempted-admin; reference:cve,2026-85544; metadata:created_at 2026_01_01, updated_at 2026_01_01, confidence Medium; sid:202685544; rev:1;)

Elastic Detection

sequence by host.name, user.name with maxspan=10m
  [ access_control where event.outcome == "failure" and reader.id != null ]
  [ access_control where event.outcome == "success" and reader.id != null ]

Note: Any Alert with rule type EQL. Requires access-control events with outcome stored in event.outcome, reader identity in reader.id, and ordering by host/user. Adjust field names to the deployed ECS mapping.

Splunk SPL Query

index=access_control sourcetype=hikvision:intercom
| eval denial=if(action=="denied",1,0), grant=if(action=="granted",1,0)
| stats sum(denial) as denials sum(grant) as grants by card_id reader_id
| where denials > 5 AND grants > 0
| sort - denials
| table reader_id card_id denials grants

Wazuh OSSEC Rule

<group name="access_control,hikvision,">
  <rule id="1085544" level="10" frequency="6" timeframe="600">
    <if_matched_sid>1085543</if_matched_sid>
    <same_field>card_id</same_field>
    <description>CVE-2026-85544: Repeated access-control denials followed by successful read for the same credential at a Hikvision intercom reader - possible forged M1 card.</description>
    <mitre>
      <id>T1556</id>
    </mitre>
  </rule>
  <rule id="1085543" level="3">
    <decoded_as>json</decoded_as>
    <field name="event_action">access_denied</field>
    <description>Hikvision intercom: access denied event</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, workaround, or advisory is available; no affected-version range is published; the CNA record for CVE-2026-85544 has been withdrawn and is currently REJECTED in the NVD, so no future coordinated fix should be expected via the CVE channel.

1. Immediate mitigations. Treat every M1-card-based door as an unaudited trust boundary. Layer compensating controls: visual verification of photo ID, manned entry, visitor escorting, and closed-circuit television coverage of every affected reader. Where the intercom supports an alternative credential type (e.g., higher-security RFID or the vendor's own secure-credential offering), migrate to it. Where card data is imported into a management platform, audit the platform for any stored or transmitted M1-sector keys and remove/rotate them. Treat any M1 key set known to be default or shared across more than one door as compromised.

2. Patch/upgrade steps. There is no patch. Do not wait for one based on this CVE record: request a security advisory and firmware guidance directly from Hikvision support, referencing the CVE identifier and the exact model/firmware revision of each installed unit. In parallel, plan a credential-technology upgrade for affected doors rather than a firmware-only fix, because the root cause is a card/reader cryptography configuration.

3. Long-term hardening. Mandate per-credential diversified keys and mutual authentication for any RFID access credential; deprecate M1-family credentials entirely from the procurement standard. Rotate access credentials on a defined schedule and immediately on personnel change. Monitor the access-control telemetry with the detection rules above. Maintain a hardware/firmware inventory capable of answering "which doors use which credential technology" so future advisories can be scoped in minutes rather than weeks.

References

• NVD record for CVE-2026-85544: https://nvd.nist.gov/vuln/detail/CVE-2026-85544 (currently REJECTED; description retained from pre-rejection CNA submission)
• Hikvision security advisory portal: https://www.hikvision.com/en/support/cybersecurity/security-advisory/ (no advisory specific to this CVE was published at time of writing)
• NXP MIFARE Classic product/security documentation for the underlying card family: https://www.nxp.com/products/rfid-nfc/mifare-classic (background on the M1 credential platform referenced in the CNA description)
• CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE-2026-85544 is not listed

Exploit-in-the-wild evidence: none available. No public PoC, no Nuclei template, and no vendor-confirmed campaign is associated with CVE-2026-85544 in the data provided. Physical-access credential cloning is, however, a well-documented real-world technique against MIFARE-family deployments, and SOC/security teams should treat any affected door as potentially already compromised until the credential technology is replaced.