gitlabAug 12, 2026

How GitLab tracks vulnerabilities through refactors and reformatting (opens in new tab)

GitLab improved vulnerability tracking to prevent duplicate findings after harmless code changes such as added comments, blank lines, or reformatting. Its normalized Scope+Offset fingerprint ignores non-functional lines while still identifying vulnerabilities by their enclosing scope and relative location. In testing, the method eliminated duplicates in a worst-case benchmark and is now available as `scope_offset_compressed`. ## The Problem with Line-Based Tracking - Vulnerabilities can appear to be new when developers: - Add comments or blank lines - Reformat files - Move functions or other code - Duplicate findings force security teams to repeat triage and reduce confidence in scan results. - GitLab’s 2022 Scope+Offset method improved on line-based tracking by using: - The narrowest enclosing scope, such as a module, class, or function - The finding’s line offset within that scope - This reduced unnecessary re-auditing by about 30%, but comments and blank lines could still change the offset. ## Normalized Scope+Offset Fingerprinting - The improved method ignores comments and blank lines when calculating a vulnerability’s fingerprint. - Because these lines do not change program behavior, they no longer change the vulnerability’s identity. - The approach preserves the previous method’s precision and reuses the scanner’s existing parse tree, so scan times are unaffected. - It does not require changes to the security report format and works with heterogeneous SAST toolchains. ## Benchmark Results - Researchers tested 439 source files across: - C/C++, C#, Go, Java, JavaScript, Python, and Ruby - They generated 2,247 commits, each adding a comment or blank line immediately before a known vulnerability. - The original method produced 1,361 duplicate fingerprints, representing a 77% increase over baseline. - The normalized method produced zero duplicates and reduced unique fingerprints by 43%. ## GitLab Availability - The algorithm is available in GitLab as: - `scope_offset_compressed` - It supports C#, C/C++, Go, Java, JavaScript, Python, Ruby, and PHP. - The accompanying research paper, *Vulnerability Tracking using Normalized Scope+Offset*, is scheduled for presentation at the ASE 2026 Industry Showcase. For teams using GitLab security scanning, `scope_offset_compressed` provides more stable vulnerability tracking without slowing scans or changing existing report integrations.

gitlabdevsecopssaststatic-analysis+3

gitlabAug 12, 2026

GitLab Patch Release: 19.2.2, 19.1.4, 19.0.6 | GitLab Docs (opens in new tab)

GitLab released patch versions 19.2.2, 19.1.4, and 19.0.6 on August 12, 2026, addressing multiple security and bug issues in CE and EE. The release fixes vulnerabilities involving cross-site scripting, authorization bypasses, privilege escalation, data exposure, and denial of service. Self-managed installations should upgrade immediately; GitLab.com is already patched, and GitLab Dedicated customers need no action. ## Release Scope and Upgrade Guidance - The patches apply to GitLab Community Edition and Enterprise Edition. - GitLab recommends upgrading all affected self-managed installations to the latest patch for their supported release line. - Patch releases may be scheduled or issued ad hoc for critical vulnerabilities. - Security issues are generally disclosed publicly 90 days after the release containing their fixes. - Unless a deployment type is explicitly excluded, omnibus, source, Helm chart, and other installation types are affected. ## Cross-Site Scripting Vulnerabilities - **CVE-2026-15217** affects Analytics Dashboards table field configuration. - Improper neutralization of user-controlled values could allow XSS in table cell content. - CVSS: **8.7**. - **CVE-2026-15216** affects Analytics Dashboards pagination controls. - User-controlled data could be rendered unsafely and enable XSS. - CVSS: **8.7**. - **CVE-2026-16627** affects the CI manual job confirmation modal. - Authenticated developers could potentially escalate privileges through unsanitized HTML. - CVSS: **7.7**. ## Authorization and Privilege Issues - **CVE-2026-15423** affects the CI/CD pipeline API. - Developer-role users could run pipelines on protected branches without the required push permissions. - CVSS: **8.5**. - **CVE-2026-19228** affects the Duo Workflow Service in GitLab EE. - An authenticated user could attribute AI usage to another namespace. - CVSS: **8.5**. - **CVE-2026-16494** affects the EE ProjectsController. - Missing checks could let authenticated users modify project settings reserved for higher-privileged roles. - CVSS: **7.1**. - **CVE-2026-8667** affects the npm distribution-tags endpoint. - Developers could modify certain package registry metadata without maintainer permissions. - CVSS: **4.3**. ## Information Disclosure and API Access - **CVE-2026-6821** affects the EE merge requests API. - Authenticated users could bypass IP-based restrictions and read limited merge request information from private projects. - CVSS: **4.3**. - **CVE-2026-4879** affects the external status check API. - Developers could view status check configuration restricted to higher-privileged roles. - CVSS: **4.3**. ## Denial of Service - **CVE-2026-7427** affects the GraphQL API JSON parser. - Improper input validation could allow unauthenticated attackers to cause a denial of service. - CVSS: **5.3**. Self-managed GitLab administrators should apply 19.2.2, 19.1.4, or 19.0.6 immediately, depending on their release branch, to receive these security fixes.

gitlabci-cdgraphqlnpm+3

cloudflareAug 5, 2026

WriteGuard: Fine-grained controls for MCP Servers (opens in new tab)

