CVE Database

Incorrect Authorization vulnerability in ash-project ash allows an actor to infer data in related records they cannot read via Ash.count/2, Ash.exists/2 and Ash.aggregate/3. Ash.Actions.Aggregate.run/4 (lib/ash/actions/aggregate.ex) applied only the root resource's read policy before running the aggregate query. The read path also applies each related resource's read policy to filter and sort references that cross a relationship, directly (for example comments.body) or through an aggregate over one, but the aggregate path skipped that step. A caller whose filter or sort reaches these functions, for example through Ash.Query.filter_input/2, an ash_lua script, or an AshAi tool offering count or exists results, can test conditions against related rows hidden from them and recover their existence and attribute values one query at a time. Ash.read/2 and its page counts are not affected. This issue affects ash: from 2.6.0 before 3.34.6.

Dolibarr ERP CRM before 24.0.2 contains an incorrect authorization vulnerability in htdocs/core/ajax/updateextrafield.php that checks only read permission before writing extrafield values. Authenticated users with read-only access can POST objectType, objectId, field and value parameters to persistently modify extrafields on viewable third parties, products, members, projects or contacts.

In OpenStack Mistral through 23.0.0, the workflow membership API lets a project that has accepted a share of another project's private workflow create a further membership naming a third project. The new membership row is created with its project_id defaulted to the accepting project rather than the original workflow owner, and thus the owner can neither see nor delete it. The third project can accept this membership (that it had not actually been granted by the owner), and then read and execute the owner's private workflow; only the accepting (not the owning) project can later revoke that access.

Malcolm's nginx Lua role-based access control (RBAC) layer decides whether an authenticated user may reach a role-restricted path (e.g. /htadmin, /auth, /admin_login, /arkime/api/esadmin, NetBox, upload endpoints) by pattern-matching the raw, percent-encoded request URI. Nginx itself, however, selects which location block actually serves the request using the percent-decoded, normalized URI. Because the RBAC check never percent-decodes its input, an authenticated low-privilege user can request an admin-only path using percent-encoding (e.g. /%68tadmin.php) and have nginx route it to the restricted location while the Lua RBAC gate evaluating the un-decoded raw string finds no matching restriction and grants access.

A policy-enforcement flaw in Zimbra Collaboration Suite allows an authenticated user to bypass disabled mail forwarding by using a Sieve notify action to send copies of email content and headers to an arbitrary address.

IBM DataPower Gateway 10.5.0.0 through 10.5.0.22, 10.6.1 through 10.6.6, 10.6.0.0 through 10.6.0.10, and 11.0.0.0 through 11.0.0.2 could allow a local attacker to obtain sensitive information due to improper authorization.

An authorization vulnerability in Apache DolphinScheduler allows authenticated users to retrieve other users' account information through the /dolphinscheduler/users/list-all endpoint without the required permissions. The endpoint fails to enforce the necessary authorization checks before returning user account information. As a result, an authenticated user can access account information they are not authorized to view. Successful exploitation may expose sensitive user information and facilitate account enumeration. This issue affects Apache DolphinScheduler: before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue.

An authorization bypass vulnerability in Apache DolphinScheduler allows authenticated users to perform unauthorized operations on workflow schedules, workflow definitions, and task instances in other projects. The affected endpoints check permissions against the supplied projectCode but fail to verify that the target resource belongs to that project. An authenticated user with the required permissions in one project can supply that project's code together with a resource identifier from another project, bypassing the target project's access restrictions. The affected endpoints include: * POST /projects/{projectCode}/schedules/{id}/online and /offline: Activate or deactivate workflow schedules in another project. * POST /projects/{projectCode}/workflow-definition/{code}/release: Change the ONLINE/OFFLINE state of workflow definitions in another project. Successful exploitation allows users to alter workflow availability and interfere with task execution in projects they are not authorized to access. This issue affects Apache DolphinScheduler: before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue.

In Stump through 0.1.10, the updateSmartList and deleteSmartList GraphQL mutations (crates/graphql/src/mutation/smart_lists.rs) depend only on the shared AccessSmartList permission and resolve the target list at Reader access (lacking a creator check). Any authenticated user with that permission can overwrite, delete, or take over another user's smart list. (updateSmartList sets creatorId to the caller identity, and can set visibility to PRIVATE, locking out the original owner.) NOTE: this is unrelated to the graphql crate on crates.io.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could create or edit scripted lookup definitions through raw configuration endpoints. The vulnerability is possible because raw transforms configuration write paths do not apply external lookup capability checks before saving scripted lookup settings.

Obot 0.26.0 before 0.26.2 contains an authorization bypass vulnerability that allows authenticated users matching any vMCP profile to reach prompts and resources of ungranted components. Because profiles were enforced only on tools, attackers can access prompts, resources, and resource templates through the vMCP owner's shared component connection.

The Gitea API endpoint for creating push mirrors (`POST /api/v1/repos/{owner}/{repo}/push_mirrors`) checked only whether mirroring was enabled and not the `[mirror] DISABLE_NEW_PUSH` setting that the web interface enforces. A repository administrator could therefore create new push mirrors on instances where the site administrator had disabled them. A push mirror pushes all refs of the repository to a remote chosen by the caller, on each commit or on a schedule.

With `[repository] FORCE_PRIVATE = true`, Gitea creates new repositories as private, but the post-receive hook still applied the `repo.private=false` push option to an empty repository created by push. Any user who can create repositories could make their new repository public in violation of the instance policy. The default configuration is not affected.