Skip to content

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

Open
bobdivx wants to merge 1 commit into
devfrom
jules-6683742158593781981-a0c79778
Open

🛡️ Sentinel: [CRITICAL] Fix command injection in docker logs API#82
bobdivx wants to merge 1 commit into
devfrom
jules-6683742158593781981-a0c79778

Conversation

@bobdivx
Copy link
Copy Markdown
Owner

@bobdivx bobdivx commented Jun 1, 2026

🚨 Severity: CRITICAL
💡 Vulnerability: The docker-logs.ts API route constructed a shell command using raw, unsanitized user inputs (id and tail query parameters) via string interpolation and executed it using execSync. This allowed arbitrary command injection.
🎯 Impact: An attacker could inject malicious shell commands (e.g., using ; or &&) through the id or tail parameters to achieve Remote Code Execution (RCE) on the server running the API.
🔧 Fix: Refactored the endpoint to use execFileAsync with an array of arguments, bypassing the shell. Additionally, strict regex validation was added to the id and tail parameters to prevent argument/flag injection.
Verification: Run pnpm test and pnpm run check to verify the code behaves as expected.


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

Co-authored-by: bobdivx <6737167+bobdivx@users.noreply.github.com>
@vercel
Copy link
Copy Markdown

vercel Bot commented Jun 1, 2026

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

Project Deployment Actions Updated (UTC)
forge Ready Ready Preview, Comment Jun 1, 2026 5:43pm

@google-labs-jules
Copy link
Copy Markdown

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

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request addresses a command injection vulnerability in the Docker logs API endpoint by replacing shell-based execution with execFileAsync and introducing input validation. Feedback on these changes suggests relaxing the regex validation to accommodate valid Docker container names (which may include dots or leading slashes) and the 'all' option for the tail parameter. Additionally, simplifying the stdout and stderr merging logic using filter(Boolean) is recommended to improve readability and handle empty lines more cleanly.

// Commande Docker pour récupérer les logs
const command = `docker logs --tail ${tail} ${containerId}`;
// Validation stricte pour éviter l'injection de commandes/flags
if (!/^[a-zA-Z0-9_-]+$/.test(containerId) || !/^\d+$/.test(tail)) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Issue: Overly Restrictive Regex Validation

Docker container names can contain dots (.) and often start with a leading slash (/) when retrieved from the Docker API (e.g., /my-container). The current regex /^[a-zA-Z0-9_-]+$/ will reject these valid names, causing the API to return a 400 error and breaking the logs view for those containers.

Additionally, the tail parameter in Docker logs can accept "all" to retrieve all logs. Restricting it to only digits /^\d+$/ prevents this valid use case.

Recommendation

Update the regex to:

  1. Allow an optional leading slash and dots in the container ID/name.
  2. Ensure the container ID/name starts with an alphanumeric character (or a slash followed by one) to prevent flag injection (e.g., passing --help as a container ID).
  3. Allow "all" as a valid value for tail.
Suggested change
if (!/^[a-zA-Z0-9_-]+$/.test(containerId) || !/^\d+$/.test(tail)) {
if (!/^\/?[a-zA-Z0-9][a-zA-Z0-9_.-]*$/.test(containerId) || !/^(?:\d+|all)$/.test(tail)) {

Comment on lines +40 to +45
logs = stdout ? stdout.trim().split('\n') : [];
if (stderr && stderr.trim().length > 0 && logs.length === 0) {
logs = stderr.trim().split('\n');
} else if (stderr && stderr.trim().length > 0) {
logs.push(...stderr.trim().split('\n'));
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Improvement: Simplify stdout/stderr Merging

The current logic for merging stdout and stderr is verbose and can introduce empty strings into the logs array if stdout or stderr contains only whitespace.

Using filter(Boolean) simplifies the merging logic, improves readability, and ensures no empty lines are added.

        const stdoutLines = stdout ? stdout.trim().split('\n').filter(Boolean) : [];
        const stderrLines = stderr ? stderr.trim().split('\n').filter(Boolean) : [];
        logs = [...stdoutLines, ...stderrLines];

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant