Skip to content

Security: zkrebbekx/pgparse

Security

SECURITY.md

Security Policy

Supported versions

pgparse is distributed as a Go module; fixes are released against the latest v0.x (and the latest v1.x once published). Please use the most recent release.

Reporting a vulnerability

Please report security issues privately, not via public issues or pull requests:

Include a description, affected version, and ideally a minimal reproducer. You can expect an acknowledgement within a few days and a fix or mitigation plan for confirmed issues.

Scope and threat model

pgparse parses SQL text into an AST. It is designed to be safe to run on untrusted input:

  • Parse never panics — internal panics are recovered and returned as errors.
  • A depth limit bounds the AST that Parse builds, rejecting pathologically nested or chained input (deeply nested parentheses, but also long left-associative chains such as a+a+…+a, t JOIN t JOIN …, or SELECT…UNION…UNION…, which build depth without recursing while parsing). This protects two stacks: the parser's own, and — just as important — any recursive consumer of the result. Deparse, Walk, and a caller's own tree walk can all traverse any tree Parse returns without overflowing the stack. A stack overflow is a fatal runtime error that recover cannot catch, so this is enforced before the tree is returned.
  • MaxInputBytes bounds input size, and MaxNodes bounds the number of AST atoms built from one input, to prevent unbounded memory allocation (including memory-amplifying input that packs many nodes into few bytes).
  • It holds no shared mutable state and is safe for concurrent use.

Not in scope: pgparse is not a security control. It parses a pragmatic subset of PostgreSQL and is not the authoritative parser, and its read/write classification (Mutates/Classify) is purely syntactic — it cannot see side effects inside functions (e.g. SELECT nextval('s')). Do not use pgparse as the sole authority for SQL firewalling, read-only gating, or access control; enforce those with server-side controls (roles, default_transaction_read_only, read-replica connections).

There aren't any published security advisories