debug known bugs

A vulnerability classified as problematic has been found in debug-js debug up to 3.0.x. This affects the function useColors of the file src/node.js. The manipulation of the argument str leads to inefficient regular expression complexity. Upgrading to version 3.1.0 is able to address this issue. The name of the patch is c38a0166c266a679c8de012d4eaccec3f944e685. It is recommended to upgrade the affected component. The identifier VDB-217665 was assigned to this vulnerability. The patch has been backported to the 2.6.x branch in version 2.6.9.

### Impact On 8 September 2025, the npm publishing account for `debug` was taken over after a phishing attack. Version `4.4.2` was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker's own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct `<script>` inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. See references below for more information on the payload. ### Patches npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. This version is functionally identical to the previously known-good version, published as a patch version bump above the compromised version. Users should upgrade to the latest patch version, completely remove their `node_modules` directory, clean their package manager's global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. ### References - https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised - https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack - https://www.ox.security/blog/npm-packages-compromised/ ### Point of Contact In the event suspicious behavior is still observed for the package listed in this security advisory after performing all of the above cleaning operations (see _Patches_ above), please reach out via one of the following channels of communication: - Bluesky, package owner: https://bsky.app/profile/bad-at-computer.bsky.social - `debug` repository, tracking issue (applies to all packages affected in the breach): https://github.com/debug-js/debug/issues/1005

I only get output with the word Chinese in the name, followed by a colon. I don't see anywhere in usage that explains why this would be. Usage shows... `var debug = require('debug')('http')` `var debug = require('debug')('worker');` `var error = debug('app:error');` Logs correctly for me... `const debug = require('debug')('Chinese:www')` `const debug = require('debug')('Chinese:foo')` No logs at all... `const debug = require('debug')('Foo:www')` `const debug = require('debug')('Foo')`

Your most recent update seems to have broken our build. It is throwing the following error: `Uncaught TypeError: t.useColors is not a function`

TypeError: Cannot read property 'style' of null happening when document.documentElement is null because there is no null check. Would like to put in a PR to fix it if you guys decide not to.

https://runkit.com/ilyaigpetrov/59a6ef385d75ca0011ffb2c3 ```js const debug = require('debug') console.log('ENABLED_1?', debug.enabled('*')); debug.enable('*'); debug.disable('*'); console.log('ENABLED_2?', debug.enabled('*')); ``` Output: ```js ENABLED_1? true ENABLED_2? true ```

if you use it from within docker, it does not work as expected, instead of showing default behaviour with colours and milli seconds between messages it shows full time, to make it work as default, you need to add: DEBUG_COLORS=true to command line I had to debug code to make it work, this behaviour could be documented, added in to readme file

For example, let's say I have the following: ``` const debug = require("debug"); const foobarDebug = debug("foo:bar"); debug.enable("foo:*"); console.log("debug.enabled('foo:bar')?", debug.enabled("foo:bar")); console.log("foobarDebug enabled?", foobarDebug.enabled); ``` will output ``` debug.enabled('foo:bar')? true foobarDebug enabled? false ``` If you create the debugger after calling `enable()` it works as expected. I understand that `enable()` overrides what was previously enabled, but I would expect that anything that passes the new filters would be enabled.

environment: node I use same namespace across few files. When I disable namespace in one file ``` let namespaces = enabledNamespaces() const index = namespaces.indexOf(namespace) namespaces[index] = `-${namespace}` debug.enable(namespaces.join()) ``` in other other file I see that debug doesn't have this namespace in the list of names, but the namespace still enabled and there is an output.

knex uses debug and it can happen that the message that is printed matches the formatter style-for example: ``` knex:bindings [ 1, 'undefined%' ] +5ms //when in fact knex:bindings: [ 1, '%j%' ], ``` maybe debug should not even attempt to replace formatter expressions when there is nothing provided?

