Kmonte/custom launcher validator

[kmontemayor2-sc]

Scope of work done

Where is the documentation for this feature?: N/A

Did you add automated tests or write a test plan?

Updated Changelog.md? NO

Ready for code review?: NO

[semgrep-code-snapchat]

Semgrep identified an issue in your code:

GitHub Actions input ${{ inputs.username }} is directly interpolated into JavaScript code in actions/github-script, allowing command injection if an attacker provides malicious input.

More details about this

The script directly interpolates ${{ inputs.username }} into a JavaScript string using GitHub Actions' expression syntax. This creates a command injection vulnerability in the actions/github-script step.

Attack Scenario:

1. An attacker opens a pull request or triggers a workflow and provides a malicious username input containing JavaScript code, such as: test"; process.env.GITHUB_TOKEN = ""; //

2. When this workflow runs, the string interpolation happens in the YAML parsing phase before the script executes, so the malicious input is directly embedded into the JavaScript code like this:

   const username = "test"; process.env.GITHUB_TOKEN = ""; //";

3. The attacker's injected JavaScript code (process.env.GITHUB_TOKEN = "";) now executes with full access to the GitHub Actions runner environment, including all secrets available to the workflow.

4. The attacker can steal GITHUB_TOKEN, access repository secrets, modify code, or exfiltrate sensitive data that the runner has access to.

The vulnerability exists because inputs.username is user-controlled (can be set by anyone triggering the workflow) and is directly embedded into the script without sanitization or escaping.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	env:
	GITHUB_TOKEN: ${{ inputs.github-token }}
	USERNAME: ${{ inputs.username }} # Move untrusted input into the env block
	script: |
	try {
	const username = process.env.USERNAME; // Reference the username from env for safety
	const result = await github.rest.repos.checkCollaborator({
	owner: context.repo.owner,
	repo: context.repo.repo,
	username: username
	});
	if (result.status === 204) {
	console.log(`${username} is a collaborator.`);
	} else {
	throw new Error(`${username} is NOT a collaborator.`);
	}
	} catch (error) {
	if (error.status === 404) {
	throw new Error(`${username} is NOT a collaborator.`);
	} else if (error.status === 403) {
	console.log(`User is not a collaborator: ${error.message}`);
	} else {
	console.log(`Error checking collaborator status: ${error.message}`);
	}
	}

View step-by-step instructions

1. Move the untrusted input ${{ inputs.username }} from the script: section to the env: section of the step. For example, add USERNAME: ${{ inputs.username }} under env:.
2. Update the code inside the script: block to use process.env.USERNAME instead of "${{ inputs.username }}". Change the line to const username = process.env.USERNAME;.
3. Always use double quotes when referencing an environment variable in shell contexts, which is not needed in this JS context, but important if used elsewhere for safety.

This prevents any user input from being injected directly as code into the script. Using process.env.USERNAME reads the value at runtime, reducing the risk of code injection.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-script-injection.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-snapchat]

Semgrep identified an issue in your code:

The subprocess.run() call uses shell=True on user-controlled command strings, allowing shell injection attacks that could execute arbitrary commands with the process's privileges.

More details about this

The subprocess.run() call executes shell_line with shell=True, which spawns a shell process to interpret the command. This is dangerous because if resolved_command or any element in resolved_args comes from untrusted input (e.g., user-provided configuration, external data), an attacker can inject arbitrary shell commands.

For example, if an attacker controls custom_resource_config.command and sets it to id; rm -rf /, the shell will execute both id and the destructive rm -rf / command. Even though shlex.quote() escapes individual arguments, it doesn't protect against injection in the command itself—only in the args list. An attacker who controls the command field can bypass this protection entirely.

Exploit scenario:

1. Attacker provides custom_resource_config.command = "echo test; cat /etc/passwd #"
2. After joining with args, shell_line becomes something like "echo test; cat /etc/passwd #"
3. When subprocess.run() executes this with shell=True, the shell interprets the semicolon as a command separator
4. Both echo test and cat /etc/passwd execute, leaking sensitive system files
5. If the process runs with elevated privileges, the attacker can exfiltrate or modify sensitive data

The shell inherits environment variables and settings from the parent process, which further expands the attack surface. Using shell=False would treat the entire string as a single command name rather than allowing shell metacharacters to be interpreted.

To resolve this comment:

💡 Follow autofix suggestion

Suggested change

	subprocess.run(shell_line, shell=True, check=True)
	subprocess.run(shell_line, shell=False, check=True)

View step-by-step instructions

1. Replace subprocess.run(shell_line, shell=True, check=True) with an invocation that does not use shell=True.
2. Change the code to directly pass the command and arguments as a list, rather than joining into a string. Use: subprocess.run([resolved_command] + resolved_args, check=True).
3. Remove any uses of shlex.quote when building the argument list, since quoting is only necessary when passing a string to the shell.
4. Ensure that resolved_command and every item in resolved_args are unquoted strings representing the command and its arguments.

Passing the command and arguments as a list with shell=False (the default) is safer, because it avoids any interpretation by a shell, preventing command injection vulnerabilities.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by subprocess-shell-true.

_{You can view more details about this finding in the Semgrep AppSec Platform.}