{
  "claim_outcome": "confirmed",
  "claim_block_reason": null,
  "variant_result": "confirmed_bypass",
  "validated_surface": "api_remote",
  "evidence_scope": "production_path",
  "claimed_impact_class": "code_execution",
  "observed_impact_class": "code_execution",
  "exploitability_confidence": "high",
  "bypass_type": "authenticated_variant_same_root_cause",
  "attacker_controlled_input": "Authenticated HTTP POST to /en-US/splunkd/__raw/v1/postgres/recovery/backup and /restore on Splunk Web (port 8000) with Authorization: Splunk <token>. The attacker controls the database parameter (libpq connection string): hostaddr=<attacker-ip> to redirect pg_dump at an attacker-controlled Postgres, and passfile=<.pgpass> + dbname=template1 to redirect pg_restore at the local Splunk Postgres as the postgres_admin superuser. The malicious database content (PL/pgSQL lo_export payload in a CHECK constraint) is loaded during restore, firing lo_export to write attacker bytes to an arbitrary path.",
  "trigger_path": "Remote attacker -> authenticate -> Splunk Web :8000 (auth required) -> proxied sidecar /v1/postgres/recovery/backup (pg_dump of attacker DB via hostaddr= injection -> BackupComplete on FIXED 10.0.7) -> /v1/postgres/recovery/restore (pg_restore into local template1 via passfile= injection; CHECK constraint fires lo_export writing attacker Python over ssg_enable_modular_input.py) -> Splunk modular-input scheduler executes overwritten script as splunk user -> /tmp/pwned/MARKER with uid=41812(splunk).",
  "end_to_end_target_reached": true,
  "sanitizer_used": false,
  "crash_observed": false,
  "read_write_primitive_observed": true,
  "exploit_chain_demonstrated": true,
  "negative_control_verified": true,
  "negative_control_detail": "Unauthenticated POST to .../recovery/backup on fixed 10.0.7 returns 401 'Authorization header must use Splunk token' — the fix blocks unauthenticated access. The variant bypass uses authentication (valid Splunk token) to reach the same endpoints and exploit the unsanitized database parameter.",
  "variant_reproduced_on_fixed_version": true,
  "variant_reproduced_on_vulnerable_version": true,
  "fix_coverage_assessment": "The fix in 10.0.7 adds authentication on backup/restore (both proxy and sidecar layers) and changes backupFile to backupName (filename-only, validated). However, the fix does NOT sanitize the database parameter, which is still passed as a raw libpq connection string to pg_dump/pg_restore. The hostaddr= and passfile= injection that powered the original CVE still works on the fixed build with authentication. The lo_export target path is in the database content (PL/pgSQL function body), not in the API parameter, so backupName validation does not prevent the arbitrary file write.",
  "blocking_mitigation": null,
  "inferred": false,
  "impact_parity": "full",
  "impact_parity_detail": "The variant achieves the same impact as the original CVE: arbitrary file write via lo_export and RCE as the splunk user (uid=41812(splunk)). The only difference is the authentication requirement — the original CVE was unauthenticated, this variant requires a valid Splunk session token.",
  "tested_targets": {
    "vulnerable": {
      "image": "splunk/splunk:10.0.6",
      "image_sha": "sha256:f3c444ec113bba9456e4ac0879d92503072f3b09721bef97a19637954328d6fd",
      "result": "original CVE reproduced (unauthenticated access confirmed)"
    },
    "fixed": {
      "image": "splunk/splunk:10.0.7",
      "image_sha": "sha256:e47c0e002bd7f9f0ac38dd32a121ee542ab8b98c8042999ea64437be48e24d4b",
      "result": "variant bypass confirmed (authenticated file write + RCE)"
    }
  }
}