Summary
When guest access is enabled, POST /api/guest/session resumes an existing guest solely from the unsigned transmute_guest_id cookie. The cookie value is the guest's ordinary database UUID, not an independent secret or a server-authenticated session token. If an attacker learns a guest UUID, the attacker can place it in the cookie and obtain a fresh JWT for that guest.
This is directly exploitable by an application administrator: the admin-only user listing discloses every guest's complete UUID, while normal file endpoints correctly deny an administrator direct access to guest-owned files. Forging the resume cookie bypasses that boundary and exposes the guest's file list and contents.
Affected versions
- Introduced with guest functionality in
a97fcb874f90292b2682357cbc54a89af93b4010.
- Affected tagged releases: v0.7.0 through v2.0.0 (including alias tags).
- Guest access must be enabled with
ALLOW_UNAUTHENTICATED=true.
- Confirmed through the real API in the official v2.0.0 image.
Root cause
The server reads the cookie and directly treats its value as a user primary key, then issues an access token for the matched account. There is no signature, MAC, random guest-session secret, or proof that the requester originally created that guest. UUID v4 entropy prevents blind online guessing, but does not make a public account identifier an authenticated session credential. In particular, the application deliberately returns the same UUID from the administrator user-list endpoint.
Impact
An application administrator can bypass file ownership checks and fully act as any guest, including listing, downloading, converting, modifying, and deleting guest-owned data. Any other disclosure of a guest UUID would enable the same takeover without administrator privileges. The forged cookie also mints a new JWT, so possession of a previous victim JWT is unnecessary.
Severity
Suggested CVSS v3.1:
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H — 7.2
This score uses the demonstrated, reliable administrator path. The conditional guest-UUID disclosure path should not be used to claim a lower privilege requirement without a separate proof.
Weaknesses: CWE-287 (Improper Authentication) and CWE-639 (Authorization Bypass Through User-Controlled Key).
Recommended remediation
Do not use the public user UUID as a guest session credential. Generate a separate cryptographically random resume secret, store only its hash against the guest record/session, and rotate it when used or when the guest is renewed. Alternatively, use an authenticated-encryption or signed cookie with strict expiration and purpose separation. A signature must cover the guest UUID and expiry using a server secret.
Keep HttpOnly, SameSite=Strict, Secure under HTTPS, and the narrow cookie path as defense in depth. Add negative tests proving that an arbitrary or another guest's UUID cannot resume that guest, even when the UUID is known.
AI-assistance disclosure
AI-assisted tooling was used to inspect code, construct the isolated API proof, and draft this report. The reporter reviewed and reproduced the issue against the official image and takes responsibility for the submission.
Summary
When guest access is enabled,
POST /api/guest/sessionresumes an existing guest solely from the unsignedtransmute_guest_idcookie. The cookie value is the guest's ordinary database UUID, not an independent secret or a server-authenticated session token. If an attacker learns a guest UUID, the attacker can place it in the cookie and obtain a fresh JWT for that guest.This is directly exploitable by an application administrator: the admin-only user listing discloses every guest's complete UUID, while normal file endpoints correctly deny an administrator direct access to guest-owned files. Forging the resume cookie bypasses that boundary and exposes the guest's file list and contents.
Affected versions
a97fcb874f90292b2682357cbc54a89af93b4010.ALLOW_UNAUTHENTICATED=true.Root cause
The server reads the cookie and directly treats its value as a user primary key, then issues an access token for the matched account. There is no signature, MAC, random guest-session secret, or proof that the requester originally created that guest. UUID v4 entropy prevents blind online guessing, but does not make a public account identifier an authenticated session credential. In particular, the application deliberately returns the same UUID from the administrator user-list endpoint.
Impact
An application administrator can bypass file ownership checks and fully act as any guest, including listing, downloading, converting, modifying, and deleting guest-owned data. Any other disclosure of a guest UUID would enable the same takeover without administrator privileges. The forged cookie also mints a new JWT, so possession of a previous victim JWT is unnecessary.
Severity
Suggested CVSS v3.1:
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H— 7.2This score uses the demonstrated, reliable administrator path. The conditional guest-UUID disclosure path should not be used to claim a lower privilege requirement without a separate proof.
Weaknesses: CWE-287 (Improper Authentication) and CWE-639 (Authorization Bypass Through User-Controlled Key).
Recommended remediation
Do not use the public user UUID as a guest session credential. Generate a separate cryptographically random resume secret, store only its hash against the guest record/session, and rotate it when used or when the guest is renewed. Alternatively, use an authenticated-encryption or signed cookie with strict expiration and purpose separation. A signature must cover the guest UUID and expiry using a server secret.
Keep
HttpOnly,SameSite=Strict,Secureunder HTTPS, and the narrow cookie path as defense in depth. Add negative tests proving that an arbitrary or another guest's UUID cannot resume that guest, even when the UUID is known.AI-assistance disclosure
AI-assisted tooling was used to inspect code, construct the isolated API proof, and draft this report. The reporter reviewed and reproduced the issue against the official image and takes responsibility for the submission.