ATM Security: Nine Flaws Expose Supply-Chain Risk

ATM security depends on more than the bank’s network and the machine’s cash safe. Nine recently disclosed flaws in CryptoPro Secure Disk, a third-party encryption and pre-boot authentication product used in some ATM environments and other Windows systems, show how one upstream component can weaken many supposedly protected devices.

The vulnerabilities were fixed before the late-August report brought them to wider attention. That is important context: this is not evidence that every ATM is currently open to remote cash theft. The findings instead expose a recurring supply-chain problem—security software can itself become a hidden attack surface.

Everyone else is reporting nine ATM flaws; we are explaining the trust chain, the realistic attack conditions and what banks in India should demand from ATM vendors.

What the ATM security research found

CryptoPro Secure Disk provides full-disk encryption and authenticates a user before Windows starts. In theory, that pre-boot layer protects data even if an attacker removes a drive or tampers with the operating system. The research found ways that assumptions inside this early trust layer could fail.

One documented issue, CVE-2025-59323 in the US National Vulnerability Database, affects versions before 7.7.4. The product failed to validate the integrity of a datastore containing configuration and cryptographic details. Crafted contents could cause denial of service or high-privilege code execution.

CISA’s CVE enrichment assigned that issue a CVSS 3.1 base score of 8.4, classified as high severity. The vector describes local access with low complexity and no prior privileges or user interaction, with potentially high impact to confidentiality, integrity and availability.

The ATM security lesson is not that nine bugs automatically let anyone empty a cash machine over the internet. It is that physical or maintenance-path access to a vulnerable pre-boot component can defeat controls below Windows, and the same component may be embedded across products that banks do not directly manage.

Why pre-boot flaws are serious

Full-disk encryption usually assumes the small environment that runs before the main operating system can be trusted to verify itself, collect credentials and release a decryption key. If that environment accepts modified configuration or exposes secrets, an attacker may operate before endpoint security tools load.

Research presented at Black Hat described weaknesses involving integrity checks, stored material and failure behaviour. The issues could be chained in certain conditions, but exploitability depends on the product version, deployment and access available to the attacker.

That last constraint should not be minimised or exaggerated. Local access is harder than sending a phishing email, yet ATMs are distributed machines serviced by multiple organisations. Technicians, depot staff, third-party maintainers and anyone who obtains physical access can sit closer to the trusted maintenance path than an ordinary customer.

A separate 2026 advisory from SEC Consult documented CVE-2025-10010 and related weaknesses in CryptoPro Secure Disk 7.6.4. It described an unencrypted pre-boot partition, integrity-validation gaps and sensitive network configuration stored in clear text. Fixed versions were released, reinforcing that CryptoPro had multiple independently researched security concerns.

Security layer	Expected control	Failure illustrated by research	Defensive action
Physical hardware	Locked cabinet and controlled ports	Drive or boot-media access creates a local attack path	Tamper detection, port controls, custody logs
Pre-boot environment	Verify components before decrypting	Incomplete integrity validation	Patch, signed boot chain, measured boot
Secrets and configuration	Protected keys and credentials	Sensitive material exposed or insufficiently validated	Hardware-backed keys, rotation, no plaintext storage
Fleet operations	Known versions across all ATMs	Third-party component hidden inside vendor stack	SBOM, inventory and deployment evidence

Why this is a software supply-chain problem

A bank may buy an ATM platform from a large manufacturer, which integrates encryption from another vendor, drivers from hardware suppliers and management tools from still more companies. The bank sees one machine, but security responsibility is distributed across a chain.

When a vulnerability is disclosed, each link must answer a different question. The component vendor must identify affected versions and produce a fix. The ATM manufacturer must test whether its integration is affected. A deployment partner must package the update. The bank must find every relevant machine, schedule installation and verify success.

Diebold Nixdorf told Wired that only two of the nine vulnerabilities were relevant to its Vynamic Security Hard Disk Encryption system. That is a useful example of why raw CVE counts do not equal fleet exposure. Product-specific analysis is necessary—but so is evidence, because customers cannot rely on an assumption that a component is configured safely.

