Bartłomiej Dmitruk

An authentication bypass exists in the admin REST API when the `admin.listeners` property is configured separately from the main `listeners` property. In this configuration, REST extensions defined via `rest.extension.classes`, such as `BasicAuthSecurityRestExtension`, are not applied to the admin resource configuration. Consequently, the `/admin/loggers` endpoint does not inherit authentication and authorization filters, allowing unauthenticated users with network access to the admin listener to read logger names and levels or modify logger levels across the cluster. This could lead to the disclosure of loaded class names and security extensions, or impact availability and observability by suppressing or inflating log output.

Apache Kafka Connect has the /connector-plugins/{connector-type}/config/validate endpoint on its REST API to validate connector configurations. Apache Kafka Connect also support Configuration Providers which enable to hide the values of sensitive configuration and only resolve them at runtime.  An attacker with access to the validate endpoint can use it to resolve and return plaintext values via any of the configuration providers installed on a Connect worker. Users are recommended to upgrade to version 4.2.2, 4.3.2, 4.4.0 or above, which fix this issue.

An unauthenticated remote attacker can exploit a path traversal issue via the '/api/pull' endpoint. This occurs because the `digestToPath()` function does not sufficiently validate layer digests, allowing the use of traversal sequences to write malicious binaries outside the intended model store. If the server process has write access to '/usr/lib/ollama', which is common in many Docker images, an attacker can place a malicious file in that directory. This file is then loaded and executed upon the next server restart, leading to remote code execution with root privileges.

An OS command injection flaw exists in the IPC handler, which allows the renderer process to execute shell commands. Although an allowlist restricts command names to specific tools such as `git`, `pandoc`, and `grep`, the argument string is concatenated with the command and passed to the `child process.spawn()` function with the `shell: true` option. This configuration allows shell metacharacters within the arguments to bypass the allowlist. An attacker capable of executing JavaScript in the renderer, such as through Cross-Site Scripting (XSS) in note content or a malicious plugin, can execute arbitrary shell commands with the privileges of the Logseq process, resulting in remote code execution on the host.

A stored cross-site scripting (XSS) issue exists where a malicious plugin can include a JavaScript payload in the `name` field of its `package.json` file. This occurs because the field is rendered using `innerHTML` without proper sanitization, enabling the execution of arbitrary code within the privileged host context.

A sandbox escape flaw allows plugins running in sandboxed iframes to inject arbitrary HTML attributes, such as event handlers, into their container element in the host DOM. Because the Content Security Policy (CSP)—a security layer that helps detect and mitigate certain types of attacks—is disabled, a malicious plugin can execute arbitrary JavaScript within the privileged host context. This may lead to unauthorized access to filesystem APIs.

The Electron preload script exposes an API method that allows the renderer process to invoke IPC (Inter-Process Communication) handlers without proper path validation. An attacker capable of executing JavaScript in the renderer, such as through a malicious plugin or Cross-Site Scripting (XSS), can read, write, or delete arbitrary files on the local system.

The update mechanism in Ollama for Windows allows Remote Code Execution due to improper handling of attacker-controlled HTTP response headers. The application constructs local file paths using values from these headers without validation, passing them to the `filepath.Join()` function. This enables path traversal using sequences like `../` to write files outside the intended update staging directory. An attacker capable of influencing update responses can write arbitrary executables to locations accessible to the current user, such as the Windows Startup directory. When combined with a lack of signature verification for updates, malicious payloads can be delivered, written to sensitive locations, and executed automatically and persistently without user interaction, as the software performs silent automatic updates.

Ollama for Windows fails to verify the integrity or authenticity of downloaded update executables. The update verification routine on Windows unconditionally returns success, bypassing digital signature and trust validation before update payloads are staged or executed. This allows attacker-supplied executables to be accepted and executed. Because the application performs silent automatic updates, malicious payloads can be installed without user awareness.