cpp: model libpq query functions as SQL-injection sinks - #22449
Open
kumarak wants to merge 2 commits into
Open
Conversation
Add the PostgreSQL libpq query-execution functions as sql-injection sinks so cpp/sql-injection flags tainted data reaching their SQL text: - PQexec / PQsendQuery: query at argument 1 - PQexecParams / PQsendQueryParams: command at argument 1 - PQprepare / PQsendPrepare: query at argument 2 The *Prepared forms take a prepared-statement name rather than SQL text and are not modeled. Follows the existing Oracle.oci sink convention.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds libpq SQL-injection sink modeling for C/C++ PostgreSQL applications.
Changes:
- Models six synchronous and asynchronous libpq query APIs.
- Adds positive tests and a change note.
- Updates expected query results.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
cpp/ql/lib/ext/Postgres.model.yml |
Defines libpq SQL-injection sinks. |
cpp/ql/test/query-tests/Security/CWE/CWE-089/SqlTainted/test_libpq.c |
Exercises the new models. |
cpp/ql/test/query-tests/Security/CWE/CWE-089/SqlTainted/SqlTainted.expected |
Records expected alerts and models. |
cpp/ql/lib/change-notes/2026-08-27-libpq-sql-sinks.md |
Documents the added analysis support. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
jketema
reviewed
Aug 28, 2026
| --- | ||
| category: minorAnalysis | ||
| --- | ||
| * Added the PostgreSQL libpq query-execution functions (`PQexec`, `PQexecParams`, `PQprepare`, and their asynchronous `PQsendQuery`/`PQsendQueryParams`/`PQsendPrepare` counterparts) as `sql-injection` sinks, so the "Uncontrolled data used in SQL query" query flags tainted data reaching their command/query arguments. |
Contributor
There was a problem hiding this comment.
I'll just keep this short:
Suggested change
| * Added the PostgreSQL libpq query-execution functions (`PQexec`, `PQexecParams`, `PQprepare`, and their asynchronous `PQsendQuery`/`PQsendQueryParams`/`PQsendPrepare` counterparts) as `sql-injection` sinks, so the "Uncontrolled data used in SQL query" query flags tainted data reaching their command/query arguments. | |
| * Added the PostgreSQL libpq (asynchronous) query-execution functions `PQexec`, `PQexecParams`, `PQprepare`, `PQsendQuery`, `PQsendQueryParams`, `PQsendPrepare` as `sql-injection` sinks. |
Comment on lines
+1
to
+3
| // Test case for the PostgreSQL libpq SQL-injection sinks modeled in Postgres.model.yml. | ||
| // Associated with CWE-089: SQL injection. | ||
|
|
Contributor
There was a problem hiding this comment.
This is obvious from the name of the test and the location.
Suggested change
| // Test case for the PostgreSQL libpq SQL-injection sinks modeled in Postgres.model.yml. | |
| // Associated with CWE-089: SQL injection. |
Comment on lines
+7
to
+10
| # Functions that take a raw SQL command string. The `*Params`/`*Prepare` forms still | ||
| # interpret their command/query text as SQL, so injection into that text is a sink even | ||
| # though the parameter *values* are passed separately. The `*Prepared` forms take a | ||
| # prepared-statement name rather than SQL text and are therefore not modeled here. |
Contributor
There was a problem hiding this comment.
Given the nature of this file, this seems all pretty obvious and not adding much. I would shorten this to:
Suggested change
| # Functions that take a raw SQL command string. The `*Params`/`*Prepare` forms still | |
| # interpret their command/query text as SQL, so injection into that text is a sink even | |
| # though the parameter *values* are passed separately. The `*Prepared` forms take a | |
| # prepared-statement name rather than SQL text and are therefore not modeled here. | |
| # The `*Params`/`*Prepare` functions interpret their command/query text as SQL, | |
| # so injection into that text is a sink even though the parameter values are | |
| # passed separately. The `*Prepared` functions take a prepared-statement name | |
| # rather than SQL text and are therefore not modeled here. |
Trim the model-file comment and change note to house style, drop the redundant test header comment, and regenerate the expected results for the shifted line numbers.
Contributor
|
Looks like your changes broke Best way to fix this:
The first of these will make the test less fragile. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds SQL injection detection support for C/C++ code using the PostgreSQL libpq API. It models the SQL query arguments of PQexec, PQexecParams, PQprepare, PQsendQuery, PQsendQueryParams, and PQsendPrepare as sinks for the Uncontrolled data used in SQL queries.
It also adds tests covering both tainted and safe inputs for each modeled API, updates the expected results, and includes a change note documenting the new libpq modeling.