Horton
Menu

Thread

  1. BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    PG Bug reporting form <noreply@postgresql.org> — 2025-02-18T08:21:47Z

    The following bug has been logged on the website:

Bug reference:      18817
Logged by:          Indrajeet Deshmukh
Email address:      bkindrajeeth@gmail.com
PostgreSQL version: 15.0
Operating system:   Linux
Description:        

Namaste Team,

During the integration of PostgreSQL Database v15 logs into a SIEM
solution,I observed that user passwords are logged in plaintext when a user
is created using the database command. This poses a serious security risk as
credentials could be exposed to unauthorized users who have access to the
logs.

Vendor: PostgreSQL
Product: PostgreSQL Database
Version: 15
Severity: High
Issue Type: Security Vulnerability

Steps to Reproduce:
Open the PostgreSQL Database CLI or execute the command via a script.
Run the following command to create a new user: 

CREATE USER indrajeet WITH PASSWORD 'indrajeet'

Check the database logs (/var/lib/pgsql/data/log). Below is the JSON log
generated when I used indrajeet as user name and indrajeet as password.

{"timestamp":"2025-02-18 08:11:38.557
UTC","user":"postgres","dbname":"postgres","pid":6069,"remote_host":"ip-100-66-2-217.ec2.internal","remote_port":53964,"session_id":"67b44074.17b5","line_num":4,"ps":"idle","session_start":"2025-02-18
08:10:28
UTC","vxid":"4/29","txid":0,"error_severity":"LOG","message":"statement:
CREATE USER indrajeet WITH PASSWORD
'indrajeet';","application_name":"psql","backend_type":"client
backend","query_id":0}

Expected Behavior: The password should be masked or excluded from logs to
prevent exposure.

Security Impact:
Confidentiality Violation: Anyone with access to logs can view user
passwords.
Risk of Credential Theft: Attackers or unauthorized users can leverage
exposed credentials for privilege escalation or lateral movement.
Compliance Issues: This may violate security policies and regulations (e.g.,
GDPR, PCI-DSS, ISO 27001).

Please do let me know if you need additional details from my side.

Thanks,
Indrajeet Deshmukh

  2. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    David Rowley <dgrowleyml@gmail.com> — 2025-02-18T12:21:04Z

    On Tue, 18 Feb 2025 at 22:51, PG Bug reporting form
<noreply@postgresql.org> wrote:
> During the integration of PostgreSQL Database v15 logs into a SIEM
> solution,I observed that user passwords are logged in plaintext when a user
> is created using the database command. This poses a serious security risk as
> credentials could be exposed to unauthorized users who have access to the
> logs.

> Steps to Reproduce:

> CREATE USER indrajeet WITH PASSWORD 'indrajeet'

There's some relevant discussion about this in [1], in particular, see [2].

David

[1] https://www.postgresql.org/message-id/flat/CALNJ-vRQB81F9Q9V%2BoDPsCTF-%2B0o_xR3%3D7_GAZfyg2sEaEfQJA%40mail.gmail.com#1f62ceb364243164a3d3a41530db055f
[2] https://www.postgresql.org/message-id/1250706.1658622457%40sss.pgh.pa.us

  3. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    Indrajeeth Deshmukh <bkindrajeeth@gmail.com> — 2025-02-18T12:52:36Z

    Namaste David,

Thanks for sharing the details. It looks like a valid issue and has not
been resolved yet. Currently, the solution is keeping the file remains
secure, but when it comes to SIEM monitoring, it will be a major concern.
Any thoughts on this?

Thanks,
Indrajeet Deshmukh

On Tue, Feb 18, 2025 at 5:51 PM David Rowley <dgrowleyml@gmail.com> wrote:

> On Tue, 18 Feb 2025 at 22:51, PG Bug reporting form
> <noreply@postgresql.org> wrote:
> > During the integration of PostgreSQL Database v15 logs into a SIEM
> > solution,I observed that user passwords are logged in plaintext when a
> user
> > is created using the database command. This poses a serious security
> risk as
> > credentials could be exposed to unauthorized users who have access to the
> > logs.
>
> > Steps to Reproduce:
>
> > CREATE USER indrajeet WITH PASSWORD 'indrajeet'
>
> There's some relevant discussion about this in [1], in particular, see [2].
>
> David
>
> [1]
> https://www.postgresql.org/message-id/flat/CALNJ-vRQB81F9Q9V%2BoDPsCTF-%2B0o_xR3%3D7_GAZfyg2sEaEfQJA%40mail.gmail.com#1f62ceb364243164a3d3a41530db055f
> [2]
> https://www.postgresql.org/message-id/1250706.1658622457%40sss.pgh.pa.us
>


-- 
Regards,
Indrajeet Deshmukh

  4. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    David G. Johnston <david.g.johnston@gmail.com> — 2025-02-18T14:37:30Z

    On Tuesday, February 18, 2025, PG Bug reporting form <noreply@postgresql.org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference:      18817
> Logged by:          Indrajeet Deshmukh
> Email address:      bkindrajeeth@gmail.com
> PostgreSQL version: 15.0
> Operating system:   Linux
> Description:
>
> Namaste Team,
>
> During the integration of PostgreSQL Database v15 logs into a SIEM
> solution,I observed that user passwords are logged in plaintext when a user
> is created using the database command. This poses a serious security risk
> as
> credentials could be exposed to unauthorized users who have access to the
> logs.
>
> Vendor: PostgreSQL
> Product: PostgreSQL Database
> Version: 15
> Severity: High
> Issue Type: Security Vulnerability
>
> Steps to Reproduce:
> Open the PostgreSQL Database CLI or execute the command via a script.
> Run the following command to create a new user:
>
> CREATE USER indrajeet WITH PASSWORD 'indrajeet'


The long-standing position here is that the encrypted password being found
in the logs is not a security issue needing fixing.  It’s maybe a bit
unfortunate that we provide both secure and insecure methods for setting or
changing a password but we do.  Use the secure methods.  Which means
compute the encrypted password off-server and send that instead of the
clear text version.

David J.

  5. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    Greg Sabino Mullane <htamfids@gmail.com> — 2025-02-18T14:38:38Z

    On Tue, Feb 18, 2025 at 9:17 AM Indrajeeth Deshmukh <bkindrajeeth@gmail.com>
wrote:

> Thanks for sharing the details. It looks like a valid issue and has not
> been resolved yet. Currently, the solution is keeping the file remains
> secure, but when it comes to SIEM monitoring, it will be a major concern.
> Any thoughts on this?
>

Other solutions:

1. Use Kerberos
2. Disallow password creation and altering, except via psql \password or
similar methods.
3. Disable logging when you are about to attempt a password change

-- 
Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

  6. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-02-18T15:37:52Z

    Indrajeeth Deshmukh <bkindrajeeth@gmail.com> writes:
> Thanks for sharing the details. It looks like a valid issue and has not
> been resolved yet. Currently, the solution is keeping the file remains
> secure, but when it comes to SIEM monitoring, it will be a major concern.
> Any thoughts on this?

The real bottom-line answer to that is that passwords are just the
tip of the iceberg.  The server log is likely to contain other
critical information depending on your application; consider credit
card numbers, HIPAA-protected medical details, etc.  The server
has no way at all to know which fields might be sensitive in that
way.  Even if we had some notion of which fields to hide, in cases
like statements with syntax errors, we couldn't reliably identify
which parts of a query string are sensitive.

The only solution is to treat the server log files with the same
amount of care as you give to the database files themselves.
Or send them to /dev/null, but that's unlikely to be very workable
in practice.

Independently of that, best practice is to never send cleartext
passwords to the server in the first place.  psql has support
for setting a password without that, and I think libpq does too.

			regards, tom lane

  7. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    Matthias Apitz <guru@unixarea.de> — 2025-02-19T05:57:52Z

    El día martes, febrero 18, 2025 a las 10:37:52 -0500, Tom Lane escribió:

> Indrajeeth Deshmukh <bkindrajeeth@gmail.com> writes:
> > Thanks for sharing the details. It looks like a valid issue and has not
> > been resolved yet. Currently, the solution is keeping the file remains
> > secure, but when it comes to SIEM monitoring, it will be a major concern.
> > Any thoughts on this?
> 
> The real bottom-line answer to that is that passwords are just the
> tip of the iceberg.  The server log is likely to contain other
> critical information depending on your application; consider credit
> card numbers, HIPAA-protected medical details, etc.  The server
> has no way at all to know which fields might be sensitive in that
> way.  Even if we had some notion of which fields to hide, in cases
> like statements with syntax errors, we couldn't reliably identify
> which parts of a query string are sensitive.
> 
> The only solution is to treat the server log files with the same
> amount of care as you give to the database files themselves.
> Or send them to /dev/null, but that's unlikely to be very workable
> in practice.
> 
> Independently of that, best practice is to never send cleartext
> passwords to the server in the first place.  psql has support
> for setting a password without that, and I think libpq does too.

What do I have to configure in the PostgreSQL server to get this
reproduced? I tried:

$ psql -Usisis testdb
psql (15.1, server 16.5)
WARNING: psql major version 15, server major version 16.
         Some psql features might not work.
Type "help" for help.

testdb=# CREATE USER bla WITH PASSWORD 'bla';
CREATE ROLE
testdb=#

and have nothing in the log:

$ tail /data/postgresql165/log/postgresql-2025-02-19_000000.log
...

2025-02-19 06:15:23.582 CET [1947] LOG:  checkpoint complete: wrote 1421 buffers (8.7%); 0 WAL file(s) added, 1 removed, 0 recycled; write=142.168 s, sync=0.003 s, total=142.186 s; sync files=57, longest=0.002 s, average=0.001 s; distance=18403 kB, estimate=18403 kB; lsn=5/72470898, redo lsn=5/7246F048

I even set 

log_statement = 'all'

and restarted the server - nothing.

The purpose of my question is to inform our 50++ PostgreSQL customers
what they must avoid...

Thanks

	matthias

-- 
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

  8. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-02-19T06:30:18Z

    Matthias Apitz <guru@unixarea.de> writes:
> What do I have to configure in the PostgreSQL server to get this
> reproduced? I tried:

[ scratches head... ]  Seems like you must be looking in the wrong
log file.  It works for me:

$ psql postgres
psql (18devel)
Type "help" for help.

postgres=# set log_statement = 'all';
SET
postgres=# CREATE USER bla WITH PASSWORD 'bla';
CREATE ROLE
postgres=# \q
$ tail .../postmaster.log
...
2025-02-19 01:19:18.638 EST [1949443] LOG:  statement: CREATE USER bla WITH PASSWORD 'bla';

If you're not running with log_statement = all, the most likely
scenario is a syntax error:

$ psql postgres
psql (18devel)
Type "help" for help.

postgres=# CREATE USER bla WITH PASWORD 'bla';
ERROR:  unrecognized role option "pasword"
LINE 1: CREATE USER bla WITH PASWORD 'bla';
                             ^
postgres=# \q
$ tail .../postmaster.log
...
2025-02-19 01:25:39.227 EST [1950440] ERROR:  unrecognized role option "pasword" at character 22
2025-02-19 01:25:39.227 EST [1950440] STATEMENT:  CREATE USER bla WITH PASWORD 'bla';

Of course, this command didn't do anything; but a person reading the
log would have a pretty strong clue what password you were about to
assign.  (And contrarily, Postgres itself would have no clue that
'bla' might be something that needs hiding.)

			regards, tom lane

  9. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    Daniel Westermann (DWE) <daniel.westermann@dbi-services.com> — 2025-02-19T06:39:56Z

    _______________________________________
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Wednesday, February 19, 2025 07:30
To: Matthias Apitz <guru@unixarea.de>
Cc: Indrajeeth Deshmukh <bkindrajeeth@gmail.com>; David Rowley <dgrowleyml@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs
 
Matthias Apitz <guru@unixarea.de> writes:
> What do I have to configure in the PostgreSQL server to get this
> reproduced? I tried:

export PGDATA=/var/tmp/xx; rm -rf $PGDATA; export PGPORT=8888; initdb; echo "logging_collector=on" >> $PGDATA/postgresql.auto.conf; echo "log_statement=ddl" >> $PGDATA/postgresql.auto.conf; pg_ctl start; psql <<< "create user u with password 'u'"; cat $PGDATA/log/*; pg_ctl stop

Regards
Daniel

  10. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    Laurenz Albe <laurenz.albe@cybertec.at> — 2025-02-19T08:58:17Z

    On Wed, 2025-02-19 at 06:57 +0100, Matthias Apitz wrote:
> What do I have to configure in the PostgreSQL server to get this
> reproduced? I tried:
> 
> $ psql -Usisis testdb
> psql (15.1, server 16.5)
> WARNING: psql major version 15, server major version 16.
>          Some psql features might not work.
> Type "help" for help.
> 
> testdb=# CREATE USER bla WITH PASSWORD 'bla';
> CREATE ROLE
> testdb=#
> 
> and have nothing in the log:
> 
> $ tail /data/postgresql165/log/postgresql-2025-02-19_000000.log
> ...
> 
> 2025-02-19 06:15:23.582 CET [1947] LOG:  checkpoint complete: wrote 1421 buffers (8.7%); 0 WAL file(s) added, 1 removed, 0 recycled; write=142.168 s, sync=0.003 s, total=142.186 s; sync files=57, longest=0.002 s, average=0.001 s; distance=18403 kB, estimate=18403 kB; lsn=5/72470898, redo lsn=5/7246F048
> 
> I even set 
> 
> log_statement = 'all'
> 
> and restarted the server - nothing.

Setting "log_statement" to "all", "mod" or "ddl" would do the trick.
You must have made some basic mistake.

Look at "pg_settings" what your current setting for "log_statement" is
and where it is coming from.

> The purpose of my question is to inform our 50++ PostgreSQL customers
> what they must avoid...

I'd call that an unfair bias against your younger customers.

Yours,
Laurenz Albe

-- 

*E-Mail Disclaimer*
Der Inhalt dieser E-Mail ist ausschliesslich fuer den 
bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat 
dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, 
dass jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder 
Weitergabe des Inhalts dieser E-Mail unzulaessig ist. Wir bitten Sie, sich 
in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.

*CONFIDENTIALITY NOTICE & DISCLAIMER
*This message and any attachment are 
confidential and may be privileged or otherwise protected from disclosure 
and solely for the use of the person(s) or entity to whom it is intended. 
If you have received this message in error and are not the intended 
recipient, please notify the sender immediately and delete this message and 
any attachment from your system. If you are not the intended recipient, be 
advised that any use of this message is prohibited and may be unlawful, and 
you must not copy this message or attachment or disclose the contents to 
any other person.

  11. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    Matthias Apitz <guru@unixarea.de> — 2025-02-19T10:00:31Z

    Am 19.02.2025 09:58, schrieb Laurenz Albe:
>> The purpose of my question is to inform our 50++ PostgreSQL customers
>> what they must avoid...
> 
> I'd call that an unfair bias against your younger customers.

With 50++ the number of the customer installations was meant, not the 
age.

      matthias

  12. Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

    Greg Sabino Mullane <htamfids@gmail.com> — 2025-02-19T17:48:47Z

    >
> testdb=# CREATE USER bla WITH PASSWORD 'bla';
> CREATE ROLE
>

Run these as well to help you debug:

SELECT pg_current_logfile();

SHOW log_statement;

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support