Cloudflare built WriteGuard to safely expand AI agents’ write access to internal MCP servers. The system centralizes authorization, risk classification, agent attribution, and auditing, addressing failures that client-side prompts or individual user vigilance cannot reliably prevent. It preserves the human user’s permissions while making each agent session identifiable and its actions queryable. ## The Risk of Uncontrolled Agent Actions - A broadly instructed cleanup agent accidentally closed thousands of tickets. - Human and agent actions were recorded under the same employee identity, making the incident difficult to investigate and repair. - Network logs could not distinguish between multiple agent sessions. - More serious failures could involve: - Amending contracts - Sending mass customer replies - Deleting database tables - Triggering destructive production actions ## MCP Fundamentals - The Model Context Protocol connects AI applications to external tools and data. - An MCP server exposes tools with: - A name - A description - An input schema - A handler that performs the operation - When an agent selects a tool, the MCP client sends the call to the server, which interacts with the downstream application. ## Cloudflare’s MCP Expansion - Cloudflare uses MCP with local clients such as OpenCode and Cloudflare OS, as well as long-running agent services. - Its internal MCP portal grew from 13 servers to 27. - Servers initially provided read-only access to systems such as Jira, GitLab, internal documentation, and operational tools. - As agents became more capable, teams requested write actions across engineering, product, design, sales, and customer success. - Cloudflare decided centralized controls were necessary because client-side skills and elicitation prompts vary across agent harnesses and can be disabled. ## WriteGuard’s Policy and Attribution Layer - WriteGuard evaluates tool configuration together with request context. - It can: - Pass a call through unchanged - Add agent attribution to supported writes - Create a scrubbed audit event - Block a call before the tool handler executes - Policies are defined per tool and include: - Risk tier - Enabled or disabled status - Labeling configuration - Risk tiers include: - **Read Only:** Search issues or inspect merge requests - **Minimal Impact:** Add reactions or mark notifications read - **Contained Write:** Add comments, create merge requests, or update issue fields - **Critical:** Merge code, deploy to production, or bulk-delete records - Labeling allows agent context to be inserted into downstream applications in formats such as plain text or HTML without modifying the MCP server. ## Preserving Human Permissions While Identifying Agents - Agents operate through the employee’s Cloudflare Access and OAuth identity. - An agent cannot perform an action its user is not authorized to perform. - Cloudflare avoided standalone agent accounts because they would create additional permissions to manage and weaken accountability. - WriteGuard supplements the human identity with MCP client and session information. - Each write can therefore be tied to both the responsible person and the specific agent session. ## Centralized, Queryable Auditing - WriteGuard classifies every invocation as successful, failed, or blocked. - It asynchronously sends scrubbed events to an internal audit Worker. - Audit records include: - MCP server and tool - Risk tier - Outcome - User and client - Request duration - Secret and sensitive input values are omitted. - Asynchronous logging avoids adding latency to the agent’s response. - MCP portal logs show raw tool invocations, while WriteGuard adds semantic classifications, agent context, and backing-service outcomes. - Central auditing makes unusually fast or widespread agent activity easier to detect and investigate. ## Recommendation Organizations expanding MCP agents beyond read-only access should use centralized, server-side policy enforcement, preserve human authorization boundaries, attach per-session agent attribution, and maintain scrubbed audit logs. Relying solely on prompts, client configuration, or undifferentiated user identities makes destructive automation difficult to prevent and even harder to understand afterward.

gitlabai-agentmodel-context-protocoltypescript+4

gitlabAug 3, 2026

Secure every commit to production with Claude and GitLab (opens in new tab)

Claude’s security tools can identify and fix vulnerabilities during coding, but they do not govern everything that happens afterward. The post argues that GitLab should secure the remaining path to production through enforced scans, approval policies, data controls, lifecycle-wide coverage, and audit evidence. Together, Claude handles in-session authoring while GitLab provides organization-wide governance. ## From In-Session Findings to Enforced Controls - GitLab applies security configuration profiles across projects and pipelines, preventing teams from bypassing required scans. - Merge request approval policies enforce separation of duties, ensuring an agent or developer cannot approve and merge its own changes. - Critical vulnerabilities can block merges until a designated approver reviews them. - Vulnerability reports and security dashboards permanently track whether findings were detected, dismissed, or resolved. ## Turning Security Activity into Audit Evidence - Compliance controls require scans to run on every merge request and expose findings for human review. - Pipeline logs, approval records, and audit events provide reproducible evidence of what was scanned and who approved each change. - Compliance frameworks such as SOC 2, PCI DSS, and FedRAMP can map evidence to named requirements. - Compliance status reports show which controls have passed, failed, or remain pending, including activity involving agents. ## Controlling Sensitive Data Sent to Models - Context exclusions prevent secrets, proprietary files, and regulated data from being sent to AI models. - Self-managed GitLab environments and self-hosted models can keep code and inference within an organization’s boundary. - Teams can select approved models, restrict model access, and prevent code from being used for training. - GitLab Duo prompt guardrails detect secrets and limit the content available to prompts, reducing prompt-injection risk. ## Scanning Beyond the Coding Session - Session-based reviews cannot detect vulnerabilities introduced after code is written, such as newly disclosed dependency flaws like Log4Shell. - GitLab provides dependency, container, infrastructure-as-code, secret, and DAST scanning across the delivery lifecycle. - Security Review Flow uses reasoning to identify business-logic flaws, authorization errors, and race conditions that deterministic scanners may miss. - Advanced SAST produces reproducible, CWE-mapped results, providing more consistent evidence than potentially variable LLM-based findings. ## Consistent Coverage for Humans and Agents - Claude’s plugin primarily reviews code written and committed within its session. - Developer shell commands, including Claude’s `!` shell escape, may fall outside that review scope. - Claude Security can review broader codebases when explicitly invoked by a developer or administrator. - GitLab pipeline scans and merge request policies apply to every change, regardless of whether it was written by a human or an agent. GitLab’s policies and lifecycle-wide scanning provide the durable controls needed after an AI coding session ends. Teams can use Claude for immediate security feedback while relying on GitLab to enforce consistent review, protect sensitive data, block unsafe releases, and maintain audit-ready evidence through production.

