CVE-2026-34047: Verified Repro With Script Download

CVE-2026-34047 is an authorization bypass in Coolify's terminal flow. The user-facing terminal pages are protected by the can.access.terminal / canAccessTerminal authorization gate, but the backend bootstrap endpoints used by the terminal WebSocket server (POST /terminal/auth and POST /terminal/auth/ips) only require authentication in the vulnerable release. A low-privileged authenticated team member can call those endpoints directly, obtain an authorized host list, connect to the real /terminal/ws WebSocket service, and cause Coolify's terminal server to spawn an SSH command toward a managed host.

• Package/component affected: coollabsio/coolify, specifically the Laravel terminal authorization routes in routes/web.php and the docker/coolify-realtime/terminal-server.js WebSocket terminal backend.
• Affected versions: Coolify versions up to and including 4.0.0-beta.470 are affected according to the ticket.
• Patched version: 4.0.0-beta.471 / the middleware fix adding can.access.terminal to the terminal bootstrap routes.
• Risk level and consequences: Critical. An authenticated low-privileged team member can bypass terminal authorization and reach the command-execution path intended only for team administrators/owners. In a real Coolify deployment, this can provide command execution on configured/managed hosts through Coolify's terminal SSH flow.

Impact Parity

• Disclosed/claimed maximum impact: Code execution / remote command execution on managed hosts by an authenticated low-privileged Member user.
• Reproduced impact from this run: Full WebSocket terminal command execution path was reproduced. The script authenticates as a Coolify team member, receives HTTP 200 from /terminal/auth and /terminal/auth/ips, opens /terminal/ws, sends a terminal SSH command payload, and receives output from a managed-host SSH peer after the host executes the attacker-supplied shell commands (printf 'REPRO_WS_COMMAND_EXECUTED\n'; whoami; hostname; pwd).
• Parity: full for the requested WebSocket terminal flow and code/command-execution impact. The managed host is a local unprivileged SSH peer created by the script, but the boundary crossed is the real Coolify terminal WebSocket server and OpenSSH command path.
• Not demonstrated: The script does not retrieve a production SSH private key or spawn a root shell on a real external host. It proves the terminal authorization bypass reaches real command execution through the product WebSocket/SSH path using a controlled local managed-host peer.

Root Cause

In the vulnerable route definitions, Coolify protects the visible terminal pages with can.access.terminal but leaves the terminal backend authorization endpoints without that middleware:

Route::get('/terminal', TerminalIndex::class)->name('terminal')->middleware('can.access.terminal');
Route::post('/terminal/auth', function () {
    if (auth()->check()) {
        return response()->json(['authenticated' => true], 200);
    }
    return response()->json(['authenticated' => false], 401);
})->name('terminal.auth');

Route::post('/terminal/auth/ips', function () {
    if (auth()->check()) {
        $team = auth()->user()->currentTeam();
        $ipAddresses = $team->servers
            ->where('settings.is_terminal_enabled', true)
            ->pluck('ip')
            ->filter()
            ->values();
        return response()->json(['ipAddresses' => $ipAddresses->all()], 200);
    }
    return response()->json(['ipAddresses' => []], 401);
})->name('terminal.auth.ips');

The real terminal WebSocket server (docker/coolify-realtime/terminal-server.js) trusts those endpoints. During WebSocket verification it calls http://coolify:8080/terminal/auth; on connection it calls http://coolify:8080/terminal/auth/ips; when a client sends a command message it parses the SSH target, checks only whether the target is present in the returned authorized IP list, and then calls pty.spawn('ssh', ...). Because the backend route authorization is too weak, a low-privileged member receives the same authorization bootstrap data as an owner/admin.

