Description

SiYuan v3.7.4-alpha.1 (a pre-release; the endpoint does not exist in stable v3.7.3 or earlier) contains an information disclosure vulnerability in the /api/av/getAttributeViewFieldViews endpoint. The route is registered with CheckAuth only and applies no publish-access filtering, so reader-role callers can retrieve the complete database view structure — every view's name, icon, layout type, and per-field Hidden flag — for any database whose avID is supplied, regardless of authorization. The issue was introduced by commit acfc02ee8 and fixed in v3.7.4.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.8",
  "pubDate": "2026-08-12T20:17:50.550Z",
  "pubdate": "2026-08-12T20:17:50.550Z",
  "executiveSummary": "An information disclosure vulnerability exists in SiYuan v3.7.4-alpha.1 within the /api/av/getAttributeViewFieldViews endpoint. The flaw allows authenticated users with low-privileged reader roles to bypass intended access controls and retrieve sensitive structural metadata of arbitrary database attribute views, including view names, icons, layout types, and per-field hidden flags. The vulnerability stems from improper authorization enforcement on the affected API route, which relies solely on the generic CheckAuth middleware without applying necessary publish-access filtering. This enables unauthorized exposure of internal database view configurations to any caller possessing a valid database identifier (avID). The risk implication involves the unauthorized enumeration of sensitive application structures, aiding reconnaissance efforts for subsequent exploitation. Exploitation requires network access to the target instance and a valid authenticated session with reader-level privileges, but does not necessitate elevated administrative rights. The issue was introduced via commit acfc02ee8 and subsequently remediated in version v3.7.4.",
  "technicalDetails": "The vulnerability resides in the backend routing and authorization logic of SiYuan, specifically within the handling of the /api/av/getAttributeViewFieldViews endpoint introduced in version v3.7.4-alpha.1 via commit acfc02ee8. The root cause of the vulnerability is an insufficient authorization check wherein the endpoint registers only with the generic CheckAuth mechanism and fails to enforce downstream publish-access filtering or object-level permission validation. In a correctly implemented authorization model, endpoints serving sensitive database attribute view structures should verify whether the requesting user possesses adequate permissions—such as ownership or explicit publish access—to view the specified database context. However, because the affected handler lacks these checks, any authenticated user can successfully query the endpoint.\nThe attack flow proceeds as follows: an attacker with standard reader-role privileges identifies a target database identifier (avID). The attacker then crafts an HTTP request directed at the vulnerable /api/av/getAttributeViewFieldViews endpoint, supplying the targeted avID parameter. Upon receiving the request, the application validates the session via CheckAuth, confirms authentication, and proceeds to execute the view retrieval logic without validating whether the caller is authorized to access the specific database views. The vulnerable component processes the request and serializes the complete database view structure back to the client. The resulting payload exposes granular metadata including every view's name, icon, layout type, and per-field Hidden flag. Post-exploitation impact is primarily informational, yet critical, as the unauthorized disclosure of schema and view configurations provides attackers with deep architectural insights into the application's data organization, potentially exposing hidden data fields and structural relationships designed to be restricted from reader-role participants."
}