CVE-2026-73610

The getLocalStorage endpoint in SiYuan exposes a localStorage map to publish readers with only three keys filtered — closed-tab history, search keywords, and expanded folder paths. The critical insight is not what was filtered, but what the filtering pattern reveals: this is reactive patching, not principled design. Someone identified three specific values as dangerous and blocked them, which means every other key in that storage map was implicitly deemed acceptable by default. That judgment is the actual vulnerability. This matters because localStorage in any mature application accumulates as a dump for session state, UI preferences, and behavioral data — none of it classified, all of it potentially cross-contaminating. The three-key filter doesn't clean this mess; it puts a sign on one door while the rest remain open. More dangerously, the filter creates a legitimacy signal. Future developers, reviewers, and automated scanners will read "three keys sanitized" and infer "these three are sensitive, the rest are acceptable." The remediation calcifies the exposure by making it look intentional rather than accidental. The endpoint name compounds this: "getLocalStorage" advertises its intent to return the entire storage, minus three keys. Any developer calling this endpoint — or any scanner cataloguing it — sees a function that promises to deliver everything. The naming is the authorization; the filter is the footnote no one reads. The exposure is worse than a simple information leak. Search keywords and folder expansion patterns reconstruct a user's investigative process — what they were researching, who they were investigating, and what they chose not to publish. An attacker harvesting this data across multiple publish-reader sessions builds a behavioral profile, not just a data dump. Three concrete actions: First, audit localStorage for any additional sensitive keys — auth tokens, session identifiers, document content — that may be exposed by parameter manipulation or endpoint variants. Second, treat the entire getLocalStorage endpoint as untrusted until a full allowlist is defined; the correct remediation is full lockdown, not expansion of the filter. Third, investigate whether sync or data junction features replicate localStorage to servers — if so, the same exposure exists server-side under a different trust model, and the three-key filter is irrelevant to that attack surface.

Reviewed through automated stages and approved by a human before publication.