GitLab 18.2 release notes

Administrators can now reassign contributions from placeholder users to active users without user confirmation. This feature addresses a key challenge for larger organizations where the process stalled when users did not check their emails to approve reassignments.

On GitLab instances where user impersonation is enabled, administrators can maintain data integrity while streamlining user management workflows. Users still receive notification emails after the reassignment is complete, ensuring transparency throughout the process.

Previously, administrators could reassign contributions and memberships from placeholder users to active users only.

On GitLab Self-Managed, administrators can now also reassign contributions and memberships from placeholder users to inactive users. This feature permits you to preserve the contribution history and membership information of blocked, banned, or deactivated users on your GitLab instance.

Administrators must first enable this setting and, when enabled, this setting streamlines user management by skipping user confirmation during reassignment while maintaining secure access control.

Previously, the DAST_AUTH_SUCCESS_IF_AT_URL variable required an exact URL match to verify successful authentication. This worked well for applications with static landing pages, but posed difficulties for applications where post-login URLs contain dynamic elements for each login.

Now, you can use wildcard patterns in the DAST_AUTH_SUCCESS_IF_AT_URL variable to match dynamic URL patterns. This enhancement provides the flexibility needed to verify authentication success even when the exact URL changes between sessions.

Dynamic Analysis now supports time-based one-time password (TOTP) multi-factor authentication.

You can run DAST scans on projects with TOTP MFA enabled to ensure comprehensive security testing. This enhancement delivers more accurate scan results by testing applications in configurations that mirror production environments where MFA is deployed.

Previously, there was no way to temporarily deactivate streaming to an audit streaming destination. You might want to do this for a number of reasons, including to troubleshoot stream connectivity or to make changes to configuration without deleting the configuration and starting again.

With GitLab 18.2, we’ve added the ability to toggle an audit stream as active or inactive. When the audit stream is inactive, audit events are no longer streamed to the chosen destination. When reactivated, audit events are again streamed to the chosen destination.

Previously, certain audit streaming destinations did not have all of the available filtering capability.

We now support filter functionality for all destinations via the UI, including the ability to filter:

• By audit event type.
• By groups or projects.

This change also means that audit event destinations such as AWS and GCP can now filter through audit events.

You now have full control over which metadata appears when you view your list of work items, making it easier to focus on the information that matters most to you.

Previously, all metadata fields were always visible, which could make scanning through work items overwhelming. Now you can customize your view by turning on or off specific fields like assignees, labels, dates, and milestones.

You can now choose how epics open from the list page with a new toggle that switches between drawer view and full-page navigation.

Use the drawer to quickly review epic details while maintaining context of your epic list, or open the full page when you need more screen space for detailed editing and comprehensive navigation.

You can now assign milestones directly to epics, creating a natural planning cascade from strategic initiatives down to execution. This enhancement helps you align longer-term planning cadences, like quarterly planning or SAFe program increments, with epics. At the same time, you can keep iterations focused on development sprints.

With this clear hierarchy in place, you can reduce administrative overhead and gain better visibility into how your strategic initiatives progress against organizational timeframes.

This release introduces enhanced sorting and pagination for GLQL views, making it easier to work with large datasets.

You can now sort by key fields including due dates, health status, and popularity to quickly find the most relevant items. The new “Load more” pagination system provides better control over data loading, replacing overwhelming full-page results with manageable chunks that load on demand.

These improvements help teams efficiently navigate complex project data and focus on what matters most at any given moment.

You can now reference issues, epics, and work items using a unified [work_item:123] syntax in GitLab Flavored Markdown. This new syntax works alongside existing reference formats like #123 for issues and &123 for epics, and supports cross-project references with [work_item:namespace/project/123].

The plain text editor also includes a new preference to maintain cursor indentation when you press Enter, making it easier to write structured content like nested lists and code blocks.

Users can now filter data in the vulnerability report to include only reachable vulnerabilities. Reachable vulnerabilities represent vulnerabilities that are both:

• On the Common Vulnerabilities and Exposures (CVE) list.
• Part of a library that is explicitly imported.

You can now use the GraphQL API to determine the pipeline when the vulnerability was introduced and when it was last detected. The Vulnerability GraphQL API now includes:

• initialDetectedPipeline: Use to retrieve additional commit information about when the vulnerability was introduced, such as the author’s user name.
• latestDetectedPipeline: Use to retrieve additional commit information about when the vulnerability was removed, such as the commit SHA.

Previously, teams using GitFlow often faced approval deadlocks when merging release/* branches to main, as most contributors had already participated in release development and then couldn’t serve as approvers.

Branch pattern exceptions in merge request approval policies solve this by automatically bypassing approval requirements for specific source-target branch combinations. Configure strict approvals for feature-to-main merges while allowing streamlined release-to-main workflows.

Key capabilities:

• Pattern-based configuration: Define source branch patterns like release/* or hotfix/* that bypass approval requirements
• Seamless integration: Branch exceptions integrate directly into existing merge request approval policies and are configurable through the UI or policy.yml file.

This eliminates the need for complex workarounds while preserving the security benefits of merge request approval policies for standard development workflows.

Previously, it was difficult to determine whether a dependency was a direct dependency, or a transient dependency imported by a descendant of the dependency.

You can now determine whether a library is primarily or transitively imported using the new dependency paths feature. You can find dependency paths on the project and group dependency list as well as in the vulnerability details. This capability allows developers to determine the most efficient path to a fix depending on how the library is imported.

AppSec teams need comprehensive visibility into their organization’s security posture across all assets. Previously, GitLab’s security workflows focused primarily on project-level scanner configuration and project-level vulnerabilities, making it difficult to understand coverage gaps and make efficient, risk-based prioritization decisions.

Security Inventory provides a centralized view of the security posture across your GitLab instance, enabling AppSec teams to:

• Get complete visibility into security coverage across projects and groups
• Identify assets that lack security scanning or have configuration gaps
• Make informed, risk-based decisions about where to focus security efforts
• Track security posture improvements over time

This feature helps bridge the gap between individual project security and organization-wide security strategy, giving you the asset inventory foundation needed for effective security program management.

The custom admin role brings granular permissions to the Admin Area for GitLab Self-Managed and GitLab Dedicated instances. Instead of granting full access, administrators can now create specialized roles that access only the specific functions needed by users. This feature helps organizations implement the principle of least privilege for administrative functions, reduce security risks from overprivileged access, and improve operational efficiency.

We’re actively seeking community feedback on this feature. If you have questions, want to share your implementation experience, or would like to engage directly with our team about potential improvements, please visit our feedback issue.

We’re also releasing GitLab Runner 18.2 today! GitLab Runner is the highly-scalable build agent that runs your CI/CD jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

Bug Fixes:

• Runners fail in FIPS mode after you upgrade to GitLab Runner 18.1.0
• Unable to start job pods with FF_USE_DUMB_INIT_WITH_KUBERNETES_EXECUTOR
• The ubi-fips image is not the default helper image flavor for GitLab Runner FIPS
• Runners remain offline for an extended period after you disable GitLab maintenance mode

The list of all changes is in the GitLab Runner CHANGELOG.