There have been multiple demonstrations of stealing credentials or influencing charging sessions via the EV-to-EVSE connection. Oxford researchers, Baker and Martinovic, demonstrated that they could sniff radiated HomePlug Green PHY data on a CCS connection using unencrypted ISO 15118/DIN 70121 [100] traffic, using a software defined radio (SDR) [101]. Köhler et al. subsequently showed that charging sessions could be wirelessly aborted by disrupting the PLC communications in their Brokenwire attack demonstrations [102]. The researchers found that they could abort CCS charging sessions at distances of 47 m using SDRs with less than 1 W of power, and this attack was successful on all seven vehicles and 18 EVSEs that they investigated.

CCS communications do not provide mutual authentication, so there is a risk of MITM attacks; this presents risks to billing data privacy and, by stealing MAC addresses, creates a possible avenue for user tracking. Idaho National Laboratory (INL) indicated that there was a risk that EVs could spread viruses to EVSE which would then further propagate the malware [103]. Rohde demonstrated disruptions to charging, including a changing power level and increased high total harmonic distortion in a DCFC charging session using a CHAdeMO connector when malware on the EV or EVSE falsified the EV battery’s state-of-charge (SOC) [104]. Another team of researchers created the V2G Injector, an open-source tool to read and write HomePlug Green PHY data. They demonstrated that a malicious actor could collect network keys and inject data into the CCS Efficient XML Interchange (EXI) network sessions [105]. In some follow-on work, a Trend Micro combined the V2G Injector with an Apache logging package (Log4j) vulnerability to escalate access privileges on a simulated EVSE running a V2G Java stack [106].

The ISO 15118 protocol has garnered extensive security and threat analyses [95,107,108,109]. Lee et al. found that the ISO 15118 communications may expose the risk of an EV spoofing another vehicle, stealing power, falsifying meter data to gain free charging, or forging the malfunction status to prevent operations [107]. Bao et al. had similar concerns of session hijacking; charging repudiation; and machine-in-the-middle (MITM), denial-of-service (DoS), and masquerading attacks [108]. The CCS Plug-and-Charge (PnC) PKI approach and credential management that were defined in ISO 15118-2 [110] have been the source of detailed studies. Siemens investigated the proposed ecosystem and noted challenges when EVSE devices are offline and the importance of managing cryptographic material, as well as emphasizing the need to secure other EVSE functions, such as multimedia services, firmware updates, and remote diagnosis [95,109]. Höfer et al. considered the privacy risks associated with ISO 15118 and found that they were inadequate for the authentication and authorization of payment and billing operations [111].

Early-generation EVSE infrastructure was vulnerable to RFID cloning and other authorization bypass mechanisms with local access to the equipment. In 2017, Fraunhofer Institute for Industrial Mathematics (ITWM) researcher Mathias Dalheimer presented weak security practices in billing transactions and RFID card data storage in public charging infrastructure at the Chaos Communication Congress [112]. He demonstrated how RFID cards could be cloned in a way that other debit or credit cardholder accounts would be billed for charging sessions. Similar EVSE operator privacy and identification concerns were shared by Achim Friedland for RFID; smart phone; and MIFARE Classic (13.56 MHz contactless smart cards) authorization mechanisms [113]. There have also been warnings about credit card skimmers on EVSE equipment [114].

INL performed six Level 2 SAE J1772 EVSE assessments between 2014–2017. Two of these products were prototypes. They found that some of the EVSE devices included iOS and Android apps that were designed for customers to manage their charging session. These applications could easily be reverse-engineered to reveal weaknesses in the EVSE management and vendor cloud interfaces [115]. Many EVSE web service vulnerabilities have also been disclosed; these will be covered in the next section.

EVSE devices often include a local web server or connect to cloud environments to relay information from the charge point operator, EVSE owner, or driver. The vulnerabilities associated with internet communications are presented in this section and can be divided into (a) local web interfaces, (b) remotely accessible EVSE devices, and (c) EVSE communication to backend systems. In the case of the latter two, the remote communications over the public internet are especially concerning because of the scalability risk.