gitlabmcpinfrastructure-as-codesast+4

gitlabJul 29, 2026

GitLab Patch Release: 19.2.1, 19.1.3, 19.0.5 | GitLab Docs (opens in new tab)

GitLab released patch versions 19.2.1, 19.1.3, and 19.0.5 on July 29, 2026, addressing important security and bug fixes in CE and EE. Self-managed installations should upgrade immediately; GitLab.com is already patched, and GitLab Dedicated customers need no action. The release fixes vulnerabilities ranging from unauthorized data access and configuration changes to denial of service and AI-related security issues. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Affected self-managed installations should upgrade to: - 19.2.1 - 19.1.3 - 19.0.5 - GitLab issues security patches through scheduled releases twice monthly or through urgent ad-hoc releases. - Vulnerability details are generally made public 90 days after the release containing the fix. ## High-Severity Access and Configuration Vulnerabilities - **CVE-2026-6267 — Workhorse information exposure (CVSS 8.5)** - An authenticated Developer could access unauthorized information because of insufficient access controls in internal request handling. - Affected CE/EE versions extend back to 10.1.0. - **CVE-2026-12436 — Pipeline Schedule API mass assignment (CVSS 8.4)** - An authenticated user could modify another user’s CI/CD configuration through improperly validated pipeline schedule attributes. - Affects versions beginning with GitLab 18.0. - **CVE-2026-13113 — Merge request approval race condition (CVSS 6.5)** - In GitLab EE, an authenticated user could merge code into a protected branch without the required approvals. - The issue resulted from a race condition in approval rule processing. - **CVE-2026-14341 — Project import authorization flaw (CVSS 4.9)** - A Maintainer could modify protected branch configuration through a projects API endpoint. - The vulnerability affected CE and EE. ## Availability, Import, and Credential Protection Fixes - **CVE-2026-15975 — Merge request discussion denial of service (CVSS 7.5)** - An unauthenticated attacker could exhaust resources and cause a denial of service. - The issue involved insufficient throttling when processing discussions. - **CVE-2026-6336 — Project import status access control (CVSS 5.3)** - An unauthorized user could view project import source information because of a missing authorization check. - **CVE-2026-16553 — Virtual Registry credential exposure (CVSS 5.4)** - Improper upstream request handling could disclose sensitive information to an unintended host. - This issue affects GitLab EE virtual registries. ## Web and AI-Assisted Feature Fixes - **CVE-2026-3093 — Cross-site scripting in paginated views (CVSS 4.7)** - A crafted URL could execute attacker-controlled JavaScript in another user’s browser. - The root cause was inadequate sanitization of user-controlled input. - **CVE-2026-15077 — Prompt injection in Duo Code Review (CVSS 4.3)** - Untrusted content processed by AI-assisted code review could allow access to information from unauthorized projects. - This affects GitLab EE versions 19.1 and 19.2 before the patched releases. - **CVE-2026-15831 — Duo Workflows token generation flaw (CVSS 4.3)** - An authenticated user could bypass administrator-configured tool governance policies through improper authorization during token generation. - The issue affects GitLab EE. ## Recommended Action Administrators should upgrade affected self-managed GitLab installations to the latest supported patch release immediately, regardless of deployment method, including Omnibus, source installations, and Helm charts. Regularly applying the newest patch release is GitLab’s recommended security practice.

gitlabci-cdapi-securityprompt-injection+3

gitlabJul 22, 2026

Modernize Java with Cursor and GitLab (opens in new tab)

