| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Affected versions of MISP incorrectly filter dashboard templates that are restricted to a specific permission flag.
DashboardsController::listTemplates() allowed a template when either:
- its restrict_to_permission_flag matched one of the current user’s permission flags, or
- restrict_to_permission_flag equaled integer 0
However, restrict_to_permission_flag is a varchar. MySQL therefore performed numeric coercion when comparing the column against integer 0. Strings such as perm_site_admin convert numerically to zero, making expressions such as perm_site_admin = 0 evaluate true and causing the “unrestricted” branch to match permission-restricted templates as well.
Version affected: ≤2.5.45 |
| Affected versions of MISP allow a collection element to be created from a bare UUID without consistently checking whether the acting user is allowed to access the referenced object.
The commit explains that collection elements themselves only store UUIDs, while the collection view later resolves those UUIDs into their underlying objects. Before this fix, the generic add() path could therefore persist a UUID for an Event or Galaxy Cluster that the caller could not normally read. The patch explicitly notes that this made collections a way to reference another organisation’s private data and had caused disclosure of organisation-only events in the beta collection view.
The fix centralizes authorization in __assertCanUseElements(). Event UUIDs are validated through Event::fetchSimpleEvent() under the current user’s ACL, while Galaxy Cluster UUIDs are checked through GalaxyCluster::fetchGalaxyClusters(). The check is applied both to the CRUD add() path and to addElementToCollection().
Version affected: ≤2.5.45 |
| In multiple functions of NfcService.java, there is a possible silent payment session hijacking enablement due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| A security flaw has been discovered in wxiaoqi Spring-Cloud-Platform 1.0/2.2/3.0. This issue affects the function OnlineController.getOnlineInfo of the file aceModules/ace-admin/auth/controller/OnlineController.java. The manipulation results in missing authorization. The attack can be executed remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet. |
| An authenticated supplicant on an adjacent network may bypass intended network authorization policy and send unrestricted traffic during a brief window (milliseconds to seconds) between the completion of the authentication phase and the full enforcement of its assigned ACL. |
| Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Prior to 1.7.4 and 1.8.1, an HTTPRoute can use an extension-managed custom backendRef to reference a backend resource in another namespace without a matching Gateway API ReferenceGrant in the target namespace. The custom-backend branch in internal/gatewayapi/route.go omits validateBackendNamespace, allowing the route-owning namespace to bind to and use the resource without the backend namespace owner's consent and violating the Gateway API cross-namespace authorization model. This issue is fixed in versions 1.7.4 and 1.8.1. |
| Kimai is an open-source time tracking application. Prior to 2.58.0, PATCH /api/timesheets/{id}/restart, PATCH /api/timesheets/{id}/duplicate, and the web duplicate workflow can derive a new record from an owned historical timesheet after the user's access to its project or activity has been revoked. TimesheetVoter evaluates the own-timesheet permission before current team access, and its canStart() logic validates object visibility but does not verify the user's current team access to the referenced project and activity. An old entry therefore acts as a persistent capability to create new time records under an unauthorized project and activity, corrupting budgets, statistics, reports, and invoices after an administrative revocation. This issue is fixed in version 2.58.0. |
| In writeToParcel of BleRssiRangingCapabilities.java, there is a possible way to obtain the Bluetooth MAC address due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In getQueryBuilderInternal of MediaProvider.java, there is a possible way to retrieve location metadata due to a permissions bypass. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple functions of RangingServiceImpl.java, there is a possible MITM due to a missing permission check. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| Semaphore UI through 2.19.12 exempts GET and HEAD requests from project resource permission checks in GetMustCanMiddleware. Attackers with guest or task_runner roles can read all project environments including plaintext secrets, credentials, and passwords via GET requests to the environment endpoint. |
| PraisonAI is a multi-agent teams system. From 1.4.0 until 1.7.2, createAgentLoop() in src/praisonai-ts/src/ai/agent-loop.ts passes executable tools to generateText() before invoking the onToolCall approval callback. Because the wrapped AI SDK executes tool handlers during generation, a callback that returns false records tool_rejected only after the denied tool has already produced side effects and populated toolResults. Applications using onToolCall as a human or policy approval boundary can therefore execute rejected file, command, API, or data-modifying operations. This issue is fixed in version 1.7.2. |
| PraisonAI is a multi-agent teams system. From 1.2.3 until 1.7.2, CommandValidator in src/praisonai-ts/src/cli/features/sandbox-executor.ts validates only the first whitespace-delimited executable against allowedCommands, then SandboxExecutor passes the complete command string to sh -c. A command beginning with an allowed executable can append a non-allowlisted command through shell metacharacters, causing arbitrary commands to run with the PraisonAI process privileges. This issue is fixed in version 1.7.2. |
| PraisonAI is a multi-agent teams system. From 1.5.1 until 1.7.2, MCPSecurity.evaluatePolicy() in src/praisonai-ts/src/mcp/security.ts invokes the configured credential validator only when AuthMethod is api-key or bearer. Basic and OAuth policies accept any non-empty Authorization header without calling auth.validate(), then return an authenticated result, allowing callers with invalid credentials to access MCP tools and resources protected by those policies. This issue is fixed in version 1.7.2. |
| Kimai is an open-source time tracking application. Prior to 2.58.0, ExportController::createExportTemplate() and ExportController::editExportTemplate() inherit only the class-level create_export permission, which ROLE_TEAMLEAD receives by default, and omit the create_export_template permission required by the API routes and user interface. A teamlead can directly access the export template creation and editing web routes to create or modify global ExportTemplate records marked available to all users, altering export columns, renderer, format, and output used by other users and administrators. This issue is fixed in version 2.58.0. |
| Kimai is an open-source time tracking application. Prior to 2.58.0, POST /api/teams/{id}/members/{userId} and POST /api/teams/{id}/activities/{activityId} verify that a teamlead may edit the Team but do not verify access_user for the referenced User or view access for the referenced Activity. A teamlead can add users or activities outside the teamlead's manageable scope to an editable team, bypassing the narrower choices enforced by TeamEditForm and UserRepository::getQueryBuilderForFormType(). The resulting relationships can be trusted by RolePermissionManager::checkTeamAccessActivity() and other team-based authorization, visibility, reporting, and workflow logic. This issue is fixed in version 2.58.0. |
| PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.59 and praisonaiagents 1.6.59, the unauthenticated POST /api/v1/runs Jobs API accepts attacker-controlled agent_yaml, and the approve field can mark execute_command as YAML-approved before @require_approval checks critical tools. This chain allows a remote caller to cause a configured language model agent to invoke arbitrary operating-system commands without credentials or operator interaction. This vulnerability is fixed in praisonai 4.6.59 and praisonaiagents 1.6.59 as fixed versions. |
| SpiceDB is an open source database system for creating and managing security-critical application permissions. From 1.34.0 until 1.54.0, SpiceDB can return PERMISSIONSHIP_HAS_PERMISSION instead of PERMISSIONSHIP_CONDITIONAL_PERMISSION or PERMISSIONSHIP_NO_PERMISSION because checkRequestToKey() and checkRequestToKeyWithCanonical() in internal/dispatch/keys/computed.go omit CheckHints when constructing dispatch Check cache keys. The incorrect result requires a permission combining relations with intersection or exclusion, a subject reachable through caveated and non-caveated branches, LookupResources with a context parameter running concurrently with CheckPermission or CheckBulkPermissions for the same resource and subject, and an enabled dispatch result cache. Under these conditions, a result computed for one hint set can poison the cache entry used by a semantically different authorization check, allowing permission without satisfying the caveat. This issue is fixed in version 1.54.0. |
| Casdoor through 4.4.0 fails to properly mask the instance-wide built-in certificate private key in /api/get-certs and /api/get-cert endpoints, allowing organization administrators to retrieve it. Attackers can use the exposed private key to forge JWT tokens for any user in any organization, including global administrators. |
| The application's role-authorization lookup defaults to granting access when a request handler's name is not present in its table of role requirements, rather than defaulting to deny. Any request handler that is not explicitly registered in this table is reachable by any authenticated user regardless of their assigned role, and any newly added handler is fail-open by default until explicitly added to the table. |