One common issue with EVSE equipment is the presence of insecure web services that can be accessed locally from a smart phone or computer. In many cases, these are designed for EVSE configuration or maintenance via Wi-Fi. In home and enterprise environments, these services should be shielded by a firewall from the wider internet, but these vulnerabilities may expose home and corporate networks to a breach via the EVSE.

In the Pen Test Partners report there were multiple local web service issues: Wallbox included insecure direct object references in their web API; an EVBox web API vulnerability allowed account hijacking; and the EO mini pro was running the insecure Telnet protocol on port 2000, allowing an attacker to change the configuration data without any authentication [116]. A Shenzen Growatt Application Programming Interface (API) allowed firmware updates that could give access to home networks, and credentials were unchecked after the first login request [116]. In the INL assessment, they found unauthorized access to configuration files, and data were provided via insecure wireless web servers [115]. In a Hack in the Box presentation, Shezef reported finding DIP switches left in configuration mode and an open configuration web server on a GE EVSE [96].

Nasr et al. analyzed 16 EV Charging Station Management Systems (EVCSMS) by inspecting five EVSE firmware packages, three mobile applications, and eight web applications. As part of this work, multiple web server vulnerabilities were disclosed for the Schneider Electric EVlink City, EVlink Parking, and EVlink Smart Wallbox products, including Cross-Site Scripting (XSS); Cross-Site Request Forgery (CSRF); Server-Side Request Forgery (SSRF); and JavaScript information exposure [117,118,119,120]. Additionally, they found multiple vulnerabilities that affected charging processes, settings/firmware, billing, PII, and user data, as well as botnet recruitment opportunities and the potential for DoS and brute force attacks on web endpoints [120].

Kaspersky Lab found that the ChargePoint smart-phone application could remotely tamper with a charging session via Wi-Fi using a buffer overflow in the web server Common Gateway Interface (CGI) binaries [121]. The risk that was presented with this website vulnerability was that charging sessions could be stopped, or the maximum charging current could be increased to amperages above the circuit rating, tripping the breaker, overheating the wiring, or, in the worst case, causing a fire [122].

The Argonne National Laboratory (ANL) and Illinois Institute of Technology (IIT) were able to locate multiple EVSE chargers on the public internet using Shodan, Nmap and Exploit Database’s SearchSploit tool based on specific signatures [88]. ANL and IIT found that some devices were running unnecessary or outdated services, using weak credentials, or missing login timeout functions. Previously, INL found that Level 2 EVSE devices were not accessible via the public internet but could be reached by other devices that were connected to the same cellular provider [115]. The Shenzen Growatt network with 2.9 million devices on it only required the predictable serial number and an unvalidated username to lock and unlock the charger, and Pen Test Partners indicated that the locking action could stop all charging [116]. The Spanish Circontrol CirCarLife web service software exposed system software information, statuses, and critical setup information which could be accessed or exfiltrated by unauthenticated or unprivileged users [123,124].

Hille and Allhoff showed that several vulnerable services running on an EVSE could be accessed from the mobile network interface [125]. They found a weak key-exchange algorithm and no brute force protections on the SSH service; the web service used an unencrypted channel for logging in that could be bypassed by forging a Session Storage cookie; passwords were hashed using the insecure MD5 algorithm, and the HTTPS port used a SHA-1 self-signed certificate; and, lastly, the SQL server was vulnerable to data exfiltration.

Multiple issues associated with EVSE vendors, e-mobility service providers, and charge service-provider backend systems have been identified. These are typically hosted in the cloud using Amazon Web Services, Google Cloud, Azure, or another cloud platform to provide, (a) EV owners monitoring and control functionality; (b) EVSE owners pricing, billing, advertisement, and other functions; (c) other EVSE providers with cross-billing APIs; (d) utilities with demand management functions. These installations often expose insecure, remote management functions.

In the INL assessments identified that a management application lacked appropriate authentication methods, such as client-side validation, unencrypted HTTP service for logon credentials, and unsanitized logon fields that were vulnerable to SQL injection attacks [115]. INL also reported compromising a File Transfer Protocol (FTP) server that then pushed out modified firmware to all EVSE devices from this vendor in the next update cycle. They further noted the potential for command injection and XSS exploits on management servers and indicated that they discovered vulnerabilities that would allow the remote management of EVSE units that did not belong to that user account.

