ChronoFrame CVE-2026-111650

No special conditions - remote unauthenticated POST to /api/wizard/storage against default ChronoFrame deployments. The root cause is that the setup-wizard API handlers (server/api/wizard/) fail to require authentication or to verify that initial setup is already complete, so even fully configured, production instances remain re-configurable. The only meaningful limiting factor is network reachability of the instance: an attacker must be able to reach the HTTP endpoint (internet-exposed or same-network). No authentication, no user interaction, no non-default feature toggle, and no specific platform are required.

All signals point to a genuinely high-priority flaw for any exposed ChronoFrame instance, tempered only by the product's tiny footprint. The vendor/VulnCheck CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes trivial remote exploitation with no authentication, no user interaction, and low complexity, and my independent assessment agrees - a single unauthenticated POST reconfigures the instance. Impact is integrity-dominant (VI:H): the attacker overwrites storage, site, and map settings, with secondary confidentiality (VC:L, future uploads/reads flow through attacker-controlled storage) and availability (VA:L, legitimate storage reads can break). EPSS is not provided (unknown) and the CVE is NOT in CISA KEV, so there is no evidence of active or widespread exploitation; a detailed public technical writeup (hackmd) documents the exact attack but the input carries no explicit POC/exploit-code flag. Net: this is a real, easily exploitable issue warranting prompt patching wherever ChronoFrame ≤1.0.0 is internet-reachable, but the obscure, hobby-scale deployment base means any exploitation is far more likely to be targeted or opportunistic scanning than mass-scale - do not let the 8.8 score imply broad enterprise risk.

An attacker locates an internet-reachable ChronoFrame instance (even one already fully set up) and sends an unauthenticated POST to /api/wizard/storage specifying their own S3 or OpenList credentials, because the setup-wizard handlers never verify authentication or that setup is already complete. Subsequent uploads and storage reads are silently routed through the attacker's provider, letting them capture new content and tamper with served media, while site and map settings can likewise be overwritten. A public technical writeup documents the exact request, though the input contains no confirmed proof-of-concept exploit flag.