The post argues that modernizing Java 8 to Java 21 should be handled as a series of small, reviewable changes rather than one large AI-generated merge request. Cursor is effective for bounded coding tasks, while GitLab provides the planning, CI/CD, security, review, and lifecycle context needed to make those changes safe. The recommended approach is to begin with a focused test fix, establish quality gates, and then modernize one application boundary at a time. ## AI-Assisted Java Modernization - Java modernization affects the build, runtime, dependencies, APIs, concurrency, tests, containers, and production behavior. - A single broad prompt can produce an oversized merge request that is difficult to validate or review. - Cursor works best when given a focused issue, such as one failing test or one bounded implementation problem. - GitLab complements Cursor with: - Durable planning through epics and issue hierarchies - GitLab MCP context inside Cursor - CI/CD and security scanning - Code Review Flow and Developer Flow - Code-owner approvals and impact analysis - Cross-service testing and review evidence ## The Java HTTP Metrics Collector - The tutorial uses Tanuki IoT Platform’s Java HTTP metrics collector. - The collector: - Checks HTTP health and maintenance endpoints - Records response status and timing metrics - Sends readings to a Rust metrics-store backend through `POST /api/metrics` - This creates a realistic boundary for modernization because both the Java client and Rust backend contract must continue working. ## Project Setup and Guardrails - Required tools include Cursor, Java 8 and Java 21, Maven, Docker, Docker Compose, and GitLab MCP. - GitLab Duo Code Review Flow, Developer Flow, and an impact-analysis flow should be enabled for the project. - The repository includes `AGENTS.md`, which provides Cursor with project structure, instructions, and Maven test commands. - The workflow begins by importing the GitLab project, cloning it, and opening it in Cursor. ## Fixing the Failing End-to-End Test - The collector allows users to configure an expected HTTP status code. - The implementation incorrectly treats every 2xx response as successful and rejects configured responses such as `503`, even when they are expected. - An existing end-to-end test exposes the mismatch, but the CI job is initially allowed to fail, turning the failure into ignored background noise. - Cursor is prompted to: - Analyze the problem first - Trace the configuration through `HttpCollector` - Fix the implementation - Run the focused tests and the full Maven test suite - Once the fix passes, Cursor creates a branch and merge request. - The formerly non-blocking end-to-end job can then become a required check once it is deterministic and green. ## Review and Merge Controls - Each merge request triggers CI/CD, tests, and security scanning. - GitLab Duo Code Review evaluates the change against Java-specific project instructions. - Concrete review findings are addressed through Developer Flow before merging. - The merge request remains the central collaboration and decision point, even when Cursor performs most of the implementation work. - Fixing the test first establishes a behavioral baseline without combining it with the Java runtime migration. ## Planning the Java 21 Migration - The Java 8-to-21 migration is treated as a larger, planned effort rather than an isolated coding task. - The modernization epic contains: - Child work items - Team discussions - Research merge requests - Pipeline history - Dependencies - Security findings - This project context gives the agent information beyond the local source code and helps define the quality gates required before changing production behavior. The practical recommendation is to use Cursor for fast, narrowly scoped implementation while relying on GitLab to provide durable planning, automated evidence, and consistent review controls. This combination allows teams to modernize incrementally without sacrificing safety or reviewability.

gitlabci-cdmodel-context-protocoljava+4

gitlabJul 16, 2026

GitLab 19.2 release notes | GitLab Docs (opens in new tab)

GitLab 19.2, released July 16, 2026, focuses heavily on AI-assisted development, workflow automation, and centralized security controls. Major additions include the generally available GitLab Duo CLI and custom flows, scheduled pipeline execution policies, and Agentic Chat integrations. Several security features remain in beta, including automated dependency remediation and vulnerability tracking on non-default branches. ## AI-Assisted Development - **GitLab Duo CLI is generally available** for Premium and Ultimate users across GitLab.com, Self-Managed, and Dedicated. - Provides interactive chat and headless CI/CD modes. - Understands GitLab projects, pipelines, and agent configurations. - Supports model selection, shared sessions, tool approvals, MCP connections, slash commands, skills, and `AGENTS.md`. - Can be installed through `glab` or as a standalone tool. - **Custom flows are generally available** across all tiers. - Define reusable, YAML-based workflows for complex multi-step tasks. - Support multi-agent orchestration and human approval checkpoints. - Trigger from mentions, assignments, pipelines, and merge request events. - Offer project or AI Catalog management, visibility controls, secure service-account execution, and YAML validation. - **Foundational flows can now start from Agentic Chat.** - Developer Flow can implement changes or open merge requests. - Code Review Flow can review merge requests. - Fix CI/CD Pipeline Flow can diagnose and repair failed pipelines. - Users approve the handoff and monitor progress in chat or under AI sessions. ## Centralized Pipeline Automation - **Scheduled pipeline execution policies are generally available for Ultimate.** - Define schedules centrally in a security policy project. - Apply them across projects without modifying each project’s `.gitlab-ci.yml`. - Run compliance scripts, security scans, and other jobs independently of commit activity. - Support daily, weekly, or monthly schedules, time zones, time windows, and branch targeting. - Each policy creates a separate pipeline. ## Dependency and Vulnerability Management - **Dependency scanning auto-remediation is in beta.** - Automatically opens merge requests for vulnerable dependency upgrades. - Defaults to patch and minor version updates. - Agentic Breaking Change Resolution can address failed pipelines caused by complex or major upgrades. - GitLab Duo analyzes errors, changelogs, and code usage, commits fixes to the same merge request, and reruns the pipeline. - The feature creates an end-to-end remediation loop, from vulnerability detection through upgrade and repair. - **Non-default branch vulnerability tracking is in beta.** - Supports long-lived branches such as `project-qa`, `project-prod`, `project-iOS`, and `project-android`. - Allows branch-specific filtering in vulnerability reports and dashboards. - Tracks all vulnerability types, including CVEs. - Preserves vulnerability metadata when branches merge into the default branch. - Allows up to twice as many tracked branches as projects in the namespace. ## Governance and Administration - **Selective GitLab Duo availability is available for GitLab Dedicated and Dedicated for Government.** - Administrators can lock selected subgroups and descendants into an “Always off” state. - Other subgroups can retain the option to enable Duo according to their permissions. - The model provides a per-subgroup allowlist rather than disabling AI for the entire instance. - Owners receive clear messaging when a parent group has disabled the features. ## Contributor Recognition - GitLab recognized **vivekshukl007** as the month’s Notable Contributor. - Their contribution added Scala language support to GitLab Orbit, improving code graph capabilities for Scala projects. GitLab 19.2 is especially valuable for teams adopting AI-driven development and centralized security automation. Organizations should evaluate Duo CLI and custom flows for productivity gains, while testing the dependency remediation and non-default branch features carefully because they remain in beta.

