rich 15.0.0
- Source
- https://github.com/Textualize/rich
- Tag scanned
v15.0.0- Compared with
v14.3.4(0 signals introduced since)- Files
- 319 scanned, 217 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 24 info
- Scan time
- 18.1 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 19 of 19 warn and critical signals; 19 demoted to info.
- Disclude version
- 4.0.0
- Scanned (UTC)
- 2026-10-14 18:17
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
likely benign Persian README text containing zero-width non-joiners used for correct word shaping.
Reasoning
U+200C ZWNJ is a standard, required character in Persian orthography (for example in می⟨U+200C⟩کند and نوار های). The file is Persian prose in a markdown README, so this is normal text rendering, not hidden content.
-
likely benign Persian documentation paragraph with ZWNJ characters in normal words.
Reasoning
Same ZWNJ usage in ordinary Persian prose (می⟨U+200C⟩کند, مارک داون context). It is required for correct Persian spelling and has no executable effect in markdown.
-
likely benign Persian README sentence about text wrapping, with standard ZWNJ spelling.
Reasoning
ZWNJ within Persian compounds such as کلمه⟨U+200C⟩ای is standard orthography. The surrounding text is a translated description of Rich's word-wrapping behavior.
-
likely benign Persian documentation sentence with normal ZWNJ usage.
Reasoning
ZWNJ in Persian words such as می⟨U+200C⟩کند is expected orthography. The snippet is documentation prose about a progress-bar example.
-
likely benign Persian README line describing a spinner example, with standard ZWNJ spelling.
Reasoning
ZWNJ in Persian words such as می⟨U+200C⟩دهد and نمی دارد is normal writing. The only oddity is a replacement or emoji glyph before 'خنده', which is a rendering artifact in a README.
-
likely benign Japanese markdown link text containing the product name Rich alongside kana and kanji.
Reasoning
Japanese prose mixing Latin 'Rich' with Hiragana and Han is normal. The identifier is actually a link label in a markdown heading-adjacent sentence, not a code identifier, so mixed scripts are expected.
-
likely benign Russian README heading whose first letter is a Latin C instead of Cyrillic С.
Reasoning
The heading 'Cовместимость' has a Latin 'C' where Cyrillic 'С' is expected. This is a plausible typo in a Russian markdown heading, not executable code. A deliberate homoglyph here would have no effect, so it is most likely a documentation typo.
-
likely benign Russian README heading mixing Latin and Cyrillic characters in one word.
Reasoning
Same heading as the homoglyph finding. Mixing Latin C with Cyrillic letters is consistent with a typing error in prose. It is in markdown text, so there is no execution path.
-
likely benign Russian README sentence referring to the Console class with a mistyped first letter.
Reasoning
'Сonsole' in running Russian prose refers to Rich's Console class. The Cyrillic С in place of Latin C is most likely a typing mistake. The surrounding text is documentation and no code is executed.
-
likely benign Russian README token mixing Cyrillic and Latin letters for the Console class name.
Reasoning
Same mixed-script 'Сonsole' token in prose. It is consistent with a typo and carries no executable or identifier-spoofing risk in a README.
-
likely benign Russian README sentence about Console.log with the same mixed-script spelling.
Reasoning
Another occurrence of 'Сonsole' in Russian documentation prose describing the log() method. The Cyrillic С is a likely typo in a markdown file, not code obfuscation.
-
likely benign A Russian README mentions a class name with a Cyrillic first letter.
Reasoning
The Cyrillic 'С' in 'Сonsole' is a homoglyph, but it sits in Russian prose in a README. It has no execution path and reads as a typing slip by a Russian-speaking author, not an attack on code.
-
## 互換性 -
-
= =likely benign Console logging uses inspect.currentframe to find the caller's location.Reasoning
Caller frame introspection is how rich's logging helper records the calling file and line. It is a documented feature of a mainstream terminal library, and the snippet shows no network, file or exec activity.
-
assert is not None = None # type: ignore[attr-defined]likely benign A pretty-print display helper temporarily sets builtins._ to match REPL expression-result behaviour.Reasoning
This mirrors the REPL convention of setting builtins._ around a display call, as sys.displayhook does. The global side effect is unusual but is a known pattern in rich's pretty-display helper and does not carry out an attack.
-
) = # type: ignore[attr-defined]likely benign The display helper stores the displayed value in builtins._ as a REPL would.Reasoning
This is the same display helper assigning builtins._ to the displayed value, matching the interactive-shell convention. The flagged code is legitimate rich behaviour and not a dropper or hook.
-
= -
= -
= assert == -
likely benign A test executes a fixed snippet that raises an exception so the traceback printer can be checked.
Reasoning
The exec call runs a fixed literal '1/0' compiled with a filename, purely to produce a ZeroDivisionError for a traceback-rendering test. The input is not attacker-controlled.
-
likely benign Another traceback test runs a fixed exception-raising snippet via exec.
Reasoning
This is the same test pattern with a fixed literal '1/0' input used to exercise traceback output. It is a test fixture, not malicious execution.
-
likely benign A developer tool shells out to black to format a file path.
Reasoning
A maintainer script runs black on a local path through a shell. The path comes from the developer's own tooling, not from untrusted input, so the risk is only a minor injection hygiene issue.
-
likely benign A second call in the same tool runs black through a shell on a local path.
Reasoning
This is the same maintainer-side call to black with shell=True on a local path. It is a build-tool convenience with no sign of a dropper or remote payload.
Reproduce This Scan
Run disclude locally to verify. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.
&&