pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedPossible command-injection or meta-command execution in `psql` input
4+ messages / 4 participants
[nested] [flat]
* Possible command-injection or meta-command execution in `psql` input
@ 2026-09-26 08:27 PG Doc comments form <noreply@postgresql.org>
0 siblings, 3 replies; 4+ messages in thread
From: PG Doc comments form @ 2026-09-26 08:27 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: y.saburov@gmail.com
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/18/index.html
Description:
AI generated ))
## Summary
The following SQL statement contains an unquoted regular-expression-like
expression:
```sql
db=# WITH products (id, name, price, action) AS
(
VALUES
(1, 'apple', 100, '...')
, (2, 'banana', 200, '...')
, (3, 'orange', 150, '...')
, (4, 'potato', 80, '...')
, (5, 'tomato', 120, '...')
)
SELECT
p.id
, p.name
, p.price
, p.action
FROM products AS p
WHERE regexp_like(p.action, ((?<!-)\d+))
;
```
The observed output is:
```text
List of relations
Schema | Name | Type | Owner | Persistence | Access method |
Size | Description
--------+----------------+-------+----------+-------------+---------------+------------+-------------
public | inventory_item | table | postgres | permanent | heap | 16 kB |
public | mytab | table | postgres | permanent | heap | 16 kB |
public | on_hand | table | postgres | permanent | heap | 16 kB |
public | suppliers | table | postgres | permanent | heap | 8192 bytes
|
public | test_table | table | postgres | permanent | heap | 16 kB |
public | users | table | postgres | permanent | heap | 16 kB |
(6 rows)
db(#
```
The expected result of the SQL query would be either:
```text
ERROR: invalid regular expression: parentheses () not balanced
```
or a normal result set from the `SELECT`.
Instead, the output contains a relation listing followed by the continuation
prompt:
```text
db(#
```
## Security concern
The relation listing resembles the output of a `psql` meta-command such as:
```psql
\d
```
or:
```psql
\dt
```
The displayed output is not a normal result of the `SELECT` statement shown
above. The query does not select from the system catalog and does not
contain any statement that would produce a `List of relations` table.
This raises the following questions:
1. Why does the input produce `psql` meta-command output?
2. Was a `psql` backslash command such as `\d` or `\dt` executed during
processing?
3. Is the regular-expression text being interpreted as `psql` input or as
SQL text?
4. Can other `psql` meta-commands be injected or executed in the same
context?
5. Are the SQL parser, the `psql` client parser, and the regular-expression
parser processing the input in the expected order?
6. Are there any restrictions on which backslash commands can be executed?
7. Can this behavior expose database metadata or execute other client-side
commands?
The concern is not limited to the meaning of `\d+` inside a regular
expression. If the observed relation listing was actually generated while
processing this input, then the behavior may indicate that input intended to
be a regular expression is reaching the `psql` command interpreter or
another command-processing layer.
In that case, it should be verified whether other `psql` meta-commands can
also be executed.
## Reproduction query
```sql
WITH products (id, name, price, action) AS
(
VALUES
(1, 'apple', 100, '...')
, (2, 'banana', 200, '...')
, (3, 'orange', 150, '...')
, (4, 'potato', 80, '...')
, (5, 'tomato', 120, '...')
)
SELECT
p.id
, p.name
, p.price
, p.action
FROM products AS p
WHERE regexp_like(p.action, ((?<!-)\d+))
;
```
## Control query
When the regular expression is passed as a proper SQL string literal, the
query should be parsed normally:
```sql
WITH products (id, name, price, action) AS
(
VALUES
(1, 'apple', 100, '...')
, (2, 'banana', 200, '...')
, (3, 'orange', 150, '...')
, (4, 'potato', 80, '...')
, (5, 'tomato', 120, '...')
)
SELECT
p.id
, p.name
, p.price
, p.action
FROM products AS p
WHERE regexp_like(p.action, $$((?<!-)\d+)$$);
```
or:
```sql
WHERE regexp_like(p.action, '((?<!-)\d+)');
```
These control queries do not contain any `psql` meta-command and should not
produce a `List of relations` output.
## Additional observation
The prompt:
```text
db(#
```
indicates that `psql` is waiting for additional input because it considers
the current command incomplete.
The following output:
```text
List of relations
```
does not appear to be generated by the `SELECT` statement itself. It is
normally associated with a `psql` inspection command such as `\d` or `\dt`.
Therefore, the full behavior should be investigated as a possible issue in
command parsing, input sanitization, or interaction between the SQL parser
and the `psql` client parser.
## Expected behavior
The input should be handled consistently as one of the following:
1. A SQL syntax error should be returned because the regular-expression
argument is not a valid SQL string literal; or
2. The expression should be passed to the regular-expression parser and
produce a regular-expression error.
It should not execute or display the result of an unrelated `psql`
meta-command.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Possible command-injection or meta-command execution in `psql` input
@ 2026-09-28 12:51 Laurenz Albe <laurenz.albe@cybertec.at>
parent: PG Doc comments form <noreply@postgresql.org>
2 siblings, 0 replies; 4+ messages in thread
From: Laurenz Albe @ 2026-09-28 12:51 UTC (permalink / raw)
To: y.saburov@gmail.com; pgsql-docs@lists.postgresql.org
On Sat, 2026-09-26 at 08:27 +0000, PG Doc comments form wrote:
> AI generated ))
Then please validate the generated stuff rather than creating
extra work.
> The following SQL statement contains an unquoted regular-expression-like
> expression:
>
> db=# WITH products (id, name, price, action) AS
> (
> VALUES
> (1, 'apple', 100, '...')
> , (2, 'banana', 200, '...')
> , (3, 'orange', 150, '...')
> , (4, 'potato', 80, '...')
> , (5, 'tomato', 120, '...')
> )
> SELECT
> p.id
> , p.name
> , p.price
> , p.action
> FROM products AS p
> WHERE regexp_like(p.action, ((?<!-)\d+))
> ;
>
> [the complaint is that you get a list of tables rather than a result]
There is no bug there. The statement is *not* a regular expression,
because the single quotes around the string literal are missing.
As a consequence, a metacommand (\d+) is executed. That "swallows"
the two closing parentheses, and psql prompts you to close the two
parentheses and end the statement. If you do that, you get the
syntax error you deserve.
In short: garbage in, garbage out. No bug.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Possible command-injection or meta-command execution in `psql` input
@ 2026-09-28 12:56 Matemática A3K <matematica.a3k@gmail.com>
parent: PG Doc comments form <noreply@postgresql.org>
2 siblings, 0 replies; 4+ messages in thread
From: Matemática A3K @ 2026-09-28 12:56 UTC (permalink / raw)
To: y.saburov@gmail.com; pgsql-docs@lists.postgresql.org
There seems not to be an AI-generated submission policy yet, even if there
is one, this submission is the non-sense of a stochastic parrot and
therefore inapplicable.
As an initial proposal for that policy, I propose the following:
- Instruct your agents not to submit content automatically.
No AI-generated content is considered useful unless it is validated by a
human, therefore restrain from submitting under these conditions as it
over-stresses the scarce human resources the project depends on
unnecessarily. Contribute by not generating that signal.
May needs further refinement, it can be placed in
https://wiki.postgresql.org/wiki/Developer_FAQ#Getting_Involved so it can
be pointed out when it happens.
On Mon, Sep 28, 2026 at 5:10 AM PG Doc comments form <noreply@postgresql.org>
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/18/index.html
> Description:
>
> AI generated ))
>
> ## Summary
>
> The following SQL statement contains an unquoted regular-expression-like
> expression:
>
> ```sql
> db=# WITH products (id, name, price, action) AS
> (
> VALUES
> (1, 'apple', 100, '...')
> , (2, 'banana', 200, '...')
> , (3, 'orange', 150, '...')
> , (4, 'potato', 80, '...')
> , (5, 'tomato', 120, '...')
> )
> SELECT
> p.id
> , p.name
> , p.price
> , p.action
> FROM products AS p
> WHERE regexp_like(p.action, ((?<!-)\d+))
> ;
> ```
>
> The observed output is:
>
> ```text
> List of relations
> Schema | Name | Type | Owner | Persistence | Access method |
> Size | Description
>
> --------+----------------+-------+----------+-------------+---------------+------------+-------------
> public | inventory_item | table | postgres | permanent | heap | 16 kB |
> public | mytab | table | postgres | permanent | heap | 16 kB |
> public | on_hand | table | postgres | permanent | heap | 16 kB |
> public | suppliers | table | postgres | permanent | heap | 8192 bytes
> |
> public | test_table | table | postgres | permanent | heap | 16 kB |
> public | users | table | postgres | permanent | heap | 16 kB |
> (6 rows)
>
> db(#
> ```
>
> The expected result of the SQL query would be either:
>
> ```text
> ERROR: invalid regular expression: parentheses () not balanced
> ```
>
> or a normal result set from the `SELECT`.
>
> Instead, the output contains a relation listing followed by the
> continuation
> prompt:
>
> ```text
> db(#
> ```
>
> ## Security concern
>
> The relation listing resembles the output of a `psql` meta-command such as:
>
> ```psql
> \d
> ```
>
> or:
>
> ```psql
> \dt
> ```
>
> The displayed output is not a normal result of the `SELECT` statement shown
> above. The query does not select from the system catalog and does not
> contain any statement that would produce a `List of relations` table.
>
> This raises the following questions:
>
> 1. Why does the input produce `psql` meta-command output?
> 2. Was a `psql` backslash command such as `\d` or `\dt` executed during
> processing?
> 3. Is the regular-expression text being interpreted as `psql` input or as
> SQL text?
> 4. Can other `psql` meta-commands be injected or executed in the same
> context?
> 5. Are the SQL parser, the `psql` client parser, and the regular-expression
> parser processing the input in the expected order?
> 6. Are there any restrictions on which backslash commands can be executed?
> 7. Can this behavior expose database metadata or execute other client-side
> commands?
>
> The concern is not limited to the meaning of `\d+` inside a regular
> expression. If the observed relation listing was actually generated while
> processing this input, then the behavior may indicate that input intended
> to
> be a regular expression is reaching the `psql` command interpreter or
> another command-processing layer.
>
> In that case, it should be verified whether other `psql` meta-commands can
> also be executed.
>
> ## Reproduction query
>
> ```sql
> WITH products (id, name, price, action) AS
> (
> VALUES
> (1, 'apple', 100, '...')
> , (2, 'banana', 200, '...')
> , (3, 'orange', 150, '...')
> , (4, 'potato', 80, '...')
> , (5, 'tomato', 120, '...')
> )
> SELECT
> p.id
> , p.name
> , p.price
> , p.action
> FROM products AS p
> WHERE regexp_like(p.action, ((?<!-)\d+))
> ;
> ```
>
> ## Control query
>
> When the regular expression is passed as a proper SQL string literal, the
> query should be parsed normally:
>
> ```sql
> WITH products (id, name, price, action) AS
> (
> VALUES
> (1, 'apple', 100, '...')
> , (2, 'banana', 200, '...')
> , (3, 'orange', 150, '...')
> , (4, 'potato', 80, '...')
> , (5, 'tomato', 120, '...')
> )
> SELECT
> p.id
> , p.name
> , p.price
> , p.action
> FROM products AS p
> WHERE regexp_like(p.action, $$((?<!-)\d+)$$);
> ```
>
> or:
>
> ```sql
> WHERE regexp_like(p.action, '((?<!-)\d+)');
> ```
>
> These control queries do not contain any `psql` meta-command and should not
> produce a `List of relations` output.
>
> ## Additional observation
>
> The prompt:
>
> ```text
> db(#
> ```
>
> indicates that `psql` is waiting for additional input because it considers
> the current command incomplete.
>
> The following output:
>
> ```text
> List of relations
> ```
>
> does not appear to be generated by the `SELECT` statement itself. It is
> normally associated with a `psql` inspection command such as `\d` or `\dt`.
>
> Therefore, the full behavior should be investigated as a possible issue in
> command parsing, input sanitization, or interaction between the SQL parser
> and the `psql` client parser.
>
> ## Expected behavior
>
> The input should be handled consistently as one of the following:
>
> 1. A SQL syntax error should be returned because the regular-expression
> argument is not a valid SQL string literal; or
> 2. The expression should be passed to the regular-expression parser and
> produce a regular-expression error.
>
> It should not execute or display the result of an unrelated `psql`
> meta-command.
>
>
>
>
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Possible command-injection or meta-command execution in `psql` input
@ 2026-09-28 15:02 David G. Johnston <david.g.johnston@gmail.com>
parent: PG Doc comments form <noreply@postgresql.org>
2 siblings, 0 replies; 4+ messages in thread
From: David G. Johnston @ 2026-09-28 15:02 UTC (permalink / raw)
To: y.saburov@gmail.com <y.saburov@gmail.com>; pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
On Saturday, September 26, 2026, PG Doc comments form <
noreply@postgresql.org> wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/18/index.html
> Description:
>
> AI generated ))
>
> ## Summary
>
> The following SQL statement contains an unquoted regular-expression-like
> expression:
This is the wrong place to get help with using PostgreSQL or to report bugs.
I don’t really care if you use AI to help write such a report - but this
particular one seems excessively long and repetitive. I’d also be a bit
surprised if AI couldn’t explain why you see the behavior that you do.
And hopefully AI would tell you that if you write SQL with syntax errors
there is usually no predicable way to know exactly what the failure mode
will look like nor is there usually much desire to try and control it.
This is why you have to test the code that you write; making sure at
minimum the happy path is functioning. You have to trust the people who
can send SQL to your server. You can limit their rights but just
connecting gives a decent amount of ability to cause grief. These are not
security issues.
David J.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-09-28 15:02 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-26 08:27 Possible command-injection or meta-command execution in `psql` input PG Doc comments form <noreply@postgresql.org>
2026-09-28 12:51 ` Laurenz Albe <laurenz.albe@cybertec.at>
2026-09-28 12:56 ` Matemática A3K <matematica.a3k@gmail.com>
2026-09-28 15:02 ` David G. Johnston <david.g.johnston@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox