Horton

Thread

Commits

  1. Clean up quoting of variable strings within replication commands.

  1. Do quoting more carefully in replication commands

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-12T18:01:50Z

    The security team received a report that pg_recvlogical was
careless about quoting --option arguments that are passed
into the START_REPLICATION command given to the server.  In
principle this'd allow an attacker to inject unwanted stuff
into START_REPLICATION's options.  However, we found it really
hard to envision a situation where somebody would be passing
strings obtained from untrustworthy sources to pg_recvlogical,
especially given that anything to do with replication already
requires pretty high privilege.  So we're electing to treat this
as a garden-variety bug rather than one requiring the CVE process.

Looking around revealed other places also being sloppy about
quoting strings inserted into replication commands, but the same
who-would-do-that argument applies to them too.  So here is a
patch that tries to clean all that up.

(I envision back-patching this all the way, but have not yet
looked at whether the back branches will require adjustments.)

			regards, tom lane

  2. Re: Do quoting more carefully in replication commands

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-06-12T19:13:52Z

    Hi,

On Fri, 12 Jun 2026 at 23:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> The security team received a report that pg_recvlogical was
> careless about quoting --option arguments that are passed
> into the START_REPLICATION command given to the server.  In
> principle this'd allow an attacker to inject unwanted stuff
> into START_REPLICATION's options.  However, we found it really
> hard to envision a situation where somebody would be passing
> strings obtained from untrustworthy sources to pg_recvlogical,
> especially given that anything to do with replication already
> requires pretty high privilege.  So we're electing to treat this
> as a garden-variety bug rather than one requiring the CVE process.
>
> Looking around revealed other places also being sloppy about
> quoting strings inserted into replication commands, but the same
> who-would-do-that argument applies to them too.  So here is a
> patch that tries to clean all that up.
>
> (I envision back-patching this all the way, but have not yet
> looked at whether the back branches will require adjustments.)
>

Thanks for the patch!

I looked at the patch and big +1 on handling quoting wherever
feasible rather than depending on some parent or child function to do that.

Not only does the patch fix quoting, it also fixes some
workflows (it is on the right side, so I think adding a test
is optional though some ERROR / behaviour would change,
for example some earlier "Syntax error" would fall through
the whole function).

$ pg_receivewal -D wal --slot=999 --no-sync
pg_receivewal: error: could not send replication command
"READ_REPLICATION_SLOT": ERROR:  syntax error
pg_receivewal: disconnected; waiting 5 seconds to try again
pg_receivewal: error: could not send replication command
"READ_REPLICATION_SLOT": ERROR:  syntax error
[loops]

The above works fine post the patch. Even for libpqwalreceiver
issue when publication_names containing a backslash, as mentioned
in your patch commit, earlier subscription used to be permanently stuck due
to that addition of E.

All in all, I did not find any issues with the patch, lgtm.

Regards,
Ayush

  3. Re: Do quoting more carefully in replication commands

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-06-12T21:02:05Z

    On 2026-Jun-12, Tom Lane wrote:

> (I envision back-patching this all the way, but have not yet
> looked at whether the back branches will require adjustments.)

In a quick skim, I wondered about this bit:

> + * Caution: this quoting logic is sufficient for identifiers and literals
> + * in the replication grammar, but not always in regular SQL.  Specifically,
> + * it'd fail for a string literal if standard_conforming_strings is off.

... given that standard_conforming_strings can no longer be off in 19.
The backpatched version should surely still have this, just in case, but
in 19 it's probably not needed.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was
amazing when I first started using it at 7.2, and I'm continually astounded by
learning new features and techniques made available by the continuing work of
the development team."
Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php

  4. Re: Do quoting more carefully in replication commands

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-12T21:24:05Z

    =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> In a quick skim, I wondered about this bit:

>> + * Caution: this quoting logic is sufficient for identifiers and literals
>> + * in the replication grammar, but not always in regular SQL.  Specifically,
>> + * it'd fail for a string literal if standard_conforming_strings is off.

> ... given that standard_conforming_strings can no longer be off in 19.
> The backpatched version should surely still have this, just in case, but
> in 19 it's probably not needed.

There are assorted places in the backend that want to generate SQL
that will work against older versions.  I don't think we can forget
about standard_conforming_strings until all those versions are off
even the support-back-to list, ie about 10 years from now.

			regards, tom lane

  5. Re: Do quoting more carefully in replication commands

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-15T19:36:57Z

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> writes:
> All in all, I did not find any issues with the patch, lgtm.

Pushed, thanks for reviewing.

			regards, tom lane