Any version of debug that I use past version 3.1.0 gives this error when trying to browserify code that includes this module ``` Cannot find module './common' from '[redacted]/node_modules/debug/dist' at FSReqWrap.oncomplete (fs.js:154:21) ``` There was a mention in #603 about a browserify incompatibility, but it doesn't appear to be the same issue.

I know this isn't an issue with the package so much as it is a personal issue, but I can't seem to find documentation anywhere to disable debug globally for all projects. Basically whenever I localhost anything my localStorage is automatically is set to {debug: *}. I will delete this issue as soon as I figure it out.

const debug = require('debug'); const log = debug('app'); log.log = console.log.bind(console); //log to stdout log('Stdout test'); //writes "app Stdout test" to stdout log.extend('extended')('Stdout test'); //writes "app:extended Stdout test" to stderr Bit annoying if i want to have a base IDebugger for stdout and another for stderr, but i have to re-bind console.log whenever i want to extend the stdout debugger.

Hi, I just noticed that when you create debug instance in a function, it is starting to leak the memory without freeing. Here's how you can reproduce it: ```js const debug = require('debug'); const loop = () => { const d = debug('namespace:that:i:want:for:this:function'); d('hello world'); setImmediate(loop); }; loop(); ``` If you run this and look at memory, it is leaking a lot without freeing them. also does not matter if I set environment to DEBUG=* or not, it still leaks. Any thoughts? EDIT: tested on 3.1.1 and 4.1.1 as well (had 3.1.1 version and then I upgraded to latest one to check if it was fixed). EDIT2: using node version 10.13 and Windows 10 x64.

This line over here defines an ANSI extended color set for bright color which doesn't display correctly: (by incorrectly I mean it's just bold white color) https://github.com/visionmedia/debug/blob/5c7c61dc0df0db4eb5de25707d8cd1b9be1add4f/src/node.js#L169 It shouldn't(?) have a traling `;1` after `${colorCode}`. So the line should like: ``const prefix = ` ${colorCode}m${name} \u001B[0m`; `` This fixes the bug (for me :) ) EDIT: This supports my observation [256 colors](http://www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html#256-colors) Also from the article: > Note that the bright versions of the background colors do not change the background, but rather make the foreground text brighter. This is unintuitive but that's just the way it works. and the `;1` option only applies to `\u001b[44` ie background colors, while the `\u001b[38` option for foreground colors does not have such thing

Whether to support running on deno ? https://github.com/denoland/deno

<!-- DO NOT SUBMIT ISSUES ASKING TO REMOVE ES6. IT WILL BE CLOSED. IT WILL BE LOCKED. We use ES2015+ for a reason. Modern best practices dictate the use of tooling like Babel and @babel/preset-env in order to target the browsers that make sense for your project. For more information, please see: https://github.com/sindresorhus/ama/issues/446#issuecomment-281014491 Please keep in mind that `debug` is downloaded, installed, transpiled and used millions of times *per day*. If you have an error with `debug`, it's most likely your own configuration (e.g. with Babel, Webpack, etc). Unless you post ample evidence you have tried to fix this yourself, it will most likely be determined that your issue is localized to your project - not `debug`. --> Coverity static analysis is complaining that `enable(namespaces)` uses an unescaped user input as the basis for a regular expression. It follows the path from the user-defined `window.localStorage.debug` value through the `load()` function in [browser.js](https://github.com/visionmedia/debug/blob/master/src/browser.js) into the `enable(namespaces)` function in [common.js](https://github.com/visionmedia/debug/blob/master/src/common.js#L177). I understand that this debug input is used to control what is logged or not -- but it leaves the library (and any dependent ones) open to receiving crafted input that could cause a denial of service attack on the user's browser (ReDoS attack). I don't believe this is an issue for a server-side DoS attack -- as the input on the server comes from an environment variable rather than the less-protected browser context. One solution might be to look at something like https://github.com/davisjam/safe-regex to defend against some types of problematic regexes -- there are other suggestions in that repo's readme as well.

