CVE-2024-6595 Overview
CVE-2024-6595 affects GitLab Community Edition (CE) and Enterprise Edition (EE) across multiple release branches. The flaw allows an authenticated user to upload a Node Package Manager (NPM) package containing conflicting package data between the package tarball and its manifest metadata. GitLab's package registry does not adequately validate consistency between these fields, which can be abused to spoof package identity.
The issue is tracked under CWE-451 (User Interface Misrepresentation of Critical Information) and CWE-434 (Unrestricted Upload of File with Dangerous Type). It affects all GitLab versions from 11.8 up to the patched releases.
Critical Impact
Attackers can publish NPM packages whose displayed metadata does not match the actual tarball contents, enabling downstream supply-chain deception against consumers of the GitLab package registry.
Affected Products
- GitLab CE/EE versions 11.8 through 16.11.5
- GitLab CE/EE versions 17.0 through 17.0.3
- GitLab CE/EE versions 17.1 through 17.1.1
Discovery Timeline
- 2024-07-17 - CVE-2024-6595 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-6595
Vulnerability Analysis
The vulnerability resides in GitLab's NPM package registry ingestion path. When a client publishes an NPM package, the request contains both a package manifest describing the package name and version and a tarball attachment carrying the actual code. GitLab accepts the upload without enforcing that the manifest metadata matches the package.json inside the tarball.
An attacker with permission to publish packages can craft an upload in which the manifest advertises one package name or version while the tarball contains different content. The GitLab UI and API surface the manifest values, but consumers who install the package retrieve the tarball contents. This mismatch enables targeted substitution attacks against downstream developers and CI pipelines pulling packages from the affected GitLab instance.
Related research on NPM ecosystem inconsistencies is documented in the VLT blog on NPM registry weaknesses and in GitLab issue #417975.
Root Cause
The root cause is missing cross-field validation between the outer NPM publish manifest and the inner tarball package.json. GitLab trusted client-supplied manifest data without reconciling it against the archive contents. This maps to CWE-434 for insufficient upload validation and CWE-451 for the resulting user-facing misrepresentation.
Attack Vector
Exploitation requires network access to a GitLab NPM registry and the ability to publish packages to a project. The attacker submits a crafted npm publish payload where the JSON manifest declares one identity and the attached tarball declares another. Consumers browsing the registry see the sanitized manifest identity while installing malicious code from the tarball.
No verified public exploit is available at the time of writing. The vulnerability requires no user interaction beyond a downstream install, and only integrity is impacted.
Detection Methods for CVE-2024-6595
Indicators of Compromise
- NPM package publish events where the manifest name or version field differs from the package.json inside the uploaded tarball.
- Unexpected new package versions appearing in GitLab projects with authors or upload sources inconsistent with the project's history.
- Downstream build failures or checksum mismatches when consumers verify installed package contents against the registry manifest.
Detection Strategies
- Audit the GitLab package registry database and object storage to compare stored manifest metadata against the package.json extracted from each tarball.
- Review GitLab audit events and API logs for PUT /api/v4/projects/:id/packages/npm/* calls originating from unexpected users or CI tokens.
- Correlate package publish timestamps with commit and pipeline activity to identify packages published without a corresponding source change.
Monitoring Recommendations
- Forward GitLab application and audit logs to a centralized analytics pipeline and alert on anomalous NPM publish patterns.
- Track package registry growth per project and flag sudden spikes or first-time publishers.
- Enable integrity checking on downstream npm install operations using lockfiles and npm audit signatures where supported.
How to Mitigate CVE-2024-6595
Immediate Actions Required
- Upgrade GitLab CE/EE to version 16.11.6, 17.0.4, or 17.1.2 or later, matching your current release branch.
- Rotate deploy tokens, personal access tokens, and CI job tokens that had write_package_registry scope during the exposure window.
- Enumerate all NPM packages published since the earliest affected version and validate their contents against expected source commits.
Patch Information
GitLab fixed the flaw by enforcing consistency between the NPM publish manifest and the tarball package.json during upload. The patched releases are GitLab 16.11.6, 17.0.4, and 17.1.2. Details are tracked in GitLab issue #417975.
Workarounds
- Restrict write_package_registry permissions to a minimal set of trusted service accounts until patching is complete.
- Require signed commits and protected pipelines for any job that publishes packages to the internal registry.
- Instruct consumers to pin dependencies by integrity hash in package-lock.json rather than by version string, ensuring tarball content is validated on install.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