gitlabmodel-context-protocolvulnerability-managementyaml+4

gitlabJul 16, 2026

When a version bump breaks your build, GitLab fixes it (opens in new tab)

GitLab’s Dependency Scanning Auto-Remediation aims to reduce security backlogs by automatically upgrading vulnerable dependencies and repairing code when those upgrades break builds. Its AI agent analyzes pipeline errors, changelogs, and code usage, then commits fixes within the same merge request. All changes remain subject to existing reviews, approval gates, and audit controls. ## Why Dependency Backlogs Grow - Transitive dependencies account for a large share of vulnerabilities; one 2025 Maven study found vulnerabilities in about 63% of latest releases through transitive dependencies, compared with 31% through direct dependencies. - Dependency remediation competes with feature work, causing high-severity issues to remain unresolved beyond PCI-DSS and FedRAMP’s 30-day expectations. - Approximately one in eight dependency updates introduces a breaking change, and even “backward-compatible” updates can break builds. - AI-assisted exploit development is also speeding up vulnerability disclosure and weaponization. ## Automated Dependency Upgrades - When SBOM-based dependency scanning identifies a vulnerable package with an available fix, GitLab automatically opens a merge request. - The upgrade targets the nearest fixed version. - If no eligible fix exists, the vulnerability remains in the report until a safe upgrade becomes available. - Each merge request is attributed to a dedicated service account for traceability. - Developers can also start remediation manually for individual findings. ## AI-Powered Breaking-Change Resolution - If the dependency upgrade causes a pipeline failure, GitLab Duo Agent Platform investigates the failure. - It considers: - Pipeline error messages - The dependency’s changelog - How the project uses the dependency - The agent commits necessary application-code changes to the same merge request. - If it cannot restore a passing pipeline, it stops and documents its findings for developers. - Supported ecosystems include Bundler, Maven, Gradle, and major Python and JavaScript/TypeScript package managers; Rust and Go support is planned. ## Safeguards and Governance - Auto-remediation never merges changes automatically. - Merge requests explain the vulnerability, target version, and AI-generated code changes. - Cooldown periods prevent repeated remediation activity from overwhelming projects. - Closed merge requests are not recreated unless a newer fix is available. - Teams can select vulnerability severities and limit upgrades to patch, minor, or major versions. - Remediation runs through the organization’s existing pipelines, access controls, approval gates, and audit trails. - Configuration can be managed at the project or group level through API-based profiles during the beta. ## Availability and Pricing - Dependency Scanning Auto-Remediation is in public beta on GitLab.com, with rollout planned for Self-Managed and Dedicated installations. - Automated version bumping is included with GitLab Ultimate. - Agentic breaking-change resolution is available through a GitLab Duo Agent Platform trial or included GitLab Credits for eligible Ultimate subscribers. GitLab recommends using the feature to turn vulnerable dependencies into reviewable, pipeline-validated merge requests, reducing manual remediation effort without sacrificing developer approval or compliance oversight.

gitlabaici-cdpython+4

gitlabJul 9, 2026

Green DevOps: Why carbon measurement belongs in your CI/CD pipeline (opens in new tab)

CI/CD pipelines consume energy and generate emissions that standard pipeline metrics do not reveal. The post argues that measuring this impact is the first step toward reducing it, recommending Eco CI for job-level measurements and Carmen for infrastructure and application-level analysis. Both tools integrate with GitLab pipelines with minimal effort and can improve sustainability, performance, and cloud costs. ## Why CI/CD Carbon Measurement Matters - Modern teams run hundreds of jobs daily, including increasingly resource-intensive AI-assisted testing and automation. - Each job has an energy and carbon cost that is usually absent from pipeline logs and architecture diagrams. - Green DevOps involves measuring emissions per pipeline, service, and Kubernetes workload to guide engineering decisions. ## Measuring Emissions at Different Layers ### Pipeline-level measurement with Eco CI - Eco CI measures energy consumption and carbon emissions for individual CI/CD jobs. - It runs as lightweight Bash scripts without additional servers or databases. - Teams can identify expensive jobs, track emissions over time, and add a carbon badge to a project README. - Because it works within existing pipelines, it is a practical starting point. ### Infrastructure and application measurement with Carmen - Carmen, the Carbon Measurement Engine, uses the Green Software Foundation Impact Framework. - It measures emissions from virtual machines, Kubernetes pods, and application workloads. - Reports are provided per component in CSV format and distinguish: - Operational carbon from energy consumption - Embodied carbon from hardware manufacturing and disposal - Outputs such as `EnergykWh` and `TotalCarbonGramsCO2eq` can be imported into Grafana, FinOps dashboards, or custom tools. - Carmen helps teams compare emissions across services, such as an API gateway versus a data-processing layer. ## Adding Carbon Reports to GitLab - Both tools can be integrated through `.gitlab-ci.yml`. - A Carmen job can: - Use a Python 3.12 image - Install Node.js, npm, Git, and the Impact Framework toolchain - Clone and install the Carmen project - Run `carbon-daemon` - Store generated reports as GitLab artifacts - Carmen can run as a separate, non-blocking job, keeping carbon measurement outside the critical delivery path. ## Turning Visibility into Engineering Improvements - Eco CI may reveal that integration tests produce unusually high emissions because dependencies are reinstalled on every run. - Adding dependency caching can reduce runtime, emissions, and CI costs without architectural changes. - Carmen can expose idle infrastructure, such as deprecated services still running in a staging Kubernetes cluster. - Decommissioning unused workloads eliminates both their operational and embodied carbon costs. ## Business and Regulatory Benefits - Emissions data creates a baseline for future reporting requirements, even when a company’s absolute footprint is relatively small. - Carbon-efficient systems are often faster and cheaper because they use fewer compute resources. - Caching, right-sizing runners, and removing idle services support both sustainability and FinOps goals. - Regulations such as the EU’s CSRD, along with enterprise procurement requirements, are increasing pressure for supply-chain and cloud-emissions reporting. Teams can start with Eco CI on one GitLab pipeline, then add Carmen for infrastructure-level visibility. Measuring carbon alongside runtime and cost makes sustainability a practical part of everyday engineering rather than a separate initiative.

