GHSA-8p3x-23rw-vfhv: 
Rust Analyse et atténuation des vulnérabilités

Severity (suggested): Medium (CVSS 3.1 ~5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). It is Low when jobs only run in the Docker runner and nobody else has access to the data volume. CWE: CWE-459 (Incomplete Cleanup), CWE-312 (Cleartext Storage of Sensitive Information) Affected: koreograf < 0.1.0-alpha.3 (0.1.0-alpha.1 and 0.1.0-alpha.2). Patched in 0.1.0-alpha.3.

Context

Credentials are encrypted at rest in SQLite with secret.key. When a job launches, the runner decrypts each attached credential and writes it as plaintext files (mode 0600) into data/jobs/<job_id>/. Nothing removes these files after the job finishes, fails, is cancelled or times out. The only code that touches data/jobs is the create_dir_all call when a job starts. Every job therefore leaves a permanent plaintext copy of its secrets in the data volume. That bypasses the encryption at rest and outlives credential rotation or deletion in the UI. Affected file names (from credentials::prepare): ssh_key, connection.pass, key.pass, become.pass, auth.json, vault.pass / vault.list, gce.json, git.pass, git_key, plus container.env (cloud tokens and proxy credentials in Docker mode). This was confirmed on a running instance: after a successful and a failed SSH job, ssh_key and auth.json were still present (0600, root) under /var/lib/koreograf/jobs/<id>/.

Location

• src/runner.rs:495 – work dir data/jobs/<job_id>, never removed
• src/runner.rs:870-935 – credential files written with write_secret
• src/runner.rs:957-970 – write_secret (0600)
• src/runner.rs:1350, src/runner.rs:1425 – container.env holding cloud tokens and proxy credentials
• src/credentials.rs:247, 285, 557, 567, 574, 587, 620, 641, 649, 657 – file names
• README "Database and backup" (line 26) mentions job directories only in the context of backups and says nothing about retention

Impact

Anyone who later gets read access to the data volume or PVC can recover the plaintext secrets of every past job without secret.key. That includes host admins, volume snapshots and backups made outside Koreograf, and a later compromised job running in local mode. Rotating or deleting a credential in Koreograf does not remove the old copies.

Remediation (acceptance criteria)

• After the job process exits, the runner deletes every credential file it wrote and container.env. This holds for every outcome: success, failure, cancel, timeout, spawn error, and an early return between writing secrets and starting the process. Implement it as a drop guard or finally-style cleanup around the run, not only on the happy path.
• Non-secret artifacts that users rely on (for example incident-report.txt, tfdata/, the job output) stay unless a retention setting says otherwise.
• On startup, a sweep removes the known secret file names from all existing data/jobs/*/ directories, to clean up installations that ran an affected version.
• Optional: a configurable retention (for example KOREOGRAF_JOB_DIR_RETENTION_HOURS) that deletes whole job directories after N hours.
• README documents what stays in a job directory and for how long.
• CHANGELOG / advisory text recommends rotating credentials that were used by jobs on affected versions.

Testing notes

• Unit test: call the credential setup for an SSH credential (key, password and become password) and a vault credential into a temp work dir, simulate success, failure and error paths of the run function, then assert that none of the secret file names exist afterwards.
• Integration test (local runner): launch a shell job with an SSH credential attached, wait for the terminal state, then assert that data/jobs/<id>/ssh_key and auth.json are gone and that the job output is still readable via GET /api/jobs/{id}/output.
• Startup sweep test: pre-create jobs/x/ssh_key and jobs/x/vault.pass, start the app with a temp KOREOGRAF_DATA, then assert that both files are removed and other files are kept.
• Cancel and timeout: launch sleep 60 with a credential, cancel, then assert cleanup.

Additional observations

Job directories themselves are 0755. finish (src/runner.rs:1631) never removes files. This intensifies GHSA-hxgj-4rj9-79fq: once an operator can read the data directory, every past job's secrets are available even after credential rotation in the UI. vault.pass / vault.list must be scrubbed too.

Patches

Fixed in v0.1.0-alpha.3. The runner records every secret file it writes and removes them, plus container.env, when the job ends for any outcome (success, failure, cancel, timeout, early error). On startup a sweep removes leftover secret files from all existing data/jobs/*/ directories, so upgrading cleans up files written by affected versions.

Workarounds

Delete ssh_key, connection.pass, key.pass, become.pass, auth.json, vault.pass, vault.list, gce.json, git.pass, git_key, and container.env below data/jobs/ and restrict access to the data volume.

Recommendation

After upgrading, rotate every credential that a job used on an affected version, and check backups or snapshots of the data volume made while an affected version ran, because they can still contain these files.