Total
11506 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-25424 | 2026-10-24 | N/A | 4.3 MEDIUM | ||
| Contributor Broken Access Control in Mediavine Control Panel <= 2.10.10 versions. | |||||
| CVE-2026-34976 | 1 Dgraph | 1 Dgraph | 2026-10-24 | N/A | 10.0 CRITICAL |
| Dgraph is an open source distributed GraphQL database. Prior to 25.3.1, the restoreTenant admin mutation is missing from the authorization middleware config (admin.go), making it completely unauthenticated. Unlike the similar restore mutation which requires Guardian-of-Galaxy authentication, restoreTenant executes with zero middleware. This mutation accepts attacker-controlled backup source URLs (including file:// for local filesystem access), S3/MinIO credentials, encryption key file paths, and Vault credential file paths. An unauthenticated attacker can overwrite the entire database, read server-side files, and perform SSRF. This vulnerability is fixed in 25.3.1. | |||||
| CVE-2026-65011 | 2026-10-24 | N/A | 4.3 MEDIUM | ||
| Graylog2 Server before commit 46a2eeb contains a missing per-entity permission check in the POST /events/definitions/{definitionId}/duplicate endpoint that allows authenticated users to clone any event definition. Attackers with the low-privilege eventdefinitions:create capability can read private event definitions including detection queries, aggregation thresholds, grouping fields, schedules, and notification bindings by duplicating them. | |||||
| CVE-2026-25427 | 2026-10-24 | N/A | 5.4 MEDIUM | ||
| Subscriber Broken Access Control in eRoom <= 1.7.1 versions. | |||||
| CVE-2026-65479 | 2026-10-24 | N/A | 5.4 MEDIUM | ||
| Subscriber Broken Access Control in Reviewer <= 3.14.2 versions. | |||||
| CVE-2026-65567 | 2026-10-24 | N/A | 5.3 MEDIUM | ||
| Unauthenticated Broken Access Control in Event Tickets <= 5.29.0.1 versions. | |||||
| CVE-2026-65495 | 2026-10-24 | N/A | 7.5 HIGH | ||
| Unauthenticated Broken Access Control in Dokan Pro <= 5.0.3 versions. | |||||
| CVE-2026-59530 | 2026-10-24 | N/A | 7.5 HIGH | ||
| Unauthenticated Broken Access Control in Stripe For WooCommerce <= 4.0.7 versions. | |||||
| CVE-2026-43665 | 1 Apple | 1 Macos | 2026-10-24 | N/A | 5.5 MEDIUM |
| This issue was addressed with additional entitlement checks. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8. A local attacker may be able to determine the legacy VNC password configured for Screen Sharing. | |||||
| CVE-2026-59529 | 2026-10-24 | N/A | 7.5 HIGH | ||
| Unauthenticated Sensitive Data Exposure in Ebook Store <= 6.19 versions. | |||||
| CVE-2026-66473 | 2026-10-24 | N/A | 7.5 HIGH | ||
| Unauthenticated Broken Access Control in Xendit Payment <= 7.1.0 versions. | |||||
| CVE-2026-66751 | 2026-10-24 | N/A | 5.4 MEDIUM | ||
| Let's Chat 0.3.0 through 0.4.8 contains an improper authorization vulnerability that allows any authenticated user to archive any room on the server by sending a DELETE request to the rooms handler without ownership verification. Attackers can enumerate room IDs via the rooms listing endpoint and permanently archive private or password-protected rooms they cannot access, with no application-level recovery path requiring direct database intervention to restore. | |||||
| CVE-2026-65485 | 2026-10-24 | N/A | 5.3 MEDIUM | ||
| Unauthenticated Broken Access Control in Content Control <= 2.6.5 versions. | |||||
| CVE-2026-27399 | 2026-10-24 | N/A | 5.3 MEDIUM | ||
| Unauthenticated Broken Access Control in MarketKing <= 2.1.40 versions. | |||||
| CVE-2023-27309 | 1 Siemens | 1 Ruggedcom Crossbow | 2026-10-24 | N/A | 5.0 MEDIUM |
| A vulnerability has been identified in RUGGEDCOM CROSSBOW (All versions < V5.2). The client query handler of the affected application fails to check for proper permissions for specific write queries. This could allow an authenticated remote attacker to perform unauthorized actions. | |||||
| CVE-2026-39433 | 2026-10-24 | N/A | 6.5 MEDIUM | ||
| Subscriber Arbitrary Content Deletion in WPAMS < 49.5.3 versions. | |||||
| CVE-2026-13078 | 1 Mongodb | 1 Mongodb | 2026-10-24 | N/A | 7.7 HIGH |
| A vulnerability was discovered in MongoDB Server where the server-side MozJS scripting engine unconditionally registered a module loading hook that enables JavaScript calls to read arbitrary files from the host filesystem using the mongod process's privileges. An authenticated user could exploit this through crafted aggregation pipeline commands to read sensitive files accessible to the MongoDB server process. | |||||
| CVE-2026-65484 | 2026-10-24 | N/A | 6.3 MEDIUM | ||
| Contributor Broken Access Control in Style Kits <= 2.6.5 versions. | |||||
| CVE-2026-65537 | 2026-10-24 | N/A | 4.3 MEDIUM | ||
| Subscriber Broken Access Control in Cyr to Lat reloaded – transliteration of links and file names <= 1.3.3 versions. | |||||
| CVE-2026-105932 | 2026-10-23 | N/A | N/A | ||
| The Apache Pulsar broker admin REST API provides endpoints to read, set and remove the topic-level entry filter policy of a topic. For persistent topics these endpoints check that the caller is authorized for the entry filters topic policy operation. The corresponding endpoints for non-persistent topics (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) do not perform this authorization check. The only authorization check these endpoints perform is an indirect lookup permission check, made while the topic's partition metadata is retrieved; it is present in all affected versions. As a result, when authentication and authorization are enabled, an authenticated user who has been granted produce or consume permission on a non-persistent topic, or on its namespace, but not permission to manage the topic's policies can read, replace or remove the topic-level entry filter policy of that topic. These operations should be restricted to users with the tenant admin role or the superuser role. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different. The practical impact is limited by two broker configuration requirements, neither of which is met by default: - Entry filters must have been installed by the operator. Entry filter implementations are loaded only at broker startup from the broker's entry filters directory, which is empty by default. A request can only select among entry filters the operator has already deployed; setting any other filter name is rejected. The issue does not allow a caller to install or load entry filter code or to run arbitrary code in the broker. - Topic-level entry filter policies must be allowed to override the broker-level configuration (allowOverrideEntryFilters, which is disabled by default). When this setting is disabled, the topic-level entry filter policy has no effect on message dispatch. In deployments where both conditions are met, an unauthorized user can remove the topic-level entry filter policy of a non-persistent topic, for example one used to restrict which messages are delivered to consumers, or apply a different installed entry filter that withholds messages from subscriptions of that topic. Removing it makes the topic fall back to the namespace-level or broker-level entry filters, which are not removed. A changed policy affects only subscription dispatchers created after the change, for example for new subscriptions or when a subscription is re-created after all of its consumers have disconnected; dispatchers that already exist keep the entry filters they were created with. Because non-persistent topics do not store messages, messages withheld by an entry filter are not delivered. Reading the policy discloses only the names of the configured entry filters. The issue does not allow reading message contents, and entry filters cannot modify message payloads. Persistent topics and namespace-level entry filter policies are not affected. Apache Pulsar versions before 3.3.0 are not affected, because in those versions the entry filters topic policy check is made in code shared by the persistent and non-persistent endpoints. This issue affects Apache Pulsar versions from 3.3.0 before 4.0.14 and from 4.1.0 before 4.2.5. - 3.3.x and 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. Users who cannot upgrade immediately and have deployed entry filters should keep allowOverrideEntryFilters at its default value of false, so that topic-level entry filter policies do not affect message dispatch. | |||||