gitlabk8sci-cddevops+4

gitlabJul 8, 2026

GitLab Patch Release: 19.1.2, 19.0.4, 18.11.7 | GitLab Docs (opens in new tab)

GitLab released patch versions 19.1.2, 19.0.4, and 18.11.7 on July 8, 2026, addressing multiple security vulnerabilities and bugs in CE and EE. GitLab strongly recommends that all affected self-managed installations upgrade immediately; GitLab.com is already patched, while GitLab Dedicated customers need no action. The release includes fixes ranging from cross-site scripting and HTML injection to authorization and credential-access issues. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Patch releases address security vulnerabilities and important bugs. - Scheduled patch releases occur twice monthly, on the second and fourth Wednesdays. - Vulnerability details are generally made public 90 days after the fixing release. - All self-managed deployments—including Omnibus, source, and Helm installations—should upgrade to the latest supported patch version. ## High-Severity Browser Script Injection Fixes - **CVE-2026-6896 — CVSS 8.7** - Affected the vulnerability evidence table renderer in GitLab EE. - An authenticated developer could potentially execute scripts in another user’s browser through unsanitized input. - **CVE-2026-13320 — CVSS 7.3** - Affected wiki markup rendering in GitLab CE and EE. - Improper sanitization could allow an authenticated user to execute scripts in another user’s browser. ## Authorization and Information Disclosure Fixes - **CVE-2026-11827 — CVSS 4.9** - Affected repository mirroring in GitLab EE. - Maintainers could potentially access credentials stored for another user because of inadequate authorization checks. - **CVE-2026-8472 — CVSS 4.3** - Affected work items in GitLab EE. - Users with minimal access could read metadata from work items in private projects. - **CVE-2026-7492 — CVSS 4.3** - Affected commit discussion display in GitLab CE and EE. - Unauthenticated users could determine whether a private project existed through cross-project references. ## Repository and Configuration Security Fixes - **CVE-2025-12506 — CVSS 3.5** - Addressed ambiguous Git tag or branch references. - A repository could display content in the web interface that differed from the content available for download. - **CVE-2026-13151 — CVSS 2.7** - Fixed incorrect authorization in GitLab EE group-level settings. - Some authenticated users could modify settings beyond their intended permissions. - **CVE-2026-6352 — CVSS 2.7** - Fixed authorization flaws in compliance violation management. - Auditor-level users could modify compliance records through certain GraphQL operations. ## Bug Fixes in GitLab 19.1.2 - Set and backfilled `organization_id` for OAuth applications before constraint validation. - Upgraded Go to version 1.25.11. - Fixed multi-architecture tags on the legacy container registry path. - Improved external agent flows by using commit author and committer identities. - Fixed ClickHouse 23.x compatibility for `ci_finished_builds`. - Added cursor pagination and checkpoint limits to Duo workflow event retrieval. - Reverted a problematic merge request and removed an obsolete active-user cron schedule. - Fixed approval-rule regressions affecting Developer-authored merge requests. - Resolved a memory leak on the commits page caused by eager description loading. - Updated the builder image revision to `5.60.1`. ## Additional Fixes in GitLab 19.0.4 - Backported the OAuth `organization_id` fixes. - Added Skopeo registry authentication through `CI_JOB_TOKEN`. - The release also contains further backported fixes, though the provided release notes are truncated before listing them. Self-managed GitLab administrators should upgrade to 19.1.2, 19.0.4, or 18.11.7 according to their supported release line, prioritizing the update because of the two high-severity script-injection vulnerabilities.

gitlabgraphqloauthcross-site-scripting+4

gitlabJul 6, 2026

Keep your GitLab seats in check with restricted access (opens in new tab)

