See how openplc compares to other vendors in security performance
OpenPLC Runtime v3's compileprogram function (webserver/openplc.py) parses directives from uploaded Structured Text (.st) program files and writes the referenced content to with no validation that filepath stays within the ./core directory. A path-validation function, validatefilepath, exists elsewhere in the codebase (webserver/credentials.py) but is never invoked from compileprogram, leaving the sink unprotected.
OpenPLCv3 contains a heap-based buffer overflow in the getData() function in webserver/core/modbusmaster.cpp. getData() reads characters between two delimiters into a caller-supplied buffer with no size parameter and no bounds check. In parseConfig() the function is invoked with the 100-byte heap-allocated MBdevice.devname field. An authenticated attacker with access to the OpenPLC web interface can send a crafted HTTP POST to the /modbus endpoint with an oversized devicename value; the value is persisted to mbconfig.cfg and parsed on load, overflowing devname and overwriting adjacent struct fields (protocol at offset 108, devaddress at offset 109, ipport at offset 210). A 200-byte payload writes 100 bytes past the allocation. The result is heap corruption leading to runtime crash and denial of service of the PLC process control loop, with attacker-controlled overwrite of adjacent configuration fields. The upstream repository was archived on 2026-04-04 and no fix is expected; the vendor has confirmed the issue does not affect OpenPLC Runtime v4.
OpenPLC Runtime v3 contains an authenticated arbitrary file write vulnerability in the legacy web UI program‑upload workflow. The application stores an attacker‑supplied filename (progfile) directly into the Programs.File database field and later uses this value as the destination path for an uploaded file without validating or restricting the path. Because Python os.path.join() honors attacker‑controlled absolute paths, an authenticated user can write arbitrary files anywhere writable by the OpenPLC webserver process. In the default build pipeline, all C++ source files within the OpenPLC runtime core directory are automatically compiled into the executable runtime binary. By writing a malicious .cpp file into this directory, an authenticated attacker can escalate the arbitrary file write into arbitrary native code execution when the operator triggers a normal program compilation and runtime start.
A path injection vulnerability exists in OpenPLC v3 (2c82b0e79c53f8c1f1458eee15fec173400d6e1a) as the binary program compiled from gluegenerator.cpp does not perform any validation on the file path parameters passed via the command line. The user-controlled input parameters are directly passed to the underlying file operation functions (fopen/ifstream/ofstream) for file reading and writing. An attacker can exploit this vulnerability by constructing a malicious path to read arbitrary readable files.
OpenPLCV3 REST API endpoint checks for JWT presence but never verifies the caller's role. Any authenticated user with role=user can delete any other user, including administrators, by specifying their user ID or they can create new accounts with role=admin, escalating to full administrator access.
OpenPLCV3 is vulnerable to a Plaintext Storage of a Password vulnerability that could allow an attacker to retrieve credentials and access sensitive information.
OpenPLCV3 is vulnerable to an Initialization of a Resource with an Insecure Default vulnerability which could allow an attacker to gain access to the system by bypassing authentication via an API.
OpenPLC v3 contains an authenticated remote code execution vulnerability that allows attackers with valid credentials to inject malicious code through the hardware configuration interface. Attackers can upload a custom hardware layer with embedded reverse shell code that establishes a network connection to a specified IP and port, enabling remote command execution.
OpenPLCV3 is vulnerable to a cross-site request forgery (CSRF) attack due to the absence of proper CSRF validation. This issue allows an unauthenticated attacker to trick a logged-in administrator into visiting a maliciously crafted link, potentially enabling unauthorized modification of PLC settings or the upload of malicious programs which could lead to significant disruption or damage to connected systems.
A denial of service vulnerability exists in the ModbusTCP server functionality of OpenPLC v3 a931181e8b81e36fadf7b74d5cba99b73c3f6d58. A specially crafted series of network connections can lead to the server not processing subsequent Modbus requests. An attacker can open a series of TCP connections to trigger this vulnerability.
OpenPLC Runtime v3 contains an input validation flaw in the /upload-program-action endpoint: the epochtime field supplied during program uploads is not validated and can be crafted to induce corruption of the programs database. After a successful malformed upload the runtime continues to operate until a restart; on restart the runtime can fail to start because of corrupted database entries, resulting in persistent denial of service requiring complete rebase of the product to recover. This vulnerability was remediated by commit 095ee09.
OpenPLCV3 has a vulnerability in the enipThread function that occurs due to the lack of a return value. This leads to a crash when the server loop ends and execution hits an illegal ud2 instruction. This issue can be triggered remotely without authentication by starting the same server multiple times or if the server exits unexpectedly. The vulnerability allows an attacker to cause a Denial of Service (DoS) against the PLC runtime, stopping any PC started remotely without authentication. This results in the PLC process crashing and halting all automation or control logic managed by OpenPLC.
/edit-user in webserver in OpenPLC Runtime 3 through 9cd8f1b allows authenticated users to upload arbitrary files (such as .html or .svg), and these are then publicly accessible under the /static URI.
OpenPLC 3 through 64f9c11 has server.cpp Memory Corruption because a thread may access handleConnections arguments after the parent stack frame becomes unavailable.
OpenPLCV3 contains an arbitrary file upload vulnerability, which could be leveraged for malvertising or phishing campaigns.
OpenPLC ScadaBR contains an unrestricted upload of file with dangerous type vulnerability that allows remote authenticated users to upload and execute arbitrary JSP files via viewedit.shtm.
OpenPLC ScadaBR contains a cross-site scripting vulnerability via systemsettings.shtm.