CVE Database

SiYuan versions before v3.7.4 fail to apply publish-access filtering to the getAttributeViewKeysByID endpoint, allowing authenticated readers to retrieve complete database column schemas including descriptions, select vocabularies, and template expressions. Additionally, getBlockDefIDsByRefText and getBlockRelevantIDs endpoints enumerate workspace-wide block IDs without publish scoping, enabling attackers to discover valid block identifiers across publish boundaries and access content from hidden or password-protected documents.

SiYuan before v3.7.4 (affected <=v3.7.2) fails to enforce publish-access filters on five filetree path-resolution endpoints (getFullHPathByID, getHPathByID, getPathByID, getIDsByHPath, and getHPathByPath). In publish mode, when Publish.Auth.Enable is false, an unauthenticated (anonymous) reader — or any publish reader token — can call these endpoints to enumerate the complete private document tree, mapping notebook names, folder hierarchies, and document titles, and resolving title paths to document IDs, including for documents marked hidden, password-protected, or publish-forbidden.

SiYuan versions before v3.7.4 fail to properly filter related-database content in renderAttributeView, allowing anonymous readers to access Relation and Rollup cell contents from hidden or password-protected databases. Attackers can request published databases that relate to restricted databases to retrieve sensitive content, or bypass row filtering entirely when the first column is a non-block type.

SiYuan versions before v3.7.4 contain an information disclosure vulnerability in the getEncryptedNotebookStatus endpoint that returns encrypted notebook identifiers, names, and lock states without publish-access filtering. Anonymous readers and publish-mode accounts can enumerate all encrypted notebooks and their current unlock status, revealing sensitive notebook names and decryption state in memory.

SiYuan before v3.7.4 contains an access control bypass vulnerability where static-file routes in the server mux bypass publish-access controls enforced on the REST API. Attackers with publish reader tokens or anonymous access in disabled-auth mode can read templates, snippets, and export artifacts by directly accessing static routes that lack the same restrictions as their REST API counterparts.

SiYuan versions before v3.7.4 fail to filter embedded block content by publish access in the getBlockDOMWithEmbed and getBlockDOMsWithEmbed endpoints. Attackers can request published blocks containing embed queries to read content from password-protected, hidden, or forbidden documents without authorization.

siyuan versions before v3.7.4 expose the session cookie signing key through the /api/system/getConf endpoint to unauthenticated users in publish mode. Attackers can retrieve the CookieKey value and forge valid session cookies to impersonate users or gain administrative access.

SiYuan versions before v3.7.4 fail to mask sensitive configuration fields in the /api/system/getConf endpoint, allowing anonymous or publish-reader users to obtain the session-cookie signing key, OS username via pandoc path, and encrypted-notebook key material. Attackers can forge and tamper with session cookies to impersonate users, and on instances without access-auth codes configured, escalate to administrator privileges.

SiYuan before v3.7.4 contains an information disclosure vulnerability in the /api/tag/getTag endpoint that returns tag labels and occurrence counts from password-protected documents to unauthenticated readers. Attackers can enumerate tag vocabulary and internal terminology from password-protected documents by calling the tag endpoint without providing the document's publish password.

SiYuan v3.7.4-alpha.1 (a pre-release; the endpoint does not exist in stable v3.7.3 or earlier) contains an information disclosure vulnerability in the /api/av/getAttributeViewFieldViews endpoint. The route is registered with CheckAuth only and applies no publish-access filtering, so reader-role callers can retrieve the complete database view structure — every view's name, icon, layout type, and per-field Hidden flag — for any database whose avID is supplied, regardless of authorization. The issue was introduced by commit acfc02ee8 and fixed in v3.7.4.

SiYuan before v3.7.4 contains an information disclosure vulnerability in the /api/notebook/getNotebookInfo endpoint that returns notebook metadata without authorization checks. Attackers can read notebook names, document counts, sizes, and timestamps for closed or non-published notebooks that should be hidden from readers.

SiYuan before v3.7.4 fails to properly validate publish access for encrypted notebooks, treating them as publicly accessible by default. Anonymous readers can enumerate and retrieve fully decrypted document content from unlocked encrypted notebooks through the publish API without authentication or key material.

SiYuan versions before v3.7.4 contain an information disclosure vulnerability in the UILayout filter that fails to properly restrict administrator workspace state from publish readers. Unauthenticated attackers can retrieve the administrator's open documents, search terms, notebook paths, and private asset locations by calling the getConf endpoint without authentication.

Craft CMS versions before 5.10.8 contain a stored cross-site scripting vulnerability in the control panel where draft names are rendered without HTML encoding in element chips and cards. A low-privilege user who can create element drafts can inject malicious JavaScript that executes in the browser of any higher-privileged user viewing the affected element, allowing account creation and other authenticated actions.

Craft CMS versions before 5.10.8 contain an authentication bypass vulnerability in the elements/save action that allows authenticated users to change passwords without verification. Attackers with edit users permission can reset any user's password including administrators by exploiting the unprotected newPassword field in the User element save flow.

A flaw was found in the multicloud-operators-subscription component of Red Hat Advanced Cluster Management (RHACM). This vulnerability allows a namespace-admin tenant to perform a confused-deputy attack by creating Subscription Custom Resources (CRs) that leverage a highly privileged ServiceAccount (SA). This enables the tenant to deploy arbitrary cluster-scoped resources, leading to privilege escalation and potential arbitrary code execution across the cluster.