```javascript debug.disable('*'); debug.enable('foo'); assert.not(debug.enabled('bar')); assert.not(debug.enabled('bar*')); // throws; returns true ``` Has to be solved in two ways: - More stringent checks on namespaces (as they shouldn't contain asterisks) - Remove the check for `ns[ns.length-1]==='*'`, which makes absolutely no sense

`DEBUG_DEPTH` env var has no effect. I tried values of `10`, `100`, `null`. No matter what I always get the following display: ``` 2020-02-08T22:17:01.423Z SCOPE STRING [ { email: '[email protected]', vars: [ [Object] ] } ] ``` My invocation: ``` debug('STRING', targetObj); ```

There is possible to reassign `createDebug.selectColor()` method but is not used. Instead that is used directly default definition based on hash calculation. I would like to have possibility to customise color selection per namespace.

We upgraded to `4.3.2` and are all of a sudden not getting logs in stderr (using in a node script). The regressions seems to have been caused by #799 Admittedly we're perhaps using the library not _exactly_ in a way that it was intended to be used. We aren't setting `DEBUG` environment variable, so `process.env.DEBUG` is `undefined`, but our namespaces are named `example-namespace*` with a trailing `*`. These were previously logging, now they're not.

 Please review or remove links to examples in your readme. Links such as the [stdout.js](https://github.com/debug-js/debug/blob/HEAD/examples/node/stdout.js) in the screenshot above return a 404 page.

# Description How to set max array length (`maxArrayLength`)? # Code I run ```ts import debug from 'debug' const log = debug('myApp'); const justArray = new Array(10_000).fill(0); log({justArray}) const objWithNestedLongArray = { nestedArray: justArray } log({ objWithNestedLongArray}) ``` # How I have tried to set max array length ``` DEBUG="myApp" DEPTH_MAX_ARRAY_LENGTH="30000" bun run index.ts ``` ``` DEBUG="myApp" DEPTH_MAXARRAYLENGTH="30000" bun run index.ts ``` ``` DEBUG="myApp" DEPTH_maxArrayLength="30000" bun run index.ts ``` # Result Despite all the 3 methods I have tried to set max array length I get the same result: ``` myApp { myApp objWithNestedLongArray: { myApp nestedArray: [ myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, myApp ... 9900 more items myApp ] myApp } myApp } +0ms myApp { myApp justArray: [ myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, myApp 0, 0, 0, 0, myApp ... 9900 more items myApp ] myApp } +15ms ``` # Additional Info https://www.npmjs.com/package/debug#environment-variables chapter in documentation tells that by using DEBUG_ I can set Options object that gets used with %o/%O formatters like DEBUG_DEPTH, do I misunderstand that part?

The package was compromised and malicious code added. --- _-= Per source details. Do not edit below this line.=-_ ## Source: ghsa-malware (558d1dda312e85212121f4ed15340349f780f5e40d6685c3687648bbb2924381) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Namespaces would conflict and only the latest namespace would be activated at the same time. Test case: ``` let debug = require('debug'); debug.enable('test1*'); debug.enable('test2*'); let log_1 = debug('test1'); let log_2 = debug('test2'); console.log(1, log_1.enabled); console.log(2, log_2.enabled); ``` Results: ``` 1 false 2 true ``` Expected: ``` 1 true 2 true ```

Affected versions of `debug` are vulnerable to regular expression denial of service when untrusted user input is passed into the `o` formatter. As it takes 50,000 characters to block the event loop for 2 seconds, this issue is a low severity issue. This was later re-introduced in version v3.2.0, and then repatched in versions 3.2.7 and 4.3.1. ## Recommendation Version 2.x.x: Update to version 2.6.9 or later. Version 3.1.x: Update to version 3.1.0 or later. Version 3.2.x: Update to version 3.2.7 or later. Version 4.x.x: Update to version 4.3.1 or later.