AntFleet

Disagreement · 5bbcd2d3-openai-2

Allowlist comparisons use normalized lists but compare against unnormalized candidates (can mis-block/allow DMs/groups)

mismatch
repo 5149da9d·PR #3·reviewed 2 days ago

Primary finding

Allowlist comparisons use normalized lists but compare against unnormalized candidates (can mis-block/allow DMs/groups)

highbughigh
  • src/web/inbound/access-control.ts:70-74
  • src/web/inbound/access-control.ts:142-147
  • src/web/inbound/access-control.ts:75-79
  • src/web/inbound/access-control.ts:106-109
  • src/web/inbound/access-control.ts:58-59
The allowlists are normalized (digits-only) but comparisons use unnormalized candidates (params.from and params.senderE164). Formatting differences (e.g., leading '+', spaces) will cause includes() to fail, incorrectly blocking legitimate senders or allowing mismatches depending on data shape. Similarly, isSamePhone uses raw string equality and may misclassify the same phone due to formatting differences.

Recommendation

Normalize candidates before comparison: - For DMs: const candidate = normalizeE164(params.from); - For groups: const candidateSender = params.senderE164 ? normalizeE164(params.senderE164) : null; - For same-phone checks: compare normalizeE164(params.from) with normalizeE164(params.selfE164 ?? "").

Counterpart finding

Group allowlist comparison uses raw senderE164 against normalized allowlist

mediumbughigh
  • src/web/inbound/access-control.ts:79-92
  • src/web/inbound/access-control.ts:117-119
`normalizedGroupAllowFrom` is built by passing each entry through `normalizeE164`, but the membership check compares against the raw `params.senderE164` without normalizing it. If the configured allowlist contains values like `+1 555-111-2222` (which normalize to e.g. `15551112222`) but the inbound senderE164 already arrives as `15551112222`, this may work coincidentally; but if the formats differ (config with `+`, sender without, or vice versa) the check will reject legitimate senders. The DM path is consistent because it also compares `params.from` (which is the raw form) — but the asymmetry is identical: normalized list vs. raw candidate. The author clearly intended to normalize both sides.

Recommendation

Compare against `normalizeE164(params.senderE164)` (and likewise normalize `candidate` for the DM path) so both sides of the comparison are in the same canonical form.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →

From the same review

These findings passed the unanimous gate on the same PR review. The disagreement above was filtered out; the findings below were posted.

← back to all disagreementsview public receiptssee unanimous findings + anatomies →
Tweet ↗