Compromised codfish GitHub Action

CI/CD release workflows are high-value supply-chain targets because they often hold package-registry tokens, cloud deploy credentials, GitHub tokens, and release automation permissions. A compromised third-party Action in that path can put the build environment at risk even when the application source code is otherwise clean.

A workflow step that uses a third-party Action runs that Action's code with the secrets and permissions the job holds. Release workflows are the worst place for a compromised one, because they usually carry package-registry, cloud-deploy, and GitHub tokens. The reference in your workflow file is the thing to fix: it keeps pointing the job at the compromised code until it is removed or pinned to a reviewed commit.

If an affected workflow ran after the compromise window with release or deploy secrets available, teams should treat those job-scoped credentials as potentially exposed until the run history, logs, release artifacts, and downstream package or deploy activity are reviewed.

Remove codfish/semantic-release-action from affected workflows or replace the release path with trusted automation. Review workflow runs after the compromise window, rotate secrets exposed to any affected jobs, rebuild clean CI caches or images where needed, pin remaining third-party Actions to reviewed SHAs, and keep workflow permissions narrowly scoped.