Coveralls is a vital tool for developers seeking to ensure code quality through continuous integration, focusing on test coverage reporting. Version 2.11.2 refines the package with a crucial update to its request dependency, bumping it from version 2.36.0 to version 2.40.0. While seemingly minor, this dependency upgrade directly impacts the reliability and security of HTTPS requests made by Coveralls, crucial for securely transmitting coverage data to the Coveralls.io service.
This adjustment is particularly important for developers concerned with maintaining up-to-date security protocols in their projects. The update addresses potential vulnerabilities and performance improvements inherent in the request library. Developers relying on Coveralls to guarantee comprehensive test coverage reporting will appreciate this enhanced stability and security.
Beyond the request module update, the core functionality of Coveralls in taking json-cov output and posting it to Coveralls.io remains consistent across both versions. Developers familiar with the 2.11.1 version can seamlessly transition to 2.11.2 knowing that their existing workflow will remain largely unchanged. The continued reliance on dependencies like js-yaml, lcov-parse, and log-driver also signifies a commitment to established tools for parsing and managing coverage data. The BSD license also ensures that you can continue to use the library without restrictions. This makes version 2.11.2 an essential upgrade for projects prioritizing secure and dependable coverage reporting.
All the vulnerabilities related to the version 2.11.2 of the package
Denial of Service in js-yaml
Versions of js-yaml
prior to 3.13.0 are vulnerable to Denial of Service. By parsing a carefully-crafted YAML file, the node process stalls and may exhaust system resources leading to a Denial of Service.
Upgrade to version 3.13.0.
Code Injection in js-yaml
Versions of js-yaml
prior to 3.13.1 are vulnerable to Code Injection. The load()
function may execute arbitrary code injected through a malicious YAML file. Objects that have toString
as key, JavaScript code as value and are used as explicit mapping keys allow attackers to execute the supplied code through the load()
function. The safeLoad()
function is unaffected.
An example payload is
{ toString: !<tag:yaml.org,2002:js/function> 'function (){return Date.now()}' } : 1
which returns the object
{
"1553107949161": 1
}
Upgrade to version 3.13.1.
Arbitrary Code Execution in underscore
The package underscore
from 1.13.0-0 and before 1.13.0-2, from 1.3.2 and before 1.12.1 are vulnerable to Arbitrary Code Execution via the template function, particularly when a variable property is passed as an argument as it is not sanitized.
Regular Expression Denial of Service in underscore.string
Versions of underscore.string
prior to 3.3.5 are vulnerable to Regular Expression Denial of Service (ReDoS).
The function unescapeHTML
is vulnerable to ReDoS due to an overly-broad regex. The slowdown is approximately 2s for 50,000 characters but grows exponentially with larger inputs.
Upgrade to version 3.3.5 or higher.
Remote Memory Exposure in request
Affected versions of request
will disclose local system memory to remote systems in certain circumstances. When a multipart request is made, and the type of body
is number
, then a buffer of that size will be allocated and sent to the remote server as the body.
var request = require('request');
var http = require('http');
var serveFunction = function (req, res){
req.on('data', function (data) {
console.log(data)
});
res.end();
};
var server = http.createServer(serveFunction);
server.listen(8000);
request({
method: "POST",
uri: 'http://localhost:8000',
multipart: [{body:500}]
},function(err,res,body){});
Update to version 2.68.0 or later
Server-Side Request Forgery in Request
The request
package through 2.88.2 for Node.js and the @cypress/request
package prior to 3.0.0 allow a bypass of SSRF mitigations via an attacker-controller server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS to HTTP).
NOTE: The request
package is no longer supported by the maintainer.
Prototype Pollution Protection Bypass in qs
Affected version of qs
are vulnerable to Prototype Pollution because it is possible to bypass the protection. The qs.parse
function fails to properly prevent an object's prototype to be altered when parsing arbitrary input. Input containing [
or ]
may bypass the prototype pollution protection and alter the Object prototype. This allows attackers to override properties that will exist in all objects, which may lead to Denial of Service or Remote Code Execution in specific circumstances.
Upgrade to 6.0.4, 6.1.2, 6.2.3, 6.3.2 or later.
qs vulnerable to Prototype Pollution
qs before 6.10.3 allows attackers to cause a Node process hang because an __ proto__
key can be used. In many typical web framework use cases, an unauthenticated remote attacker can place the attack payload in the query string of the URL that is used to visit the application, such as a[__proto__]=b&a[__proto__]&a[length]=100000000
. The fix was backported to qs 6.9.7, 6.8.3, 6.7.3, 6.6.1, 6.5.3, 6.4.1, 6.3.3, and 6.2.4.
Regular Expression Denial of Service in hawk
Versions of hawk
prior to 3.1.3, or 4.x prior to 4.1.1 are affected by a regular expression denial of service vulnerability related to excessively long headers and URI's.
Update to hawk version 4.1.1 or later.
Uncontrolled Resource Consumption in Hawk
Hawk is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with partial cryptographic verification of the request and response, covering the HTTP method, request URI, host, and optionally the request payload. Hawk used a regular expression to parse Host
HTTP header (Hawk.utils.parseHost()
), which was subject to regular expression DoS attack - meaning each added character in the attacker's input increases the computation time exponentially. parseHost()
was patched in 9.0.1
to use built-in URL
class to parse hostname instead.Hawk.authenticate()
accepts options
argument. If that contains host
and port
, those would be used instead of a call to utils.parseHost()
.
Prototype Pollution in hoek
Versions of hoek
prior to 4.2.1 and 5.0.3 are vulnerable to prototype pollution.
The merge
function, and the applyToDefaults
and applyToDefaultsWithShallow
functions which leverage merge
behind the scenes, are vulnerable to a prototype pollution attack when provided an unvalidated payload created from a JSON string containing the __proto__
property.
This can be demonstrated like so:
var Hoek = require('hoek');
var malicious_payload = '{"__proto__":{"oops":"It works !"}}';
var a = {};
console.log("Before : " + a.oops);
Hoek.merge({}, JSON.parse(malicious_payload));
console.log("After : " + a.oops);
This type of attack can be used to overwrite existing properties causing a potential denial of service.
Update to version 4.2.1, 5.0.3 or later.
hoek subject to prototype pollution via the clone function.
hoek versions prior to 8.5.1, and 9.x prior to 9.0.3 are vulnerable to prototype pollution in the clone function. If an object with the proto key is passed to clone() the key is converted to a prototype. This issue has been patched in version 9.0.3, and backported to 8.5.1.
form-data uses unsafe random function in form-data for choosing boundary
form-data uses Math.random()
to select a boundary value for multipart form-encoded data. This can lead to a security issue if an attacker:
Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request.
This is largely the same vulnerability as was recently found in undici
by parrot409
-- I'm not affiliated with that researcher but want to give credit where credit is due! My PoC is largely based on their work.
The culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/form_data.js#L347
An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a x-request-id
header added by the server. These sorts of headers are often used for distributed tracing, to correlate errors across the frontend and backend. Math.random()
is a fine place to get these sorts of IDs (in fact, opentelemetry uses Math.random for this purpose)
PoC here: https://github.com/benweissmann/CVE-2025-7783-poc
Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID).
For an application to be vulnerable, it must:
form-data
to send data including user-controlled data to some other system. The attacker must be able to do something malicious by adding extra parameters (that were not intended to be user-controlled) to this request. Depending on the target system's handling of repeated parameters, the attacker might be able to overwrite values in addition to appending values (some multipart form handlers deal with repeats by overwriting values instead of representing them as an array)If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.
mime Regular Expression Denial of Service when MIME lookup performed on untrusted user input
Affected versions of mime
are vulnerable to regular expression denial of service when a mime lookup is performed on untrusted user input.
Update to version 2.0.3 or later.
Memory Exposure in tunnel-agent
Versions of tunnel-agent
before 0.6.0 are vulnerable to memory exposure.
This is exploitable if user supplied input is provided to the auth value and is a number.
Proof-of-concept:
require('request')({
method: 'GET',
uri: 'http://www.example.com',
tunnel: true,
proxy:{
protocol: 'http:',
host:'127.0.0.1',
port:8080,
auth:USERSUPPLIEDINPUT // number
}
});
Update to version 0.6.0 or later.