dbcve.org
SQL InjectionWeakness · CWE-89

CVE-2026-60090

CRITICAL · 9.8 CVSS v3.1 Published 2026-07-11
Patch available
A vendor patch is available. No clean upgrade release — apply the published patch.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click Patch available 6 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
PraisonAI before 4.6.78 fails to validate the caller-controlled dimension argument in the PGVector and Cassandra knowledge-store create_collection() backends. Although schema, keyspace, and collection-name identifiers are validated, the dimension value (declared as int but not enforced at runtime) is interpolated directly into the vector column of the generated CREATE TABLE DDL. A caller able to influence collection-creation dimensions can pass a string such as '3); DROP TABLE tenant_secrets; --' to inject SQL/CQL tokens into the statement executed by the database driver.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

PraisonAI before 4.6.78 fails to validate the dimension parameter in create_collection() for PGVector and Cassandra backends. The dimension value, declared as int but not enforced at runtime, is directly interpolated into CREATE TABLE DDL statements without sanitization, enabling SQL/CQL injection.

MitigationUpgrade to PraisonAI 4.6.78 or later which implements proper input validation for the dimension parameter. As a workaround, enforce integer type validation on all dimension inputs before DDL generation.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Check installed PraisonAI version
    Run 'pip show praisonai' or check your package manager for the installed version number
    Affected if The installed version is lower than 4.6.78 (e.g., 4.6.77, 4.6.0, etc.)
  2. Identify vector store backend in use
    Inspect your PraisonAI configuration or code for the vector store type being instantiated (look for 'PGVector' or 'Cassandra' in your setup files, environment variables, or runtime logs)
    Affected if The configuration specifies PGVector or Cassandra as the vector database backend
  3. Locate create_collection calls in your codebase
    Search source code for 'create_collection' function calls and examine how the dimension parameter is passed (grep -r 'create_collection' or similar)
    Affected if Your code calls create_collection() with a dimension parameter that could be influenced by user input
  4. Inspect dimension parameter handling in source code
    Examine the PraisonAI library source (site-packages/praisonai/) for the create_collection method implementation in PGVector/Cassandra backends, specifically looking for dimension parameter usage in DDL statements
    Affected if The dimension value is directly interpolated into CREATE TABLE/CREATE KEYSPACE DDL strings without type checking or sanitization (e.g., f'CREATE TABLE ... ({dimension})' or similar string formatting)
  5. Verify type enforcement on dimension input
    Check if the dimension parameter undergoes integer type validation before being used in DDL generation - look for isinstance(dimension, int) or equivalent type checks in the code path
    Affected if No integer type validation exists, or the validation can be bypassed (e.g., dimension passed as string that gets interpolated directly)

You are affected if you run PraisonAI versions before 4.6.78 with PGVector or Cassandra backends, and your create_collection() implementation lacks proper integer type validation on the dimension parameter before DDL interpolation.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Patch available Apply the vendor patch
Vendor patch github.com →
Interim mitigation

Upgrade to PraisonAI 4.6.78 or later which implements proper input validation for the dimension parameter. As a workaround, enforce integer type validation on all dimension inputs before DDL generation.

Recommended fix High confidence

PraisonAI 4.6.78 or later

  1. Identify the PraisonAI installation directory
  2. Check the current PraisonAI version (e.g., via pip show praisonai or package.json)
  3. Upgrade to version 4.6.78 or later using: pip install praisonai>=4.6.78 or pip install --upgrade praisonai
  4. Verify the upgrade was successful and the dimension parameter is now properly validated as an integer in create_collection()

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation2.0 h
  • Implementation3.0 h
  • Testing3.0 h
  • Review / QA2.0 h
10.0 hours of engineering $1,750
Get the patch applied

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,800.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-60090 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-60090 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data