CVE-2020-13356
Description
An issue has been discovered in GitLab CE/EE affecting all versions starting from 8.8.9. A specially crafted request could bypass Multipart protection and read files in certain specific paths on the server. Affected versions are: >=8.8.9, <13.3.9,>=13.4, <13.4.5,>=13.5, <13.5.2.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Unvalidated remote_id parameter in GitLab's multipart middleware allows authenticated attackers to read arbitrary files from object storage.
Vulnerability
A vulnerability exists in the Gitlab::Middleware::Multipart handler in GitLab CE/EE versions 8.8.9 up to 13.3.8, 13.4.0 to 13.4.4, and 13.5.0 to 13.5.1. The mitigation for a previous issue [1] failed to properly validate the remote_id parameter when processing file upload parameters that are nested inside a hash (e.g., user[avatar][.remote_id]). This allows an attacker to specify a remote file identifier from object storage, bypassing normal multipart file handling restrictions.
Exploitation
An authenticated user with the ability to upload files (e.g., avatar images) can exploit this vulnerability. The attacker must first enable object storage for uploads in the GitLab configuration. Steps: (1) Upload a file (e.g., PNG under 200KB) to the configured object storage bucket to obtain its remote identifier. (2) Intercept a request to the profile update endpoint (e.g., POST /profile). (3) Modify the user[avatar] parameter to user[avatar (syntax variation) and add the parameters user[avatar][.remote_id] with the target file name, user[avatar][.size] set to 1, and user[avatar][.name] set to a valid extension. The crafted multipart request is processed and the server reads the specified file from object storage [1].
Impact
Successful exploitation allows an attacker to read arbitrary files stored in the object storage backend, bypassing file access controls. This can lead to exposure of sensitive data, including other users' uploaded files, configuration files, or any data stored in the same bucket. The attack does not require direct access to the object storage provider [1].
Mitigation
The issue is fixed in GitLab versions 13.5.2, 13.4.5, and 13.3.9. Users should upgrade to these or later versions. There is no known workaround apart from disabling object storage for uploads if upgrading is not immediately possible. The vulnerability is not currently listed on the CISA Known Exploited Vulnerabilities (KEV) catalog. For self-managed instances, referencing the official advisory and the fixed releases is recommended [1].
AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3>=8.8.9, <13.3.9; >=13.4, <13.4.5; >=13.5, <13.5.2+ 1 more
- (no CPE)range: >=8.8.9, <13.3.9; >=13.4, <13.4.5; >=13.5, <13.5.2
- (no CPE)range: >=8.8.9
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing validation of `remote_id` parameter for file upload parameters nested inside a hash in `Gitlab::Middleware::Multipart`."
Attack vector
An authenticated attacker sends a crafted multipart POST request to an endpoint that accepts file uploads (such as the user profile avatar update endpoint). The attacker supplies a `remote_id` parameter nested inside a hash (e.g., `user[avatar][.remote_id]`) along with a `user[avatar` boundary parameter that lacks the closing bracket. This bypasses the Multipart middleware's protection and causes the server to fetch a file from object storage using the attacker-supplied `remote_id` value, leaking the file's contents back to the attacker [ref_id=1].
Affected code
The vulnerability resides in `Gitlab::Middleware::Multipart`, the Rack middleware responsible for parsing multipart file uploads. The mitigation for issue #850447 did not properly validate the `remote_id` parameter when the file upload parameter was nested inside a hash (e.g., `user[avatar]`).
What the fix does
The advisory does not include a patch diff, but the issue was addressed by adding proper validation of the `remote_id` parameter when it appears inside a hash structure in multipart uploads. The fix ensures that the mitigation originally applied for issue #850447 also covers the nested hash case, preventing attackers from specifying arbitrary `remote_id` values to read files from object storage [ref_id=1].
Preconditions
- configObject storage must be enabled for uploads
- authAttacker must be authenticated as a user
- networkAttacker must have network access to the GitLab instance
- inputAttacker must be able to send a crafted multipart POST request
Reproduction
1. Enable Object Storage for Uploads in `/etc/gitlab/gitlab.rb` with appropriate AWS credentials and a remote bucket. 2. Log in as a user. 3. Upload a file (PNG, GIF, ICO, JPEG, or TIFF, under 200KB) to the configured bucket under `tmp/uploads`. 4. Intercept the avatar update request and modify the multipart parameters: change `user[avatar]` to `user[avatar`, add `user[avatar][.remote_id]` with the uploaded filename, `user[avatar][.size]` set to 1, and `user[avatar][.name]` set to `test.png`. 5. Submit the request and navigate to the user avatar to view the leaked file content [ref_id=1].
Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13356.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/230878mitrex_refsource_MISC
- hackerone.com/reports/927953mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.