[MINOR] Integrity check relies on checksums.txt fetched from the same remote as the binary (derived from user-controllable inputs gitea-url/repo). A malicious input could point to an attacker-controlled host serving both a forged binary and matching checksum, defeating the verification. Consider pinning allowed hosts/repos, enforcing HTTPS, and verifying signed checksums or comparing hashes against a trusted source.
[MINOR] Inputs (repo, vcs-url) are used directly in double-quoted bash strings for curl URLs. If these inputs contained command substitution syntax like (...), bash would execute it even within quotes. Although typically controlled by trusted workflow authors, consider validating inputs against an allowlist (e.g., owner/name pattern) or sanitizing to strip , backticks, and parentheses to reduce risk.
[MINOR] VCS_URL is accepted as-is without validation. As a defense-in-depth measure, validate that the URL uses HTTPS (and a sane host) to avoid accidentally sending reviewer tokens over insecure transport.
[MAJOR] In the Gitea download branch, DOWNLOAD_URL is constructed from the untrusted SERVER_URL and used with Authorization: token headers. The downloaded binary is then executed after checksum verification (which only checks integrity against the same host). An attacker-controlled gitea-url can serve a malicious binary and matching checksum, leading to RCE on the runner and token leakage.
[MAJOR] On Gitea runners, SERVER_URL is set from inputs.gitea-url with only a basic https/no-whitespace check. This allows a malicious host (e.g., https://evil.com) to be used for subsequent authenticated requests, enabling SSRF and exfiltration of reviewer-token/action-repo-token.
[MINOR] SERVER_URL validation on Gitea only checks for https and no whitespace. Strengthen validation by pinning the host to github.server_url on the runner or enforcing an allowlist/host equality check to prevent use of arbitrary external domains.
[MINOR] On the Gitea code path, curl follows redirects (-L) while sending an Authorization header to the initial host. If the server responds with a redirect to a different host (e.g., object storage/CDN), curl will forward the custom Authorization header to that new host, potentially leaking a bearer token to third parties. Consider avoiding -L when using Authorization, or handle redirects explicitly (first request without -L to obtain Location, then re-request the final URL without the Authorization header).
[MINOR] ACTION_TOKEN is written to GITHUB_ENV, making it available to all subsequent steps (including the 'Run review' step). This expands the blast radius if any later step or invoked tool is compromised. Prefer scoping the token only to the asset download step (e.g., pass via step-local env or unset it immediately after use).
[MINOR] Tokens used in HTTP headers are not sanitized for control characters. Although tokens should come from trusted secrets, adding a simple check to ensure ACTION_TOKEN contains no CR/LF or whitespace would prevent potential header injection if an unexpected token source is used.
[MINOR] On Gitea runners, inputs.gitea-url is only validated for https and lack of whitespace/newlines, but not restricted to the runner's actual server host. Since ACTION_TOKEN may be sent to SERVER_URL in Authorization headers for release downloads, a misconfigured or malicious override could exfiltrate tokens to an external host. Consider enforcing that SERVER_URL host matches the platform-provided github.server_url host (or an allowlist) and disallow arbitrary external hosts by default.
[NIT] Checksum verification uses checksums.txt fetched from the same release source as the binary, which verifies integrity but not authenticity. Consider adding signature verification (e.g., GPG) or another trust anchor to mitigate a compromised release distribution channel.
[MINOR] Sensitive value in step outputs: The composite action writes action_token to GITHUB_OUTPUT to pass between steps. While not exposed as an action output, avoid persisting secrets as outputs where possible to reduce accidental leakage via logs. Prefer environment files with masking or re-derive the token in subsequent steps.