The fix is to require the same terminal authorization gate on the backend bootstrap routes, e.g. adding ->middleware('can.access.terminal') to both terminal.auth and terminal.auth.ips. The reproduction script applies this middleware as the fixed negative-control behavior and verifies that the member is blocked with HTTP 403 before WebSocket command execution.

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh from the bundle root (or with PRUVA_ROOT pointing at the bundle).
2. The script:
   • Reuses the prepared Coolify repository at <project_cache_dir>/repo when available.
   • Checks out v4.0.0-beta.470 and starts the real Laravel application with a SQLite test database.
   • Starts the real docker/coolify-realtime/terminal-server.js WebSocket service.
   • Creates an owner, a low-privileged member, a terminal-enabled server record for 127.0.0.1, and a local managed-host SSH peer on 127.0.0.1:2222.
   • Logs in as the member through Coolify's magic-link route and makes real HTTP requests to POST /terminal/auth/ips and POST /terminal/auth.
   • Connects to ws://127.0.0.1:6002/terminal/ws with the member session cookies and sends a terminal SSH command payload.
   • Verifies the vulnerable path returns command output from the managed host.
   • Applies the fixed middleware to the two terminal bootstrap routes, repeats the same member flow, and verifies the endpoints return 403 and no managed-host command executes.
3. Expected evidence of reproduction:
   • bundle/logs/vuln_result.txt shows IPS_STATUS=200 and AUTH_STATUS=200 for the member user.
   • bundle/logs/terminal_vuln.log shows WebSocket authentication, authorized IP retrieval, received command, parsed SSH metadata, and Spawning PTY process for terminal session.
   • bundle/logs/managed_host_vuln.log shows MANAGED_HOST_PROCESS with the attacker-supplied shell command and MANAGED_HOST_PROCESS_EXIT ... output='REPRO_WS_COMMAND_EXECUTED....
   • bundle/logs/ws_client_vuln.log shows the WebSocket client received REPRO_WS_COMMAND_EXECUTED, whoami, hostname, and pwd output followed by pty-exited.
   • bundle/logs/fixed_result.txt shows IPS_STATUS=403 and AUTH_STATUS=403 for the same member role.

Evidence

Key runtime artifacts from the final successful runs:

• bundle/repro/reproduction_steps.sh — self-contained reproducer.
• bundle/repro/runtime_manifest.json — runtime evidence manifest with service_started=true, healthcheck_passed=true, and target_path_reached=true.
• bundle/logs/reproduction_steps.log — orchestration log with final summary:
  • Vulnerable: Member endpoints 200/200, WebSocket managed-host command execution=true
  • Fixed: Member endpoints 403/403, WebSocket blocked=true
  • SUCCESS: CVE-2026-34047 reproduced with WebSocket command execution and fixed negative control
• bundle/logs/vuln_result.txt:
  • IPS_STATUS=200
  • IPS_BODY={"ipAddresses":["127.0.0.1","coolify-testing-host","host.docker.internal","localhost"]}
  • AUTH_STATUS=200
  • AUTH_BODY={"authenticated":true}
• bundle/logs/terminal_vuln.log proves the real terminal backend path:
  • Websocket client authentication succeeded.
  • Fetched authorized terminal hosts for websocket session.
  • Received websocket message. { ... keys: [ 'command' ] ... }
  • Parsed terminal command metadata. { targetHost: '127.0.0.1', ... }
  • Spawning PTY process for terminal session.
  • PTY process exited. { ... exitCode: 0 ... }
• bundle/logs/managed_host_vuln.log proves command execution on the managed-host peer:
  • MANAGED_HOST_PROCESS label=vuln command=" printf 'REPRO_WS_COMMAND_EXECUTED\\n'; whoami; hostname; pwd "
  • MANAGED_HOST_PROCESS_EXIT label=vuln rc=0 output='REPRO_WS_COMMAND_EXECUTED\nvscode\n...\n/tmp\n'
• bundle/logs/ws_client_vuln.log proves the WebSocket client received command output:
  • CLIENT_MSG="pty-ready"
  • CLIENT_MSG="REPRO_WS_COMMAND_EXECUTED\r\nvscode\r\n...\r\n/tmp\r\n"
  • CLIENT_MSG="pty-exited"
