| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Missing Authorization (CWE-862) in Kibana can lead to unauthorized information disclosure via Privilege Abuse (CAPEC-122). A user with limited feature privileges can access workflow execution outputs in their Kibana space without the authorization required to do so through the documented API. The accessible data may include sensitive information returned by workflow steps, such as results from connected data sources that the caller would not otherwise be authorized to access. |
| Missing Authorization (CWE-862) in Kibana can lead to unauthorized cross-space information disclosure via user-supplied input that circumvents space-level access control. |
| The Tutor LMS Elementor Addons plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 4.0.0 This is due to missing capability checks on the `activate_tutor_free()` and `activate_elementor_free()` functions registered as `admin_action_*` handlers. This makes it possible for authenticated attackers, with Subscriber-level access and above, to activate the Tutor LMS and Elementor plugins without proper authorization. |
| SolarWinds Serv-U is affected by a broken access control vulnerability that allows a domain administrator to create system administrator accounts. The impact is lower in Windows deployments. |
| SolarWinds Serv-U is affected by a privilege escalation vulnerability that allows a domain administrator to escalate their user type to that of a system administrator. The impact is lower in Windows deployments. |
| PraisonAI is a multi-agent teams system. Prior to version 4.6.40, the fix for GHSA-9mqq-jqxf-grvw / CVE-2026-44336 is incomplete. The original advisory description named four vulnerable handlers in `mcp_server/adapters/cli_tools.py`. Commit `68cc9427` ("fix(security): harden MCP rules path handling…") added a `_resolve_rule_path()` helper and applied it to `rules.create`, `rules.show`, and `rules.delete`. `workflow.show` was left unchanged. Two adjacent handlers in the same file have the same pattern, `workflow.validate` and `deploy.validate`. Neither was mentioned in the original advisory. Both remained unchanged. The original advisory also identified the dispatcher (`server.py:281-298`) as a root cause. It accepts unvalidated `**kwargs` from `params["arguments"]` with no enforcement against the tool's declared `input_schema`. That code is unchanged prior to version 4.6.40. A single unauthenticated MCP `tools/call` to `praisonai.workflow.show` returns the contents of any file the host user can read: `/etc/passwd`, `~/.ssh/id_rsa`, `~/.aws/credentials`, or any project `.env`. Version 4.6.40 contains an updated fix. |
| Ninja Forms WordPress plugin version 3.14.8 and prior contains a missing authorization vulnerability in the render callback of the `ninja-forms/submissions-table` Gutenberg block that allows authenticated attackers with Author-level privileges to expose stored form submissions to unauthenticated visitors by embedding the block with an arbitrary formID on a published post. Attackers can retrieve the signed bearer token injected into every page visitor's browser via `wp_localize_script` and use it against the REST API submissions endpoint to access all saved form submission field values, including sensitive personally identifiable information such as names, email addresses, and phone numbers. |
| HumHub is an Open Source Enterprise Social Network. In versions 1.13.0 through 1.18.2, a missing authorization check in the Space member management controller allowed any authenticated user to trigger the removal of all members from any Space, regardless of their own role or membership in that Space. Versions 1.13.0 through 1.18.2 are affected. The vulnerability has been patched in version 1.18.3, and all users are encouraged to upgrade to this version or later immediately. No known workaround is available. |
| Missing Authorization (CWE-862) in Kibana allows an authenticated user to access and modify Cloud Connect configuration and service settings without the required feature privileges, via direct requests to insufficiently protected product endpoints. |
| kirby-modules through 5.5.7, fixed in commit 315417e, contains an information disclosure vulnerability that allows any authenticated Kirby Panel user to retrieve the full plaintext commercial license key by sending a GET request to the modules/activate dialog endpoint. The plugin's activate dialog handler in lib/areas.php returns the complete key via ModulesLicense::readKey() without performing an administrator check, as the dialog is gated only by the access.system permission which defaults to true for all non-admin roles, enabling attackers to use the disclosed key to activate the plugin on arbitrary third-party installations. |
| Taiga 6.10.1 contains a missing authorization vulnerability that allows unauthenticated attackers to disclose the full member roster and internal workflow configuration of any private project by supplying a project ID to the filters_data API endpoints on UserStory, Task, Issue, and Epic viewsets. Attackers can send unauthenticated GET requests to the filters_data endpoints with sequential integer project IDs to enumerate private project membership details including user IDs, full names, and gravatar hashes, bypassing the access controls that correctly restrict other project API endpoints. |
| FOG is a free open-source cloning/imaging/rescue suite/inventory management system. Prior to versions 1.5.10.1832 and 1.6.0-beta.2313, the `clearAES` and `clearPMTasks` methods in `FOGPage` can be invoked by an unauthenticated attacker via a single HTTP GET request through the public `client` node endpoint. This allows remote wiping of host AES encryption credentials and deletion of all power management scheduled tasks, with no login, session, or CSRF token required. Versions 1.5.10.1832 and 1.6.0-beta.2313 fix the issue. |
| Network-AI (npm: network-ai) versions 5.12.2 through 5.13.3 fail to apply the configured authorization check (checkAuth/secret) to the ApprovalInbox GET read routes, so even when an operator configures a secret, unauthenticated actors can access sensitive approval request details. The GET /approvals/?status=all, GET /approvals/:id, GET /approvals/stats, and GET /approvals/sse routes disclose full ApprovalEntry content including action/target shell-command strings, file paths, justifications, and risk levels. All responses also carry a hardcoded Access-Control-Allow-Origin: * header, enabling cross-origin disclosure from any website the operator visits. This is an incomplete fix for GHSA-mxjx-28vx-xjjj. |
| PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an authorization bypass enabling owner lockout. The `DELETE /workspaces/{workspace_id}/members/{user_id}` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role="member"`). Any member can remove any other member, including the workspace owner, using a single DELETE. There is no caller-role check, no target-role check, no "cannot remove last owner" guard. PraisonAI Platform version 0.1.4 patches the issue. |
| A missing permission check in Jenkins Contrast Continuous Application Security Plugin 3.11 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using an attacker-specified username, API key, and service key. |
| Missing permission checks in Jenkins Contrast Continuous Application Security Plugin 3.11 and earlier allow attackers with Overall/Read permission to enumerate the names of configured Contrast metadata. |
| PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have a broken workspace authorization check that allows any authenticated low-privilege workspace member to escalate their own role to `owner`. The issue is caused by privileged workspace-management routes using the shared dependency `require_workspace_member(...)` without requiring `admin` or `owner`. The dependency defaults to `min_role="member"`, so routes that should be administrative are accessible to ordinary workspace members. As a result, a normal workspace member can promote their own account from `member` to `owner`; add arbitrary users as `owner` or `admin`; change other members' roles; remove legitimate owners or members; take over workspace membership completely; and/or perform destructive workspace operations after escalation. This is a broken access control / vertical privilege escalation vulnerability. PraisonAI Platform version 0.1.4 patches the issue. |
| PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an authorization bypass enabling workspace metadata + settings tampering. The `PATCH /workspaces/{workspace_id}` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role="member"`). Any member can rewrite the workspace's `name`, `description`, and the `settings` JSON blob. The settings field is a free-form JSON object — depending on which downstream code reads it, this becomes a configuration-injection primitive for any setting the platform exposes there. PraisonAI Platform version 0.1.4 patches the issue. |
| PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an authorization bypass enabling destructive action. The `DELETE /workspaces/{workspace_id}` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role="member"`). Any member of the workspace can issue a single DELETE to wipe the entire workspace, including every project, issue, comment, agent, label, and member record (cascading via the foreign-key relationships). There is no owner-role gate, no confirmation token, no soft-delete window, no recovery path. PraisonAI Platform version 0.1.4 patches the issue. |
| PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have aprivilege escalation / cross-tenant member injection. The `POST /workspaces/{workspace_id}/members` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role="member"`) and forwards the request body's `user_id` and `role` straight into `MemberService.add(workspace_id, user_id, role)`, which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. PraisonAI Platform version 0.1.4 patches the issue. |
