By Jay Turla (Principal Security Researcher)
Over just three days, Pwn2Own Automotive 2025 uncovered 49 unique zero-day vulnerabilities. The full details of these discoveries will remain undisclosed for a set period to give automotive manufacturers (OEMs) and suppliers enough time to address them.
While we await the disclosures of this year’s findings, we revisit two remote code execution (RCE) vulnerabilities from last year’s Pwn2Own Automotive contest. McCaulay Hudson and Alex Plaskett, security researchers from NCC Group’s Exploit Development Group, discovered these vulnerabilities in the Phoenix Contact CHARX SEC-3100 electric vehicle (EV) charging controller:
- CVE-2024-25994: arbitrary file upload RCE vulnerability
- CVE-2024-25995: config injection RCE vulnerability
The researchers presented their findings at last year’s RomHack and 44CON conferences. In this blog entry, we summarize CVE-2024-25994 and CVE-2024-25995, highlight their broader impact on automotive cybersecurity, and discuss potential mitigations.
Trend Zero Day Initiative™ (ZDI), VicOne’s co-host for Pwn2Own Automotive and partner in vulnerability discovery and disclosure, reported both vulnerabilities to Phoenix Contact. The vendor has since issued a firmware update to fix them.
Arbitrary file upload vulnerability
To compromise the Phoenix Contact EV charging controller, the researchers first mapped its attack surfaces, including physical interfaces, device states, and external services. During their assessment, they found that the device runs custom web services.
One notable service, CharxUpdateAgent, listens on port 9999 and exposes several key URLs and functions:
- /get-update
- /return-database
- /return-logs
The researchers also reverse-engineered most of the custom services and binaries, which were built using Cython (Python in C), and performed dynamic analysis by emulation in QEMU. This approach provided them insights into deploying configuration files, modifying debug options, and managing service executions. They then discovered CVE-2024-25994, an arbitrary file upload vulnerability caused by improper validation. By sending a POST request to https://<charx-ip>:9999/return-database, they were able to execute system commands and access local resources.
Config injection vulnerability
The researchers also identified another custom web service, CharxSystemConfigManager, running on port 5001/tcp. This service allows an authenticated remote attacker to set config injections in /data/charx-system-config/manager/system-user-configuration.ini.
Values from the CellularNetwork section are copied to the PPP (Point-to-Point Protocol) config file at /etc/ppp/peers/charx-provider. An attacker could also exploit a critical function to trigger a system reboot by issuing a POST request at https://<charx-ip>:5001/api/v1.0/reboot and subsequently disrupt the EV charging controller’s operation.
Conclusion
Unrestricted file uploads, as seen in CVE-2024-25994, pose significant risks to web servers and applications. This vulnerability allows a remote attacker to upload a backdoor or malicious script, enabling unauthorized actions or code execution. To mitigate this risk, strict file and input validation should be enforced, particularly in how uploaded content is processed and stored.
RCE vulnerabilities have been prevalent in many web services, often because of inadequate input validation. In the case of the Phoenix Contact EV charging controller, CVE-2024-25995 highlights the lack of both input validation and authentication. To reduce such risks, developers should implement robust user authentication mechanisms on critical endpoints and ensure proper sanitization of user inputs.
Manufacturers and developers should consistently follow API security best practices and refer to the OWASP Top 10 guidelines, especially since their hardware often incorporates web services.
A background on coordinated disclosure timelines
Most might wonder why there is often a delay from the time Trend ZDI announces that a team has successfully hacked or “pwned” a device or software at Pwn2Own events until the subsequent publication of the techniques used in the hacks. This delay is part of the coordinated vulnerability disclosure (CVD) process, which is designed to manage zero-day vulnerabilities more responsibly.
In the 1990s, only a few hackers actively hunted for vulnerabilities, and many vendors were unprepared to handle them. Both white hat hackers and vendors had concerns, such as, “Are hackers submitting vulnerabilities in exchange for benefits?” or “Will the vulnerabilities be fixed, or will the submission be a waste of time?” It came to this compromise: Hackers first submit the vulnerabilities to the vendors, who then release a patch and publicly acknowledge the hackers for their discovery.
According to Trend ZDI’s disclosure policy, a submitted vulnerability is disclosed once a patch is available or after a certain period if the vendor is unresponsive. This approach prevents or lowers the risk of vulnerability exploitation by either resolving the issue or making the public aware of a threat that has no known fix. This explains the time gap between the initial submission of vulnerabilities and the detailed disclosure.
