Node-notifier is a popular Node.js package enabling cross-platform desktop notifications for macOS, Windows, and Linux, with Growl as a fallback. Version 4.6.1 improves upon the 4.6.0 release, offering users a refined experience. Both versions share the same core functionality: providing a unified API to trigger native notifications across different operating systems. Key dependencies like cli-usage, growly, lodash.clonedeep, minimist, semver, shellwords, and which remain consistent, ensuring compatibility and a familiar feature set for developers upgrading.
The subtle yet significant difference lies in the updated devDependencies. Version 4.6.1 upgrades the mocha testing framework to version ^3.0.0, enabling developers contributing to node-notifier to use newer testing features and syntax. It also affects developers relying on node-notifier indirectly, as it points to a better tested and potentially more stable dependency chain. The core functionality remains largely unchanged between the two versions suggesting that the update prioritizes stability and improved testing infrastructure. The maintainer seems to focus on stability, making node-notifier a reliable choice for projects requiring notification functionality, which can be easily integrated to notify users about background tasks, completed processes or errors. Considering the relatively small changes and dependency updates, upgrading to 4.6.1 is advisable for projects already using node-notifier.
All the vulnerabilities related to the version 4.6.1 of the package
OS Command Injection in node-notifier
This affects the package node-notifier before 8.0.1. It allows an attacker to run arbitrary commands on Linux machines due to the options params not being sanitised when being passed an array.
Inefficient Regular Expression Complexity in marked
What kind of vulnerability is it?
Denial of service.
The regular expression inline.reflinkSearch may cause catastrophic backtracking against some strings.
PoC is the following.
import * as marked from 'marked';
console.log(marked.parse(`[x]: x
\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](`));
Who is impacted?
Anyone who runs untrusted markdown through marked and does not use a worker with a time limit.
Has the problem been patched?
Yes
What versions should users upgrade to?
4.0.10
Is there a way for users to fix or remediate the vulnerability without upgrading?
Do not run untrusted markdown through marked or run marked on a worker thread and set a reasonable time limit to prevent draining resources.
Are there any links users can visit to find out more?
If you have any questions or comments about this advisory:
Inefficient Regular Expression Complexity in marked
What kind of vulnerability is it?
Denial of service.
The regular expression block.def may cause catastrophic backtracking against some strings.
PoC is the following.
import * as marked from "marked";
marked.parse(`[x]:${' '.repeat(1500)}x ${' '.repeat(1500)} x`);
Who is impacted?
Anyone who runs untrusted markdown through marked and does not use a worker with a time limit.
Has the problem been patched?
Yes
What versions should users upgrade to?
4.0.10
Is there a way for users to fix or remediate the vulnerability without upgrading?
Do not run untrusted markdown through marked or run marked on a worker thread and set a reasonable time limit to prevent draining resources.
Are there any links users can visit to find out more?
If you have any questions or comments about this advisory: