CVE-2026-15036
A vulnerability was determined in Harness up to 2.28.2. This vulnerability affects the function getAuthorizedSpaces of the file app/api/cont
CVSS
4.3
Medium
EPSS
0.4%
p32
KEV
—
Exploit Today
10
0-100
Published: Jul 8, 2026 · Last modified: Jul 9, 2026 · CWE-285 · CWE-639
0.4%EPSS · 30 days0.4%
2026-07-092026-07-21
A vulnerability was determined in Harness up to 2.28.2. This vulnerability affects the function getAuthorizedSpaces of the file app/api/controller/gitspace/list_all.go of the component gitspaces Endpoint. Executing a manipulation can lead to authorization bypass. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-632594.3 MED—
———Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana can lead to information disclosure via user-supplied identifiers that reference scheduled query result data from Kibana Spaces the requester is not authorized to access.2hCVE-2026-653166.5 MED—
———XXL-Job version 2.4.2 contains an insecure direct object reference vulnerability that allows authenticated users to read execution log content from job groups they are not authorized to access by supplying arbitrary sequential log IDs to the logDetailCat endpoint. Attackers can enumerate log records across all job groups by calling the logDetailCat endpoint with incremented logId parameter values, bypassing the permission check present in the sibling logDetailPage endpoint, and retrieve sensitive log content from restricted job groups.3hCVE-2026-561477.1 HIG—
———Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana can lead to unauthorized information disclosure and case attachment integrity compromise via Privilege Abuse (CAPEC-122). An inconsistency in Kibana's file access authorization logic allows a low-privileged authenticated user to retrieve, modify, and delete case attachments that belong to feature areas they are not authorized to access. Because the access control check and the resource retrieval use different resolution mechanisms, an authenticated attacker with limited file management permissions can obtain the contents of, modify, or delete protected case attachments — such as those associated with Security Solution cases — without holding the privileges required to access those features.4hCVE-2026-474198.3 HIG—
———PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an* Insecure Direct Object Reference. The agent CRUD endpoints (`GET / PATCH / DELETE /workspaces/{workspace_id}/agents/{agent_id}`) gate access on `require_workspace_member(workspace_id)` only, then resolve `agent_id` through `AgentService.get(agent_id)` which is a primary-key lookup with no workspace constraint. A user who is a member of any workspace `W1` can read, modify, or delete agents that belong to a different workspace `W2` by guessing or harvesting an agent UUID and calling `…/workspaces/W1/agents/<W2-agent-id>`. PraisonAI Platform version 0.1.4 patches the issue.6hCVE-2026-474188.1 HIG—
———PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an Insecure Direct Object Reference. The project CRUD endpoints (`GET / PATCH / DELETE /workspaces/{workspace_id}/projects/{project_id}` and `GET .../{project_id}/stats`) gate access on `require_workspace_member(workspace_id)` only, then resolve `project_id` through `ProjectService.get(project_id)` / `update(project_id, ...)` / `delete(project_id)` / `get_stats(project_id)`. None of these calls thread `workspace_id` through to constrain the lookup. A user who is a member of any workspace `W1` can read, modify, delete, or read stats for projects that belong to a different workspace `W2`. PraisonAI Platform version 0.1.4 patches the issue.6hCVE-2026-474178.1 HIG—
———PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an Insecure Direct Object Reference. The comment endpoints (`POST /workspaces/{workspace_id}/issues/{issue_id}/comments` and `GET .../comments`) gate access on `require_workspace_member(workspace_id)` only, then call `CommentService.create(issue_id=issue_id, ...)` and `CommentService.list_for_issue(issue_id)` without verifying that `issue_id` belongs to `workspace_id`. A user who is a member of any workspace `W1` can read every comment on, and post new comments to, any issue in any other workspace `W2`. PraisonAI Platform version 0.1.4 patches the issue.6h