Blog Security Shopping for an admin account via path traversal
November 29, 2019
5 min read

Shopping for an admin account via path traversal

How to exploit a path traversal issue to gain an admin account


GitLab security researchers conduct internal testing against GitLab assets and against free and open-source software (FOSS) critical to GitLab products and operations to ultimately make our product and company more secure.


Most web applications are not standalone – they depend on other applications in order to fulfill their purpose. Calls to other web apps can be done in various ways depending on the other side's API. In this post, we'll discuss calls to REST APIs and some security implications when calling those REST endpoints.

Representational State Transfer (short: REST) is an HTTP-based protocol that uses different HTTP methods (e.g. GET/POST/PUT/DELETE) to interact with a remote API endpoint.

Let's take a look at a very specific (GitLab) example to get an impression of what can go wrong when two web apps talk REST to each other.

GitLab's Customers Portal

At our GitLab community can shop for various GitLab subscriptions and also buy CI minutes. The customers source code is non-public, so I will just use a few relevant snippets as examples to illustrate the issue.

The customers portal needs to interact with the API in order to let know things like how many CI minutes you've bought. The HTTP calls to the API are implemented using HTTParty.

For PUT requests this looked like:

    def put(path, *args)
      options = valid_options(args)

      HTTParty.put(full_url(path), options)


    def full_url(path)
      URI.join(BASE_URL, path).to_s

Let's look at the caller to the put method:

response = Client::GitlabApp.put("/api/v4/namespaces/#{@namespace_id}", body: @attrs.to_json, token: API_TOKEN)

The above line of code is the place where the Client::GitlabApp is used to update a subscription on; this call occurs when a customer moves the subscription from one namespace to another. The parameter @namespace_id is user controlled but the payload of the PUT operation (body: @attrs.to_json) is not. The API_TOKEN is an access token to's API with admin privileges. The threat which arises from the call to Client::GitlabApp.put is the possibility to traverse the path on's API by supplying a @namespace_id of ../other/path and thus being able to reach other API endpoints than the intended /api/v4/namespace/.

This type of attack, namely a path (or directory) traversal attack, is a very common and generic issue. It can occur basically everywhere that path parameters are being plunged together (e.g. file systems access or unpacking of archive files).


It gets really interesting when we think about the impact and exploitation of this issue. Since we do not control the payload (@attrs.to_json) of the PUT operation one could think that the impact of this traversal is quite limited. In REST the PUT operation is being used to update existing resources. Usually the to-be-updated attributes of the resource are sent in the body of the HTTP request, just like the JSON encoded @attrs in our case.

The API endpoint on is implemented using Grape which implements parameter handling in a way that any PUT/POST parameters will be merged with the path-based GET parameters into the params hash. This means that besides the body: @attrs.to_json payload in the PUT operation we could, using the unsanitized @namespace_id parameter, not only traverse API endpoints using ../ sequences, we could also inject attributes on the API endpoint by appending ?some_attribute=our_value to @namespace_id. So, in addition to the path traversal, we can also inject arbitrary arguments on the API endpoint. In combination the two steps can enable quite powerful attacks.


Taking the above building blocks of path traversal and attribute injection in a request using an admin token on the API, we have a quite powerful and universal attack at hand. While investigating and verifying the issue on GitLab's staging environment it could be used to promote regular accounts to admin. The actual payload is quite simple: ../users/<userID>?admin=true it resulted in a PUT request to<userID>?admin=true.

Within the staging environment the exploit payload looked like this within the Chrome developer tools:


The reward was a shiny 🔧 sign to access the admin area on the targeted account:


The modification was done using the "Change linked Group" feature for a GitLab Bronze subscription. But as the same vector can be used with purchased CI minutes it would just have cost eight dollars and a few clicks to become an admin on 😏.


The issue was mitigated promptly by the fulfillment backend team. The application is now enforcing the @namespace_id parameter to be numerical. Also additional defense-in-depth measures have been taken to avoid path traversals and similar attacks.


We've seen here a very good example of the typical pitfalls in modern applications which make use of backend services via API calls. The path traversal in combination with the ability to inject further attributes in the API call allowed us to cause severe impact. The issue, even though present in the code base, could be used to elevate user privileges on

Security Research at GitLab Security research is one component of our broader security organization's efforts to enhance the security posture of our company, products, and client-facing services. See our Security Handbook to learn more.

Photo by Marta Branco on Pexels

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert