Socials

A stored Cross-Site Scripting (XSS) vulnerability exists in the project delete flow of Coolify ≤ v4.0.0-beta.420.6. A low-privileged member can create a project with malicious data that triggers JavaScript execution when an administrator deletes it.

Affected Versions: ≤ v4.0.0-beta.420.6
Fixed in: v4.0.0-beta.420.7
CWE: CWE-79 (XSS), CWE-20 (Improper Input Validation)
Severity: Critical (9.4)

Root Cause:
- Project metadata (name/description) is not sanitized before being rendered in the deletion confirmation flow.

Proof of Concept (PoC)

    1. Log in with a regular (non-admin) user account.
    2. Create a new project with the following malicious name:

    <details x=xxxxxxxxxxxxxxxxxx:2 open ontoggle="prompt('PoC');">

    3. Inside this project, add any resource (e.g., GitLab, Docker image, etc.).
    4. When an administrator try to delete the project, the payload is automatically executed.


Impact:
- Account/session takeover (cookies, tokens)
- Access to projects, terminals, and API keys
- Full compromise of Coolify instance if exploited.

Exploitability: Remote, low privileges, requires admin interaction.
    

• GitHub PoC
• CVE Record

The issue was fixed in Coolify v4.0.0-beta.420.7. Mitigation includes:
• Sanitize and escape project metadata before rendering • Enforce strict Content-Security-Policy (CSP) • Validate user inputs against XSS payloads

Low-privileged members can inject dangerous Docker Compose directives during deployment, leading to RCE.

Cause: insufficient validation of user-provided compose fields

Reproduction Steps:
1. Authenticate as a member-level user (non-administrator)
2. Create or edit a project in Coolify
3. Supply malicious configuration using one of the Docker Compose payloads above 
4. Deploy the project
5. Verify exploitation by checking for host-side artifacts (e.g., /tmp/proof_rce.txt) or reviewing command output in deployment logs

• GitHub PoC
• CVE record

The issue was fixed in Coolify v4.0.0-beta.420.7. Update to this version.

Coolify versions prior to and including v4.0.0-beta.420.6 are vulnerable to a critical remote code execution (RCE) flaw in the project deployment workflow. The platform allows authenticated users, with low-level privileges, to inject arbitrary shell commands via the Git Repository URL field during project creation. By submitting a crafted repository string containing command injection syntax, an attacker can execute arbitrary commands on the underlying host system, resulting in full server compromise.

Cause: direct concatenation into shell
Reproduction Steps:
1. Login as a low-privileged user
2. Create a new project
3. Select private GIT
4. Insert a malicious payload in the Git Repository URL field (e.g. [email protected]:fake/repo.git; cat /etc/passwd #;)
5. Deploy the project → observe arbitrary command execution in the log

• GitHub PoC
• CVE record

Impact: Full server compromise. If coolify is installed as root the shell command will be runned as root.

Malformed program uploads cause an unrecoverable crash requiring full reinstall.

OpenPLCRuntimeV3 suffers from a persistent denial of service (DoS) vulnerability in the /upload-program-action endpoint.
By modifying the epoch_time parameter during program upload, a low-privileged authenticated user can corrupt the backend database.
This corruption initially disables critical pages and eventually prevents the entire runtime from starting, effectively bricking the application until it is rebased.

Reproduction Steps:

1. Open burpsuite
2. Open burpsuite browser
3. Go on the openplc interface
4. Authenticate with a low-privileged account.
5. Upload a program via /programs
6. Choose a random name.
7. Turn on burpsuite proxy
8. Send request to repeater
9. Edit epoch_time section and change by a random character like "L" instead of original epoch_time
10. Send the new crafted request.
11. Observe /programs and you will see that is no more working
12. After that sometimes when OpenPLC Restart the runtime fails to launch and it's impossible to restart OpenPLC after this.



Burp Request Example:
POST /upload-program-action HTTP/1.1
Host: TARGET:8080
Content-Type: multipart/form-data; boundary=----BOUNDARY
Cookie: session=[valid-session-cookie]

------BOUNDARY
Content-Disposition: form-data; name="prog_name"

test
------BOUNDARY
Content-Disposition: form-data; name="prog_descr"

test
------BOUNDARY
Content-Disposition: form-data; name="prog_file"; filename="demo.st"
Content-Type: text/plain

PROGRAM demo
END_PROGRAM
------BOUNDARY
Content-Disposition: form-data; name="epoch_time"

"Just edit here and it will work (e.g "Hello !")"
------BOUNDARY--

• Github PoC
• CVE record

Impact: OpenPLCV3 will be unaccessible after app or OS reboot.

I discovered a vulnerability in the OpenPLC Runtime webserver (released version: 2024-12-31) that allows authenticated users to upload arbitrary files (e.g., .html) as profile pictures. These files are stored in the /static/ directory and are accessible without authentication, enabling stored XSS or malicious hosting scenarios.

    1. Authenticated user uploads a .html file as a profile picture.
    2. File is stored in /static/ and given a predictable ID (e.g., http://localhost:8080/static/336029.html)
    3. Any user (even unauthenticated) can access the uploaded file directly.
    4. If the file contains JavaScript or other malicious code, it will execute in the victim’s browser.

• Github PoC
• CVE record