What banks in India should ask vendors

The first request is a software bill of materials, or SBOM, for each supported ATM image. An SBOM lists components and versions so an institution can map a new vulnerability to deployed assets without waiting for manual investigation.

The second is a product-specific impact statement. It should say whether CryptoPro Secure Disk is present, which versions and configurations are affected, which CVEs apply, what compensating controls exist and which update resolves them.

The third is deployment evidence. A vendor saying that a patch is “available” is different from a bank proving it reached every in-scope machine. Fleet dashboards should record installed versions, failures, offline terminals and exceptions with owners and deadlines.

The fourth is secure-boot architecture. Banks should prefer hardware-rooted trust, signed updates, measured boot, protected key storage and tamper evidence. Controls should fail closed without creating an unsafe plaintext fallback.

The fifth is contractual time. Service agreements need deadlines for impact analysis, emergency patches and verified deployment. They should also define disclosure duties when a subcontractor or embedded component is affected.

ATM flaws are not the same as remote jackpotting

“Jackpotting” describes malware forcing an ATM to dispense cash. The FBI warned in February 2026 about increased malware-enabled jackpotting incidents in the United States, often involving physical access to install malware. That threat is related to endpoint compromise but is not proof that the nine CryptoPro issues were exploited in those crimes.

Separating possibility from evidence is crucial in cybersecurity reporting. A vulnerability can be technically severe without confirmed exploitation. Conversely, the absence of public exploitation does not justify delaying a patch when machines are widely distributed and physically accessible.

Customers should also understand that these findings do not expose card PINs merely because someone uses an ATM. Fraud controls such as skimmer detection, transaction monitoring and card protections remain separate layers.

Why “security through obscurity” failed

Specialised embedded systems are sometimes treated as safer because few people understand their internals. Burch’s Black Hat talk, titled “The Cost of Obscurity,” challenged that logic. Limited scrutiny can allow design assumptions to survive longer; it does not prevent a determined researcher or attacker from examining the system.

Defence should assume components will eventually be understood. Signed code, strong key management, least privilege, reproducible configuration and rapid patching provide security even when architecture is public.

Our coverage of the Samsung security update shows the same operational principle at consumer scale: a long vulnerability list is useful only when affected devices, fixed versions and rollout status are clear.

The wider strategic angle also resembles our report on AI and government spyware. Better discovery tools can find flaws faster, but institutions still need governance and deployment systems that turn discovery into protection.

What ATM operators should do now

Operators should inventory CryptoPro Secure Disk across ATMs, kiosks and Windows endpoints; compare versions with vendor advisories; obtain their ATM manufacturer’s applicability statement; and verify installed fixes. Machines that cannot be patched quickly should receive compensating controls and heightened physical monitoring.

They should review maintenance access, USB and boot controls, drive-removal detection, remote-management authentication and logs for unexpected pre-boot changes. Incident teams need a process to preserve a suspected machine without destroying volatile or disk evidence.

Finally, procurement teams should treat embedded security software as a continuing dependency, not a one-time feature. The contract should keep component inventories current through the entire supported life of the ATM.

The bottom line: the newly disclosed flaws do not mean every cash machine is vulnerable in the same way. They do mean ATM security is only as strong as its least visible component—and banks need enough supply-chain visibility to find, patch and verify that component before an attacker does.

FAQs

What software had the nine ATM-related vulnerabilities?

The findings concerned CryptoPro Secure Disk, a disk-encryption and pre-boot authentication product used in some ATM security implementations and other Windows environments.

Can the flaws be exploited remotely over the internet?

The documented high-severity issue uses a local attack vector. Actual exploitability depends on version, configuration and access; the disclosures do not show that any internet user can remotely empty an ATM.

Were patches released?

Yes. The reported vulnerabilities were fixed, with affected-version boundaries and vendor-specific applicability requiring confirmation for each deployment.

What is the most important defence for banks?

Maintain an accurate component and version inventory, obtain vendor impact statements, deploy fixes and verify installation across the complete ATM fleet.