CVE-2026-73194 is a heap overflow in DBI's placeholder parsing where the ':N' branch passes input through atoi() without range validation. A value exceeding INT_MAX wraps silently to negative, which trivially satisfies the 99,999 placeholder limit added in version 1.650 — that limit exists, but only for positive numbers. This is not a missing check; it's a composition failure between two primitives that each work correctly in isolation.
The immediate risk: any code path that prepares statements with attacker-controlled SQL strings can trigger this. This includes ORM layers, query builders, and template systems that construct SQL from external input — they all call prepare() automatically, and the vulnerable code runs before your application logic can validate anything. You do not need to explicitly use ':N' syntax to be exposed; you only need to be downstream of code that processes untrusted input into SQL.
To assess your exposure: audit all prepare() and prepare_cached() calls for statement strings that originate anywhere other than hardcoded developer literals. ORM frameworks, dynamic query builders, and any system that concatenates user input into SQL are high-risk call sites. If DBI 1.650 or 1.651 is in your dependency tree and you're using any dynamic SQL construction, treat this as exploitable until a patch is available. The 1.650 limit fix addresses the resource exhaustion symptom from the original report but creates a false sense of remediation — negative numbers bypass it entirely.
Beyond patching, examine your DBI dependency chain. Frameworks like DBIx::Class, Rose::DB, or any template system that builds queries transitively depend on DBI and may be running vulnerable code in a context you didn't design. The atoi() usage in ':N' parsing is a known-insecure pattern flagged by CERT standards for nearly two decades — its presence suggests this code path hasn't seen security-hardening passes and may carry other similar assumptions about what inputs are 'reasonable'.