Most recent entries from all

Withdrawn: CLEANSTART-2026-EM10970 — Security fixes for CVE-2017-9233, CVE-2019-15903, CVE-2021-45960, CVE-2021-46143, CVE-2022-22822, CVE-2022-22823, CVE-2…

2026-10-16T04:02:33.183781+00:00

Withdrawn by the publisher.

Affected: CleanStart: expat

Multiple security vulnerabilities affect the expat package. These issues are resolved in later releases. See references for individual vulnerability details.

EUVD-2026-276651

2026-10-16T04:02:33.183830+00:00

EUVD-2026-276651

fkie_cve-2026-32767

2026-10-16T04:02:33.183846+00:00

SiYuan is a personal knowledge management system. Versions 3.6.0 and below contain an authorization bypass vulnerability in the /api/search/fullTextSearchBlock endpoint. When the method parameter is set to 2, the endpoint passes user-supplied input directly as a raw SQL statement to the underlying SQLite database without any authorization or read-only checks. This allows any authenticated user — including those with the Reader role — to execute arbitrary SQL statements (SELECT, DELETE, UPDATE, DROP TABLE, etc.) against the application's database. This is inconsistent with the application's own security model: the dedicated SQL endpoint (/api/query/sql) correctly requires both CheckAdminRole and CheckReadonly middleware, but the search endpoint bypasses these controls entirely. This issue has been fixed in version 3.6.1.

GHSA-j7wh-x834-p3r7 — SiYuan: Authorization Bypass Allows Arbitrary SQL Execution via Search API

2026-10-16T04:02:33.183876+00:00

Affected: Go: github.com/siyuan-note/siyuan/kernel

## Summary

SiYuan Note v3.6.0 (and likely prior versions) contains an authorization bypass vulnerability in the `/api/search/fullTextSearchBlock` endpoint. When the `method` parameter is set to `2`, the endpoint passes user-supplied input directly as a raw SQL statement to the underlying SQLite database without any authorization or read-only checks. This allows any authenticated user — including those with the `Reader` role — to execute arbitrary SQL statements (SELECT, DELETE, UPDATE, DROP TABLE, etc.) against the application's database.

This is inconsistent with the application's own security model: the dedicated SQL endpoint (`/api/query/sql`) correctly requires both `CheckAdminRole` and `CheckReadonly` middleware, but the search endpoint bypasses these controls entirely.

## Root Cause Analysis

### The Vulnerable Endpoint

**File:** `kernel/api/router.go`, line 188

```go ginServer.Handle("POST", "/api/search/fullTextSearchBlock", model.CheckAuth, fullTextSearchBlock) ```

This endpoint only applies `model.CheckAuth`, which permits **any** authenticated role (Administrator, Editor, or Reader).

### The Properly Protected Endpoint (for comparison)

**File:** `kernel/api/router.go`, line 177

```go ginServer.Handle("POST", "/api/query/sql", model.CheckAuth, model.CheckAdminRole, model.CheckReadonly, SQL) ```

This endpoint correctly chains `CheckAdminRole` and `CheckReadonly`, restricting SQL execution to administrators in read-write mode.

### The Vulnerable Code Path…