• bundle/logs/fixed_result.txt proves the negative control:
  • IPS_STATUS=403
  • AUTH_STATUS=403
  • Response message: Access to terminal functionality is restricted to team administrators.
• bundle/logs/ws_client_fixed.log shows the WebSocket handshake fails in the fixed path (Unexpected server response: 500) before any command reaches the managed host.
• bundle/logs/managed_host_fixed.log contains only server readiness and no MANAGED_HOST_PROCESS, confirming no command execution in the fixed negative control.

Environment details captured by the script include the vulnerable git commit (575b0766d12bad2a78febff72ab59c017772bcf7 for v4.0.0-beta.470), local PHP version, Coolify Laravel service health, terminal WebSocket readiness, and managed-host SSH readiness.

Recommendations / Next Steps

• Add can.access.terminal middleware to all terminal backend bootstrap routes, not only the visible terminal UI pages.
• Keep authorization checks server-side in the WebSocket/bootstrap flow; do not rely on frontend route visibility or UI navigation controls.
• Ensure /terminal/auth and /terminal/auth/ips enforce the same admin/owner authorization semantics as /terminal and resource terminal pages.
• Add regression tests for low-privileged team members covering:
  • POST /terminal/auth returns 403.
  • POST /terminal/auth/ips returns 403.
  • /terminal/ws fails closed and never reaches command execution when backend auth routes reject the session.
• Upgrade affected installations to 4.0.0-beta.471 or later.

Additional Notes

• Idempotency: The final reproducer was run successfully multiple times. The last two full script executions completed with exit code 0 and reproduced the vulnerable-vs-fixed behavioral difference.
• The managed host is a controlled local SSH peer, which avoids requiring privileged system SSH setup while still proving that attacker input crosses Coolify's real HTTP/WebSocket boundary and reaches the real terminal-server node-pty/OpenSSH command execution path.
• The fixed negative control uses the middleware behavior from the patch to prove the same member session is blocked with 403 before WebSocket command execution.

No distinct fixed-version bypass or materially different terminal trigger was validated for CVE-2026-34047. The original bug is that Coolify's terminal WebSocket backend trusted /terminal/auth and /terminal/auth/ips, while those bootstrap routes only checked authentication in v4.0.0-beta.470. The patch in v4.0.0-beta.471 adds can.access.terminal to both bootstrap routes. Source review found that the WebSocket command-execution sink still depends on those routes, and runtime variant testing of the ticket-suggested API-token/private-key chain did not expose private key material to a low-privileged Member on either the vulnerable or fixed target.

Fix Coverage / Assumptions

The original fix relies on this invariant: every terminal WebSocket session that can reach docker/coolify-realtime/terminal-server.js command execution must first pass the Laravel terminal authorization bootstrap endpoints.

The fix explicitly covers:

• POST /terminal/auth in routes/web.php, now protected by ->middleware('can.access.terminal').
• POST /terminal/auth/ips in routes/web.php, now protected by ->middleware('can.access.terminal').
• The authorization predicate in app/Http/Middleware/CanAccessTerminal.php, which aborts non-admin/non-owner users with 403.
• The canAccessTerminal gate in app/Providers/AuthServiceProvider.php, which returns true only for isAdmin() or isOwner().

The reviewed command sink is pty.spawn('ssh', ...) in docker/coolify-realtime/terminal-server.js. That file exposes only /terminal/ws, validates the WebSocket handshake by posting to /terminal/auth, fetches host authorization from /terminal/auth/ips, and checks isAuthorizedTargetHost() before spawning SSH. I did not find a second WebSocket path or alternate message type that starts a PTY without those bootstrap routes.

The fix does not directly change unrelated API token or private-key API authorization. That path was therefore tested as a candidate because the ticket mentioned it as part of the broader exploit chain. The test showed no private key disclosure with a Member-created read/write token.

Variant / Alternate Trigger

Tested candidate: low-privileged Member API-token/private-key path.

