CVE-2026-101091

COMPONENT VERSION RANGE

NewScan fingerprints SiYuan from its response and reports this CVE when the detected version falls inside the affected range below.

Added 2026-09-29 (/daily-cve). Deliberately floored at `ge: 3.8.1` so it cannot double-report with the 3.8.1 stored-XSS row below: the two ranges are disjoint, an install on 3.7.3 gets one finding and an install on 3.8.2 gets the other, rather than both saying 'upgrade SiYuan'. CVE-2026-101091 (7.1, GHSA-67p9-hm94-xwf3) is the version-matched id - block query embed blocks execute their SQL against siyuan.db without validation, so a crafted .sy document carrying a non-SELECT statement writes to the notebook database of whoever imports it. CVE-2026-101092 (6.9, GHSA-j9p6-5639-gf4f) rides in `cves`: getCurrentAttrViewImages does not enforce publish-access, letting a publish READER - the low-privilege role a published notebook hands to the internet - read image asset paths from databases they were never given. `medium` for both and that is the calibration, not timidity: 101091 needs the victim to import or sync an attacker-supplied document, and 101092 leaks asset paths rather than the assets' contents. This is the shape the interfaces.json SiYuan row explicitly declines to claim - its note records that the ~30 publish-access filter bugs on OTHER endpoints are NOT detected by an open-kernel probe - so a version gate is the only honest home for 101092 and this row is where it lands. VERSION SOURCE is the existing tech_signatures "SiYuan" version_from, unchanged and not re-derived: GET /api/system/version answers 200 {"code":0,"msg":"","data":"x.y.z"} ANONYMOUSLY even with the lock screen password set, measured 2026-08-31 against b3log/siyuan:v3.7.3 and :v3.8.1 for the row below. MEASUREMENT STATUS OF THIS ROW, stated rather than implied: the version gate is proven at the unit level (tech_version_from_checks now drives the real /api/system/version document at 3.8.1, 3.8.3 and 3.8.4 through the same pattern and asserts exactly one id below 3.8.4 and none at it), and the bounds are real releases - b3log/siyuan carries both v3.8.3 and v3.8.4 tags, read from hub.docker.com on 2026-09-29. What did NOT happen is the live container pair: the v3.8.3 image pulled and started, but the Docker daemon on this host stopped answering (`docker ps`/`docker logs` hung past 120s, the published loopback port answered with an empty reply), so the end-to-end probe was not made and is not claimed. Re-measure on the next batch that touches SiYuan. Version-match only regardless: confirming 101091 means writing SQL into a stranger's notes.