GHSA-84jc-3hj2-hwc7

Summary

The POST /v1/domain/_image and POST /v1/oauth2/{rs_name}/_image handlers call validate_image() on the uploaded body before the ACL check that restricts image upload to admins. Any bug in an image validator is therefore reachable by an unauthenticated remote client rather than being admin-gated.

One such bug exists today: png_has_trailer() panics on inputs shorter than 8 bytes, or whose first chunk-length field is near u32::MAX.

On a default build this has no server-wide impact. The panic unwinds only the requester's own tokio task; the server process survives, no shared state is poisoned, and other connections are unaffected. This was reported privately rather than as a public issue because (a) the project previously treated an admin-triggered thread crash of identical impact as security-relevant (e51d0dee4), and this is reachable by a broader population; and (b) a downstream build with panic = "abort" would upgrade it to an unauthenticated process-crash DoS.

Details

Validate-before-authorize ordering

Both handlers parse and validate attacker-controlled bytes before checking whether the caller is permitted to upload at all:

• server/core/src/https/v1_domain.rs:118 — image.validate_image() runs; handle_image_update(client_auth_info, …) (the ACL check) is at line 129.
• server/core/src/https/v1_oauth2.rs:550 — same ordering.

The VerifiedClientInformation extractor (server/core/src/https/extractors/mod.rs:18-90) always returns Ok — it builds a ClientAuthInfo from whatever credentials are present (including none) and does not reject anonymous callers. Authorization is deferred to handle_image_update(), which is never reached if the validator panics or errors first.

PNG validator panic (demonstrator)

validate_image() (server/lib/src/valueset/image/mod.rs:98) checks only a 256 KiB maximum size, not a minimum, before dispatching to the format-specific validator.

Short input —...