chore(v11.x): release 11.7.6

[github-actions]

🤖 I have created a release beep boop

11.7.6 (2026-02-14)

🩹 Fixes

• make describe().timeout() work (aafe6fd)
• test: replace wmic usage with native Windows API (#5694) (73ebdfa)

🧹 Chores

• format all code (#5629) (0696784)
• remove Netlify (#5630) (8d01d33)

---

This PR was generated with Release Please. See documentation.

[hlovdal]

Please make sure that #5605 is included in this release, because it fixes a security dependency issue.

Also, even though "^8.0.2" will allow for moving forward to 8.0.3 which contains the fix, it would be better to explicitly require minimum that version, e.g.

"diff": "^8.0.3",

[mark-wiemer]

As Josh said in #5650 (comment):

With love and appreciation, joshuakgoldberg.com/blog/please-stop-sending-me-nested-dependency-security-reports

I'll add: this vulnerability does not affect Mocha. Unless you're using it to parse files you don't own, there is nothing risky. The first line of the advisory is clear:

Attempting to parse a patch whose filename headers contain the line break characters \r, \u2028, or \u2029 can cause the parsePatch method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory.

This is at the very worst a mild inconvenience for Mocha users, as they have to find their relevant test files and rename them. No security risk.

Please, if you think there's a risk, reproduce the actual issue (not just the warning) before pinging here.

[Seb33300]

@mark-wiemer Even if the risk is theoretical in Mocha, the presence of a known CVE still triggers security scanners and audit findings for downstream users. Some security certifications and compliance frameworks do not allow shipping dependencies with known vulnerabilities, regardless of exploitability.

And you cannot assume or enforce how dependencies are used downstream. Providing a fix is the safest default.

[JoshuaKGoldberg]

Even if the risk is theoretical in Mocha

It is not theoretical. This security vulnerability does not impact Mocha.

security scanners and audit findings
Some security certifications and compliance frameworks do not allow shipping dependencies with known vulnerabilities, regardless of exploitability.

That is where the problem lies. It's a "boy who cried wolf" situation.

From another perspective: we have an extremely limited budget maintaining Mocha. It has been years since more than two maintainers have been regularly active for any sustained amount of time, and in those years, no maintainer has ever been able to spend more than part-time effort on the project. We, like the vast majority of open source projects, are understaffed and overwhelmed with the bare minimum of work to keep the project going.

Security scanners regularly report false positives without applying nuance to who those packages impact. This creates a great deal of noise in the ecosystem and causes extra work for overloaded projects like Mocha. Which is improper, unfair, and detrimental to the ecosystem. It's a waste of our time to try to take action -let alone urgently- on incorrect security reports that do not impact Mocha. That takes away time from other, actually user-benefitting work.

Speaking of which, we will soon release the next, beta-7 version of Mocha 12 currently released: mocha@12.0.0-beta-6. That version of Mocha both includes the requested bump of the diff package as well as several more package upgrades that rely on being able to require(esm). Rather than playing wack-a-mole with false positive security reports in v11, we will prioritize getting v12 shipped.

I think it's great that you're looking at the security reports and advocating for it (really, a super positive & beneficial thing!). But getting Mocha to respond to incorrect security reports is not long-term optimally helpful for users of Mocha. The best places you could try to make better here would be for security reporting mechanisms such as npm audit that produce incorrect reports, cause compliance frameworks to needlessly block package updates based on those reports, and reduce trust in security reporting mechanisms altogether.

[voxpelli]

Some security certifications and compliance frameworks do not allow shipping dependencies with known vulnerabilities

It's very rare to ship something with mocha as a non-dev dependency?

Also: Lockfile maintenance is key. Do an npm update or such. Only if something in our dependency chain would demand you to use a security flagged version would it need us to act in my mind.

[JoshuaKGoldberg]

Err, the v11.x ref is protected. How do we get this released? Should I --admin merge this?

[mark-wiemer]

@JoshuaKGoldberg sorry for the issues, I set this up and I can edit the branch rule to make this easier, let me do that now...

[mark-wiemer]

I had wrongly checked the "Restrict updates" box, I've unchecked it and now we can merge, I'll merge now :)

[github-actions]

🤖 Created releases:

• v11.7.6

🌻

[dlockhart]

Exciting to see this released, but should this have published 11.7.6 to npm or is that a separate workflow?

[JoshuaKGoldberg]

Ah, right, we have to manually approve these. https://github.com/mochajs/mocha/actions/runs/26012935644 was waiting on us. I approved just now. Thanks for the prod 😄

[torokati44]

Ooh, it failed. 😐

[dlockhart]

It's possible that you may need to rotate your token if you're using a granular one -- npm invalidated them all last night due to the ongoing Shai Hulud attacks.

[JoshuaKGoldberg]

sigh. Thanks. https://www.npmjs.com/package/mocha/v/11.7.6 is now published.

Our CI system was, in fact, using an old npm token. I set up a new one that'll expire in a week. We'll have to rework our trusted publishing setup a bit.