| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Kimai (kimai/kimai) before 2.65.0 contains a business logic / improper authorization vulnerability in the default team creation endpoints. An authenticated user with project permission-management privileges can create or use a customer, project, or activity whose name matches an existing team; because the endpoints POST /api/customers/{id}/team, POST /api/projects/{id}/team, and POST /api/activities/{id}/team reuse an existing team of the same name and add the current user as teamlead without verifying that the user is authorized to manage that team, the attacker gains unauthorized team-lead (administration) rights over the existing team. Fixed in 2.65.0. |
| The getgrav/grav-plugin-api plugin before 1.0.13 fails to validate that the scopes of a newly created API key are a subset of the caller's scopes in createApiKey. The self-target path of requireApiKeyPermission() requires only the baseline api.access scope, and the new key's scopes are read directly from the request body with no subset check. An attacker holding a minimal-scope API key on a super account can submit an empty scopes array to mint an unscoped, full-access super key, bypassing scope restrictions (and enabling further chains such as configuration write to RCE). |
| Subscriber Privilege Escalation in Buddyboss Platform <= 3.5.0 versions. |
| 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. |
| PraisonAI is a multi-agent teams system. From version 4.5.110 to before version 4.6.61, praisonai.sandbox.SandlockSandbox is documented and implemented as the kernel-enforced sandbox backend for untrusted code. Its SandboxConfig.native() path lets callers configure allowed filesystem paths and network=False. On systems where the optional sandlock module imports but reports that Landlock is unavailable, SandlockSandbox.execute() and run_command() do not fail closed. They silently fall back to SubprocessSandbox(self.config). That fallback keeps the same high-level native policy object but does not enforce the native filesystem or network boundary during code execution. A sandboxed payload can read files outside the configured allowed path and open network connections despite network=False. This issue has been patched in version 4.6.61. |
| Incorrect privilege assignment in the IAM policy of AWS CICD-toolchain-for-serverless-applications 1.0.7 through 1.0.10 allows remote authenticated users with push access to the application source repository to escalate privileges and access or modify resources outside the application stack in the same AWS account via application templates deployed by the toolchain pipeline.
To remediate this issue, users should upgrade existing toolchain stacks to version 1.0.11 or later. |
| MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the GRANT PROXY statement treats an IDENTIFIED clause with an empty password as though authentication were not specified, causing it to check the wrong grantor privileges. A low-privileged attacker who can name another account can exploit this authorization error to set that account's password. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2. |
| n8n before 2.41.5 and 2.42.x before 2.42.2 passes a failed workflow's full execution context, including the identity of the user who started the run, to the configured error workflow. A project editor can set a colleague's workflow settings.errorWorkflow to an error workflow they own, inherit the colleague's identity when that workflow fails, and resolve the colleague's per-user dynamic credential secrets. |
| In the Linux kernel, the following vulnerability has been resolved:
memfd: deny writeable mappings when implying SEAL_WRITE
When SEAL_EXEC is added, SEAL_WRITE is implied to make W^X. But the
implied seal is set after the check that makes sure the memfd can not have
any writable mappings. This means one can use SEAL_EXEC to apply
SEAL_WRITE while having writeable mappings.
This breaks the contract that SEAL_WRITE provides and can be used by an
attacker to pass a memfd that appears to be write sealed but can still be
modified arbitrarily.
Fix this by adding the implied seals before the call for
mapping_deny_writable() is done. |
| A vulnerability was detected in dhikshitha29 Insurance-Management-System 91de5edda5baa109ad8e9baf03ce6a3ceda84183/125362cc21dca20d74091a4913a5096bb58dd837. This vulnerability affects unknown code of the file /Agent/includes/UpdatePolicyHolder-inc.php of the component Policy Holder Update Form. The manipulation of the argument Policy_no results in improper authorization. It is possible to launch the attack remotely. The exploit is now public and may be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The project was informed of the problem early through an issue report but has not responded yet. |
| Incorrect Privilege Assignment vulnerability in Hamid Alinia Login with phone number login-with-phone-number allows Privilege Escalation.This issue affects Login with phone number: from n/a through 1.7.16. |
| A vulnerability was identified in YunaiV ruoyi-vue-pro up to 2025.09. This affects an unknown part of the file /crm/business/transfer. Such manipulation leads to improper authorization. It is possible to launch the attack remotely. The exploit is publicly available and might be used. It is suggested to upgrade the affected component. The vendor confirms: "The controllers check the relevant update permission and obtain the acting user ID from the authenticated server context. The services require CRM OWNER permission and call transferPermission, which explicitly rejects a caller who is neither the owner nor an authorized CRM administrator." |
| A vulnerability was determined in YunaiV yudao-cloud up to 2025.09. Affected by this issue is some unknown functionality of the file /crm/contact/transfer of the component HTTP Request Handler. This manipulation of the argument contactId causes improper authorization. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. The affected component should be upgraded. The vendor confirms: "The controllers check the relevant update permission and obtain the acting user ID from the authenticated server context. The services require CRM OWNER permission and call transferPermission, which explicitly rejects a caller who is neither the owner nor an authorized CRM administrator." |
| A flaw has been found in YunaiV ruoyi-vue-pro up to 2025.09. Impacted is an unknown function of the file /crm/contact/transfer. This manipulation of the argument ids/newOwnerUserId causes improper authorization. The attack is possible to be carried out remotely. The exploit has been published and may be used. You should upgrade the affected component. The vendor confirms: "[T]he current code already checks the functional update permission, uses the authenticated server-side user ID, requires CRM OWNER permission, and explicitly rejects non-owner transfers in the shared transfer service, except for authorized CRM administrators." |
| A security vulnerability has been detected in YunaiV ruoyi-vue-pro up to 2025.09. This vulnerability affects unknown code of the file /crm/contract/transfer. The manipulation of the argument id/newOwnerUserId leads to improper authorization. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. Upgrading the affected component is advised. The vendor confirms: "[T]he current code already checks the functional update permission, uses the authenticated server-side user ID, requires CRM OWNER permission, and explicitly rejects non-owner transfers in the shared transfer service, except for authorized CRM administrators." |
| A weakness has been identified in YunaiV yudao-cloud up to 2025.09. This affects an unknown part of the file /crm/business/transfer. Executing a manipulation of the argument ids/newOwnerUserId can lead to improper authorization. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. It is recommended to upgrade the affected component. The vendor confirms: "[T]he current code already checks the functional update permission, uses the authenticated server-side user ID, requires CRM OWNER permission, and explicitly rejects non-owner transfers in the shared transfer service, except for authorized CRM administrators." |
| A vulnerability was detected in YunaiV yudao-cloud up to 2025.09. This issue affects some unknown processing of the file /crm/receivable/submit. The manipulation of the argument ID results in improper authorization. The attack can be executed remotely. The exploit is now public and may be used. The patch is identified as 0f573e1d8e1a895e1bcbb7740ef75306412c3f9d (master-jdk17). It is best practice to apply a patch to resolve this issue. The vendor confirms: "[W]e have now added the missing per-record CRM WRITE permission check to submitReceivable, the path reported as CVE-2025-10277, in both Boot and Cloud master-jdk17. Possession of a functional submit permission alone no longer permits submission of a record for which the caller lacks CRM write access." |
| An access issue was addressed with improved access restrictions. This issue is fixed in iOS 18.7.11 and iPadOS 18.7.11, iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Tahoe 26.7.2, visionOS 27.2. A malicious app may be able to access the camera without user permission. |
| Incorrect Privilege Assignment vulnerability in M A Vinoth Kumar Frontend Dashboard frontend-dashboard allows Privilege Escalation.This issue affects Frontend Dashboard: from n/a through 3.0.7. |
| Incorrect Privilege Assignment vulnerability in Mitsubishi Electric GENESIS64 versions 10.97.3 and prior, ICONICS Suite versions 10.97.3 and prior, Hyper Historian versions 10.97.3 and prior, AnalytiX versions 10.97.3 and prior, MobileHMI 10.97.3 and prior, MC Works64 all versions, Mitsubishi Electric Iconics Digital Solutions GENESIS64 versions 10.97.3 and prior, ICONICS Suite versions 10.97.3 and prior, Hyper Historian versions 10.97.3 and prior, AnalytiX versions 10.97.3 and prior, and MobileHMI 10.97.3 and prior allows an attacker who can log in using the same administrator account for the affected products to launch and operate DCOM objects locally or remotely. During installation, the installers of the affected products unnecessarily grant default DCOM permissions to the administrator account of the affected products. Users with that administrator accounts can locally or remotely launch and operate DCOM objects that should require UAC elevation. As a result, the attacker may disclose, tamper with, destroy, or delete internal information, or cause the affected system to enter a denial-of-service (DoS) condition. |
