Threats Tagged 'cwe-862'

The Download Monitor WordPress plugin before 5.2.6 does not perform authorization checks on one of its download-logging AJAX actions, and exposes the nonce protecting it to unauthenticated visitors, allowing unauthenticated users to inject arbitrary download log entries and inflate a site's download statistics.

### Summary The PraisonAI Platform API has two authorization failures that together break workspace isolation. The service layer for issues and projects performs global primary-key lookups without checking workspace ownership, so any authenticated user can read, modify, and delete resources in any workspace just by swapping UUIDs in their API requests. On top of that, every member management endpoint (add, update role, remove) only requires `min_role="member"`, which lets any workspace member promote themselves to owner and kick out the original owner. A low-privilege member of one workspace can steal data from every other workspace and take over any workspace they belong to. Both issues come from the same gap: the route layer pulls `workspace_id` from the URL and verifies membership, but the service layer ignores the workspace scope for resource lookups and ignores the caller's role level for member operations. The `require_workspace_member()` dependency does its job correctly. The problem is that the service layer doesn't use the information it provides. ### Details #### Part 1: Cross-Workspace IDOR (Issues and Projects) **Vulnerable Files:** - `praisonai_platform/services/issue_service.py` - `praisonai_platform/services/project_service.py` - `praisonai_platform/api/routes/issues.py` - `praisonai_platform/api/routes/projects.py` There is a consistent split between the route layer and the service layer. Routes pull `workspace_id` from the URL and verify membership: ``` GET /api/v1/workspaces/{workspace_id}/issues/{issue_id} ^^^^^^^^^^^^^^ require_workspace_member() checks this ``` But the service methods these routes call perform global lookups that ignore `workspace_id` entirely: **IssueService.get(), line 72:** ```python async def get(self, issue_id: str) -> Optional[Issue]: """Get issue by ID.""" return await self._session.get(Issue, issue_id) ``` **ProjectService.get(), line 47:** ```python async def get(self, project_id: str) -> Optional[Project]: """Get project by ID.""" return await self._session.get(Project, project_id) ``` Both use `session.get(Model, pk)`, which is a global lookup by primary key with no `WHERE workspace_id = ?` filter. Compare that with the properly scoped `list_for_workspace()` methods in the same files: **IssueService.list_for_workspace(), line 76:** ```python async def list_for_workspace(self, workspace_id: str, ...) -> list[Issue]: stmt = select(Issue).where(Issue.workspace_id == workspace_id) # ... properly scoped ``` The listing is scoped correctly. The get, update, and delete methods are not. Since `update()` and `delete()` in both services call `self.get()` internally, the workspace bypass cascades through all write operations too. **Route that discards workspace_id, issues.py line 82:** ```python @router.get("/{issue_id}", response_model=IssueResponse) async def get_issue( workspace_id: str, # Extracted from URL issue_id: str, user: AuthIdentity = Depends(require_workspace_member), # Membership verified session: AsyncSession = Depends(get_db), ): svc = IssueService(session) issue = await svc.get(issue_id) # workspace_id never passed to service ``` **All affected operations:** | Service | Method | Line | Workspace scoped? | |---------|--------|------|-------------------| | IssueService | `get()` | 72 | No, uses `session.get(Issue, issue_id)` | | IssueService | `update()` | 97 | No, calls `self.get(issue_id)` | | IssueService | `delete()` | 150 | No, calls `self.get(issue_id)` | | IssueService | `list_for_workspace()` | 76 | **Yes**, filters by `workspace_id` | | ProjectService | `get()` | 47 | No, uses `session.get(Project, project_id)` | | ProjectService | `update()` | 62 | No, calls `self.get(project_id)` | | ProjectService | `delete()` | 88 | No, calls `self.get(project_id)` | | ProjectService | `get_stats()` | 97 | No, only filters by `project_id` | | ProjectService | `list_for_workspace()` | 51 | **Yes**, filters by `workspace_id` | #### Part 2: Workspace Takeover via Missing Role Enforcement **Vulnerable Files:** - `praisonai_platform/api/routes/workspaces.py` (member management routes) - `praisonai_platform/api/deps.py` (authorization dependency) - `praisonai_platform/services/member_service.py` (role hierarchy implementation) The authorization dependency supports role-based access: **require_workspace_member(), deps.py line 54:** ```python async def require_workspace_member( workspace_id: str, user: AuthIdentity = Depends(get_current_user), session: AsyncSession = Depends(get_db), min_role: str = "member", # Accepts higher roles, but nobody passes them ) -> AuthIdentity: member_svc = MemberService(session) has = await member_svc.has_role(workspace_id, user.id, min_role) if not has: raise HTTPException(status_code=403, ...) ``` The `has_role()` method correct

Home Assistant is open source home automation software focused on local control and privacy. Prior to 2026.5.0, the iOS Companion app treats tag links (NFC or QR) delivered through an OS-level routing mechanism such as iOS universal links as if they were physically scanned, without validating the calling app or prompting the user. As a result, any untrusted app on the device can forward an arbitrary tag to Home Assistant, causing it to execute the associated automation as though a legitimate user had scanned an authorized tag. This allows silent, unattended automation execution by untrusted local callers. This issue has been fixed in version 2026.5.0.

Home Assistant is open source home automation software focused on local control and privacy. Prior to 2026.5.3, the Companion app treats tag links (NFC or QR) delivered through an OS-level routing mechanism as if they were physically scanned, without validating the calling app or prompting the user. As a result, any untrusted app on the device can forward an arbitrary tag to Home Assistant, causing it to execute the associated automation as though a legitimate user had scanned an authorized tag. This allows silent, unattended automation execution by untrusted local callers. This issue is fixed in version 2026.8.1.

Consul Community Edition and Consul Enterprise 1.18.21 through 2.0.2 are vulnerable to a partial arbitrary file read when configured to use the Vault Connect CA provider with JWT or AppRole authentication. A privileged attacker with `operator:write` permission may direct Consul to read and forward credential files outside the intended scope, potentially leading to the exfiltration of sensitive secrets from the Consul server host. This vulnerability, CVE-2026-19017, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3.

A user holding a permission to update privilege definitions could modify a wildcard privilege already assigned to their own role to grant broader permissions than they were authorized to hold, including full administrative access, without any additional authorization check or role reassignment.

Tobit Laboratories AG TeamDavid's Webbox does not enforce authentication or authorization checks when serving these log files. As a result, attackers can obtain sensitive error information or internal application details, potentially aiding in further attacks. This issue affects TeamDavid through Rollout 524.

The MStore API WordPress plugin before 4.21.0 does not perform authorization or purchase-ownership checks on its REST product-review creation route, allowing an unauthenticated attacker to create WooCommerce product reviews with an attacker-chosen reviewer name, email and star rating on stores configured to accept reviews only from verified owners.

The MStore API WordPress plugin before 4.21.0 does not verify the payment with the payment gateway before marking an order as paid on several of its payment-completion endpoints, allowing an unauthenticated attacker to mark an arbitrary order fully paid without paying and obtain goods or services for free.

The Templately WordPress plugin before 3.7.1 does not have an authorisation check on one of its request handlers, allowing unauthenticated attackers to overwrite the administrator's stored cloud service connection with an account under their control, disconnecting the legitimate administrator and redirecting the site's cloud template library to attacker-controlled content.