Psono Server vulnerabilities

Psono Server CE and EE versions 4.0.33 through 7.2.3 compared the request path for the bulk-secret-read endpoint with a hard-coded unprefixed path. In deployments with URL_PREFIX, the comparison failed and the POST request was authorized with write scope instead of read scope, allowing an authenticated attacker with a read-disabled, write-enabled API key to retrieve encrypted secret data and nonces.

Psono Server CE and EE versions 0.1.0 through 7.2.3 accepted a user-controlled host when configuring a personal Duo device and passed it to the Duo client without an allowlist or explicit timeout. An authenticated attacker could cause the server to connect to selected hosts over HTTPS on port 443 and distinguish failure modes, providing an internal DNS and service-reachability oracle.

Psono Server CE and EE versions 3.1.0 through 7.2.3 did not consume a stored WebAuthn challenge after assertion verification. An unauthenticated attacker with the user's password and one captured valid WebAuthn assertion could replay it with separate login tokens, bypassing the WebAuthn second factor.

Psono Server (CE and EE) versions 1.0.0 through 7.2.3 did not enforce the direction of file-transfer credentials on file-repository operations. An authenticated attacker with read-only access could present a download transfer to the upload endpoint, obtain a signed upload URL for an attacker-selected object key, and append a chunk to the owner's file.

Psono Server versions 5.3.5 through 7.2.3 used a permission class that did not enforce token write scope when claiming a device code. An authenticated attacker with a restricted API key-derived session could claim an attacker-controlled device code and obtain a full read-write session valid for up to 365 days.