Vulnerability details | GitLab Docs Skip to main content Go to GitLab Docs homepage What's new? What's new? Get free trial Toggle menu * Use GitLab * GitLab Duo * GitLab Orbit * Extend * Install * Administer * Subscribe * Contribute * Solutions Getting started Tutorials Manage your organization Organize work with projects Plan and track work Manage authentication and authorization Use Git Manage your code Use CI/CD to build your application Secure your application Getting started Tutorials AI Governance Application security Compliance Detect Triage Analyze Explain vulnerabilities Vulnerability details SAST false positive detection Secret false positive detection Remediate GitLab advisory database CVE ID requests Policies Security glossary Deploy and release your application Manage your infrastructure Monitor your application Analyze GitLab usage Release notes Feature support Find your GitLab version * GitLab Docs / * Use GitLab / * Secure your application / * Analyze / * Vulnerability details Help us learn about your current experience with the documentation. Take the survey . Vulnerability details * Tier : Ultimate * Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated History * Redesigned vulnerability page: * Introduced in GitLab 19.0 as a beta feature with a feature flag named vulnerability_details_enrichment . Disabled by default. * Enabled on GitLab.com, GitLab Self-Managed, and GitLab Dedicated in GitLab 19.3. * Display of malware findings: * Introduced in GitLab 19.4 as a beta feature with a feature flag named vulnerability_malware_detection . Enabled by default. The availability of the redesigned vulnerability page is controlled by a feature flag. The display of malware findings is controlled by a separate feature flag. For more information, see the history. Each vulnerability in a project has a vulnerability page. The page header shows the vulnerability title, when and in which pipeline it was detected, how many related merge requests and issues there are (if any), and the actions available to you. The right sidebar shows the vulnerability s status and severity. The rest of the vulnerability s data is grouped into the following sections: * Risk : The scores and flags that help you prioritize the vulnerability. * Remediation : The solution reported by the scanner, when one is available. * Details : The vulnerability description, the scanner that reported it, and the location in your code, container image, or dependencies. * Supplementary information : Identifiers such as CVE and CWE, links to external references, and security training. * Evidence : The request and response recorded by the scanner, for the scanners that report them. * Related MRs and Related issues : The merge requests and issues linked to the vulnerability. * Activity : A log of status changes, comments, and detection events. Each section is collapsible. To hide or show the contents of a section, in the section header, select Collapse ( ) or Expand ( ). For vulnerabilities in the Common Vulnerabilities and Exposures (CVE) catalog, the Risk section also includes: * CVSS score * EPSS score * KEV status * Reachability status (Limited availability) For further details on this additional data, see vulnerability risk assessment data . For vulnerabilities identified as malware, the CVSS, EPSS, and KEV scores are not shown, and the Remediation section is hidden. GitLab cannot recommend a remediation for malware the way it can for a CVE. The affected versions of the package are malicious rather than vulnerable, so no fixed version exists. Malware findings are based on GitLab malware advisories . If the scanner determined the vulnerability to be a false positive, an alert is shown above the Risk section. If GitLab Duo identified the vulnerability as a possible false positive, the Risk section shows a False positive confidence score instead. For more information, see false positive detection . For vulnerabilities detected by SAST, GitLab Duo can automatically analyze them and generate a merge request with context-aware code fixes. For more information, see Agentic SAST vulnerability resolution . Secret false positive detection * Tier : Ultimate * Add-on : GitLab Duo Core, Pro, or Enterprise * Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated * Status : Beta History * Introduced in epic 17885 in GitLab 18.10 as a beta feature with a feature flag named duo_secret_detection_false_positive . Enabled on GitLab.com, GitLab Self-Managed, and GitLab Dedicated . GitLab Duo automatically analyzes secret detection findings to identify potential false positives. Dismissing false positives reduces noise in your vulnerability report by flagging findings that are likely not actual security risks. For each analyzed vulnerability, GitLab Duo provides the following information: * A confidence score indicating the likelihood that the assessment is correct. * An explanation of why the finding might or might not be correct. * Visual indicators that a vulnerability has been identified as a potential false positive in the vulnerability report. For more information, see secret false positive detection . Vulnerability Resolution * Tier : Ultimate * Add-on : GitLab Duo Enterprise, GitLab Duo with Amazon Q * Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated Model information * Default LLM * LLM for Amazon Q: Amazon Q Developer * Available on GitLab Duo with self-hosted models History * Introduced in GitLab 16.7 as an experiment on GitLab.com. * Changed to beta in GitLab 17.3. * Changed to require GitLab Duo add-on in GitLab 17.6 and later. Use GitLab Duo Vulnerability resolution to automatically create a merge request that resolves the vulnerability. By default, it is powered by the Anthropic claude-3.5-sonnet model. GitLab cannot guarantee that the large language model produces correct results. You should always review the proposed change before merging it. When reviewing, check that: * Your application s existing functionality is preserved. * The vulnerability is resolved in accordance with your organization s standards. Watch an overview Prerequisites: * You must have the GitLab Ultimate subscription tier and GitLab Duo Enterprise. * You must be a member of the project. * The vulnerability must be a SAST finding from a supported analyzer: * Any GitLab-supported analyzer . * A properly integrated third-party SAST scanner that reports the vulnerability location and a CWE Identifier for each vulnerability. * The vulnerability must be of a supported type . Learn more about how to enable all GitLab Duo features . To resolve the vulnerability: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Secure > Vulnerability report . * Optional. To remove the default filters, select Clear ( ). * Above the list of vulnerabilities, select the filter bar. * In the dropdown list that appears, select Activity , then select Vulnerability Resolution available in the GitLab Duo (AI) category. * Select outside the filter field. The vulnerability severity totals and list of matching vulnerabilities are updated. * Select the SAST vulnerability you want resolved. * A blue icon is shown next to vulnerabilities that support Vulnerability Resolution. * In the upper-right corner, select Resolve with AI . If that button is not shown, select AI actions , then select Resolve with AI . If this project is a public project, be aware that creating an MR will publicly expose the vulnerability and offered resolution. To create the MR privately, create a private fork , and repeat this process. * Add an additional commit to the MR. This forces a new pipeline to run. * After the pipeline is complete, on the pipeline security tab , confirm that the vulnerability no longer appears. * On the vulnerability report, manually update the vulnerability . A merge request containing the AI remediation suggestions is opened. Review the suggested changes, then process the merge request according to your standard workflow. Provide feedback on this feature in issue 476553 . Supported vulnerabilities for Vulnerability Resolution To ensure that suggested resolutions are high-quality, Vulnerability Resolution is available for a specific set of vulnerabilities. The system decides whether to offer Vulnerability Resolution based on the vulnerability s Common Weakness Enumeration (CWE) identifier. The current set of vulnerabilities are selected based on testing by automated systems and security experts. GitLab is actively working to expand coverage to more types of vulnerabilities. View the complete list of supported CWEs for Vulnerability Resolution * CWE-23: Relative Path Traversal * CWE-73: External Control of File Name or Path * CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') * CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) * CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') * CWE-116: Improper Encoding or Escaping of Output * CWE-118: Incorrect Access of Indexable Resource ('Range Error') * CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer * CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') * CWE-126: Buffer Over-read * CWE-190: Integer Overflow or Wraparound * CWE-200: Exposure of Sensitive Information to an Unauthorized Actor * CWE-208: Observable Timing Discrepancy * CWE-209: Generation of Error Message Containing Sensitive Information * CWE-272: Least Privilege Violation * CWE-287: Improper Authentication * CWE-295: Improper Certificate Validation * CWE-297: Improper Validation of Certificate with Host Mismatch * CWE-305: Authentication Bypass by Primary Weakness * CWE-310: Cryptographic Issues * CWE-311: Missing Encryption of Sensitive Data * CWE-323: Reusing a Nonce, Key Pair in Encryption * CWE-327: Use of a Broken or Risky Cryptographic Algorithm * CWE-328: Use of Weak Hash * CWE-330: Use of Insufficiently Random Values * CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) * CWE-345: Insufficient Verification of Data Authenticity * CWE-346: Origin Validation Error * CWE-352: Cross-Site Request Forgery * CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') * CWE-369: Divide By Zero * CWE-377: Insecure Temporary File * CWE-378: Creation of Temporary File With Insecure Permissions * CWE-400: Uncontrolled Resource Consumption * CWE-489: Active Debug Code * CWE-521: Weak Password Requirements * CWE-539: Use of Persistent Cookies Containing Sensitive Information * CWE-599: Missing Validation of OpenSSL Certificate * CWE-611: Improper Restriction of XML External Entity Reference * CWE-676: Use of potentially dangerous function * CWE-704: Incorrect Type Conversion or Cast * CWE-754: Improper Check for Unusual or Exceptional Conditions * CWE-770: Allocation of Resources Without Limits or Throttling * CWE-1004: Sensitive Cookie Without 'HttpOnly' Flag * CWE-1275: Sensitive Cookie with Improper SameSite Attribute Troubleshooting Vulnerability Resolution sometimes cannot generate a suggested fix. Common causes include: * False positive detected: * Before proposing a fix, the AI model assesses whether the vulnerability is valid. It may judge that the vulnerability is not a true vulnerability, or isn t worth fixing. * This can happen if the vulnerability occurs in test code. Your organization might still choose to fix vulnerabilities even if they happen in test code, but models sometimes assess these to be false positives. * If you agree that the vulnerability is a false positive or is not worth fixing, you should dismiss the vulnerability and select a matching reason . * To customize your SAST configuration or report a problem with a GitLab SAST rule, see SAST rules . * Temporary or unexpected error: * The error message may state that an unexpected error has occurred , the upstream AI provider request timed out , something went wrong , or a similar cause. * These errors may be caused by temporary problems with the AI provider or with GitLab Duo. * A new request may succeed, so you can try to resolve the vulnerability again. * If you continue to see these errors, contact GitLab for assistance. Data shared with third-party AI APIs for Vulnerability Resolution The following data is shared with third-party AI APIs: * Vulnerability name * Vulnerability description * Identifiers (CWE, OWASP) * Entire file that contains the vulnerable lines of code * Vulnerable lines of code (line numbers) Vulnerability Resolution in a merge request * Tier : Ultimate * Add-on : GitLab Duo Enterprise * Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated History * Introduced in GitLab 17.6. * Enabled by default in GitLab 17.7. * Generally available in GitLab 17.11. Feature flag resolve_vulnerability_in_mr removed. Use GitLab Duo Vulnerability resolution to automatically create a merge request suggestion comment that resolves the vulnerability finding. By default, it is powered by the Anthropic claude-3.5-sonnet model. To resolve the vulnerability finding: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests . * Select a merge request. * Vulnerability findings supported by Vulnerability Resolution are indicated by the tanuki AI icon ( ). * Select the supported findings to open the security finding dialog. * In the lower-right corner, select Resolve with AI . A comment containing the AI remediation suggestions is opened in the merge request. Review the suggested changes, then apply the merge request suggestion according to your standard workflow. Provide feedback on this feature in issue 476553 . Troubleshooting Vulnerability Resolution in a merge request sometimes cannot generate a suggested fix. Common causes include: * False positive detected: * Before proposing a fix, the AI model assesses whether the vulnerability is valid. It may judge that the vulnerability is not a true vulnerability, or isn t worth fixing. * This can happen if the vulnerability occurs in test code. Your organization might still choose to fix vulnerabilities even if they happen in test code, but models sometimes assess these to be false positives. * If you agree that the vulnerability is a false positive or is not worth fixing, you should dismiss the vulnerability and select a matching reason . * To customize your SAST configuration or report a problem with a GitLab SAST rule, see SAST rules . * Temporary or unexpected error: * The error message may state that an unexpected error has occurred , the upstream AI provider request timed out , something went wrong , or a similar cause. * These errors may be caused by temporary problems with the AI provider or with GitLab Duo. * A new request may succeed, so you can try to resolve the vulnerability again. * If you continue to see these errors, contact GitLab for assistance. * Resolution target could not be found in the merge request, unable to create suggestion error: * This error may occur when the target branch has not run a full security scan pipeline. See the merge request documentation . Vulnerability code flow * Tier : Ultimate * Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated For specific types of vulnerabilities, GitLab Advanced SAST provides code flow information. A vulnerability s code flow is the path the data takes from the user input (source) to the vulnerable line of code (sink), through all assignments, manipulation, and sanitization. For details on how to view a vulnerability s code flow, see Vulnerability code flow . Vulnerability status values A vulnerability s status can be: * Needs triage : The default state for a newly discovered vulnerability. * Confirmed : A user has seen this vulnerability and confirmed it to be accurate. * Dismissed : A user has evaluated this vulnerability and dismissed it . Dismissed vulnerabilities are ignored if detected in subsequent scans. * Resolved : The vulnerability has been fixed or is no longer present. If a resolved vulnerability is reintroduced and detected again, its record is reinstated and its status set to Needs triage . A vulnerability typically goes through the following lifecycle: %%{init: { "fontFamily": "GitLab Sans" }}%% stateDiagram accTitle: Vulnerability lifecycle accDescr: Typical lifecycle of a vulnerability direction LR Needs_triage: Needs triage [*] --> Needs_triage Needs_triage --> Confirmed Needs_triage --> Dismissed Dismissed --> [*] Confirmed --> Resolved Resolved --> Needs_triage: If reintroduced and detected again Resolved --> [*] Vulnerability is no longer detected History * A link to the commit that resolved the vulnerability was introduced and made generally available on GitLab Self-Managed and GitLab Dedicated in GitLab 17.9. Feature flag vulnerability_representation_information removed. A vulnerability may be no longer detected because of changes made deliberately to remediate it or as a side effect of other changes. When a security scan runs and a vulnerability is no longer detected in the default branch, the scanner adds No longer detected to the record s activity log but the record s status does not change. Instead, you should check and confirm the vulnerability has been resolved and if so, manually change its status to Resolved . You can also use a vulnerability management policy to automatically change the status of vulnerabilities matching specific criteria to Resolved . You can find a link to the commit that resolved the vulnerability in the Activity section of the vulnerability page. Vulnerability dismissal reasons When you dismiss a vulnerability you must choose one of the followin