request@2.9.201 vulnerabilities

Simplified HTTP request client.

Direct Vulnerabilities

Known vulnerabilities in the request package. This does not include vulnerabilities belonging to this package’s dependencies.

Automatically find and fix vulnerabilities affecting your projects. Snyk scans for vulnerabilities and provides fixes for free.
Fix for free
Vulnerability Vulnerable Version
  • M
Server-side Request Forgery (SSRF)

request is a simplified http request client.

Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF) due to insufficient checks in the lib/redirect.js file by allowing insecure redirects in the default configuration, via an attacker-controller server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS to HTTP).

NOTE: request package has been deprecated, so a fix is not expected. See https://github.com/request/request/issues/3142.

How to fix Server-side Request Forgery (SSRF)?

A fix was pushed into the master branch but not yet published.

*
  • M
Remote Memory Exposure

request is a simplified http request client.

Affected versions of this package are vulnerable to Remote Memory Exposure. A potential remote memory exposure vulnerability exists in request. If a request uses a multipart attachment and the body type option is number with value X, then X bytes of uninitialized memory will be sent in the body of the request.

Note that while the impact of this vulnerability is high (memory exposure), exploiting it is likely difficult, as the attacker needs to somehow control the body type of the request. One potential exploit scenario is when a request is composed based on JSON input, including the body type, allowing a malicious JSON to trigger the memory leak.

How to fix Remote Memory Exposure?

Upgrade request to version 2.68.0 or higher.

>2.2.5 <2.68.0
  • M
Remote Memory Exposure

request is a simplified http request client.

Affected versions of this package are vulnerable to Remote Memory Exposure. A potential remote memory exposure vulnerability exists in request. If a request uses a multipart attachment and the body type option is number with value X, then X bytes of uninitialized memory will be sent in the body of the request.

Note that while the impact of this vulnerability is high (memory exposure), exploiting it is likely difficult, as the attacker needs to somehow control the body type of the request. One potential exploit scenario is when a request is composed based on JSON input, including the body type, allowing a malicious JSON to trigger the memory leak.

How to fix Remote Memory Exposure?

Upgrade request to version 2.68.0 or higher.

>2.2.5 <2.68.0