Deck Mate 2 CVE-2025-34502
HIGHAttack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain physical access to shuffler
-
DeliveryConnect to exposed physical update port
-
ExploitFlash malicious bootloader/kernel/filesystem
-
ExecutionBypass absent secure-boot verification
-
PersistPersistent code execution across reboots
-
ImpactManipulate shuffle integrity / exfiltrate card data
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Missing immutable root of trust
|
| Exploitation Conditions | Requires hands-on PHYSICAL access to the Deck Mate 2 shuffler and its physical update/programming port; there is NO secure-boot chain or runtime integrity check, so an attacker can rewrite the bootloader, kernel, or filesystem without cryptographic detection. No authentication or user interaction is needed once physical access is obtained (PR:N/UI:N). Exploitation is LIMITED by: (1) the need for physical proximity and device disassembly/port access (AV:P), and (2) on units running the vendor's newer firmware that strengthens update-chain integrity and disables the physical update ports, this specific avenue is mitigated - so exposure depends on firmware version and whether physical ports remain enabled. |
| Impact | This is a physical-access hardware root-of-trust flaw, not a remotely exploitable network bug, and every signal points to a low-to-moderate real-world priority despite the HIGH technical impact. The CVSS 4.0 vector (AV:P/AC:L/PR:N/UI:N) confirms exploitation requires PHYSICAL access to the Deck Mate 2 shuffler, which is the dominant limiting factor and correctly caps the score at 7.0. EPSS is very low (0.22%, 11th percentile), consistent with a bug that cannot be scanned or exploited over the internet; the flaw is not in CISA KEV and no public exploit code is identified. Signals are internally consistent rather than conflicting: low EPSS + physical vector + no KEV all agree this is targeted/opportunistic (an insider or someone with device access), not mass-exploitable. The one caveat is impact context - because this is casino gaming equipment, a successful physical compromise has outsized business/integrity consequences (rigging shuffles, exfiltrating card order) that the generic CVSS impact metrics do not capture. Overall: genuine and serious for the specific threat model of an attacker who can reach the device, but low urgency from a broad patch-prioritization standpoint. |
| Exploit ScenarioDerived | An attacker who gains physical access to a Deck Mate 2 shuffler (e.g. an insider, a compromised maintenance window, or device access on the casino floor) opens the unit and reflashes or replaces the bootloader, kernel, or filesystem via the physical update port, since no cryptographic boot verification detects the tampering. The malicious firmware persists across power cycles, giving durable code execution that could manipulate shuffle outcomes or leak card ordering. No public POC exists; the flaw was documented by IOActive/VulnCheck research rather than an in-the-wild exploit. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 30, 2026
Physical attackers with hands-on access to a Deck Mate 2 card shuffler can bypass boot verification entirely and persistently rewrite the bootloader, kernel, or filesystem, gaining code execution that survives reboots and power cycles. The device lacks both a verified secure-boot chain and runtime integrity validation for its controller and display modules, so tampered firmware is never cryptographically detected; no authentication or user interaction is needed once the attacker has access to the physical update/programming port. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, and EPSS is low at 0.22% (11th percentile), consistent with a flaw that requires device disassembly - this is a physical-access root-of-trust weakness rather than a remotely reachable network bug.
RemediationAI
The primary fix is to apply the vendor's more recent Deck Mate 2 firmware, which per the advisory strengthens update-chain integrity and disables the physical update ports; no specific firmware version number is confirmed in the available data, so confirm the current hardened release directly with Shuffle Master / Light & Wonder before deployment. Where the newer firmware cannot be applied immediately, compensating controls must be physical, since no network-facing mitigation exists: restrict and log physical access to the devices and their service/update ports, and require escort or dual authorization for any service event (trade-off: operational overhead for casino floor staff). Disable or physically block the update/programming port with a lockable cover or port blocker on units that still expose it (trade-off: makes legitimate firmware servicing more cumbersome and may void service agreements if done improperly). Apply tamper-evident seals over enclosure seams and the update port and inspect them on a defined schedule, treating any break as a compromise requiring reflash from a known-good image (trade-off: seals add consumable cost and inspection labor, and seal breaches indicate but do not prevent tampering). Isolate affected shufflers from any management or update network where one exists, and validate device firmware hashes during maintenance against vendor-supplied baselines. Consult the IOActive analysis (https://www.ioactive.com/wp-content/uploads/2025/05/IOActive-card-shuffler-security.pdf) and the VulnCheck advisory (https://www.vulncheck.com/advisories/shuffle-master-deck-mate-2-missing-secure-boot) for vendor-specific guidance; no KEV listing or public exploit code has been identified, so prioritization can follow physical-access risk rather than emergency patching.
Affected ProductsAI
The affected product is the Deck Mate 2 card shuffler platform (Shuffle Master / Light & Wonder), specifically units whose controller and display modules run firmware that lacks a verified secure-boot chain and runtime integrity validation. Exposure depends on firmware version and hardware configuration: devices running older firmware, and those whose physical update/programming ports remain enabled, are fully exposed, whereas the vendor states that more recent firmware updates strengthen update-chain integrity and disable the physical update ports, mitigating this particular avenue. No CPE identifiers were included in the provided data. For detailed product and version guidance, consult the IOActive card-shuffler security analysis (https://www.ioactive.com/wp-content/uploads/2025/05/IOActive-card-shuffler-security.pdf) and the VulnCheck advisory (https://www.vulncheck.com/advisories/shuffle-master-deck-mate-2-missing-secure-boot).
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause class is CWE-1326, Missing Immutable Root of Trust in Hardware: the Deck Mate 2 controller and display modules boot without a cryptographic chain of trust, meaning no signed first-stage bootloader anchors the firmware image and no runtime measurement validates the kernel or filesystem after startup. Because the boot chain is unverified, an attacker who can reach the physical update/programming port or the storage medium can substitute or modify any layer of the stack - bootloader, kernel, or root filesystem - and the device will accept and execute the modified image on the next reboot. This is a hardware/embedded trust failure rather than a memory-corruption or injection bug, so exploitation is bounded by physical proximity and port accessibility (AV:P in the assessed CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H vector, and AV:P in the vendor-reported CVSS 4.0 vector); the high confidentiality, integrity, and availability ratings reflect total control of the platform once tampering succeeds. No CPE strings or exact firmware identifiers were supplied in the available intelligence, and the advisory references - the IOActive card-shuffler security PDF and the VulnCheck advisory for Shuffle Master Deck Mate 2 - are the primary technical sources.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Physical access is mandatory (AV:P) and no auth or interaction is required once at the device (PR:N/UI:N); tampering with boot/firmware yields full confidentiality, integrity, and availability impact within the shuffler (S:U).
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
Deck Mate 2 lacks a verified secure-boot chain and runtime integrity validation for its controller and display modules. Without cryptographic boot verification, an attacker with physical access can modify or replace the bootloader, kernel, or filesystem and gain persistent code execution on reboot. This weakness allows long-term firmware tampering that survives power cycles. The vendor indicates that more recent firmware updates strengthen update-chain integrity and disable physical update ports to mitigate related attack avenues.
Executive ViewAI
The Deck Mate 2 card shuffler contains a physical-access boot verification bypass (CVE-2025-34502) that allows anyone with hands-on access to the device's programming port to persistently rewrite firmware, gaining code execution that survives reboots. This flaw undermines the integrity of casino and gaming operations, where a compromised shuffler could be used to manipulate card order or disrupt play, and it currently has no vendor patch. Leadership should prioritize physical security controls and vendor engagement, as the risk is concentrated in environments with insufficient device access restrictions.
No vendor-released patch identified at time of analysis. Interim mitigations include strict physical access controls (badge access, CCTV, tamper-evident seals on programming ports), disabling or physically blocking unused update/programming ports, regular firmware integrity verification via offline checksums where feasible, and enhanced monitoring for unauthorized device tampering during maintenance windows.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
GitHub PoC
Exploit-DB