CVE-2024-6595 - Exploiting GitLab's NPM Package Metadata Conflict

In June 2024, security researchers uncovered a vulnerability affecting GitLab CE/EE (Community Edition and Enterprise Edition), tracked as CVE-2024-6595. This flaw allowed attackers to upload NPM packages with conflicting package data, potentially leading to confusion, supply chain attacks, or other security issues in software projects relying on GitLab's NPM package registry.

This long read explains what the vulnerability is, how it works, demonstrates a potential exploitation scenario, and provides sources for further reading.

This vulnerability impacted

- GitLab CE/EE versions starting from 11.8 up to (but not including) 16.11.6

Versions from 17.1 up to (but not including) 17.1.2

With CVE-2024-6595, attackers could upload an NPM package to the GitLab NPM registry that contained conflicting or inconsistent metadata. For instance, this could mean declaring a package as one thing in the package.json file but something else in the uploaded tarball or associated metadata. This inconsistency could be leveraged in multiple ways, including:

Official References

- CVE Record at GitLab
- NPM Package Registry Docs

How Did The Vulnerability Work?

The flaw existed in how GitLab handled the receiving and registering of NPM packages. When you publish an NPM package, there's a package.json file inside, but NPM also uses other metadata provided in API calls and request headers while publishing.

The vulnerability was that GitLab did not always properly check for consistency between these multiple sources of package information.

package.json inside the tarball says name: "my-different-module", version "2.."

A malicious user could upload a package that says it's one thing, but is actually another. If a developer or automation relies on one source (like the API or package.json), they could be tricked into installing the wrong code.

Demonstration: Exploiting CVE-2024-6595

Let's walk through a simple exploitation scenario.

Preparation

Suppose an attacker wants to trick someone into installing a malicious package by abusing this flaw.

Create a directory and package.json file

mkdir confuse-package
cd confuse-package
echo '{
  "name": "innocent-package",
  "version": "1..",
  "description": "This seems harmless!"
}' > package.json

Now, let’s say, during publish, the attacker uses NPM commands or a custom script to override the name/version in the metadata sent to GitLab’s NPM registry. For example, using the NPM CLI with --registry flag and by manipulating the tarball or API.

data-binary "@package.tgz" \

"https://gitlab.example.com/api/v4/projects//packages/npm/fake-package"

The tarball (package.tgz) contains package.json with "innocent-package".

- The upload route/endpoint says it’s "fake-package".

But the actual contents are for an entirely different package, "innocent-package".

- A developer using the NPM registry to install "fake-package" would get the files/content for "innocent-package".

Risks and Impact

- Supply chain attacks: Attackers upload malicious code under the guise of a trusted internal package.
- Dependency confusion: Automated systems or CI/CD pipelines fetching based on registry listings get the wrong code.
- Denial of trust: Developers lose faith in the accuracy of private registries if packages can lie about their contents.

17.1.2 or higher

After these versions, GitLab validates that all metadata matches between the registry and the internal package.json before accepting uploads.

Conclusion

CVE-2024-6595 is a classic example of why input validation matters in package registries. If your GitLab is running an older version, update as soon as possible—things like this can quickly become footholds for wider supply-chain attacks.

Timeline

Published on: 07/17/2024 02:15:10 UTC
Last modified on: 07/19/2024 14:52:54 UTC