GitLab Developer Account Leads to Full OpenStack Cloud Control via CI/CD Runner Misconfigurations
A penetration testing team from Bastion has shown how a routine developer account in GitLab can serve as the starting point for a full infrastructure compromise, ultimately granting control over an OpenStack cloud environment.
Initial Access via GitLab Account
With only a standard developer account and no VPN, domain credentials, or RDP access, the testers created a test project and added a .gitlab-ci.yml file. The pipeline was configured to run reconnaissance commands and contact an external webhook. Execution occurred on the runner PROD-K8S-RUNNER01 under the gitlab_runner user, which belonged to the docker group.
Privilege Escalation to Root
Membership in the docker group provided direct access to the Docker socket, allowing containers to be launched with host namespaces mounted. The team deployed a C2 beacon and then used it to run a container that added their SSH key to the host’s root authorized_keys file, achieving root access on the runner.
Kubernetes Access and Node Compromise
Manual inspection of the host revealed a kubeconfig file belonging to a CICD service account for the prod-cluster-k8s cluster. The account possessed permissions to read secrets, create pod exec sessions, perform port forwards, and create role bindings. These rights enabled the creation of a privileged pod that mounted the filesystem of node PROD-K8S01-MS1-MAIN-1.
Cloud Credential Extraction and Impact
Analysis of /etc/kubernetes on the node yielded an OpenStack cloud-config file. Using the extracted credentials, the testers enumerated servers, networks, users, and roles. Although the account lacked the explicit admin role, its combined permissions across nova, cinder, neutron, glance, octavia, heat, magnum, and managed Kubernetes services provided effective administrative control over the entire cloud infrastructure.
The full attack chain required no complex exploits, only common misconfigurations: running CI/CD runners with docker group membership, storing kubeconfigs on build hosts, and granting overly broad RBAC permissions to service accounts.
Related articles
Critical Fastjson Zero-Day CVE-2026-16723 Actively Exploited for Remote Code Execution on Java Servers
A critical zero-day vulnerability tracked as CVE-2026-16723 is being actively exploited in Fastjson 1.x versions ranging from 1.2.68 to 1.2.83. The flaw enables unauthenticated remote code execution on Java servers that process attacker-controlled JSON, particularly when applications run as Spring Boot executable fat JARs. Exploitation succeeds even when AutoType is disabled and does not require elevated privileges or user interaction. No official patch is available for the 1.x branch, forcing organizations to rely on SafeMode activation or migration to fastjson2. Active campaigns have primarily targeted organizations in the United States, with additional activity observed in Singapore and Canada across finance, healthcare, and retail sectors. The vulnerability stems from type resolution logic that allows attackers to bypass restrictions via resource lookups before security controls are applied.
Critical Vulnerability in JetBrains TeamCity Allows Unauthenticated Remote Code Execution
JetBrains has disclosed a critical vulnerability in its on-premises TeamCity CI/CD server that permits remote attackers to execute arbitrary operating system commands without authentication. The flaw, tracked as CVE-2026-63077, affects the agent polling protocol and can be exploited simply by accessing the TeamCity Server over HTTP or HTTPS. With a CVSSv3.1 base score of 9.8, the issue is rated Critical and could lead to data theft, configuration changes, or compromise of build artifacts and downstream pipelines. No in-the-wild exploitation had been observed at the time of disclosure. JetBrains has released fixed versions TeamCity 2026.1.3 and 2025.11.7, along with a patch plugin for all releases since 2017.1, and recommends restricting external access until updates can be applied.
Critical OS Command Injection Flaw in Arista VeloCloud Orchestrator Exploited in the Wild
Arista Networks has disclosed a critical vulnerability in the on-premises version of its VeloCloud Orchestrator product used for centralized SD-WAN management. The flaw, tracked as CVE-2026-16812, is an OS command injection issue that allows remote attackers to compromise the system without any authentication. Exploitation has already been confirmed, and the vulnerability carries the maximum CVSS base score of 10.0 in both version 4.0 and 3.1, classifying it as Critical. Successful attacks can impact the confidentiality, integrity, and availability of the orchestrator and all managed data. In addition, a compromised VeloCloud Orchestrator instance may grant attackers access to connected VeloCloud Edge devices across the network.
CISA Adds Exploited Flaws in FortiOS and VeloCloud Orchestrator to Known Exploited Vulnerabilities Catalog
The US Cybersecurity and Infrastructure Security Agency has added two actively exploited vulnerabilities to its Known Exploited Vulnerabilities catalog. CVE-2026-16812 affects the on-premises version of Arista VeloCloud Orchestrator and allows OS command injection that can lead to data leakage, tampering, and denial of service. The flaw carries a maximum CVSS v3.1 base score of 10.0 and is rated Critical. CVE-2025-68686 impacts Fortinet FortiOS and can be used to bypass specific patches and steal sensitive information when combined with another vulnerability that grants prior filesystem access. Federal agencies must remediate the VeloCloud issue by July 30 and the FortiOS issue by August 10.