#cicdsecurity

Read Time:3 Minute, 24 Second

GitLab has released security updates for a maximum-severity vulnerability that could let a remote attacker execute code on a self-managed server without first signing in. CVE-2026-97229 carries a CVSS score of 10.0 and affects both GitLab Community Edition and Enterprise Edition, placing the issue at the top of the patch queue for organizations that run their own development infrastructure.

The company published corrected versions on October 12, 2026. GitLab.com already uses patched software, and GitLab Dedicated customers do not need to perform the upgrade themselves. The urgent action applies to self-managed instances in the affected branches.

A CI/CD expression reaches the serverThe vulnerability is an integer overflow in GitLab’s regular-expression compiler for continuous integration and delivery workflows. Regular expressions are patterns used to identify or transform text, and they are common in pipeline rules. According to the advisory, insufficient validation could allow a specially constructed expression in CI/CD configuration to trigger arbitrary code execution.

The public description says exploitation is possible under certain conditions but does not disclose a complete recipe. Even with those details withheld, the severity vector is stark: the attack is reachable over a network, has low complexity, needs neither privileges nor user interaction, and can have a high impact on confidentiality, integrity and availability.

This is not a browser-only script injection that disappears when a tab closes. The potential execution occurs on the GitLab server, where repositories, build metadata, secrets and automation converge. GitLab credited researcher joaxcar, who reported the problem through the company’s HackerOne program.

Why a GitLab takeover can spreadA compromised source-code platform offers more than access to individual repositories. Attackers may seek CI/CD variables, deploy keys, package registries, runner credentials and service tokens. If those secrets grant access to cloud accounts or production environments, a single server flaw can become the first stage of a broader software supply-chain incident.

An intruder with server-level execution could also modify code, tamper with build artifacts, interrupt pipelines or erase evidence. Even organizations that mirror repositories elsewhere would need to examine whether trusted releases or container images were produced during the period of suspected access.

Affected versions and fixed releasesGitLab identifies three affected release lines. Administrators should update according to the branch they currently operate:

GitLab 19.2 installations earlier than 19.2.8 should move to 19.2.8 or a later supported release.

GitLab 19.3 installations earlier than 19.3.4 should move to 19.3.4 or later.

GitLab 19.4 installations earlier than 19.4.2 should move to 19.4.2 or later.

Version 19.3.4 has a known issue affecting merge-request pages when the Ona integration is enabled, with a correction expected in 19.3.5. Teams using that integration should plan around the compatibility problem, but it should not become a reason to leave the critical code-execution vulnerability open.

The same security release addresses additional weaknesses, including authorization problems, cross-site scripting and an issue associated with the GitLab Duo Agent Platform. Reviewing the complete release notice is important because an upgrade can close several independent attack paths at once.

Defensive priorities after upgradingAdministrators should first inventory every internet-facing and internal self-managed instance, including forgotten test servers and disaster-recovery nodes. After upgrading, teams should review application, audit, runner and reverse-proxy logs for unusual pipeline submissions, malformed expressions, unexpected project creation, new access tokens and unexplained child processes.

Secrets stored in CI/CD variables deserve special attention if exploitation is suspected. Incident responders should determine which credentials were accessible, revoke them in the systems where they are honored and then replace them in GitLab. Merely changing the value in the project does not invalidate a token at its destination.

GitLab has not said that CVE-2026-97229 is being exploited in real-world attacks. However, the absence of confirmed exploitation is not a safe maintenance window for a network-accessible, unauthenticated CVSS 10 flaw. Fast patching, targeted log review and credential hygiene are the proportionate response.

Read Time:3 Minute, 42 Second

A fresh GhostAction supply-chain campaign compromised 346 GitHub repositories after attackers took control of two maintainer accounts and planted a fraudulent security-audit workflow. Once triggered, the GitHub Actions job stole automation secrets and searched both current files and historical commits for credentials, demonstrating how one compromised developer identity can fan out across an entire project portfolio.

Security researchers at Socket linked the October 8 activity to repositories writable by the accounts “henrywoo” and “kitao.” The affected set included the popular Pyxel project, which has more than 18,000 GitHub stars, and Uber’s AthenaDriver repository.

A security audit that quietly exports credentialsThe attackers added a file named .github/workflows/security-audit.yml, commonly using commit messages such as “Add security audit workflow” or “Update security audit workflow.” Its benign label helped the modification resemble ordinary repository maintenance. In reality, the job collected valuable data and transmitted it via an HTTP POST request to the attacker-controlled address 193.32.204[.]199.

GitHub Actions workflows frequently receive credentials so they can publish packages, access cloud services or update other repositories. GhostAction targeted secrets referenced by legitimate project jobs, including personal access tokens and credentials for PyPI and crates.io. A stolen publishing token could allow an adversary to distribute a malicious update under the identity of a trusted package.

The latest variant also searched repository content and the complete Git history. It requested a full clone with fetch-depth: 0, then looked for patterns associated with AWS access keys and session tokens, GitHub and GitLab tokens, Google and Slack credentials, SendGrid secrets and API keys for prominent AI services. Old commits matter because deleting a secret from the current branch does not remove it from previous revisions.

Automation multiplied the blast radiusSocket counted 318 affected repositories in the henrywoo namespace, including 279 forks, another 27 under kitao, and the AthenaDriver project. Commits appeared in short bursts and reached inactive repositories that had not changed for years, suggesting automated discovery and modification rather than manual selection.

The campaign follows earlier GhostAction waves. Researchers previously documented hundreds of compromised repositories and thousands of targeted secrets. The expansion into Git-history scanning shows that the operators are improving their collection methods and seeking credentials that maintainers may have forgotten.

No malicious PyPI or crates.io release tied to this latest wave had been identified when the activity was reported. That is reassuring but not proof that stolen credentials went unused. Cloud keys, repository tokens and service credentials can support quieter objectives, while package-publishing access might be held for later exploitation.

Deleting the workflow is not remediationAny repository in which the malicious workflow executed should be treated as a possible credential exposure. Maintainers need to remove the job, but they must also revoke and replace every secret it could read. GitHub sessions, personal access tokens, SSH keys, OAuth grants and package-registry credentials tied to the hijacked account deserve review.

Inspect Actions history for unexpected security-audit jobs and failed runs.

Search commits for the known workflow paths and suspicious commit messages.

Review egress logs for traffic to 193.32.204[.]199.

Scan every branch, tag and historical commit for exposed credentials.

Audit package and container releases for unauthorized versions.

Cloud providers and third-party services should be checked for activity performed with the exposed keys. Where possible, responders should determine the workflow’s exact run time and correlate it with API logs, package publication and changes to repository settings.

Protect workflow changes as production codeRepository owners can reduce this class of risk by requiring review for changes under .github/workflows, enforcing protected branches and limiting Actions permissions. Secrets should be narrowly scoped, short-lived where possible and unavailable to jobs that do not require them. GitHub secret scanning and push protection can catch some hardcoded credentials before they become permanent history.

Organizations should also review what a maintainer account can modify. Hundreds of repositories under one identity turn a single phishing or token-theft event into a scalable compromise. Hardware-backed multi-factor authentication, periodic session review and rapid offboarding are essential, but authorization still needs least privilege.

GhostAction’s lesson is that CI/CD configuration is executable infrastructure. A workflow presented as a harmless audit can obtain trusted credentials, access years of code history and open a route into downstream ecosystems. It deserves the same review discipline, ownership and monitoring as the software it builds.