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
WordPress Patches Race Condition in Core Update Process Enabling Unauthenticated Remote Code Execution
WordPress addressed a critical race condition vulnerability in its core update mechanism on October 28, 2026, that could allow remote code execution without authentication. The flaw affects the automatic update process used by the majority of installations, exposing a temporary installer during file extraction to a predictable folder. Wordfence recorded 60,471 exploitation attempts within the first 24 hours after disclosure. The issue was discovered by researcher Umut Bayram and fixed across multiple branches including version 7.1.4, which bundles 22 security patches. Mitigations include immediate updates, restricting public access to the wp-content update directory, and ensuring application firewall coverage. Versions 4.6 and earlier receive no further security updates.
Google Releases November Android Security Patch Fixing 216 Vulnerabilities Including Critical Zero-Click Flaws
Google has issued its November security update for Android, addressing a total of 216 vulnerabilities with 23 classified as critical. The patch resolves multiple remote code execution flaws that require no additional privileges or user interaction, qualifying as zero-click attacks. Specific fixes include CVE-2026-58868 in the Framework component and CVE-2026-58876 along with CVE-2026-58936 in the System component, all impacting Android versions 14 through 17. Additional patches cover privilege escalation, information disclosure, and denial-of-service issues across the kernel, Bluetooth, virtualization layers, and chipsets from MediaTek and Qualcomm. No evidence of in-the-wild exploitation has been noted in the bulletin, yet the critical nature of the remote code execution bugs warrants immediate attention. Users must verify the 2026-11-05 patch level or newer in device settings, as simply running the latest Android version does not guarantee all fixes are installed. Some updates arrive via Google Play system updates while others depend on device manufacturers.
Backdoor with Password 123456 and Hardcoded Keys: How AI Cracked 'Encrypted' USB Drives
An AI agent rapidly discovered critical cryptographic weaknesses in multiple USB encryption and copy-protection products, including hardcoded backdoor accounts and keys that bypassed user passwords entirely. In the SecZure YutianDun drive, two hidden accounts with passwords 123456 and SECZURE.COM allowed full decryption of files without the administrator password. NetacFileLock used a fixed AES-256 key embedded in the binary, ignoring the user password completely while also logging passwords in plaintext and employing ECB mode. KakaSoft USB Copy Protection relied on a modified MD5 implementation with altered shift constants and a hardcoded internal password derived from an embedded seed, enabling full Blowfish decryption without any user input. Nexcopy stored its Triple DES content key and IV in an encrypted configuration file protected only by a fixed 32-byte certificate inside the viewer application. The AI completed analyses in minutes that previously required hours of manual time-travel debugging and reverse engineering.
CVE-2026-98432: Temporary nftables Filter with Auto-Rollback for Ubuntu Servers
Administrators are deploying a temporary nftables-based mitigation for CVE-2026-98432 on Linux systems while awaiting official kernel patches. The filter drops IPv4 TCP packets with IP header length exceeding five, reducing exposure to the vulnerability. The procedure includes verifying kernel status via Canonical, preparing rollback commands, and using systemd timers to automatically remove the table after five minutes if connectivity is lost. Steps cover syntax validation with nft --check, integration with existing firewall configurations, and post-reboot verification to ensure the temporary table persists without interfering with ufw or Docker rules. Red Hat guidance on discarding packets containing IP options is referenced as a complementary measure. The process is designed for single-server testing before scaling to production fleets, with explicit instructions to avoid flush ruleset operations that could disrupt other tables.