Harden gh-annotations workflow command escaping

[Zhaowenhao23469]

Overview

gh-annotations writes GitHub Actions workflow commands directly to stdout. The current implementation already encodes raw \r and \n bytes, which prevents direct line-break command injection. However, GitHub workflow command parsing has separate escaping rules for command data and command properties.

The file= annotation property currently does not escape %, :, and , according to the workflow command property grammar. Annotation message data also does not escape % before CR/LF encoding.

Expected behavior

Values written into GitHub Actions workflow commands should follow the same split used by actions/toolkit:

• data: %, \r, \n
• properties: %, \r, \n, :, ,

Why this matters

Source paths and package metadata can be influenced by scanned repository contents. Applying the full workflow command escaping rules avoids malformed annotations and reduces the chance of command parsing confusion in GitHub Actions logs.

Proposed fix

Add dedicated helpers for workflow command data/property escaping and use them only in the gh-annotations output path:

• property escaping for file=...
• data escaping for the annotation message and rendered tables

I have a small patch prepared with regression coverage for %, ,, :, and %0A-style sequences.

[Sayan2208]

Hi, I would like to work on this issue.

I have a focused fix that applies GitHub Actions workflow command escaping separately for command data and command properties in the gh-annotations output path.

I will open a PR following the contributing guide and include regression tests for %, %0A/%0D, :, and , handling.

[G-Rath]

We appreciate the issue, but we've discussed this internally and decided this kind of issue is not a concern for the scanner as

• it really applies to anything running in GHAs that prints output based on user input
• it requires you to be scanning package manifests that are very crafted, which in most cases would likely require a more serious exploit to do maliciously
• the crafted manifest would likely be rejected by package managers as they usually error when running in CI if files are not in sync, which would alert you to the bad content
• at most this would allow you to mark command output and annotations, which are not very impactful, and the scanner will still omit a non-zero exit code to indicate vulnerabilities

We'll be updating our documentation in the coming weeks to reflect this, and potentially making changes to the already landed code to prioritize ease of maintenance.