🛡️ Sentinel: [CRITICAL] Fix command injection in docker logs API

[bobdivx]

🚨 Severity: CRITICAL
💡 Vulnerability: Command injection and Denial-of-Service via execSync execution with unvalidated user inputs (id, tail).
🎯 Impact: Attackers could execute arbitrary shell commands on the host system or block the Node.js event loop by supplying malicious URL parameters to the docker-logs API endpoint.
🔧 Fix: Refactored docker-logs.ts to use asynchronous execFile with explicit argument arrays, bypassing the shell. Additionally, sanitized user inputs by ensuring the container ID does not start with a hyphen and parsing the tail parameter as an integer. Sanitized error messages prevent sensitive system information leakage.
✅ Verification: Ran pnpm check and pnpm test. Code reviewed and memory recorded.

Added .jules/sentinel.md journal entry detailing learnings on the risks of execSync.

---

PR created automatically by Jules for task 14088851990673779717 started by @bobdivx

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
forge	Ready	Preview, Comment	May 15, 2026 5:40pm

[gemini-code-assist]

Code Review

This pull request fixes a command injection vulnerability in the Docker logs API by migrating from execSync to execFile and adding validation for the containerId and tail parameters. Reviewers identified opportunities to further improve security and reliability by capping the tail value to prevent memory exhaustion, merging stdout and stderr to preserve all log entries, and ensuring that execution errors are not misrepresented as successful log output.

[gemini-code-assist]

While the tail parameter is now parsed as an integer, it lacks an upper bound. A malicious user could provide an extremely large value, which could lead to excessive memory consumption or cause the execFile process to fail due to the default maxBuffer limit (1MB). Enforcing a reasonable maximum limit (e.g., 5000 lines) is recommended to prevent potential Denial-of-Service vectors.

Suggested change

	const tail = parseInt(tailStr, 10);
	if (isNaN(tail) || tail < 0) {
	return new Response(JSON.stringify({ error: "Paramètre tail invalide" }), {
	status: 400,
	headers: { 'Content-Type': 'application/json' }
	});
	}
	const tail = parseInt(tailStr, 10);
	if (isNaN(tail) || tail < 0 || tail > 5000) {
	return new Response(JSON.stringify({ error: "Paramètre tail invalide (max 5000)" }), {
	status: 400,
	headers: { 'Content-Type': 'application/json' }
	});
	}

[gemini-code-assist]

The use of the logical OR operator (||) here means that if stdout contains any data, the content of stderr is completely ignored. Docker containers often output log entries to both streams. It is better to concatenate both outputs to ensure that no log information is lost.

Suggested change

	const output = stdout.trim() || stderr.trim();
	const output = (stdout + stderr).trim();

[gemini-code-assist]

In the catch block, err.stderr typically contains the error message from the docker command itself (e.g., "Error: No such container") rather than the container's application logs. Returning this as valid log content with a 200 OK status is misleading and could leak internal system information. Since stderr from the container is already captured in the success case (when combined with stdout), the catch block should only handle actual execution failures by throwing a sanitized error.

    } catch (err: any) {
        // Sanitize error to prevent leaking secrets/internal state
        throw new Error("Erreur lors de la récupération des logs Docker");
    }