Manus-Pi

SiYuan before v3.8.5 contains an information disclosure vulnerability that allows read-only publish readers to learn metadata of publish-excluded documents through the getNotebookInfo endpoint. Attackers, including anonymous visitors when no reader password is set, can query publish-visible notebooks to obtain document count, size and modification timestamps of hidden documents.

SiYuan before v3.8.5 contains a missing authorization vulnerability in the getRefCreateSavePath, getShorthandSavePath, and getDocCreateSavePath endpoints that allows read-only publish visitors to learn unpublished notebook box IDs. Attackers with read-only or anonymous publish access can POST any open notebook ID to receive the global save-box ID and save-path template, revealing a hidden notebook's existence and creation time.

SiYuan before 3.8.5 contains an information disclosure vulnerability that allows publish readers to read password-protected and publish-disabled database rows via the /api/export/preview endpoint. Attackers can request an export preview of a public document embedding a database view to obtain protected rows' primary-key text and cell values.

Tornado before 6.5.9 fails to limit the number of query string fields in HTTPServerRequest. init , allowing remote attackers to cause event-loop stalling by sending requests with thousands of query parameters. Attackers can send unauthenticated GET requests with unbounded query-string field counts to degrade response times for all clients sharing the same IOLoop.

**Name of the Vulnerable Software and Affected Versions** SiYuan versions prior to 3.8.4 **Description** Insufficient validation of SQL statements in block query embed blocks executed against `siyuan.db` allows for the execution of non-read-only SQL statements. An attacker can create malicious `.sy` documents that trigger these statements automatically during background indexing, rendering, or export operations without requiring authentication. **Recommendations** Update to version 3.8.4 or later.

**Name of the Vulnerable Software and Affected Versions** ash authentication versions 5.0.0-rc.10 through 5.0.0-rc.13 **Description** An authentication bypass by spoofing exists in the `dynamic oidc` strategy. This allows an attacker using one identity-provider connection to be signed in as a local user associated with a different connection. The issue occurs because the intended identity namespacing, which should format the `strategy` field of `UserIdentity` rows as `"<name>/<connection id>"`, is not applied. Instead, the ` connection id ` variable is only populated on an ephemeral runtime struct and is not used during the identity change process in the `DynamicOidc.IdentityChange.change/3` function. Consequently, the system falls back to the bare strategy name for identity writes and reads in `oauth2/user resolver.ex` and `oauth2/sign in preparation.ex`. Because the unique key for the identity resource is `(uid, strategy)` and the system does not handle the `iss` (issuer) claim, users from different providers with the same `sub` (subject) value are treated as the same user. This can lead to account takeover without victim interaction or the silent merging of distinct users who happen to share the same subject identifier across different providers. **Recommendations** For versions 5.0.0-rc.10 through 5.0.0-rc.13, update the software to version 5.0.0-rc.14 or later. After updating, each `UserIdentity` row's `strategy` field must be manually relinked to the `"<name>/<connection id>"` format to ensure existing identities match the new namespacing logic. For deployments using more than one connection, perform an out-of-band audit by exporting `sub` values from each identity provider and intersecting them to identify and resolve accounts that may have been merged.

**Name of the Vulnerable Software and Affected Versions** fast-uri versions 4.1.3 through 4.1.4 **Description** The mailto parser compares query field names to reserved names such as `to`, `subject`, and `body` while they are still percent-encoded. Because the parser only decodes these names when storing them as generic headers, a percent-encoded version of a reserved field name is not recognized during the initial parse but is re-emitted as the literal field name during serialization. This desynchronization allows an attacker to smuggle a chosen recipient, subject, or body field across a roundtrip if an application validates the URI from the first parse and then serializes and sends it. **Recommendations** Update fast-uri to version 4.1.5 or later. As a temporary workaround, do not act on a mailto URI that has been re-serialized without first decoding and re-validating the `recipient`, `subject`, and `body` fields.