A moderate security vulnerability has been identified in the GitHub Actions runner that can allow environment variable and path injection in workflows that log untrusted data to STDOUT. This can result in environment variables being introduced or modified without the intention of the workflow author.
To allow us to address this issue and maintain the ability for you to dynamically set environment variables we have introduced a new set of files to manage environment and path updates in workflows.
Patching your actions and workflows
If you are using self-hosted runners make sure they are updated to version 2.273.1 or greater.
Action authors who are using the toolkit should update the @actions/core package to v1.2.6 or greater to get the updated addPath and exportVariable functions.
Action and workflow authors who are setting environment variables via STDOUT should update any usage of the set-env and add-path workflow commands to use the new environment files.
If you need to log untrusted information such as issue titles, bodies, or commit messages to STDOUT we recommend that you disable command processing prior to doing that.
Starting today runner version 2.273.5 will begin to warn you if you use the add-path or set-env commands. We are monitoring telemetry for the usage of these commands and plan to fully disable them in the future.
You can now fine-tune access to external actions. These updated settings make it easier to achieve your security and compliance goals with GitHub Actions.
You can limit external actions to just those created by GitHub, those in the Marketplace that were created by verified authors, or a combination
You can optionally list specific external actions. Wildcards, tags, and SHAs enable flexibility and specificity
Starting today you can temporarily disable a GitHub Actions workflow either in the UI or through the API. With this functionality you can stop a workflow from being triggered without having to delete the file from the repo. Later you can easily re-enable it again from the UI or through the API.
This new functionality can be useful in some situations, for example:
An error on a workflow is producing too many or wrong requests impacting external services negatively.
You want to temporarily pause a workflow that is not critical and is consuming too many minutes on your account.
You want to pause a workflow that is doing requests to a service that is down.
You are working on a fork and you don't need all the functionality of some workflows it includes (e.g. scheduled workflows).