• Entrypoint: authenticated Member token creation semantics equivalent to the /security/api-tokens Livewire component (app/Livewire/Security/ApiTokens.php).
• API data path: /api/v1/security/keys route in routes/api.php, implemented by App\Http\Controllers\Api\SecurityController::keys().
• Sensitive-data guard: app/Http/Middleware/ApiSensitiveData.php, which grants private-key serialization only when the token can root or read:sensitive.
• Runtime result: the generated Member token had abilities ['read','write'], TOKEN_CAN_READ_SENSITIVE=false, and the serialized private-key response omitted the private_key field on both targets.

This candidate is not a bypass because it does not reach the same terminal command-execution sink and it did not disclose SSH private key material on the fixed target. It is best treated as a ruled-out adjacent chain rather than a confirmed variant.

Other paths reviewed:

• /terminal/ws WebSocket command message: still depends on /terminal/auth and /terminal/auth/ips.

• message, resize, pause, resume, ping, and checkActive WebSocket messages: do not start a new PTY without an active session or are non-command control messages.

• Global and resource terminal UI routes in routes/web.php: already use can.access.terminal.

• Latest tagged release v4.1.2: source inspection confirms /terminal/auth and /terminal/auth/ips still carry can.access.terminal.

• Package/component affected: coollabsio/coolify, terminal authorization routes in routes/web.php, terminal WebSocket backend in docker/coolify-realtime/terminal-server.js, and the adjacent API-token/private-key path reviewed for variant coverage.

• Affected versions tested: vulnerable v4.0.0-beta.470 at commit 575b0766d12bad2a78febff72ab59c017772bcf7; fixed v4.0.0-beta.471 at commit 914d7e0b50505bc1fd56c34974fca09ad354e92a.

• Latest release checked by source inspection: v4.1.2 at commit e7dff30b7c998c301fd91bd169727b90c59ec291 retains the terminal middleware on the bootstrap endpoints.

• Risk level and consequences for the parent issue: critical authenticated authorization bypass to terminal-backed command execution on managed hosts.

• Risk level for this variant stage result: no new validated risk beyond the parent issue.

Impact Parity

• Disclosed/claimed maximum impact for the parent: authenticated low-privileged Member can reach terminal WebSocket command execution on managed hosts and potentially chain API/private-key access.
• Reproduced impact from this variant run: no bypass. The Member API-token/private-key candidate was exercised on both tested versions, but private key material remained hidden and no terminal command execution path was reached through a distinct entry point.
• Parity: none for a new variant/bypass.
• Not demonstrated: a fixed-version terminal bypass, fixed-version managed-host command execution, or fixed-version SSH private-key disclosure to a Member.

Root Cause

The parent root cause is insufficient server-side authorization on the terminal bootstrap routes. In v4.0.0-beta.470, /terminal/auth and /terminal/auth/ips only require an authenticated session. The WebSocket backend trusts those endpoints and uses their output to decide whether to spawn SSH.

The fixed version adds the missing authorization middleware to those exact bootstrap routes. Because the WebSocket sink still relies on those routes and no alternate unauthenticated/Member-authorized terminal bootstrap was found, the same underlying bug could not be reached from a distinct fixed-version path.

The ticket-suggested API-token/private-key chain uses different code. Runtime testing showed the relevant sensitive-data invariant holds for the tested Member token: without read:sensitive or root, SecurityController hides private_key. Therefore this adjacent chain did not demonstrate the same root cause reaching the same impact after the terminal fix.

Known fix commit/tag tested: v4.0.0-beta.471 (914d7e0b50505bc1fd56c34974fca09ad354e92a).

Reproduction Steps

