Vulnerability: bump pygments version to 2.20.0

[apoorvkh]

There's a vulnerability in pygments versions 2.19.2 and prior. Can we bump the minimum version this package depends on to avoid that issue? Thanks.

https://nvd.nist.gov/vuln/detail/CVE-2026-4539

[github-actions]

Thank you for your issue. Give us a little time to review it.

PS. You might want to check the FAQ if you haven't done so already.

Rich was created by Will McGugan. Consider sponsoring Will's work on Rich.

This is an automated reply, generated by FAQtory

[jepify]

bump

[webknjaz]

@apoorvkh @jepify have you already performed a detailed analysis on whether that code path can actually be reached from within Rich? Doing so would help the maintainers judge whether this is slop more quickly.

The discussion at pygments/pygments#3058 (comment) suggests that it doesn't really deserve a CVE number, and the maintainers do not consider it a vulnerability per their threat model.

Here's why fake vulnerability crusades are harmful: https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage.

---

Tip

If you suspect something to be a vulnerability (in any open source project), it's imperative that the maintainers are informed privately per project's reporting guidelines. Ignoring security policies is a bad tone and is also actively harmful.

Be responsible.

https://github.com/Textualize/rich/security

[webknjaz]

In general, bumping lower bounds of deps tends to harm compatibility on the depresolver level and should have a strong justification other than "I ran a tool but didn't interpret/check the results".

Example handling elsewhere: pytest-dev/pytest#14359 / pytest-dev/pytest#14361 + getpelican/pelican#3587 / getpelican/pelican#3586.

[apoorvkh]

Thanks for the points. I haven't done any code analysis for rich and am unfamiliar with the codebase, so it might make more sense for a maintainer. I'm just raising this because this is a declared CVE (whether it should be or not), which signals importance and also leaks into the security analyses of further downstream dependencies.

Agree that, if this is not truly a vulnerability, there is extra maintainer cost. If that is the case, there should be no CVE and/or Pygments should dispute it. But since this is a CVE, rich maintainers should at least consider it and decide if this library is specifically unaffected. The cost of consideration is worth it, because we could otherwise miss more severe vulnerabilities otherwise.

In any case, rich maintainers actually already considered this in #4044 which I unfortunately missed. Closing accordingly.

[github-actions]

I hope I helped!

Consider sponsoring my work on Rich. I give tech support for free, in addition to maintaining Rich and Textual.

If you like using Rich, you might also enjoy Textual.

Will McGugan