| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Camunda 7.24.0 before 7.24.14 and 7.23.0 before 7.23.17 contains a missing authorization check vulnerability in engine-rest task sub-resources that allows authenticated attackers with no permission grants to access task comments and attachments by calling singular read and delete endpoints that lack the authorization-filtered checks enforced on their corresponding list endpoints. Attackers can exploit TaskAttachmentResourceImpl and TaskCommentResourceImpl methods such as getAttachment, getAttachmentData, deleteAttachment, and getComment using only a known object ID to read, download, or permanently delete task attachments and comments. |
| Missing authorization in the Sieve notify action (6.2.22 through 6.3.6) and in the mail-rule Reply action (6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to send mail through the server as any address. A Sieve notify sends a notification message, and its :from tag names the sender; the server set the notification's From header to that :from as the script wrote it, without checking that the address belongs to the account - the check that the Sieve vacation action applies to its own :from, and that the server applies to the sender of mail queued over COM or sent from the webmail. An account that can store a Sieve script (over ManageSieve, the REST API's self-service filter, or the administration interface) could therefore have the server send a notification from any address, on this server or anywhere; and where the claimed address is at a domain the server hosts with DKIM signing enabled, the server signed the notification with that domain's DKIM key, because it signs by the From header's domain, producing forged mail aligned to pass the domain's DMARC policy. The notify action and this behaviour were introduced in 6.2.22. In the mail-rule engine, a rule's Reply was likewise sent from whatever address the action named, whoever the rule belonged to, so that an account acting on its own rules over COM, a domain administrator, or an API key confined to a domain (over the REST API from 6.3.4) could have a domain's or an account's rule reply from any address, signed, where that address is at a domain the server hosts with DKIM signing enabled, with that domain's key. |
| Missing authorization in the Sieve editheader action (6.2.22 through 6.3.6) and in the mail-rule Set header value action (6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to make the server send mail as any address, DKIM-signed where the address is at a domain the server signs for. A Sieve script's editheader (addheader/deleteheader) could add or delete any header field except Received and Return-Path, and the server applies a script's header edits before it queues a redirect, so the redirected copy is sent as the script left it. The server signs a message's first delivery pass as the domain named in its From header wherever it signs DKIM for that domain and the message carries no signature of it. A script could therefore delete and re-add From - another account's address, or anyone's at a hosted domain - and redirect, so the server sent the message in that name and, for a hosted domain, signed it with that domain's DKIM key, a forgery aligned to pass the domain's DMARC; or, where another sender's domain is one the server signs for, delete the DKIM-Signature that sender's message arrived with, alter a field, and redirect, so the server re-signed the altered message as that sender's domain. editheader placed no restriction on From, Sender, Resent-From, Resent-Sender or DKIM-Signature. The editheader action was introduced in 6.2.22. In the mail-rule engine, a domain's or an account's rule's Set header value action could likewise set From, Sender, Resent-From, Resent-Sender or DKIM-Signature ahead of a forward or a copy, whoever the rule belonged to, so that an account acting on its own rules over COM, a domain administrator, or an API key confined to a domain (over the REST API from 6.3.4) could have the server forward or copy a message in the name of any address, signed, where that address is at a domain the server hosts with DKIM signing enabled, with that domain's key. |
| MISP contains a vulnerability in the handling of module plugin settings. When the server rebuilds module-supplied settings for API consumption, it drops the redacted and cli_only flags that a module declares in its own configuration metadata.
As a result:
- A module that marks a setting (such as an API key) as redacted still has its value returned in full by the servers/getSetting and servers/serverSettingsEdit endpoints, exposing sensitive credentials to any authenticated user who can read server settings.
- A module that marks a setting as cli_only (intended to be editable only via the command-line interface) can still be modified through the web API, bypassing the intended access restriction.
An authenticated user with access to server settings can therefore read sensitive module credentials and modify settings that the module author intended to restrict to CLI-only access.
Affected: <2.5.48 |
| MISP contains an access control flaw in the proposal (shadow attribute) visibility logic. The authorization check accepted any attribute or object carrying one of the user's sharing groups without verifying the distribution level, and denied the owning organisation access to proposals on its own organisation-only attributes.
- A user belonging to a sharing group could view proposals on attributes or objects with that sharing group, regardless of the attribute's distribution level (levels 1-3 should restrict visibility)
- The owning organisation could not view proposals on its own org-only attributes
Security impact: Unauthorized disclosure of proposed attribute changes to users who should not have access based on distribution level restrictions.
Affected: <2.5.48 |
| A security flaw has been discovered in aircheng-org iWebShop-5 up to 5.16. The affected element is the function admin_repwd/admin_repwd_act of the file controllers/system.php of the component Password Change. The manipulation of the argument password/repassword results in cross-site request forgery. It is possible to launch the attack 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. |
| Missing Authorization vulnerability in Apache Answer.
This issue affects Apache Answer: through 2.0.2.
An unauthenticated or unauthorized user can retrieve the invited-user list associated with a non-public question due to missing visibility authorization checks.
Users are recommended to upgrade to version 2.0.3, which fixes the issue. |
| Frappe HR is an open-source human resources management solution (HRMS). Prior to 15.58.3 and 16.4.3, HRMS PWA API endpoints for employee data do not consistently authorize employee-specific PWA API requests. An authenticated user requests records associated with another employee. The user can request records associated with another employee through PWA API endpoints. Successful exploitation can access sensitive HR data belonging to other employees. This issue is fixed in versions 15.58.3 and 16.4.3. |
| A security flaw has been discovered in dyad-sh dyad up to 1.16.0. Affected by this issue is some unknown functionality of the component OAuth Callback Handler. Performing a manipulation results in cross-site request forgery. The attack may be initiated remotely. Upgrading to version 1.17.0-beta.1 can resolve this issue. The patch is named 39fbae87b38573616a1a3b152cdb292787bb1109. It is advisable to upgrade the affected component. |
| A vulnerability has been found in David-Crty Databasement up to 1.8.1. Affected by this vulnerability is an unknown functionality of the file app/Http/Requests/Api/V1/SaveScheduledRestoreRequest.php of the component Scheduled Restore. Such manipulation of the argument schema_name leads to missing authorization. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 1.8.2 addresses this issue. It is suggested to upgrade the affected component. |
| The TrueBooker WordPress plugin before 1.3.0 does not perform any capability check on one of its setup handlers, and the token it does check is issued to unauthenticated visitors, allowing anyone to overwrite the plugin's entire configuration and to discard any setting they do not supply. |
| The TrueBooker WordPress plugin before 1.3.0 does not have authorisation checks in some of its AJAX actions, and does not validate the submitted service price server-side, allowing unauthenticated users to create bookings at a price of their choosing and to attach them to arbitrary customer accounts. |
| The TrueBooker WordPress plugin before 1.3.0 does not have authorisation checks in place in some of its functionality, allowing unauthenticated users to create and modify booking services and categories, including their prices. |
| The ForgeRock client fails to correctly validate refresh tokens. This allows a refresh token to be treated as a valid access token, enabling its use for consuming protected resources. This bypasses the intended security control that requires valid client credentials in addition to a refresh token to obtain a new access token.
An attacker who obtains a stolen or exposed refresh token can leverage this vulnerability to directly access protected resources. This is possible because the standard security flow requiring client credentials to exchange a refresh token for an access token is circumvented. |
| ERPNext is a free and open source Enterprise Resource Planning tool. Prior to 15.121.0 and 16.34.0, certain endpoints for status modification fail to enforce proper authorization checks. A low-privileged authenticated user can invoke state-changing whitelisted methods without required write, submit, cancel, document, or role checks. This allows the user to modify data beyond the user's permitted role. This issue is fixed in versions 15.121.0 and 16.34.0. |
| ClickVisual through 1.1.2 contains a missing authorization vulnerability in the /api/v2/reports handlers that allows authenticated low-privileged users to access ClickHouse instances they were not granted. Attackers can iterate the instance-id parameter in ReportSourceDatabases, ReportSourceTables, ReportTableColumns and WhereCheckRun to enumerate schemas and infer row counts of restricted tables. |
| Piranha CMS through 12.2 contains a missing authorization vulnerability in the Piranha.Manager LanguageApiController that allows any authenticated manager user to list, create, edit and delete site languages without the granular Language, LanguageAdd, LanguageEdit or LanguageDelete permissions. Attackers can call the manager/api/language Get, Save and Delete actions directly to remove languages and reassign sites to the default, affecting localized content instance-wide. |
| The PickPlugins Product Designer for WooCommerce WordPress plugin through 1.0.40 does not perform any capability check and its nonce verification is inverted, accepting requests with an invalid or absent nonce while rejecting valid ones, and it does not validate the post the data is written to, allowing unauthenticated users to insert design template data into the metadata of any post on the site. |
| Radar before 1.12.2 contains a missing authorization vulnerability in the handleLocalTerminal WebSocket endpoint (/api/local-terminal) that allows authenticated or unauthenticated attackers to spawn a privileged shell by relying only on a runtime-mode check instead of role-based access control. Attackers can connect to the endpoint to execute /bin/bash -l on the Radar host with Radar's own kubeconfig and process credentials injected into the shell environment, achieving remote code execution with Radar's privileges even when the --disable-local-terminal flag is set. |
| Sure 0.7.0 through 0.7.6-alpha.6 contains a missing authorization vulnerability in Transactions::BulkUpdatesController#create that allows family members to bypass account sharing permissions. Authenticated members with read_only or no share can submit arbitrary entry_ids to modify other members' transaction dates, names, notes, categories, merchants and tags, corrupting budgets and reports. |
