CVE-2026-63095
Dendrite through 0.13.8 contains an improper authorization vulnerability in the Matrix Client-Server API that allows any authenticated local
CVSS
6.5
Medio
EPSS
0.2%
p8
KEV
—
Exploit Today
2
0-100
Publicado: 17 jul 2026 · Última mod.: 17 jul 2026 · CWE-639
0.2%EPSS · 30 días0.2%
2026-07-182026-08-07
Dendrite through 0.13.8 contains an improper authorization vulnerability in the Matrix Client-Server API that allows any authenticated local user to delete third-party identifier bindings belonging to other users by submitting an arbitrary address and medium to the account deletion endpoint without ownership verification. Attackers can exploit the unverified Forget3PID handler to remove a victim's email or MSISDN binding and subsequently rebind the address through an identity server to hijack the victim's password reset flow.
- github.comhttps://github.com/geo-chen/oss/blob/main/dendrite.md#finding-1-idor-in-post-account3piddelete-allows-any-authenticated-user-to-remove-any-other-users-third-party-identifier
- www.vulncheck.comhttps://www.vulncheck.com/advisories/dendrite-improper-authorization-via-post-account-3pid-delete-endpoint
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-481698.8 ALT—
——0PraisonAI is a multi-agent teams system. Versions prior to 0.1.4 of the PraisonAI Platform API have two authorization failures that together break workspace isolation. The service layer for issues and projects performs global primary-key lookups without checking workspace ownership, so any authenticated user can read, modify, and delete resources in any workspace just by swapping UUIDs in their API requests. On top of that, every member management endpoint (add, update role, remove) only requires `min_role="member"`, which lets any workspace member promote themselves to owner and kick out the original owner. A low-privilege member of one workspace can steal data from every other workspace and take over any workspace they belong to. Both issues come from the same gap: the route layer pulls `workspace_id` from the URL and verifies membership, but the service layer ignores the workspace scope for resource lookups and ignores the caller's role level for member operations. The `require_workspace_member()` dependency does its job correctly. The problem is that the service layer doesn't use the information it provides. Version 0.1.4 of the PraisonAI Platform API patch the issue.21hCVE-2026-705616.5 MED—
——0TestLink 1.9.20 and prior contains an insecure direct object reference vulnerability that allows any authenticated user, including low-privilege guest accounts, to read arbitrary attachments by supplying an integer attachment ID to the attachmentdownload.php handler without any project or role authorization check. Attackers can enumerate sequential integer IDs through the attachment download endpoint to retrieve file contents from private projects they have no membership in, bypassing the per-project access control model and exposing test specifications, requirements documents, execution evidence, and other sensitive uploaded files across the entire installation.1dCVE-2026-66058——
——0Frappe is a full-stack web application framework. Prior to 16.20.0 and 15.112.0, unrestricted access to a Document Follow API (update_follow) is possible for an authenticated user.
This issue is fixed in versions 16.20.0 and 15.112.0.1dCVE-2026-160396.5 MED3.2%
——1The MStore API WordPress plugin before 4.21.0 does not restrict its vendor-orders endpoint to the caller's own orders, allowing any authenticated user, including Subscribers, to read every WooCommerce order in the store together with each customer's personal information.1dCVE-2026-152144.3 MED3.2%
——1The Subscriptions for WooCommerce WordPress plugin before 2.0.1 does not verify that the requester owns the subscription being viewed before rendering its details, allowing any authenticated customer to read another customer's subscription information (the subscribed product, status, and dates) by supplying that subscription's ID.1dCVE-2026-705576.5 MED26.5%
——8diboot-core's POST /common/load-related-data endpoint resolves caller-supplied field names to any @TableField column of any entity and returns those values for all rows, with no field or entity allowlist. The only guard, relatedDataSecurityCheck(), returns true unconditionally, so any authenticated user (including a zero-role account) can read @JsonIgnore-annotated secret fields such as IamAccount.authSecret and IamAccount.secretSalt for every account, or arbitrary secret fields of any other entity. Shiro's two-iteration MD5 with an 8-character salt is trivially crackable offline, so the disclosed admin password hashes convert to full administrative takeover. The endpoint is not example code; the official diboot-admin-ui frontend requires it, so deployments following the vendor's recommended integration expose it. The mechanism was renamed relatedData* to attachMore* on the development branch, but attachMoreSecurityCheck() also returns true unconditionally.1d