The hook
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.
How it works
The issue is a source/config risk in GitHub Actions workflow files. A workflow that still references incident-associated codfish/semantic-release-action refs may execute untrusted action code if it runs, but the workflow reference alone does not prove the job ran or that any credential was exposed.
The blast radius
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.
// what fixvibe checks
What FixVibe checks
FixVibe repo scans look for high-confidence security patterns and dependency risk in source context. Reports identify the affected area and recommended fix. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Ironclad defenses
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.