Command Injection in Feathersjs with Jwt Tokens

Command Injection in a FeathersJS application using JWT tokens occurs when untrusted input is passed to a system shell or to a function that executes commands, and that path is not properly validated. Even when endpoints are protected by JWT-based authentication and authorization, server-side code that builds shell commands from user-controlled data can be exploited. Attackers who obtain a valid JWT (through theft, weak token handling, or an overly permissive scope) can leverage it to trigger command execution if the API accepts parameters such as filenames, paths, hostnames, or identifiers that flow into functions like exec, execFile, or child processes.

FeathersJS does not inherently introduce command injection, but integrations that rely on hooks or services to run shell utilities can become vulnerable. For example, a hook might use a user-supplied host or filename to run diagnostics or generate reports via a system command. If JWT tokens are used for access control, developers might assume that a verified token guarantees safe input, but authorization and input validation are separate concerns. A valid token does not sanitize data; if the service layer concatenates strings to form a shell command, an attacker can supply payloads such as ; id or | cat /etc/passwd depending on OS, leading to unauthorized command execution under the context of the running process.

Consider a scenario where a FeathersJS service accepts hostname from the request and uses it in a script triggered by a JWT-authenticated user. If the input is not strictly validated and is interpolated into a shell command, the JWT provides access but the command injection stems from unsafe handling of the parameter. Attack patterns include OS command injection via crafted headers, query parameters, or body fields that reach the hook or service. The presence of JWT tokens influences the attack surface by determining which identities can reach the vulnerable code path, but the root cause remains improper input handling around command construction.

Real-world examples align with common weaknesses such as CWE-78 (OS Command Injection). An attacker who manages to steal or forge a JWT with sufficient scope could exploit a vulnerable endpoint to run arbitrary commands, potentially leading to data exposure, lateral movement, or server compromise. This is especially risky when the FeathersJS app runs with elevated privileges or interacts with sensitive system utilities. Therefore, even with JWT-based security, developers must treat all external inputs as untrusted and apply strict allowlists, avoid shell interpolation, and use safer APIs that do not involve shell processing.

To identify such issues, scanning tools examine the unauthenticated attack surface as well as authenticated flows, looking for places where user data reaches command execution routines. In the context of JWT usage, they check whether token validation is correctly implemented and whether authorization logic is complemented by rigorous input validation. The combination of a valid token and a command injection flaw can be particularly dangerous because it may allow an authenticated attacker to execute system-level commands, bypassing intended access restrictions.

Remediation focuses on ensuring that JWT tokens are used for proper authentication and authorization while inputs are strictly validated and commands are constructed safely. Do not rely on tokens alone to prevent injection; treat all user-controlled data as untrusted regardless of authentication state.

• Use parameterized commands or safe APIs: prefer child_process.execFile with an array of arguments instead of string-based exec, and avoid shell features like metacharacters.
• Validate and sanitize inputs rigorously: enforce strict allowlists for values such as hostnames, filenames, and identifiers. Reject or escape any characters that are not expected.
• Leverage FeathersJS hooks to centralize validation: perform checks in hooks so that services receive only clean data, reducing the risk of injection across multiple services.

Example of an unsafe pattern to avoid:

const { exec } = require('child_process');
app.service('reports').hooks({
  before: {
    create: [context => {
      const hostname = context.data.hostname; // user-controlled
      exec(`ping -c 1 ${hostname}`, (err, stdout) => {
        if (err) throw err;
        context.result = stdout;
      });
      return context;
    }]
  }
});

The above example is vulnerable because hostname is directly interpolated into a shell command. An attacker who presents a valid JWT and sends hostname as example.com; cat /etc/passwd can execute arbitrary commands.

Secure implementation using execFile and input validation:

const { execFile } = require('child_process');
const allowedHosts = new Set(['host1.example.com', 'host2.example.com', 'localhost']);
app.service('reports').hooks({
  before: {
    create: [context => {
      const hostname = context.data.hostname;
      if (!allowedHosts.has(hostname)) {
        throw new Error('Invalid hostname');
      }
      return context;
    }],
    after: [context => {
      const hostname = context.result.hostname;
      return new Promise((resolve, reject) => {
        execFile('ping', ['-c', '1', hostname], (err, stdout) => {
          if (err) return reject(err);
          context.result = { output: stdout };
          resolve(context);
        });
      });
    }]
  }
});

In this secure version, the hook validates the hostname against an allowlist before using execFile with separate arguments, eliminating shell interpretation. JWT tokens still manage who can invoke the endpoint, but the command construction is safe.

Additionally, ensure JWT verification is correctly implemented in FeathersJS using authentication hooks and that tokens are not accepted for endpoints that trigger command-like operations without proper authorization scopes. Combine this with output scanning to ensure no sensitive data or code is returned in responses, and apply consistent input validation across all services.