Skip to main content

SEC.AUTH.HBA_PARSE_ERROR — A line the server could not parse

  • Category: security
  • Severity: medium
  • Level: 0
  • Confidence: deterministic
  • Downtime class: none — the finding is about how the server authenticates, not about a statement
  • Stability: stable
  • Suites: audit
  • Applies to: PostgreSQL 18

The file says something the server is not doing​

pg_hba_file_rules reports a line PostgreSQL could not understand with an error and no fields. The view reads the file as it is on disk, and a file holding such a line is not loaded at all: a reload is refused as a whole, and the server keeps the rules it loaded before. A restart fails, because the server does not start on a file it cannot load. Measured on PostgreSQL 18.4, the log says pg_hba.conf was not reloaded and could not load pg_hba.conf.

So the consequence is quiet: neither the broken line nor any other edit in the same file is in force, and the server keeps authenticating by rules the file may no longer show.

# intended: tighten the app subnet to SCRAM, in place of an older md5 line
host  all  app  10.0.4.0/24  scram-sha-25       # typo, so the whole file is refused on reload
# …and the server keeps whatever it loaded before this edit, md5 included

Bad​

hst   all  all  10.0.0.0/8   scram-sha-256

Good​

host  all  all  10.0.0.0/8   scram-sha-256

Then reload and read the view back — the reload is what makes the fix take effect, and the view is what proves it:

SELECT pg_reload_conf();
SELECT rule_number, line_number, error FROM pg_hba_file_rules WHERE error IS NOT NULL;

Why the other checks go quiet on this line​

They report undetermined and point here, rather than judging the empty fields the server left behind. Both alternatives are wrong, in opposite directions: a broken trust line is in force nowhere, so flagging it would invent a hole, and whatever it was meant to restrict is not restricted, so clearing it would invent a wall.

An empty reading is not a clean server​

If pg_hba_file_rules answers without refusing and returns no rules at all, this check reports undetermined with the reason catalog_reading_implausible, once for the run. A PostgreSQL that had loaded no host-based authentication rules would accept no connections, and the audit arrived over one. The view reads the file, so it may be a file without entries, which the server refuses to load while it keeps the rules it had. Nothing about authentication has been checked: confirm which file the server is actually reading with SHOW hba_file before treating the run as clean.