Export limit exceeded: 416127 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (15845 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-109433 1 Camunda 1 Camunda 7 2026-10-23 6.5 Medium
Camunda 7.24.0 before 7.24.16 and 7.23.0 before 7.23.17 contains an authorization bypass vulnerability in the Cockpit webapp that allows authenticated attackers to bypass permission checks due to an inverted comparison logic in AbstractCockpitPluginResource.isPermissionDisabled(). Attackers with minimal Cockpit access can exploit a non-empty disabledPermissions configuration to read all process instances, process definitions, and incidents engine-wide without triggering any logging, regardless of their actual data grants.
CVE-2026-70083 1 Microsoft 14 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 11 more 2026-10-23 5.5 Medium
Incorrect authorization in DNS Server allows an authorized attacker to perform tampering locally.
CVE-2026-115370 1 Linuxcontainers 1 Incus 2026-10-23 4.3 Medium
Incus 6.0.5 before 6.0.7, 6.12.0 before 7.0.2, and 7.1.0 before 7.5.0 contains a restriction bypass vulnerability that allows restricted project users to use pull mode migration via clustered refresh requests. Attackers with instance creation rights can send a refresh migration request for an existing instance to make the server open outbound TLS websocket connections and probe reachable services.
CVE-2026-115364 1 Openbao 1 Openbao 2026-10-23 2.2 Low
OpenBao before 2.6.3 contains a missing authorization check that allows attackers to stop Agent and Proxy services by omitting the X-Vault-Header. When require_request_header is enabled, attackers can send requests via server-side request forgery to /agent/v1/quit or /proxy/v1/quit to shut down these services.
CVE-2026-114515 1 Schorschii 1 Oco-server 2026-10-23 6.5 Medium
OCO-Server is a self-hosted endpoint management application for computer inventory, software deployment, and mobile device management. Prior to 1.2.3, a valid Self-Service Portal user with permission to create job containers and read visibility on a computer and package can queue an uninstall job without deploy permission for those resources. Requests to `self-service/ajax-handler/job-containers.php` pass `uninstall_package_assignment_id[]` values to `lib/SelfService/CoreLogic.class.php::uninstallSelfService()`. Its permission-check loop continues after denied `METHOD_DEPLOY` checks without removing rejected IDs from `$installationIds`, then passes the original list to `lib/CoreLogic.class.php::uninstall()`. The CoreLogic object is constructed with a null SystemUser, causing `lib/CoreLogic.class.php::checkPermission()` to treat the operation as system context and unconditionally permit it. Enumerable `computer_package.id` values allow selection of readable installed-package assignments, including those on other users' computers. The `deploySelfService()` install path instead aborts on denied deployment permission, and resources lacking read permission remain blocked. This permits unauthorized software-removal jobs across resources visible to the acting user's role. This issue is fixed in version 1.2.3.
CVE-2026-114132 1 Nuxt 1 Nuxt 2026-10-23 N/A
Nuxt is an open-source web development framework for Vue.js. Prior to 4.6.2, Nuxt resolves pages case-insensitively by default while Nitro matches server-side route-rule keys case-sensitively, allowing a request whose path differs only by letter case to render without the server rule intended for that page. The mismatch can skip redirect, headers, proxy, ssr: false, and noScripts, and can cause getRouteRules(event) and matchRouteRules to return no rule for the case variant. Applications that set router.options.sensitive: true in nuxt.config are not affected; setting sensitive only in app/router.options.ts does not establish this exclusion because the server follows the nuxt.config value. Access checks implemented in server middleware, page route middleware, or page data fetching remain independent of this matcher. This issue is fixed in version 4.6.2.
CVE-2026-111668 1 Beizhu-1209 1 Aihelms 2026-10-23 5.4 Medium
AIHelms through 0.1.25 contains a missing authorization vulnerability in apps/api/v1/efficiency.py that allows authenticated low-privileged users to bypass efficiency:read and efficiency:write permission checks. Attackers can query routes like /cost/detail, /top-users and /budget to read organization-wide AI spend, and can modify suggestion statuses or generate reports.
CVE-2026-106461 2 Backstage, Linuxfoundation 4 Backstage, Plugin-scaffolder-backend, Backstage and 1 more 2026-10-23 4.3 Medium
Backstage is an open framework for building developer portals. Prior to 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by incorrect authorization in scaffolder task listing. An authenticated internal user may be able to view metadata for scaffolder tasks outside the visibility intended by a deployment's permission policy. Stored task secrets are not included in the affected response, and no integrity or availability impact was identified. This issue is fixed in version 4.1.0.
CVE-2026-115502 1 Knime 1 Business Hub 2026-10-23 N/A
A missing authorization check allows anyone having access to a "link without login" for a DataApp to list and potentially access jobs of other users created by the same link in KNIME Business Hub prior to 1.19.0. As workaround remove all "links without login" to DataApps.
CVE-2026-115509 1 Jitsucom 1 Jitsu 2026-10-23 4.2 Medium
Jitsu console before 2.14.0-beta.41 contains an incorrect authorization vulnerability in sources/state.ts handlers that call findFirst without await, so the syncId ownership check never fails. Authenticated users knowing another workspace's sync ID can read, overwrite or delete its stream cursors, causing data re-ingestion or skipped data.
CVE-2026-115369 1 Openbao 1 Openbao 2026-10-23 2.2 Low
OpenBao from 2.5.0 before 2.6.2 fails to enforce the PKI role allowed_ip_sans_cidr restriction on IP SANs taken from a CSR when use_csr_sans is enabled. Authenticated callers with sign permission can submit a CSR with an out-of-range IP SAN to pki/sign/<role> and obtain CA-signed certificates for unauthorized IPs.
CVE-2026-115365 1 Openbao 1 Openbao 2026-10-23 6.6 Medium
OpenBao from 2.3.0 before 2.6.3 contains an incorrect authorization vulnerability in its ACL policy cache that allows tokens to reference policies from arbitrary namespaces using specially crafted policy names. Attackers holding such tokens can gain capabilities of cached policies in other namespaces, including the root namespace, to act across namespace boundaries.
CVE-2026-113595 1 Sharkord 1 Sharkord 2026-10-23 4.3 Medium
Sharkord before 0.0.26 contains a missing authorization vulnerability in the others.changeLogo tRPC mutation that allows any authenticated member to modify the server logo without the MANAGE_SETTINGS permission. Attackers can remove the current logo and replace it with an uploaded image that is published to every connected client.
CVE-2026-56836 1 Mervinpraison 1 Praisonai 2026-10-23 8.2 High
PraisonAI is a multi-agent teams system. From version 4.5.112 to before version 4.6.59, PraisonAI's installed console entrypoint is Typer-first. In current releases, the recipe command is registered in the Typer app and praisonai recipe serve dispatches to the deprecated Typer command in src/praisonai/praisonai/cli/commands/recipe.py. That Typer command can start the Recipe HTTP server on a non-localhost interface with no authentication. It prints a deprecation warning, and then launches the server. Because config.auth is absent, create_app() does not attach the API-key or JWT middleware. Unauthenticated requests can then reach the recipe API and, when enabled, /admin/reload. This issue has been patched in version 4.6.59.
CVE-2026-56838 1 Mervinpraison 1 Praisonai 2026-10-23 7.8 High
PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.59, PraisonAI recipe execution blocks default-denied dangerous tools unless the caller explicitly passes allow_dangerous_tools=True. The normal recipe.run() path enforces this with _check_tool_policy(). The streaming path, recipe.run_stream(), loads the same recipe, checks dependencies, and then calls _execute_recipe() without running the dangerous-tool policy check. As a result, a recipe that honestly declares execute_command in TEMPLATE.yaml requires.tools is denied by recipe.run(), but reaches the execution engine through recipe.run_stream() with allow_dangerous_tools=False. This issue has been patched in version 4.6.59.
CVE-2026-57116 1 Mervinpraison 1 Praisonai 2026-10-23 9.8 Critical
PraisonAI is a multi-agent teams system. From version 4.2.1 to before version 4.6.59, PraisonAI's AgentOS FastAPI deployment surface remains unauthenticated in current main and in releases after the published patched version for GHSA-pm96-6xpr-978x / CVE-2026-40151. The chat route directly calls agent.chat(request.message). No-auth and wrong-bearer requests both execute the deployed agent. This is broader than passive metadata disclosure. In any deployment where AgentOS wraps agents with tools, private context, memory, API integrations, or cost-bearing model calls, an unauthenticated reachable client can drive those agents. This issue has been patched in version 4.6.59.
CVE-2026-57142 1 Mervinpraison 1 Praisonai 2026-10-23 7.8 High
PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.61, PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools. For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context. As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool. This issue has been patched in version 4.6.61.
CVE-2026-57117 1 Mervinpraison 1 Praisonai 2026-10-23 8.8 High
PraisonAI is a multi-agent teams system. From version 4.6.10 to before version 4.6.59, LocalManagedAgent / SandboxedAgent compute bridging wraps read_file, list_files, and write_file when a compute provider is attached. The bridge converts those file operations into shell command strings using raw path arguments, then sends those strings to shell-backed compute providers. An attacker who can influence a file-tool path argument can break out of the quoted path and execute arbitrary shell commands in the compute environment. With compute="local", commands execute through the local subprocess compute provider on the host. With Docker, commands execute in the container. This issue has been patched in version 4.6.59.
CVE-2026-56832 1 Mervinpraison 1 Praisonai 2026-10-23 8.8 High
PraisonAI is a multi-agent teams system. From version 4.5.2 to before version 4.6.59, praisonai.bots.DiscordApproval approves a pending dangerous tool call when it sees any later non-bot message in the configured Discord channel whose text is classified as approval, such as yes. As a result, any user who can post in the configured approval channel can approve a pending high-risk tool call by sending yes after the approval message appears. the same PoV also shows that the Slack and Telegram messaging approval backends have no explicit approver allowlist parameter, but the primary report-grade issue is the Discord backend's unthreaded channel cross-talk: the approving message does not need to be a reply or otherwise request-bound. This issue has been patched in version 4.6.59.
CVE-2026-56835 1 Mervinpraison 1 Praisonai 2026-10-23 8.3 High
PraisonAI is a multi-agent teams system. From version 3.11.0 to before version 4.6.59, PraisonAI's Slack bot applies its configured allowed_users, allowed_channels, and unknown-user pairing policy in the normal Slack message event handler, but not in the adjacent Slack app_mention event handler. A Slack workspace user who can mention the bot in a channel where the Slack app is present can trigger the configured PraisonAI agent even when: the sender is not in BotConfig.allowed_users; the channel is not in BotConfig.allowed_channels; unknown_user_policy="deny" is configured; and the same event content is correctly dropped by the normal message handler. This issue has been patched in version 4.6.59.