Export limit exceeded: 403128 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 16691 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (16691 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-51892 | 1 Infiniflow | 1 Ragflow | 2026-10-05 | 6.5 Medium |
| infiniflow ragflow 0.24.0 is vulnerable to Incorrect Access Control via /v1/document/get/<doc_id>. | ||||
| CVE-2026-51896 | 1 Infiniflow | 1 Ragflow | 2026-10-05 | 6.5 Medium |
| infiniflow ragflow 0.25.3 contains improper access control in resume (api/apps/connector_app.py). Depending on the exposed entry, an attacker can perform unauthorized cross-session or privilege-crossing operations. | ||||
| CVE-2026-51904 | 2026-10-05 | 9.8 Critical | ||
| SuperAGI up to v0.0.14 contains an improper access control vulnerability in the agent execution controller. In affected source snapshots, create_agent_execution and create_agent_run in superagi/controllers/agent_execution.py accept a caller-supplied agent_id and fail to verify that the referenced agent belongs to the authenticated user's organization. A remote authenticated attacker from one organization can create or start execution records for agents owned by another organization through /agentexecutions/add or /agentexecutions/add_run. | ||||
| CVE-2026-51914 | 1 Transformeroptimus | 1 Superagi | 2026-10-05 | 8.8 High |
| TransformerOptimus SuperAGI v0.0.14 is vulnerable to Incorrect Access Control in the agent template controller. In affected source snapshots, save_agent_as_template and publish_template in superagi/controllers/agent_template.py accept caller-supplied agent_id or agent_execution_id values and do not verify that the referenced agent or execution belongs to the authenticated user's organization. | ||||
| CVE-2026-105121 | 1 Openidentityplatform | 1 Openam | 2026-10-05 | 4.9 Medium |
| OpenAM before 16.1.3 contains an improper authorization vulnerability that allows delegated administrators to destroy sessions outside their realms because realm checks use the requester's realm. Authenticated accounts holding the iplanet-am-session-destroy-sessions attribute can supply a target session identifier or handle to forcibly log out users in any realm. | ||||
| CVE-2026-51894 | 1 Infiniflow | 1 Ragflow | 2026-10-05 | 6.5 Medium |
| infiniflow ragflow 0.24.0 is vulnerable to Incorrect Access Control via run_mindmap. A reachable path accepts a caller-selected object or tenant identifier and reaches a data-access operation without a visible owner, tenant, workspace, or membership binding on that object. | ||||
| CVE-2026-51879 | 1 Hkuds | 1 Deeptutor | 2026-10-05 | 9.1 Critical |
| deeptutor 1.4.0 contains an authorization bypass through a user-controlled object identifier in TutorBotManager.write_bot_file. A remote caller can enumerate bot IDs and overwrite another bot's whitelisted control files through the HTTP tutorbot file route. | ||||
| CVE-2026-51893 | 2026-10-05 | 9.8 Critical | ||
| infiniflow ragflow 0.24.0 is vulnerable to Incorrect Access Control via trace_mindmap. An externally reachable path accepts a caller-selected object or tenant identifier and reaches a data-access operation without a visible owner, tenant, workspace, or membership binding on that object. | ||||
| CVE-2026-105632 | 1 Makeplane | 1 Plane | 2026-10-05 | N/A |
| Plane is an open-source project management tool. Prior to 1.4.0, the GraphQL joinProject mutation lets any workspace member add themselves to any project in that workspace including network=0 (secret/private) projects they were never invited to and grants them a full Member role (read + write). The resolver checks only workspace-level membership/role and never checks the target project's visibility (network). This collapses project-level tenant isolation within a workspace: a low-privilege member can read and modify confidential data in every private project. This issue is fixed in 1.4.0. | ||||
| CVE-2026-104974 | 1 Makeplane | 1 Plane | 2026-10-05 | 8.1 High |
| Plane is an open-source project management tool. Prior to 1.4.0, a user whose account has been deactivated by setting is_active=False can still log in with existing credentials. Successful authentication silently changes is_active back to True, reactivating the account without notifying the administrator. This issue is fixed in 1.4.0. | ||||
| CVE-2026-105635 | 1 Makeplane | 1 Plane | 2026-10-05 | 7.4 High |
| Plane is an open-source project management tool. Prior to 1.4.0, ProjectJoinEndpoint at GET /api/workspaces/{slug}/projects/{project_id}/join/{pk}/ uses permission_classes = [AllowAny] and returns the full ProjectMemberInvite record, including its email, token, and role, to unauthenticated callers. The corresponding POST endpoint checks only whether the submitted email matches project_invite.email and does not validate the invitation token. An attacker who knows the invitation UUID can discover the invited email, register an account with that email, and accept the invitation without receiving the original invite. This issue is fixed in 1.4.0. | ||||
| CVE-2026-105640 | 1 Makeplane | 1 Plane | 2026-10-05 | 9.1 Critical |
| Plane is an open-source project management tool. Prior to 1.4.0, Plane trusts email addresses returned by Gitea OAuth and by self-managed GitLab OAuth deployments where email confirmation is disabled, without verifying that the provider authenticated ownership of the address. An attacker can set an OAuth identity's unverified provider email to a victim's address, which Plane matches directly to the victim's existing local account. The attacker can then log in to the victim's Plane account without knowing the victim's password. GitHub, GitLab.com, and Google are not affected because those providers return verified email addresses. This issue is fixed in 1.4.0. | ||||
| CVE-2026-103085 | 2026-10-05 | 6.5 Medium | ||
| Improper Access Control vulnerability in WP User Manager WP User Manager wp-user-manager allows Privilege Abuse.This issue affects WP User Manager: from n/a through 2.9.20. | ||||
| CVE-2026-105382 | 1 Onetwothreeneth | 1 Hospitalmanagementsystem | 2026-10-05 | 7.3 High |
| A flaw has been found in onetwothreeneth HospitalManagementSystem up to 9ef91ed6007314b6473110ed699dff76d158f61d. This affects the function update_subaccount of the file php/controller.php of the component Account Administration. This manipulation of the argument user_id causes improper authorization. Remote exploitation of the attack is possible. The exploit has been published and may be used. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-97324 | 2 Yunaiv, Zhijiantianya | 2 Ruoyi-vue-pro, Ruoyi-vue-pro | 2026-10-05 | 7.3 High |
| A vulnerability was identified in YunaiV/zhijiantianya ruoyi-vue-pro up to 2026.08. Affected is the function updateDemoOrderPaid of the file yudao-module-pay/src/main/java/cn/iocoder/yudao/module/pay/controller/admin/demo/PayDemoOrderController.java of the component Demo-order Payment Callback Handler. The manipulation of the argument ID leads to improper authorization. The attack can be initiated remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-94606 | 1 Goauthentik | 1 Authentik | 2026-10-05 | 8.9 High |
| authentik is an open-source identity provider. Prior to 2026.2.7, 2026.5.7, and 2026.8.2, authentik email authenticator enrollment during an authentication or enrollment flow accepts a recipient address supplied in the setup request instead of using the address already established by the flow. An actor who knows a target user's password can substitute an attacker-controlled address, receive the one-time code, and finish enrolling the factor as the target. The target must not have enrolled the email factor already. Successful enrollment gives the actor a session as the target and access to single sign-on applications behind the account. Other authenticator types are not affected. This issue is fixed in versions 2026.2.7, 2026.5.7, and 2026.8.2. | ||||
| CVE-2026-85057 | 1 Zitadel | 1 Zitadel | 2026-10-05 | 8.7 High |
| ZITADEL is an open source identity management platform. From 3.0.0 until 3.4.13 and 4.16.1, ZITADEL Actions V1 enables the goja Node-compatible require() registry without restricting its filesystem source loader. An organization Action author with ORG_OWNER, org.action.write, and org.flow.write permissions can run JavaScript at OIDC, SAML, and login-flow trigger points and load files readable by the ZITADEL server process. This can disclose mounted configuration and secrets, including credentials stored through ZITADEL_FIRSTINSTANCE_LOGINCLIENTPATPATH or ZITADEL_FIRSTINSTANCE_MACHINEKEYPATH, and recovered bootstrap credentials can enable escalation from an organization administrator to an instance administrator. The issue affects Actions V1, and host command execution is not established. This issue is fixed in versions 3.4.13 and 4.16.1. | ||||
| CVE-2026-77321 | 1 Mauriceboe | 1 Trek | 2026-10-05 | 4.3 Medium |
| TREK is a collaborative travel planner. Prior to 3.3.0, the get_trip_summary tool in server/src/mcp/tools/trips.ts is registered for scoped OAuth MCP tokens without requiring trips:read and returns core trip summary data regardless of the delegated scopes. A token granted only an unrelated capability, such as weather:read, can receive trip metadata, member email addresses from server/src/services/tripService.ts, itinerary days, and accommodations for every trip accessible to the token's user. Cross-user trip authorization remains enforced, but the missing scope check defeats the consented least-privilege boundary and exposes trip content and third-party contact information to an MCP client that was not authorized to read it. This issue is fixed in version 3.3.0. | ||||
| CVE-2026-71886 | 1 Legion Of The Bouncy Castle Inc. | 1 Bc-java | 2026-10-05 | N/A |
| In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component's binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker's assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key's signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key's identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it. | ||||
| CVE-2026-71885 | 1 Legion Of The Bouncy Castle Inc. | 1 Bc-java | 2026-10-05 | N/A |
| In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key carried in the leaf itself, while the credential's X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate's public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party's certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party's identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim's X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate's subject public key, in the cipher suite's signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application's responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected. | ||||