{
  "root_cause_equivalence": "confirmed",
  "confidence": "high",
  "parent_root_cause": "The InMemoryRecoveryManager.backup() and .restore() methods in postgres-service/internal/postgres/postgres_recovery_manager.go build pg_dump/pg_restore command lines using the HTTP request's database field as a raw libpq connection string without sanitization. This allows hostaddr= injection (redirect to attacker-controlled Postgres) and passfile= injection (authenticate as postgres_admin superuser against local Splunk Postgres). Combined with a malicious database containing a PL/pgSQL lo_export() payload in a CHECK constraint, this enables arbitrary file write and RCE.",
  "variant_root_cause": "Same as parent: the database parameter is still passed as a raw libpq connection string to pg_dump/pg_restore without sanitization in the fixed build (10.0.7). The fix added authentication and changed backupFile to backupName, but did not sanitize the database parameter. The hostaddr= and passfile= injection still works on the fixed build with authentication. The lo_export() mechanism (writing to an arbitrary path via database content) is identical.",
  "shared_sink": "pg_restore loading a malicious dump into the local Splunk Postgres as the postgres_admin superuser, firing a CHECK constraint that calls lo_export() to write attacker-controlled bytes to an arbitrary filesystem path",
  "shared_vulnerable_code": "postgres-service/internal/postgres/postgres_recovery_manager.go (backup/restore methods, lines 68-203)",
  "differences": [
    {
      "aspect": "authentication",
      "parent": "Unauthenticated — no auth check on the endpoints",
      "variant": "Authenticated — requires a valid Splunk session token (the fix added auth at both proxy and sidecar layers)"
    },
    {
      "aspect": "file_path_control",
      "parent": "Attacker controls the output file path via backupFile (absolute path)",
      "variant": "Attacker cannot control the backup file path via the API (backupName is validated as filename-only); instead, the arbitrary file write target is in the database content (PL/pgSQL lo_export() call), not in the API parameter"
    },
    {
      "aspect": "database_parameter",
      "parent": "Raw libpq connection string (hostaddr= and passfile= injection)",
      "variant": "Raw libpq connection string (hostaddr= and passfile= injection) — IDENTICAL, NOT FIXED"
    }
  ],
  "equivalence_assessment": "The variant exploits the same unsanitized database parameter (the same root cause) as the parent CVE. The same pg_dump/pg_restore -> lo_export -> arbitrary file write -> RCE chain is used. The fix addressed authentication and the file path parameter but left the database parameter completely unsanitized. The variant confirms that the root cause persists on the fixed build, requiring authentication but achieving the same impact (RCE as the splunk user)."
}