Summary
onefetch's "Version" field falls back to a project manifest's (package.json/Cargo.toml) version field when the repository has no git tags, and the "Project" field's repo name falls back to the manifest's name field when the repository has no configured remote. Both are parsed with standards-compliant parsers and displayed via InfoField::style_value (src/info/utils/info_field.rs) with no filtering of control characters. Since a manifest's string field has no character restrictions, and running onefetch on a directory is the tool's entire purpose, any escape sequence embedded in these fields is written to the terminal and interpreted live.
POC
(available upon request)
Impact
I validated this by creating a git repository with no tags and a package.json whose version field contained a JSON-escaped OSC title-set sequence, then running onefetch on it inside a tmux session and capturing the literal byte stream written to the pty via tmux pipe-pane (which taps the raw bytes before tmux's own screen-buffer interpretation) and inspecting it as a hex dump. The captured stream contained the exact injected sequence, unmodified, directly adjacent to the version text, confirming it reaches the terminal without any stripping. I used a benign title-set marker specifically to confirm the sequence reaches output unstripped, rather than a more aggressive payload; the specific range of what an injected OSC/CSI sequence can do depends on the victim's terminal emulator and was not enumerated further.
Suggested Fix
Strip control characters, particularly the ESC byte, from a field's value before it's styled and written to the terminal. I'd suggest fixing this in InfoField::style_value, the single point every field already passes through, rather than only in the version field used to demonstrate this, since the project-name fallback has the same root cause and any future manifest-derived field would otherwise reintroduce the same gap.
Summary
onefetch's "Version" field falls back to a project manifest's (
package.json/Cargo.toml)versionfield when the repository has no git tags, and the "Project" field's repo name falls back to the manifest'snamefield when the repository has no configured remote. Both are parsed with standards-compliant parsers and displayed viaInfoField::style_value(src/info/utils/info_field.rs) with no filtering of control characters. Since a manifest's string field has no character restrictions, and runningonefetchon a directory is the tool's entire purpose, any escape sequence embedded in these fields is written to the terminal and interpreted live.POC
(available upon request)
Impact
I validated this by creating a git repository with no tags and a
package.jsonwhoseversionfield contained a JSON-escaped OSC title-set sequence, then runningonefetchon it inside a tmux session and capturing the literal byte stream written to the pty viatmux pipe-pane(which taps the raw bytes before tmux's own screen-buffer interpretation) and inspecting it as a hex dump. The captured stream contained the exact injected sequence, unmodified, directly adjacent to the version text, confirming it reaches the terminal without any stripping. I used a benign title-set marker specifically to confirm the sequence reaches output unstripped, rather than a more aggressive payload; the specific range of what an injected OSC/CSI sequence can do depends on the victim's terminal emulator and was not enumerated further.Suggested Fix
Strip control characters, particularly the ESC byte, from a field's value before it's styled and written to the terminal. I'd suggest fixing this in
InfoField::style_value, the single point every field already passes through, rather than only in the version field used to demonstrate this, since the project-name fallback has the same root cause and any future manifest-derived field would otherwise reintroduce the same gap.