GitLab has remediated an issue in GitLab EE affecting all versions from 12.0 before 19.0.6, 19.1 before 19.1.4, and 19.2 before 19.2.2 that under certain conditions could have allowed an authenticated user to bypass IP-based access restrictions and read limited merge request information from a private project due to missing authorization checks in a merge requests API endpoint.

Deserialization of Untrusted Data vulnerability in ash-project ash allows an unauthenticated attacker to inject a filter expression through a forged keyset pagination cursor, resulting in SQL injection or code execution depending on the data layer. Read actions with keyset pagination decode the client-supplied page[:after] or page[:before] cursor in decode_values/2 in lib/ash/page/keyset.ex using non_executable_binary_to_term/2 with [:safe]. That guard blocks new atoms, funs, and ports, but not a struct built from atoms already interned in a running Ash application, so a decoded %Ash.Query.Call{} expression survives and is spliced into the keyset filter as a comparison value in do_filters/4 and evaluated. Because the cursor bypasses the Ash.Expr macro, the runtime never applies the private?/public? gate that would otherwise reject it. On AshPostgres the injected fragment is inlined into the SQL query; on the ETS and Simple data layers it is evaluated in-process as an arbitrary function call. This issue affects ash: from 1.17.0 before 3.31.3.

An improper validation vulnerability in the instancePostMigration function in lxd/instance_post.go of LXD allows an authenticated attacker with can_create_instances permissions on a restricted project to bypass project-level security restrictions. When migrating an instance between projects, LXD fails to validate the instance's configuration against the target project's enforced restrictions (such as restricted.containers.lowlevel, restricted.devices.*, and restricted.networks.access). An attacker can exploit this by creating a disallowed or high-privilege instance in an unrestricted project and subsequently moving it into the restricted project.

An authorization bypass vulnerability in LXD allows an authenticated user to bypass project-level disk and volume limits. Two related code paths fail to verify resource limits during volume operations: the storagePoolVolumeTypePostMove function omits the limits.AllowVolumeCreation check before moving a volume across projects, and volume snapshot restore operations skip the AllowVolumeUpdate check when the configuration is nil (Config == nil). An attacker can exploit these flaws to allocate storage resources that exceed the administrative limits configured for a project.

An improper neutralization of special elements vulnerability in LXD's NVIDIA instance configuration handling allows an authenticated attacker to inject arbitrary configuration directives. By supplying newline characters within the 'nvidia.driver.capabilities' or 'nvidia.require.*' configuration values, an attacker can manipulate the generated lxc.conf file. This flaw enables the attacker to execute arbitrary code on the host system with the privileges of the LXD daemon.

An authorization bypass vulnerability in LXD due to a timing flaw during configuration merging allows an authenticated attacker to bypass target project restrictions during cross-project instance copies. When copying an instance to a target project, LXD performs restriction checks before configuration merging is complete, creating a time-of-check to time-of-use (TOCTOU) condition. An attacker can exploit this flaw to copy instances with disallowed high-privilege configurations into restricted projects, bypassing security controls.

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass target project restrictions during instance migration. When migrating an instance to a target project, LXD accepts configuration overrides without validating the new configuration against the target project's enforced restrictions. An attacker can exploit this flaw to move instances with disallowed high-privilege configurations into restricted projects, bypassing security controls.

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass project-level container isolation restrictions. When a project is configured with restrictions on container privileges (such as enforcing restricted.containers.privilege=isolated), LXD fails to enforce the requirement if an instance configuration omits the security.idmap.isolated key. An attacker can exploit this flaw by creating or updating an instance without explicitly setting security.idmap.isolated, bypassing the target project's security constraints.

A link following vulnerability in LXD allows an attacker to achieve root command execution on the host system. During the import or unpacking of crafted image or backup archives, LXD fails to properly validate and confine the backup.yaml file when it exists as a symbolic link. An attacker can exploit this flaw by providing a malicious archive with a symlinked backup.yaml file, causing LXD to process unconfined configuration metadata and execute arbitrary commands with root privileges.

A link following vulnerability in LXD allows an attacker to achieve arbitrary file read and write operations on the host system. When importing or unpacking an image archive, LXD fails to validate whether the metadata.yaml file is a symbolic link. An attacker can exploit this flaw by providing a crafted image archive with a symlinked metadata.yaml file pointing to target file paths on the host system.

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass target project security restrictions during cross-project instance migrations. When moving an instance cross-project to a different cluster member via POST /1.0/instances/{name} with migration: true, project: <target>, and target: <member>, the destination node skips all project restriction checks because the request arrives as an internal cluster notification. An attacker can exploit this to introduce disallowed instance configurations into a restricted project.

Dell Display and Peripheral Manager (DDPM Windows), versions prior to 2.3.0.17, contain Improper Access Control vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges and arbitrary code execution.

Dell Display and Peripheral Manager (DDPM Windows), versions prior to 2.3.0.17, contain Improper Access Control vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges and arbitrary code execution.

Dell Display and Peripheral Manager (DDPM Windows), versions prior to 2.3.0.17, contain an Authentication Bypass by Spoofing vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges and arbitrary code execution.