How Hackers Can Unlock Any Car from Brand X Worldwide

A technical article that gained 215 points and 75 comments on Hacker News reveals a troubling fact: in most parts of the world, the doors of a certain brand's cars can be unlocked remotely. The author, Shubs, documented this finding on his personal blog, prompting the security community to once again scrutinize connected-car security.

Where the Attack Surface Comes From

According to Shubs' analysis, the problem does not lie in traditional mechanical locks or the radio-frequency signals of remote key fobs. The attack path points to the communication link between the vehicle and cloud services. Modern cars commonly feature remote control capabilities, allowing owners to unlock and start their vehicles via a mobile app. Behind this convenience is a continuous exchange of data between the vehicle's built-in cellular communication module and the manufacturer's servers. When this communication protocol has design flaws or authentication bypasses, attackers may be able to forge commands, causing the vehicle to mistakenly believe it has received an unlock request from the legitimate owner.

Shubs did not disclose the specific brand name or vulnerability details in the summary, but judging from the direction of discussion in the HN comments, this problem is fairly widespread. Multiple commenters noted that different manufacturers adopt similar but fragile patterns for permission verification of cloud APIs—relying on static tokens or predictable session identifiers rather than strongly encrypted mutual authentication.

Mutual Authentication is a critical security mechanism in connected-car cloud communication. In traditional one-way authentication, only the server verifies the identity of the client (the vehicle), whereas mutual authentication requires both parties to verify each other's identity credentials. This is typically implemented based on a certificate system or asymmetric encryption and can effectively prevent man-in-the-middle attacks and command forgery. The article's mention that manufacturers rely on "static tokens or predictable session identifiers" is precisely a typical manifestation of the lack of mutual authentication—once a static token is leaked or can be predicted, an attacker can impersonate the legitimate owner to send unlock commands to the vehicle. In contrast, mutual authentication requires an attacker to possess both the vehicle's private key and a certificate chain trusted by the server, greatly raising the bar for attack. In connected-car scenarios, because vehicle lifecycles exceed ten years, the design of key rotation and certificate revocation mechanisms is also more complex than in traditional web applications.

What "Most of the World" Means

The qualifier "most of the world" in the title deserves attention. Vehicle remote control functionality depends on cellular network coverage, so the effective range of the attack is directly related to the network infrastructure of the target market. In regions with high cellular penetration, this attack surface is almost everywhere. This also explains why the problem is described as global rather than regional—as long as the vehicle is online, an attacker theoretically has a point of contact.

From a security research perspective, the severity of this type of vulnerability lies in the fact that it bypasses the constraint of physical contact. Traditional car theft requires approaching the vehicle, defeating locks, or relaying remote key signals, whereas cloud command injection can occur from any distance. An attacker does not need to be in the parking lot, or even in the same country.

The Telematics Control Unit (TCU) is the core hardware component that enables remote control of a vehicle. The TCU contains an eSIM or physical SIM card and maintains a persistent connection to the manufacturer's cloud via 4G/5G networks, responsible for transmitting remote commands such as unlock, start, and location. Its firmware is typically provided by Tier-1 suppliers and then integrated by the manufacturer. The TCU's attack surface includes: SIM card configuration flaws, insufficient APN (Access Point Name) permission isolation, and missing signature verification for firmware updates. The premise of the article's statement that "the attack surface is almost everywhere" is precisely that the TCU has become standard equipment in the vast majority of modern vehicles. Notably, some manufacturers, to reduce costs, have the TCU share a network channel with the in-vehicle infotainment system, further expanding the attack surface—if an attacker can compromise the infotainment system, they may be able to move laterally to the TCU and then reach the cloud command channel.

Community Reaction and Industry Inertia

Among the 75 HN comments, the focus of discussion quickly shifted from technical details to accountability. Some commenters argued that manufacturers prioritizing convenience over security when implementing remote control features is the root cause of such problems. Others pointed to more structural issues: the automotive industry's software supply chain is complex, cloud services are often provided by third-party vendors, and manufacturers themselves have limited control over security boundaries.

One detail: Shubs' original article was described as "Unlocking any car from X brand" rather than targeting a specific model. This phrasing suggests the vulnerability may exist in brand-level shared infrastructure rather than in configuration differences among individual models. If so, the impact would cover a large number of vehicles sold by that brand in the relevant markets, and remediation would need to start from the cloud service side rather than relying on per-vehicle OTA updates.

OTA (Over-the-Air) updates are often regarded as the primary means for smart cars to patch vulnerabilities, but their limitations are particularly prominent in the context of this article. OTA updates mainly target vehicle-side firmware and software, whereas the root cause of the vulnerability described here lies on the cloud service side—permission verification logic, token generation mechanisms, and API authentication flows all run on the manufacturer's servers. This means that even if the vehicle side supports OTA, it cannot fix the server-side authentication bypass. Cloud-side remediation requires the manufacturer to modify backend code, rotate keys, reissue certificates, and ensure that existing vehicles update their configurations in sync, with coordination costs far higher than per-vehicle OTA. In addition, the TCU firmware of some older models does not support remote updates, forcing manufacturers to perform offline repairs through recalls or dealer channels, which entails enormous logistics and labor costs on a global scale.

Implications for Connected-Car Security

This case once again reminds us that the attack surface of smart cars has long extended beyond the physical boundaries of the vehicle itself. Cloud APIs, mobile apps, and cellular communication modules—every link can become an entry point. For security researchers, black-box testing of automotive cloud services remains a relatively unexplored field; for manufacturers, the permission model of remote control features requires stricter threat modeling than traditional web applications.

Shubs' discovery is not an isolated case. In recent years, connected-car security research has gradually expanded from the CAN bus and keyless entry systems to the cloud interface level. As vehicle connectivity rates continue to rise, such "open the door without meeting" vulnerabilities will become increasingly difficult to ignore.

One-line Summary

A certain brand's automotive cloud communication link has an authentication flaw that allows remote injection of unlock commands, affecting a large number of online vehicles worldwide.

Paragraph Summary

Shubs disclosed on Hacker News that a certain brand's car doors can be unlocked remotely in most parts of the world, with the attack path pointing to the communication link between the vehicle and cloud services rather than traditional mechanical locks or remote key signals. The root cause is that the manufacturer's cloud API permission verification relies on static tokens or predictable session identifiers and lacks strongly encrypted mutual authentication, allowing attackers to forge commands that make the vehicle believe it has received an unlock request from the legitimate owner. Because the vulnerability may exist in brand-level shared infrastructure, the impact covers a large number of vehicles sold by that brand in the relevant markets. HN community discussion points to structural industry problems: convenience prioritized over security, and cloud services often provided by third-party vendors. Remediation must start from the cloud service side rather than relying on per-vehicle OTA updates.