By: Alex Williams
In the rapidly evolving landscape of the Internet of Things (IoT), staying ahead of potential threats isn’t just about protection; it’s about empowerment. At Pellera, we believe that understanding the intricate details of your technology stack is the first step toward a more secure, resilient future. By shedding light on hidden risks, we empower your team to innovate with confidence.
Recently, our dedicated security researchers responsibly disclosed four vulnerabilities within the Advantech DeviceOn/iEdge platform. This discovery highlights the importance of rigorous security practices and the value of partnership in navigating complex digital environments. In this article, we will walk you through our findings and provide actionable insights to strengthen your security posture.
Understanding the Landscape: Advantech DeviceOn/iEdge
Advantech is a global leader in industrial computing and IoT solutions with a yearly revenue of around US $2 billion. It provides products like industrial PCs, embedded systems, and edge computing platforms for smart manufacturing, healthcare IT, and other markets. The Advantech DeviceOn/iEdge software is a key component in this ecosystem, designed for IoT management and monitoring. It comes standard on their cloud solution product (EIS-S230) and can be used to manage a wide variety of Advantech IoT devices, including the EIS-D620, EIS-D110/EIS-D210, and EIS-D150 series.
In September 2025, Pellera responsibly disclosed four vulnerabilities in this platform, which were then publicly disclosed in November 2025. Understanding these Advantech iEdge vulnerabilities is crucial for any organization relying on the systems to maintain operational integrity.
The Breach Point: Unauthenticated Directory Traversal to Arbitrary File Read (CVE-2025-59171)
While analyzing of the product, we discovered the following vulnerability:
Our research found that this vulnerability is in Node-RED and had been silently patched as of May 1, 2018 (version 0.20.0-beta.2). However, DeviceOn/iEdge is running version 0.17.5, which is still vulnerable. The vulnerability is a simple directory traversal.
NodeRed Server\nodejs\node_modules\node-red\red\api\index[JB1] .js:
NodeRed Server\nodejs\node_modules\node-red\red\api\ui.js:
NodeRed Server\nodejs\node_modules\node-red\red\runtime\nodes\registry\registry.js:
The value of the HTTP Request-URI is never sanitized or normalized for directory traversal-related characters or strings. The vulnerability can be abused to read any file on the target machine as an unauthenticated user. With the ability to now read any file on the server, Pellera then wanted to see if there were any cracks in the authentication system that could be abused to escalate from an unauthenticated to an authenticated context.
Escalating the Risk: Cracking the Authentication System
The following file “Server\APIGateway\apps\authentication\advAuthorization.js” is used to handle the authentication for DeviceOn/iEdge:
Where the function accountChecker() is used as the authentication function, which can be seen in the server’s Node.js entry point file “Server\APIGateway\app.js”:
The authentication function, accountChecker() which is called by checkAuth(), is used for all Requests-URIs except for the listed unauthenticated endpoints. The unauthenticated Request-URIs are “/rmm/v1/ui-config/system”, “/rmm/v1/system/iscfapp”, and “/rmm/v1/system” and Request-URIs that begin with either “/restapi/WSNManage/” or “/export/”.
During the authentication process, the password for the root account is symmetrically encrypted using AES256 rather than being hashed. The key used in the encryption is readily available in the same file, “advantech_e2i_aes256”. The encrypted password, Base64-encoded, for the root account is stored in the file ‘./config/web/encrypted’ which has a full path (in a default installation on Windows Server 2022) of “C:\Program Files (x86)\Advantech\E2I\Server\APIGateway\config\web\encrypted”.
By abusing the previous vulnerability, an attacker can read any file on the server including password file:
After leaking the encrypted password and knowing that the password was encrypted using AES256 with the key “advantech_e2i_aes256”, the password can be decrypted:
Since the username of the root account cannot be changed, the credentials for the root account are root:P@ssw0rd123X. An attacker can now escalate from an unauthenticated to an authenticated context as the root account.
ctl_selfweb() Import Directory Traversal to Remote Code Execution (CVE-2025-62630)
Pellera discovered the following authenticated directory traversal vulnerability that can lead to remote code execution.
DeviceOn/iEdge includes multiple plugins installed by default that can be used for a variety of functions. The Expression plugin can be used to recalculate sensor data using mathematical expressions. When a user attempts to load a configuration file for the Expression plugin, the function ctl_selfweb() is called to handle the HTTP POST request. An example of the HTTP POST request sent looks like the following:
When the request is received, the server determines the action to take based on the value of the Command JSON key. If that value is equal to “Import”, then the import configuration functionality is selected. In that previous request, the value of the file JSON key is used to store the filename of the configuration file, and the value of the base64_archive JSON key is used to store the Base64-encoded contents of the configuration file.
Then, the file path “./<file>” is built, where <file> is the filename of the imported configuration file. The server then creates a file at the previous location and populates the contents of the file to the Base64-decoded value of the base64_archive JSON key.
Server\APIGateway\apps\expression\index.js:
Server\APIGateway\inc\utility.js:
The value of the JSON key file is not sanitized for directory traversal characters/string. Additionally, the extension of the file is not restricted, and the file’s contents (which are stored in the value of the JSON key base64_archive) are also not restricted. An authenticated attacker has the potential to create arbitrary files, overwrite files, or in the worst case, achieve remote code execution in the context of NT authority\system.
However, since the authentication system can be bypassed with the previous vulnerability, these vulnerabilities can be chained together to achieve unauthenticated remote code execution as NT authority\system.
Proof of Concept
In this proof of concept, the following steps are performed:
- Use the Unauthenticated Directory Traversal vulnerability to retrieve the saved encrypted password.
- Decrypt the password using the hardcoded key.
- Log into the product with the decrypted credentials.
- Use the ctl_selfweb() Import Directory Traversal vulnerability to overwrite the index.js file for the Modbus-Master plugin (a different plugin) with a Node.js webshell payload.
- Reload the Modbus-Master plugin to execute the new Node.js index.js file.
- Access the newly created webshell.
Transforming Risk into Resilience: Mitigation Strategies
There are several vulnerabilities in this chain, some of which have already been fixed as of their discovery, but the server was using the old vulnerable versions of the software. Additionally, there are some unusual coding practices, especially during the authentication process, that can be exploited to cause further damage to the system.
Here is how you an empower your organization to stay secure and avoid these issues:
1. Keep Dependencies Current
Keep your dependencies updated. Outdated dependencies can leave you vulnerable to risks, and patching regularly is key to staying safe. For example, the unauthenticated directory traversal allowing arbitrary file reads was fixed back in 2018, without an associated CVE. This highlights why staying on top of updates is important.
2. Sanitize and Normalize Inputs
All file operations that use user-supplied data must be sanitized or normalized for directory traversal-related characters or strings. Additionally, if the supplied data includes a file extension, ensure that the extension is checked correctly. For example, we have discovered a vulnerability in a different product that looked like the following:
The issue in this example, excluding the fact that the value of the FilePath parameter is not sanitized or normalized for directory traversal-related characters or strings, is that the check for the path including the string “.sql” is not performed correctly. The “.sql” string must exist at the end of the path, not anywhere in the path. The value “fake.sql\..\..\..\..\Windows\win.ini” could be supplied by an attacker to circumvent the “.sql” check.
3. Validate File Uploads
Ensure that file contents are checked, if possible. In this vulnerability, the value of the *base64_archive* parameter contains a base64 encoded .zip file. While it’s not necessary to check for the contents of an uploaded file if the file can be ensured to be uploaded to the correct directory with the correct extension, it is good practice. More information about file upload handling can be found on OWASP’s recommendations.
4. Secure Password Storage
Passwords should be stored in hash form, not encrypted form. The product encrypts the password before storing it. However, the key for encryption is hardcoded in the server’s files, which makes decryption simple. Instead, the server should be the hashing password before saving this data. Specific algorithms and methods for password storage can be found on OWASP’s recommendations. Additional information can be found in CISA’s ICS advisory.
Timeline of Discovery and Disclosure
- September 3, 2025: Pellera reports four vulnerabilities to Advantech via their security disclosure email.
- September 11, 2025: Pellera requests an update from Advantech; Advantech responds that they were unable to receive our first email and requests we resend our report.
- September 12, 2025: Pellera sends a OneDrive link to Advantech containing the report.
- September 17, 2025: Advantech confirms receipt of the report and directs the information to the leader of the DeviceOn/iEdge product; Pellera requests to be notified when progress is made; Advantech confirms the product is End of Life (EOL) and has been removed from their website.
- September 18, 2025: Pellera requests to ensure that no update will be made to remediate the security vulnerabilities and requests for the EOL date for the product.
- September 21, 2025: Advantech confirms that the vulnerabilities will not be remediated and states that the EOL date for iEdge was March 2023; Pellera reports the four vulnerabilities found to Vulnerability Information and Coordination Environment (VINCE) for coordination with Cybersecurity and Infrastructure Security Agency (CISA).
- November 6, 2025: CISA releases an ICS advisory regarding these vulnerabilities and assigned the following CVEs: CVE-2025-58423, CVE-2025-59171, CVE-2025-62630, and CVE-2025-64302.
Conclusion
The discovery of these Advantech iEdge vulnerabilities serves as a powerful reminder of the need for proactive security. While this specific product has reached its end of life, the lessons learned remain vital. By embracing secure coding practices, managing dependencies, and fostering a culture of transparency, we can build technology that is not only powerful but also resilient.
At Pellera, we are committed to being your partner in this journey. Contact our team today to learn more about how we can help secure your infrastructure, empower your teams, and drive your business momentum forward.