GitLab’s restricted access feature helps organizations prevent unexpected seat overages by blocking new billable users once all purchased seats are occupied. Recent improvements make it work more reliably with SAML, SCIM, LDAP, OIDC, and SSO provisioning, while providing clearer warnings and audit information. The feature is forward-looking: it prevents future growth but does not automatically resolve existing overages. ## How restricted access controls seats - Available on GitLab.com and Self-Managed. - When all licensed seats are used, new billable users cannot be added. - Users who only need authentication can receive the non-billable Minimal Access role. - Existing billable members are not downgraded or removed when restricted access is enabled. - Organizations must resolve current overages by removing users or purchasing more seats. ## Identity provider integration - Users provisioned through SAML, SCIM, or LDAP are assigned Minimal Access when no paid seats are available. - Automated synchronization can continue without immediately creating billable overages. - OIDC-only users can be assigned Minimal Access at the top-level group and authenticate without consuming seats. ## Dormant user reactivation - GitLab can deactivate inactive users to free seats. - Previously, SSO or OIDC sign-ins could silently reactivate dormant users as billable members. - With restricted access enabled and no seats available, reactivated users enter a pending approval state. - Their existing group and project memberships are preserved until an administrator approves them. ## Improved operational visibility - Configuration warnings now appear for LDAP, SAML group links, and SCIM. - GitLab distinguishes between approaching and reaching the seat limit. - Group owners and instance administrators can receive email notifications when users fall back to Minimal Access. - Audit logs show Minimal Access fallback events. ## Self-Managed settings cache Self-Managed installations cache application settings for 60 seconds by default. Changes between restricted access and user cap may therefore take up to a minute to appear consistently. Administrators can adjust the cache interval if necessary. ## Restricted access versus user cap - **Restricted access:** Controls additions based on available licensed seats. - **User cap:** Sends new users into an administrator approval workflow regardless of seat availability. - The two features cannot be enabled simultaneously; enabling restricted access automatically disables user cap. ## Enabling the feature - **GitLab.com:** Settings > General > Permissions and group features > Seat control > Restricted access. - **Self-Managed:** Admin > Settings > General > New user account restrictions > Seat control > Restricted access. - GitLab.com does not support restricted access when the top-level group is shared with an external group. Restricted access is recommended for organizations seeking predictable licensing costs while retaining automated identity provisioning and controlled user reactivation.

gitlabidentity-providersamlsingle-sign-on+4

gitlabJul 1, 2026

GitLab Patch Release: 18.8.11 | GitLab Docs (opens in new tab)

GitLab 18.8.11 is an out-of-band patch release for Community and Enterprise Editions, released July 1, 2026. It fixes a regression introduced by the Rails 7.2 upgrade that could cause database connections to leak when database load balancing is enabled. The release contains no security fixes or new migrations. ## Database Connection Leak Fix - Resolves database connection leaks affecting installations that use database load balancing. - Intended to improve stability for customers upgrading to the required GitLab 18.8 stop. ## Upgrade Considerations - No new database migrations are included. - Multi-node deployments should not require downtime. - Omnibus packages normally stop GitLab, run migrations, and restart during upgrades, regardless of upgrade size. - Administrators can disable this automatic reconfiguration for upgrades by creating: ```text /etc/gitlab/skip-auto-reconfigure ``` ## Updating and Subscriptions - Administrators should follow GitLab’s update instructions to install 18.8.11. - Premium and Ultimate features require a paid subscription, while GitLab.com provides access to GitLab-hosted infrastructure. Upgrade to 18.8.11 particularly if database load balancing is enabled, as it addresses a stability-related connection leak without introducing migration or downtime requirements.

gitlabdatabase-migrationsruby-on-railsdatabase-load-balancing+2

gitlabJun 24, 2026

GitLab Patch Release: 19.1.1, 19.0.3, 18.11.6 | GitLab Docs (opens in new tab)

GitLab released patch versions **19.1.1, 19.0.3, and 18.11.6** on June 24, 2026, addressing important bugs and security vulnerabilities in CE and EE. Self-managed installations should upgrade immediately; GitLab.com is already patched, and GitLab Dedicated customers need no action. The release fixes issues ranging from cross-site scripting and information disclosure to authorization bypasses and improper access controls. ## Release Guidance - The patches apply to GitLab Community Edition and Enterprise Edition. - GitLab recommends upgrading all affected self-managed installations to the latest supported patch release. - GitLab publishes scheduled patch releases twice monthly, with additional critical releases when necessary. - Vulnerability details are generally made public 30 days after the fixing release. - Unless otherwise specified, all deployment types—including Omnibus, source installations, and Helm charts—are affected. ## High-Severity Cross-Site Scripting Vulnerabilities - **CVE-2026-10086 — Analytics Dashboard** - A developer-level authenticated user could execute arbitrary client-side code in another user’s session through insufficient input sanitization. - Affects GitLab EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 8.7** - **CVE-2026-10712 — Web IDE Workbench Asset Handler** - Improper path validation could allow an unauthenticated attacker to execute JavaScript in a victim’s browser session. - Affects CE and EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 8.0** ## Information Disclosure and Authorization Issues - **CVE-2026-12053 — Duo Workflows** - Insufficient output filtering could expose sensitive information previously committed to a project. - Affects GitLab EE 19.1 versions before 19.1.1. - **CVSS: 7.7** - **CVE-2026-5309 — Virtual Registry Cleanup Policy API** - Authenticated users could read or modify another group’s cleanup policy settings. - Affects EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 5.4** - **CVE-2026-2238 — Rapid Diffs** - Unauthenticated users could view confidential issue references on public projects. - Affects CE and EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 5.3** - **CVE-2026-11379 — DAST Site Profile Management** - Developer-level users could potentially extract DAST site profile secrets due to incorrect authorization. - Affects EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 5.3** ## Additional Security Fixes - **CVE-2026-8330 — CI/CD API** - Sensitive data could be written to application logs because of insufficient filtering. - **CVSS: 4.4** - **CVE-2026-1606 — Snippets** - Authenticated users could conceal content within snippets through improper input validation. - **CVSS: 4.3** - **CVE-2026-5952 — Maven Package Registry** - Developers could bypass package protection rules and overwrite protected Maven package metadata. - **CVSS: 4.3** - **CVE-2026-5796 — Group Packages API** - Reporters could view package metadata from projects where the Package Registry was disabled. - **CVSS: 4.3** ## Recommended Action Administrators of affected self-managed GitLab instances should upgrade to **18.11.6, 19.0.3, or 19.1.1**, depending on their supported release branch, as soon as possible. Updating promptly is particularly important because several vulnerabilities permit code execution, sensitive-data exposure, or unauthorized access.

