[Bug] Potential command injection risk in auto_assign_reviewers GitHub Actions workflow

RT-Thread Version

master branch, commit 630f4fa7a37ca99af5952946eea327cf9f1df21c Affected file: .github/workflows/auto_assign_reviewers.yml

Hardware Type/Architectures

Not hardware-specific. This issue affects a GitHub Actions workflow in the repository, not a specific BSP, board, MCU, or CPU architecture.

Develop Toolchain

Other

Describe the bug

This is a security-sensitive GitHub Actions workflow issue. I am intentionally not including the full PoC payload in this public issue. I can provide the detailed validation case privately to the maintainers if needed.

Summary

The affected workflow appears to be:

.github/workflows/auto_assign_reviewers.yml

The workflow processes pull request changed-file metadata in a pull_request_target context. The changed file names are attacker-controlled input. The workflow then stores these file names in an intermediate mapping and later reconstructs shell data structures from that mapping using shell evaluation logic.

If pull request file names are not safely encoded before reaching shell evaluation, specially crafted file names may be interpreted as shell syntax. This can lead to command injection in the GitHub Actions workflow.

Current version checked

I checked the current master branch at:

630f4fa7a37ca99af5952946eea327cf9f1df21c

At this commit, the relevant workflow structure still appears to be present.

Security impact

If exploitable, an attacker who can open or update a pull request may be able to execute shell commands in the affected GitHub Actions workflow context.

This is security-relevant because the workflow runs under pull_request_target and has pull request write permission.

I did not attempt to read, print, exfiltrate, or use any token or secret. I also did not run a destructive test against the project infrastructure.

High-level technical indicators

The risky pattern appears to involve:

• pull_request_target workflow trigger;
• reading changed file names from pull request metadata;
• writing pull request file names into an intermediate mapping without sufficient encoding;
• reconstructing shell variables from that mapping using shell evaluation;
• running the workflow with pull-requests: write permission.

I am omitting the exact payload and reproduction filename from this public issue to avoid making the issue directly exploitable.

Suggested remediation

Possible remediation approaches:

1. Avoid using shell eval on data derived from pull request metadata.
2. Do not construct shell code from pull request file names.
3. Treat all pull request file names as untrusted input.
4. Use a safe JSON processing path, such as Python json or direct jq processing, instead of converting JSON data into shell assignments.
5. Safely encode or reject file names containing shell metacharacters before processing.
6. Reduce permissions for jobs that process untrusted pull request metadata.
7. Consider splitting the workflow into:
   • a low-privilege job that computes reviewer information;
   • a separate trusted job that performs pull request write operations only after consuming sanitized output.

Private details

I can provide maintainers with:

• exact source-to-sink explanation;
• affected workflow snippets;
• current commit evidence;
• non-destructive maintainer-side validation steps;
• full PoC details using a harmless marker only.

Please let me know the preferred way to share those details privately.

Other additional context

GitHub Actions workflow environment.

Relevant context:

• GitHub Actions
• pull_request_target event
• ubuntu-22.04 runner
• bash / jq based workflow scripts

Start by reviewing .github/workflows/auto_assign_reviewers.yml, tracing changed-file metadata from the pull_request_target event through the intermediate mapping and shell evaluation. Replace the unsafe handling with a path that does not construct shell code from filenames, then verify that untrusted pull requests cannot inject commands while required reviewer assignment behavior and permissions remain intact.