From the EV Charging Station to the Vendor’s Inbox: The Risk of Hardcoded Credentials

Introduction

During our analysis of a commercially available DC fast charger, SaiFlow’s research team uncovered a critical security flaw with immediate real-world consequences: production firmware containing hardcoded credentials to valid email accounts under the vendor’s domain, potentially granting direct access to active inboxes and sensitive communications.

It was the kind of mistake that should never reach production, and yet, there it was.

These weren’t test accounts or a sandbox environment. These were real credentials, embedded in plaintext, providing direct access to live inboxes filled with system alerts, user data, internal support threads, and even billing communications.

An attacker leveraging these accounts could impersonate the vendor, send phishing emails that appear indistinguishable from official support messages, or access sensitive communications related to infrastructure. In one case, the credentials unlocked full access to a Microsoft Office 365 mailbox, including calendar, contacts, and all other features. Another set of credentials exposed an account tied to a major Chinese email provider (https://163.com).

In this post, we’ll walk through what was found, how it was embedded in the firmware, and the broader risks it exposes, not just for this vendor, but for anyone using internet-connected EV charging infrastructure.

If you’re a CISO at a company that manufactures EV charging infrastructure, this article may prompt you to revisit your release pipeline to ensure no sensitive credentials, even from test environments, ever make it into the field.

What Did We Find?

The SaiFlow research team recently analyzed the firmware package of a commercially available DC Fast Charger as part of our ongoing research into the security posture of embedded EV charging infrastructure. The firmware came in the form of an Android APK running on the device’s internal system.

Digging through the decompiled code, we came across something that immediately raised a red flag: hardcoded plaintext SMTP credentials.

Both were embedded in what appeared to be production code, not leftover debug logic or an unused test class. Specifically, the credentials were part of a class responsible for sending emails from the device (EmailManager.java). The credentials appeared to belong to a test account, but they weren’t fake placeholders; they were real.

Even more critically, the Office 365 credentials also granted full access to the account’s Outlook inbox.

Why Is This A Big Deal?

With valid email credentials embedded in firmware, attackers can send emails directly from the vendor’s trusted domain. These messages pass all authentication checks (SPF, DKIM, DMARC) and appear completely legitimate.

This opens the door to serious risks:

• Scalable Phishing Campaigns: Attackers could send fake “payment failure” or “account update” emails to EV users, tailored with session data from exposed inboxes, making them highly convincing and less likely to be caught by spam filters
• Vendor Impersonation: A malicious actor could pose as a support technician and request CSMS (charging management system) access from charging site operators. If granted, this could lead to full charger control.
• Charger Manipulation at Scale: Gaining access to backend systems could allow attackers to remotely stop sessions, set charging limits to zero, or even overload circuits, causing disruption, equipment damage and potentially posing a threat to grid stability and safety.
• Internal Phishing: One exposed Office 365 account contained calendar data, internal threads, and contact lists. An attacker could send perfectly timed messages impersonating team members, referencing real meetings, time zone patterns, and conversations.

In our case, the company mailing group exposes full employee contact details, along with role indicators such as “IT Administrator,” “Chairman,” and “HR” . All of this information can aid targeted phishing or social engineering attempts:

🗎In some cases, full inbox access was available. In others, SMTP credentials alone enabled email transmission without inbox visibility – but with the same potential for deception.

Even “test” accounts were found to hold production data, OCMF (Open Charge Metering Format) data, charging logs, telemetry, and sensitive company information, demonstrating how easily real-world operations can be exposed.

This information can reveal operational details such as energy consumption, pricing, meter readings, timestamps, and charger identifiers, as well as commercially sensitive content on product development and business partnerships.
The presence of such data in a non-production mailbox shows how easily real-world operations and confidential information can be exposed.

What the Industry Should Learn from This

For EVSE Vendors:

• Eliminate Hardcoded Credentials from Firmware – use short-lived, scoped tokens instead.
• Store and manage authentication secrets in a Hardware Security Module (HSM) to prevent extraction from firmware.
• Remove Test Artifacts from Production Builds before production release.
• Formalize Firmware Security Review Processes, including static secret scanning and third-party validation.

For CPOs:

• Demand security audits of vendor firmware – check for embedded secrets, revocable credentials, and integrity controls.
• Restrict charger connectivity– limit egress traffic to required protocols such as OCPP, blocking others like SMTP. Enforce with Next-Generation Firewalls (NGFW) and IDS/IPS for monitoring and threat detection.
• Assume telemetry and alerts may contain sensitive data – treat compromised credentials as high-impact.

About SaiFlow and How We Can Help

SaiFlow provides a tailored runtime contextual cybersecurity solution for charging sites and distributed energy networks, focusing on securing their standard protocols, such as OCPP, OCPI, IEEE 2030.5, DNP3, IEC 61850, and more. SaiFlow’s platform provides posture management, cyber monitoring, detection, and prevention abilities, all incorporating smart-grid and sensor data in establishing the baselines, correlations, and anomalies of these types of networks.

SaiFlow protects EV charging infrastructure against a wide range of threats. In the context of this blog post, our platform helps by:

1. Detecting Malicious Activity Across the Charging Infrastructure – If compromised access is used to manipulate charger behavior or disrupt operations, SaiFlow’s platform detects it through real-time monitoring of energy anomalies and network behavior.
2. Controlling Charger Communications – With full visibility into all charging site communication, SaiFlow’s platform identifies and blocks unexpected connections, like unauthorized outbound requests, giving operators control over what their chargers connect to.

A Note on Responsible Disclosure

Before publishing this post, we attempted responsible disclosure through the vendor’s official RFC 9116–compliant security.txt. While the policy was clearly defined and appeared well-structured, the listed mailboxes were no longer active. All alternative contact attempts via other company emails or LinkedIn messages received no reply.

Maintaining an active and responsive security.txt channel isn’t just about compliance. It’s an important tool for helping researchers share findings that ultimately strengthen your products and protect your users.

Disclaimer

It should be noted that despite countless attempts to privately disclose the described vulnerabilities through the EV charger vendor’s official security contact, no response was provided, hence the identity of the vendor will be kept anonymous at this point, to avoid mass exploitation of this vulnerability in production environments.

Our research was conducted with caution and care. At no point did we attempt to disrupt services, access user data beyond what was already exposed, or modify any system.

If you’re a CPO or security lead worried this might affect your deployed infrastructure, feel free to reach out discreetly for more context.