| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An incorrect authorization vulnerability in the WinBox
authentication flow of MikroTik RouterOS allows a remote authenticated attacker
with credentials for a low-privilege account permitted to use WinBox to obtain
the authorization policy of a different existing account. The stage-one EC-SRP
challenge and proof are verified using the attacker's account, while the
independently supplied stage-two username is used to install the target
account's privileges. By specifying a higher-privilege account such as admin, a
low-privilege user can obtain a full administrative session without knowing the
target account's password and can use that session to increase the privileges
of the attacker's own account. |
| Improper Authorization vulnerability in Apache SkyWalking BanyanDB.
The Canopy includes incomplete proof-of-concept role and monitoring-proxy functionality. Under a non-default configuration with a readonly Canopy user and a reachable monitoring target, that user can send non-read requests through the monitoring proxy.
This issue affects Apache SkyWalking BanyanDB: from 0.11.0 before 0.11.1.
Users are recommended to upgrade to version 0.11.1, which fixes the issue. |
| An **incorrect authorization** flaw has been found in **network interface handling** in the **Foreman** package. The domain and subnet interface API checks only that the caller holds a host permission. It does not apply the search limit on that permission, so the request is answered from every interface on the domain or subnet. A low-privileged network attacker or user must already be allowed to view some hosts and to view a domain or subnet shared with other hosts. They can request that domain or subnet's interfaces. The response includes interface records of hosts they are not allowed to view. If the attacker or user is also allowed to edit some hosts, they can submit a change to one of those interfaces. The interface is then saved with that change. |
| In @neo4j/graphql versions from 7.0.0 up to but not including 7.6.4, the none quantifier in @authorization filters on relationships and connections is not negated when translated to Cypher, so it behaves like some. A rule such as "none of the related denied users matches the JWT subject" therefore returns exactly the records it was meant to exclude, and excludes those it was meant to return. An authenticated user whom such a rule is meant to deny can read the protected records. This is also the case for mutations, so the impact is that sensitive data could also be created and deleted by users that shouldn't have access according to the typedefs. Fixed in 7.6.4. |
| goose from 1.28.0 before 1.44.0 contains an authorization bypass vulnerability that allows tools to run without user approval in Manual Approval mode because persisted read-only annotations are never cleared by update_goose_mode. After a session uses Smart Approval mode, prompt-injected calls to tools annotated readOnlyHint: true execute without prompting, bypassing the user's selected approval mode in PermissionInspector::inspect. |
| A flaw was found in Quay. A user configured in GLOBAL_READONLY_SUPER_USERS is able to view robot account tokens for repositories they are not a member of, allowing an attacker with read-only superuser privileges to impersonate any robot account. |
| ERPNext 15.55.0 through 16.50.0 contains an incorrect authorization vulnerability in the get_timesheet_html method that lets authenticated portal users view project Timesheets. The method only checks Project read access, ignoring hide_timesheets and project membership, so attackers can retrieve timesheet names, status, time-log dates and last modifiers. |
| Parse Server 8.2.2 before 8.6.94 and 9.0.0 before 9.10.1-alpha.14 applies its GraphQL introspection control only to operation text sent directly with a request, not to operations resolved from Apollo Server's automatic persisted query cache. Unauthenticated attackers holding the public Application Id and client key can replay an introspection query previously cached by a master or maintenance key client to retrieve the schema, including private class and field names. |
| A connected peer cluster can modify a Temporal Server cluster's local namespaces, which are never replicated to that peer, because the receiving cluster applies inbound namespace replication updates to them. In a multi-cluster deployment, each cluster pulls replication tasks from the remote clusters an administrator has registered with connection enabled; the sending side excludes local namespaces, but the receiving side does not apply the same rule. When an inbound task names an existing namespace, the server checks at most that the namespace identifiers match, then overwrites its state, description, owner, retention, archival settings, and cluster list, and its active cluster when the task carries a higher failover version, without checking that the namespace is global. A party that controls a registered peer's replies, by operating or compromising it, can therefore change any local namespace whose name and identifier it can supply, without any credential on the receiving cluster: for example, marking it Deprecated, making the peer its active cluster, and shortening its retention, after which new Workflow starts in that namespace fail. Local namespaces include the built-in temporal-system namespace. Namespace metadata the History service refreshes from the peer while processing its history replication tasks passes through the same logic. A cluster with no remote cluster registered with connection enabled is not exposed. |
| SurrealDB before 3.3.0 contains an authorization bypass vulnerability that allows record users to read fields hidden by field-level SELECT permissions through LIVE SELECT projections. Attackers can project restricted fields from the unreduced $after or $before parameters under an alias to receive exact stored values in CREATE, UPDATE, and DELETE notifications. |
| LavaLite CMS through 10.1.2 contains an authorization bypass vulnerability that allows authenticated low-privileged users to modify other users' accounts by abusing the AbstractRequest isWorkflow() check. Attackers can send a PATCH request to the user update route with a target identifier to change name, email, password, status, or mobile, including for administrators. |
| jshERP through 3.6 contains an incorrect authorization vulnerability in GET /supplier/exportExcel that allows authenticated users to bypass role data scope restrictions enforced by /supplier/list. Attackers restricted to personal or department data can export every supplier, customer and member record, exposing contacts, phone numbers, tax numbers, bank accounts and balances. |
| jshERP through 3.6 contains an authorization bypass vulnerability that allows authenticated users restricted to personal or department data to list other users' bills by adding a purchaseStatus value. Attackers can include purchaseStatus=0 in the search JSON on GET /depotHead/list, causing DepotHeadService.select to drop the creator filter and expose all tenant purchase, sales and inventory bills. |
| The Appointment Booking Calendar — Simply Schedule Appointments Booking Plugin plugin for WordPress is vulnerable to Incorrect Authorization in all versions up to, and including, 1.6.11.11. This is due to the appointment update REST API endpoint not restricting which fields can be modified by token-authenticated customers. This makes it possible for unauthenticated attackers to modify admin-controlled fields on that appointment, including faking payment confirmation, reassigning the appointment to another user, and changing the service type. |
| The Squadeno WordPress plugin before 1.12.0 does not enforce its restrictions on every way a sport can be saved, allowing users with the lowest-tier Trainer role to change the section, age group, author, password, comment settings and date of a sport they are assigned to. |
| Backstage is an open framework for building developer portals. Prior to 0.21.9, the @backstage/plugin-kubernetes-backend package is affected by sensitive information disclosure in kubernetes resource queries. An authenticated user holding the standard Kubernetes resource read permission could retrieve sensitive values that the Kubernetes plugin is designed to mask, potentially exposing credentials and other confidential material held in the connected clusters. Exposure is limited to resources that the Backstage service account is permitted to read and that match the targeted catalog entity's namespace and label selector. Deployments whose cluster credentials do not grant read access to these resources are unaffected. This issue is fixed in version 0.21.9. |
| Backstage is an open framework for building developer portals. Prior to 2.1.6 in @backstage/plugin-search-backend and 1.8.7 in @backstage/plugin-search-backend-module-elasticsearch, search engine permission filtering could return documents denied by policy. An authenticated Backstage user subject to a DENY policy for search document types could receive unauthorized results in deployments with permission.enabled set to true and an Elasticsearch or OpenSearch backend. This issue is fixed in @backstage/plugin-search-backend 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch 1.8.7. |
| pacioli provides least-privilege governance and a governed agent broker for ERPNext. From version 0.9.6 until version 0.10.0, the pacioli-guard document-layer consent gate allows nested cancellation operations to ride any consent established by an enclosing governed act without checking whether the marker authorizes cancellation. A credential with API Key Scope.require_consent can submit a caller-controlled Sales Invoice or other supported document under a valid human-minted submit marker and reach Document.cancel() for a different pre-existing submitted document, bypassing the marker's document and act binding, single-use spend, and denial audit. The unauthorized cancellation can reverse the target document's ledger effect; principals without a consent-gated grant are not affected. This issue is fixed in version 0.10.0. |
| The Fundiin cho WooCommerce WordPress plugin through 3.4.0 does not have proper authorisation on several of its REST API routes, relying instead on a credential that is identical on every installation, allowing unauthenticated attackers to disclose the store's payment credentials and customer order data, overwrite the payment gateway configuration so that payments are credited elsewhere, and mark unpaid orders as paid. The same missing authorisation also allows arbitrary script to be stored in a field which is output unescaped on the classic checkout, leading to unauthenticated stored XSS on stores that do not use the block-based checkout. |
| The Portfolio Filter Gallery WordPress plugin before 2.2.1 does not perform proper authorization checks in a set of AJAX actions, allowing users with at least the Contributor role to read, modify and delete other users' galleries as well as site-wide gallery filters. |
