Contents

• Security Policy
  • Supported Versions
  • Reporting a Vulnerability
  • Security Considerations
    • Connection Strings
    • SQL Injection — WHERE Clause
    • Network Security
    • Shared Memory

Security Policy

Supported Versions

Version	Supported
3.x	✅ Active
2.x	✅ Security fixes
1.x	❌ End of life
0.x	❌ End of life

Reporting a Vulnerability

If you discover a security vulnerability in PgClone, please report it responsibly:

1. Do not open a public GitHub issue for security vulnerabilities
2. Email the maintainer directly or use GitHub’s private vulnerability reporting feature
3. Include a clear description of the vulnerability and steps to reproduce

We will acknowledge your report within 48 hours and provide a timeline for a fix.

Security Considerations

PgClone operates with superuser privileges and handles database connections. Users should be aware of the following:

Connection Strings

Connection strings passed to pgclone functions may contain passwords in plaintext. To avoid exposing credentials:

• Use .pgpass files or the PGPASSFILE environment variable instead of inline passwords
• Restrict access to pgclone functions to trusted users only
• Avoid logging connection strings in application logs

SQL Injection — WHERE Clause

The "where" option in JSON parameters is validated against SQL injection patterns (DDL/DML keywords and semicolons are rejected) and executed inside a READ ONLY transaction on the source database. This provides two layers of protection:

• Only use WHERE filters with trusted input
• Do not pass user-supplied strings directly into the "where" option
• The keyword validation and read-only transaction wrapping (v2.2.1) prevent most injection attacks, but defense-in-depth is recommended

Network Security

pgclone connects to remote PostgreSQL instances using libpq. Ensure:

• Firewall rules restrict which hosts can be reached
• Use SSL connections where possible (sslmode=require in connection strings)
• Source databases should grant minimal required privileges (read-only access is sufficient for cloning)

Shared Memory

Async job state is stored in PostgreSQL shared memory. Job metadata (schema names, table names, progress) is visible to all database users who can call pgclone_progress() or query pgclone_jobs_view. This is expected behavior but should be considered in multi-tenant environments.