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 consequence is quiet: the line authenticates nobody, so the next matching line decides who gets in. A file whose author believes it contains a narrow rule may be running on the broad one below it.

# intended: only the app subnet, and only with SCRAM
host  all  app  10.0.4.0/24  scram-sha-25       # typo — rejected, so this line does nothing
host  all  all  0.0.0.0/0    md5                # …and this is what actually applies

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 lets nobody in, so flagging it would invent a hole — and its intended restriction is gone, so clearing it would invent a wall.