Ts-loader, a TypeScript loader for webpack, saw a release of version 4.5.0 following version 4.4.2. While both versions share the same core dependencies like chalk, semver, micromatch, loader-utils, and enhanced-resolve, the primary difference lies in their devDependencies, specifically in the version of TypeScript supported. Version 4.5.0 upgrades the typescript dev dependency to ^3.0.1 from 2.9.2 in version 4.4.2. This indicates that version 4.5.0 is built and tested against TypeScript 3.0.1, potentially offering better compatibility and leveraging new features introduced in that TypeScript version.
For developers using ts-loader, this TypeScript version bump is a significant consideration. If your project already utilizes TypeScript 3.0.1 or later, version 4.5.0 is likely a better choice to ensure a smoother and fully supported experience. Conversely, if your project relies on an older TypeScript version, sticking with ts-loader 4.4.2 might be preferable until you can upgrade your TypeScript dependency. Users should be aware that some features or bug fixes available in ts-loader 4.5.0 may rely on functionalities introduced in TypeScript 3.0.1. Besides the TypeScript upgrade, the fileCount and unpackedSize under the dist section are slightly different, which could indicate small changes and optimisations. Developers should consider this information when choosing the version that best suits them.
All the vulnerabilities related to the version 4.5.0 of the package
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.
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.