Cloud-to-cloud communications can be enabled through the Open Charge Point Interface (OCPI) [126]. This allows charge providers to bill other providers without downloading additional apps, etc. A ChargePoint GraphQL endpoint publicly exposed the details of their API interface, which could have acted as a first step to more severe attacks that would have impacted the 150,000 chargers connected to the ChargePoint system [116].

The Open Charge Point Protocol (OCPP) is commonly used between EVSE devices and backend or cloud networks to configure the charger and obtain charging statistics. The earlier versions of the protocol used unencrypted HTTP, so there were MITM risks for intercepting transaction data [90]. At DeepSec in 2016, Achim Friedland also pointed out the risk of network traversal once a charging station was compromised, as well as issues of missing OCPP guidance for network settings or certificate management [113]. Mathias Dalheimer and Achim Friedland further warned that it was also possible to decipher the data from the EVSE to the backend systems to intercept RFID, credit card via smart phone app, or other near-field-communication (NFC) data [112,113,127]. Rubio et al. further noted the risk of MITM attacks on OCPP [128]. In a joint white paper published by DigiCert, ChargePoint, and Eonti, the team performed a 360° maturity assessment on the ISO 15118-2 PKI system and scored the standard poorly in 85% of their governance, technical, and operations areas [129].

Supply chain vulnerabilities are also a risk for EV charging operations. During the Russian invasion of Ukraine in early 2022, Pocceти Злeктpoтpaнcпopт (Rosseti Electric Transport) EV chargers along the M-11 motorway between Moscow and Saint Petersburg were disabled and displayed anti-Putin and pro-Ukraine messages. Purportedly, a Russian EV charger provider, Gzhelprom, outsourced components, including the data controller to a Ukrainian Company, AutoEnterprise, which maintained remote backdoor access and control of the charging functionality [130,131]. This access allowed the component vendor to change the settings in the EVSE devices remotely.

Maintenance interfaces are common on EVSE devices. These may be serial (e.g., RS485, RS232, serial over USB, or other Universal Asynchronous Receiver-Transmitter (UART) interfaces); Wi-Fi or Ethernet (e.g., SSH, Telnet, HTTP, etc.); Bluetooth; or via the front panel/screen. Cybersecurity researchers have found several vulnerabilities in the hardware and software running on EVSE. Two EVSE devices studied by Fraunhofer included USB ports that would copy logs and configuration data, including the OCPP server login and password, and authentication tokens from previous users [112]. Furthermore, modifying the configuration data on the USB drive and re-inserting it would automatically update the EVSE. This was the same behavior reported by INL in their Level 2 assessments.

INL also found (a) all the EVSE devices were running outdated Linux kernels with superfluous services (e.g., Telnet and FTP); (b) the processes were running as root, and stored passwords could be cracked “in a reasonable amount of time” because of weak hashing; (c) five devices did not include secure boot, and firmware images could be extracted; (d) firmware was unsigned; (e) there were active serial ports, ethernet jacks, and USB ports on the EVSE devices; (f) JTAG interfaces allowed direct control of the processor; (g) physical tamper-detection tools could be bypassed; (h) multiple insecure coding practices were observed [115]. Kaspersky Lab found that they could trigger a factory reset using a special blinking pattern that was picked up with the photodiode on the EVSE [121].

In a Pen Test Partners report, EO Mini Pro 2, Hypervolt, and Wallbox EVSE devices used Raspberry Pi single-board computers in their products. These inexpensive computers do not include secure bootloaders, so any data on them—such as homeowner Wi-Fi Pre-Shared Keys (PSKs) or other credentials, such as usernames, passwords, etc.—could be stolen by physically pulling the memory [116,132,133]. Schneider EV chargers included hard-coded credentials, improper verification of cryptographic signatures, encrypted credentials disclosure mechanisms, unverified user password changes, and passwords hashed without a salt [117,118,119].