#17380: fix(imessage): reject non-numeric chat_id values to prevent silent misrouting
channel: imessage
stale
size: XS
trusted-contributor
Cluster:
Messaging Platform Improvements
## Problem
`parseChatTargetPrefixesOrThrow` uses `Number.parseInt(value, 10)` to parse `chat_id:` targets but only checks `Number.isFinite()` on the result. Since `parseInt` parses leading digits and ignores trailing characters, hex identifiers like `2ecba0e20f3a4299b0efb228a5990731` silently parse to `2`, routing messages to the wrong chat with no error.
## Fix
Add a strict `/^\d+$/` regex check before `parseInt` so non-numeric values throw a clear error suggesting `chat_identifier:` instead.
## Tests
Added two test cases:
- Hex identifier rejection (`chat_id:2ecba0e...`)
- Mixed alphanumeric rejection (`chat_id:12abc`)
All 12 tests in `targets.test.ts` pass.
Fixes #17362
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
This PR fixes a silent misrouting bug in `parseChatTargetPrefixesOrThrow` where `Number.parseInt("2ecba0e20f3a4299b0efb228a5990731", 10)` would return `2` (parsing only leading digits), causing messages to be routed to the wrong chat. The fix adds a strict `/^\d+$/` regex validation before calling `parseInt`, with a helpful error message suggesting `chat_identifier:` for non-numeric values.
- The fix in `parseChatTargetPrefixesOrThrow` is correct and well-tested
- Two new test cases cover hex identifier and mixed alphanumeric rejection
- **Issue found**: The sibling function `parseChatAllowTargetPrefixes` in the same file (lines 105-113) has the identical `parseInt` + `isFinite` vulnerability and was not updated — a hex `chat_id` in an `allowFrom` entry would still silently match the wrong chat
<h3>Confidence Score: 3/5</h3>
- The targeted fix is correct, but the same bug remains in the allowlist parsing path which could cause incorrect access control behavior.
- The fix for `parseChatTargetPrefixesOrThrow` is sound and well-tested. However, `parseChatAllowTargetPrefixes` in the same file has the identical vulnerability and was not addressed, meaning the parseInt leading-digits problem still exists in the allowlist code path. This is a partial fix.
- `src/imessage/target-parsing-helpers.ts` — the `parseChatAllowTargetPrefixes` function (lines 105-113) needs the same strict numeric validation applied.
<sub>Last reviewed commit: 6ede6e3</sub>
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#22168: fix(imessage): resolve group sessions without chat identifiers
by AIflow-Labs · 2026-02-20
76.1%
#18664: fix(imessage): honor groupConfig regardless of allowlistEnabled
by brandonwise · 2026-02-16
76.1%
#16548: fix(telegram): enhance chat_id validation and diagnostics
by tanujbhaud · 2026-02-14
75.6%
#18511: fix(signal): signal:-prefixed phone numbers fail target resolution ...
by yinghaosang · 2026-02-16
75.0%
#8648: fix: don't treat bare numeric Discord IDs as definitive target IDs
by dbottme · 2026-02-04
74.5%
#11178: fix: use Number.parseInt with explicit radix in parseDateToMs
by Yida-Dev · 2026-02-07
74.2%
#19916: fix: strict silent-reply detection to prevent false positives with ...
by hayoial · 2026-02-18
74.0%
#16733: fix(ui): avoid injected newlines when tool output is hidden
by jp117 · 2026-02-15
73.9%
#17070: fix(telegram): Outbound: ignore empty legacy target fields
by yhw2003 · 2026-02-15
73.9%
#18969: Fix #18864: Accept plain openid in qqbot message send
by jwchmodx · 2026-02-17
73.7%