fix(security): block PasswordHash changes via config API

[cursor]

Summary

Fixes a critical auth bypass where anyone with WebUI.Token could take over a configured admin account.

Bug and impact

An attacker with only the API token (from config.toml, logs, or GET /api/token) could:

1. POST /web/config or POST /api/config with {"changes": {"WebUI.PasswordHash": ""}} to clear the stored password hash
2. Call POST /web/auth/set-password using WebUI.Token as the bootstrap setup token
3. Set a new admin password and gain full WebUI access

This bypassed the hardening in #225/#228 that restricted set-password when a password was already configured.

Root cause

ApplyDottedConfigChanges / POST /web/config only skipped [redacted] placeholder values for sensitive keys. An empty string was accepted and persisted, re-opening bootstrap mode without requiring TORRENTARR_SETUP_TOKEN.

Fix

• Reject all direct WebUI.PasswordHash writes via config endpoints (except the [redacted] placeholder)
• Password changes must go through POST /web/auth/set-password
• Added unit and integration tests covering empty-string rejection and the full takeover chain

Validation

• dotnet test tests/Torrentarr.Infrastructure.Tests/ --filter FullyQualifiedName~WebUIAuthHelpersTests
• dotnet test tests/Torrentarr.Host.Tests/ --filter FullyQualifiedName~ConfigRedactionTests

  

[cursor]

Critical bypass found in PR #271

The dotted-key guard (RejectPasswordHashConfigChange) is correct for the paths it covers, but two config API shapes still bypass it and can clear PasswordHash, reopening bootstrap POST /web/auth/set-password with only the API token.

Bypass 1: Full /api/config replace

POST /api/config without a changes wrapper deserializes a full TorrentarrConfig and never calls RejectPasswordHashConfigChange:

else
{
    updatedConfig = JsonConvert.DeserializeObject<TorrentarrConfig>(payload.GetRawText());
}

Trigger: Authenticated caller sends POST /api/config with WebUI.PasswordHash: "" in a full config body → 200 OK → set-password with setupToken: <api-token> succeeds.

Bypass 2: Section-level WebUI replace

ApplyDottedConfigChanges only checks dotted keys. A top-level WebUI object in changes replaces the entire section:

{"changes": {"WebUI": {"PasswordHash": "", ...}}}

Trigger: Same account-takeover chain as above; confirmed with integration test returning 200 before fix.

Recommended fix

Add a save-time guard (ValidatePasswordHashForConfigApiSave) that rejects any PasswordHash change on config API persistence, regardless of payload shape. Implemented on branch cursor/critical-bug-investigation-82da.

What looks good

• Dotted-key rejection for "" and arbitrary hash values
• [redacted] placeholder handling for normal frontend round-trips
• Regression tests for the originally reported dotted-key attack

  

_{Sent by Cursor Automation: Torrentarr - Find critical bugs}

[cursor]

PR Validation (Cursor Automation)

Recommendation: Close (incorrect fix)
Primary reason: The PR blocks WebUI.PasswordHash only for dotted changes payloads, but POST /api/config still accepts a full JSON replacement payload that can set or clear WebUI.PasswordHash without going through POST /web/auth/set-password.

Gates

Gate	Status	Notes
Merge conflicts	Pass	origin/cursor/critical-bug-investigation-7357 merged cleanly with origin/master; no conflicts.
dotnet build	Pass	dotnet build -c Release passed with 0 errors and 6 existing NU1510 warnings.
dotnet test (non-live)	Pass	dotnet test -c Release --no-build --filter "Category!=Live" passed: 745 passed, 0 failed.
vitest	Pass	npm ci && npx vitest run passed: 16 files, 154 tests.

Validation

Axis	Score	Notes
Purpose	Pass	Direct config changes to WebUI.PasswordHash are a real auth/config issue and the PR is aimed at the correct surface.
Correctness	Fail	ApplyDottedConfigChanges rejects WebUI.PasswordHash, but the no-changes branch in POST /api/config still deserializes and saves a full TorrentarrConfig, leaving a direct PasswordHash write path. This also fails the Torrentarr-specific check that POST /api/config should use dotted changes merge rather than full JSON replace.
Tests	Fail	Added tests cover /web/config and /api/config dotted changes, but not the remaining full-payload /api/config bypass.
Hygiene	Pass	Focused 5-file change with no generated SDK junk or unrelated noise.
Overlap	Pass	Not treating as a duplicate: the prompt’s 2026-06-15 winner table names #271 for Config PasswordHash security. #258 overlaps broader /api/config dotted-only work but is not the preferred focused PasswordHash winner.

Why

The merge/build/test gates are green, but the security invariant is still not enforced globally: WebUI.PasswordHash can still be supplied through the full-replacement POST /api/config path because that branch bypasses the new RejectPasswordHashConfigChange helper. The fix should either remove/disable full replacement for /api/config in favor of dotted changes, or explicitly reject WebUI.PasswordHash changes before saving any full config payload.

Required repo context was checked. Note: docs/audits/pr-triage-2026-06-15.md was not present in the checkout; the latest available audit file was docs/audits/pr-triage-2026-06-11.md, and the trigger prompt’s 2026-06-15 winner table was used for overlap guidance.

Overlap

None as a duplicate recommendation. Related broader config PR: #258.

Commands run

git fetch origin master; git fetch origin cursor/critical-bug-investigation-7357; git checkout -B pr-validate origin/cursor/critical-bug-investigation-7357; git merge origin/master; git diff --stat origin/master...HEAD; gh pr list --state open --search "PasswordHash repo:Feramance/Torrentarr"; gh pr view 258 --json ...; temporary /tmp/dotnet SDK install because dotnet was initially missing; dotnet restore; dotnet build -c Release; dotnet test -c Release --no-build --filter "Category!=Live"; npm ci; npx vitest run; git status --short --branch; git diff --exit-code.

  

_{Sent by Cursor Automation: Torrentarr PR validation triage}