Short answer: pgvector 0.8.7, released on 5 October 2026, fixes a buffer overflow when building IVFFlat indexes. The advisory lists versions 0.8.6 and earlier as affected and says a database user who can create an IVFFlat index can write out of bounds, which can lead to arbitrary code execution. Upgrading is two steps: install the new package, then run ALTER EXTENSION vector UPDATE in each database. In the lab below, existing IVFFlat and HNSW indexes stayed valid and returned the same results after both steps.

The lab ran PostgreSQL 18.6 with the official pgvector/pgvector 0.8.6 and 0.8.7 images sharing one data directory, the same as upgrading the package on a server. It does not reproduce the overflow. The script and full output are public.

Check what you are running

Two versions matter: the package on the server, and the version installed in each database. They can differ.

SELECT name, default_version, installed_version
FROM pg_available_extensions WHERE name = 'vector';

-- After installing the 0.8.7 package, before ALTER EXTENSION:
  name  | default_version | installed_version
--------+-----------------+-------------------
 vector | 0.8.7           | 0.8.6

default_version is what the server's package can install; installed_version is what this database's catalog says. Run it in every database where the extension exists, not only the one your application uses.

What the upgrade did to existing indexes

A 100,000-row table with an IVFFlat index and an HNSW index, built on 0.8.6. After the 0.8.7 package was installed, before the catalog update, the planner still used the IVFFlat index and returned the same five nearest neighbours. Then:

ALTER EXTENSION vector UPDATE TO '0.8.7';
Time: 1.792 ms

   index    | indisvalid | indisready
------------+------------+------------
 items_pkey | t          | t
 items_ivf  | t          | t
 items_hnsw | t          | t

-- Nearest five to id 42, via the index and exact (no vector index):
 42, 69157, 31458, 37741, 62874
 42, 69157, 31458, 37741, 62874

The catalog update took under 2 ms and no index needed rebuilding here. The advisory does not say whether indexes built on an affected version should be rebuilt, so if untrusted roles could have built IVFFlat indexes before you upgraded, treat that as a separate review question.

Who could trigger it

The advisory's condition is the ability to create an IVFFlat index. Creating an index requires owning the table, and any role that can create a table can create its own table with a vector column. So the question is which login roles can create tables:

SELECT r.rolname, r.rolsuper,
       (SELECT string_agg(n.nspname, ', ') FROM pg_namespace n
         WHERE n.nspname NOT LIKE 'pg\_%' AND n.nspname <> 'information_schema'
           AND has_schema_privilege(r.oid, n.oid, 'CREATE')) AS can_create_in
FROM pg_roles r WHERE r.rolcanlogin ORDER BY 1;

 rolname  | rolsuper | can_create_in
----------+----------+---------------
 analyst  | f        |
 app_rw   | f        |
 postgres | t        | public

On this new PostgreSQL 18 cluster, only the superuser could create tables. That is the default since PostgreSQL 15. On PostgreSQL 14 and earlier, every role can create tables in public, and the PostgreSQL 15 release notes state that upgrading a cluster or restoring a dump keeps those old permissions. A database that started on 14 or earlier may still allow it after an upgrade. Check, and if no application role needs it:

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

Test that on a copy first: migrations, ORMs and reporting tools sometimes create temporary or helper tables in public.

On RDS, Aurora and other managed services

You cannot install a pgvector package yourself; the provider ships it with an engine minor version. At the time of writing, AWS's RDS extension versions page did not list 0.8.7. Until it does:

  • Run the version query above to see what your engine offers. If default_version is newer than installed_version, run ALTER EXTENSION vector UPDATE.
  • Restrict which roles can create tables, as above. That narrows who could build an IVFFlat index.
  • Watch the provider's release notes for an engine minor version with 0.8.7, then upgrade the minor version and run the extension update. AWS notes that engine upgrades do not update extensions automatically.

Checklist

  1. Query pg_available_extensions in every database that has vector.
  2. List login roles that can create tables; revoke CREATE on public from PUBLIC where nothing needs it.
  3. Self-managed: install the 0.8.7 package, restart if your packaging requires it, then ALTER EXTENSION vector UPDATE in each database.
  4. Managed: upgrade to an engine minor version that ships 0.8.7 when one is available, then run the extension update.
  5. Confirm indisvalid on vector indexes and compare a few nearest-neighbour results with exact search.

If you are choosing between index types while you are here, see HNSW vs IVFFlat, and for filtered queries returning too few rows, filtered vector search.

Frequently asked questions

Which pgvector versions are affected by CVE-2026-103484?

Versions 0.8.6 and earlier. The fix is in pgvector 0.8.7, released on 5 October 2026.

Who can trigger the vulnerability?

According to the advisory, a database user with the ability to create an IVFFlat index. Creating an index requires owning the table, so in practice any role that can create a table in some schema.

I only use HNSW indexes. Do I still need to upgrade?

Yes. The overflow is in IVFFlat index builds, and any role that can create a table can build an IVFFlat index on it whether or not your application uses IVFFlat.

How do I check which pgvector version I am running?

Run SELECT name, default_version, installed_version FROM pg_available_extensions WHERE name = 'vector' in each database. default_version is what the server package can install; installed_version is what that database uses.

Do I need to rebuild vector indexes after upgrading to 0.8.7?

In the lab, IVFFlat and HNSW indexes stayed valid after the upgrade and returned the same nearest neighbours as exact search. The advisory does not say whether indexes built on an affected version should be rebuilt.

Does the upgrade cause downtime?

ALTER EXTENSION vector UPDATE took under 2 milliseconds in the lab. Installing the new package on a self-managed server may need a restart depending on your packaging; on managed services the extension arrives with an engine minor version upgrade.

Is pgvector 0.8.7 available on Amazon RDS and Aurora?

AWS's RDS extension versions page did not list it when checked on 27 October 2026. Until it does, restrict which roles can create tables and watch the release notes for an engine minor version that includes it.

Why does PostgreSQL 14 matter here?

Before PostgreSQL 15, every role could create tables in the public schema, and upgrading or restoring a dump keeps those permissions. A database that started on 14 or earlier may still let every role create tables, and therefore IVFFlat indexes.