It should be no surprise that running untrusted code in a GitHub Actions workflow can have unintended consequences. It’s a killer feature, to automatically run through a code test suite whenever a pull request is opened. But that pull request is run in some part of the target’s development environment, and there’s been a few clever attacks found over the years that take advantage of that. There’s now another one, what Legit Security calls Github Environment Injection, and there were some big-name organizations vulnerable to it.
The crux of the issue is the $GITHUB_ENV file, which contains environment variables to be set in the Actions environment. Individual variables get added to this file as part of the automated action, and that process needs to include some sanitization of data. Otherwise, an attacker can send an environment variable that includes a newline and completely unintended environment variable. And an unintended, arbitrary environment variable is game over for the security of the workflow. The example uses the NODE_OPTIONS variable to dump the entire environment to an accessible output. Any API keys or other secrets are revealed.
This particular attack was reported to GitHub, but there isn’t a practical way to fix it architecturally. So it’s up to individual projects to be very careful about writing untrusted data into the $GITHUB_ENV file.
Five years later, I joined a hackerspace, and eventually found out that its CCTV cameras, while being quite visually prominent, stopped functioning a long time ago. At that point, I was in a position to do something about it, and I built an entire CCTV network around a software package called 