1. Run bundle/vuln_variant/reproduction_steps.sh from the bundle root, or set PRUVA_ROOT to the bundle path and run it from any directory.
2. The script creates isolated Git worktrees for v4.0.0-beta.470 and v4.0.0-beta.471, prepares a local PHP/Laravel SQLite runtime, creates an owner, a low-privileged Member, and a valid private key record, then creates a Member read/write token and exercises the private-key serialization path on both targets.
3. Expected evidence for the negative result:
   • bundle/logs/vuln_variant/vulnerable_api_token_private_key_probe.log shows ROLE=member, TOKEN_ABILITIES=["read","write"], TOKEN_CAN_READ_SENSITIVE=false, and LEAKED_PRIVATE_KEY_MARKER=false.
   • bundle/logs/vuln_variant/fixed_api_token_private_key_probe.log shows the same values on the fixed target.
   • bundle/logs/vuln_variant/reproduction_steps.log summarizes NO BYPASS.

The script exits 1 by design when no fixed-version bypass is reproduced. It completed twice without crashing.

Evidence

Primary evidence files:

• bundle/vuln_variant/reproduction_steps.sh — stage-specific runtime variant probe.
• bundle/vuln_variant/runtime_manifest.json — runtime manifest with tested target commits and proof artifact list.
• bundle/logs/vuln_variant/reproduction_steps.log — full orchestration log from the final run.
• bundle/logs/vuln_variant/vulnerable_api_token_private_key_probe.log — vulnerable-version candidate output.
• bundle/logs/vuln_variant/fixed_api_token_private_key_probe.log — fixed-version candidate output.
• bundle/logs/vuln_variant/vulnerable_version.txt — tested vulnerable commit.
• bundle/logs/vuln_variant/fixed_version.txt — tested fixed commit.

Key excerpts from the final run:

[vulnerable] ROLE=member
[vulnerable] TOKEN_ABILITIES=["read","write"]
[vulnerable] TOKEN_CAN_READ_SENSITIVE=false
[vulnerable] LEAKED_PRIVATE_KEY_MARKER=false

[fixed] ROLE=member
[fixed] TOKEN_ABILITIES=["read","write"]
[fixed] TOKEN_CAN_READ_SENSITIVE=false
[fixed] LEAKED_PRIVATE_KEY_MARKER=false

Summary: vulnerable_leak=false fixed_leak=false vulnerable_sensitive=false fixed_sensitive=false
NO BYPASS: Member token path ran on both targets but did not expose private-key material on the fixed target

Source evidence:

• routes/web.php: /terminal/auth and /terminal/auth/ips gain can.access.terminal in v4.0.0-beta.471.
• app/Http/Middleware/CanAccessTerminal.php: non-admin/non-owner users are blocked.
• docker/coolify-realtime/terminal-server.js: the WebSocket terminal sink still depends on the two Laravel bootstrap endpoints.
• app/Http/Middleware/ApiSensitiveData.php: sensitive API output requires root or read:sensitive token ability.

Recommendations / Next Steps

• Keep the can.access.terminal middleware on all terminal bootstrap routes, not only visible UI routes.
• Add regression tests for Member access to both /terminal/auth and /terminal/auth/ips returning 403.
• Add an end-to-end WebSocket regression test asserting a Member session cannot reach pty.spawn('ssh', ...) after /terminal/auth or /terminal/auth/ips rejects the session.
• Add API regression tests ensuring Member-created read or read/write tokens cannot serialize private_key from /api/v1/security/keys unless a deliberately authorized read:sensitive or root ability is present and permitted by policy.
• Consider centralizing terminal authorization in a service used by both Laravel and the WebSocket backend, so future terminal bootstrap endpoints cannot omit the owner/admin gate.

Additional Notes

• Idempotency confirmation: bundle/vuln_variant/reproduction_steps.sh was executed twice successfully. Both executions completed and produced the same negative verdict pattern. The command exits 1 because no fixed-version bypass was found, which is the required script convention for a negative variant result.
• The candidate runtime probe uses Laravel bootstrap/model/controller-equivalent logic with a SQLite database rather than starting the full HTTP server. This was sufficient for the tested API-token/private-key serialization path and avoided reusing the previous stage's terminal reproducer.
• The stage did not modify the repro checkout. It used isolated Git worktrees under /tmp/coolify-vuln-variant/worktrees for version testing.