gitlabci-cdapi-securitycross-site-scripting+4

gitlabJun 18, 2026

AI Catalog updates for governance and operations (opens in new tab)

GitLab 19.1 expands the AI Catalog from a manually triggered tool into a governed automation platform. New event-driven Duo Flow triggers, configuration validation, agent restrictions, and model allowlists help enterprises run AI workflows continuously while maintaining security and operational control. The release is designed to make agentic automation safer and more reliable at production scale. ## Event-Driven Duo Flow Automation - Four new triggers let flows respond automatically to GitLab events: - Merge request code conflicts - Draft merge requests becoming ready for review - Merge request approvals - New work item creation - These triggers enable automated conflict summaries, compliance checks, deployment readiness checks, notifications, triage, labeling, and routing. - Pipeline triggers can now filter for specific states: failure, success, or cancellation. - Conflict-detected and draft-to-ready triggers are enabled by default. - A beta pattern-based approval tier lets developers approve repeated tool uses for an entire session instead of approving each invocation individually. ## Governance for Agents and Flows - Instance administrators and top-level group owners gain controls over which AI content users can run. - **Disable custom agents and flows** prevents users from creating or enabling custom-built content. - **Restrict the AI Catalog to your group hierarchy** blocks AI Catalog items from outside the organization’s namespace, including community and third-party contributions. - These controls help prevent unapproved agents and workflows from entering regulated or production environments. ## Pre-Save Flow Configuration Validation - GitLab now validates AI Catalog flow configurations against the Duo Workflow Service before saving them. - Errors such as missing inputs or invalid tool parameters appear directly in the UI. - This moves troubleshooting to configuration time, reducing the risk of broken or overly active flows running in production. ## Approved AI Model Controls - A public beta lets administrators define an allowlist of approved AI models. - Organizations can also set an organization-wide default model. - Teams retain flexibility within approved boundaries while meeting provider, compliance, or data-residency requirements. - The first version applies to GitLab Duo Agentic Chat, with broader coverage planned. Overall, GitLab 19.1 recommends treating AI workflows like production automation: trigger them from real events, validate them before deployment, and govern both the agents and models they use. Enterprises adopting the AI Catalog should configure the new restrictions and model policies before enabling widespread automated flows.

gitlabai-agentci-cddevsecops+3

gitlabJun 18, 2026

One vulnerability view: From scanner coverage to AI governance (opens in new tab)

GitLab 19.1 presents a unified approach to application security and AI governance. It lets organizations enforce third-party SARIF-compatible scanners across every project, centralize findings, and automate remediation. At the same time, new AI governance features record agent activity and require approval for sensitive actions, enabling faster development without sacrificing accountability. ## Enforcing Complete Scanner Coverage - Security scanners are often configured separately for each project, creating coverage gaps and policy drift. - GitLab 19.1 allows administrators to enforce third-party scanners across all projects. - SARIF-compatible scanner results flow into GitLab’s unified vulnerability view. - Findings use the same governance and remediation workflows as GitLab-native results. - GitLab Duo Agent Platform can: - Triage findings with SAST False Positive Detection. - Generate merge requests through Agentic SAST Vulnerability Resolution. - Automatically remediate third-party scanner findings before production. ## Improving Secret Detection - Secret detection now scans every commit on a newly created branch, rather than only the latest commit. - This helps identify credentials introduced in earlier commits. - Secret False Positive Detection, now generally available, provides: - A confidence score for each finding. - An explanation displayed in the vulnerability report. - Developers can focus on genuine exposures instead of test credentials, placeholders, and example tokens. ## Governing AI Agent Actions - AI coding agents can create merge requests, invoke tools, commit code, and modify projects. - GitLab’s AI audit event streaming beta records every agent action and sends it to existing audit log destinations. - Agent tool approval guardrails let administrators configure each tool to: - Run automatically. - Require human approval. - Remain blocked. - Sensitive operations, such as writing files or deleting resources, can therefore require explicit review. - Approval decisions are also recorded, creating an auditable history for incident response and compliance. ## Governed Autonomy GitLab’s overall goal is to combine autonomous development with enforceable controls. Organizations can prove scanner coverage, automate vulnerability remediation, restrict risky agent behavior, and review a complete audit trail of what agents did. The practical recommendation is to centralize scanner governance and configure approval requirements for high-impact AI actions, allowing agents to work quickly while keeping security and accountability under human control.

gitlabdevsecopsvulnerability-managementsast+4