This vulnerability is an integer wraparound during pgvector's IVFFlat index build on 32-bit PostgreSQL. The counter overflow occurs at construction time, writing data at incorrect offsets within the index structure.
The EPSS score of 0.00343 is misleading if you only look at production 32-bit deployments—they're rare. But the actual attack surface sits elsewhere: development environments and CI/CD pipelines. Many AI/ML developers using pgvector work on resource-constrained systems where 32-bit builds remain common. When these developers run CREATE INDEX or REINDEX against IVFFlat indexes (the standard path for vector similarity search), they trigger the vulnerable code path.
The critical question is whether corruption persists to production. The overflow corrupts runtime memory during construction, but if it damages structural metadata—page headers, entry counts, or offset values that get flushed to disk—that corruption becomes permanent. A 64-bit production system loading an index built on 32-bit could encounter malformed metadata causing crashes, incorrect query results, or denial of service. The absence of explicit "on-disk corruption" language in the CVE reflects what was tested, not what necessarily persists.
What to check: identify any pgvector deployments where indexes were built on 32-bit systems and are now running on 64-bit. Run REINDEX on those indexes to rebuild them under 64-bit conditions—this is the definitive remediation. Audit CI/CD pipelines that run pgvector index operations; they often have weaker security postures than production and provide a high-value target for attackers seeking pipeline compromise. If you're on an older pgvector version (0.7.x or earlier), upgrade to 0.8.6 or later and reindex.
The EPSS score correctly reflects production exploitability but completely misses the supply-chain reachability: compromised dev infrastructure building indexes that production systems then load.