Export limit exceeded: 16080 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (16080 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-116410 | 2026-10-30 | 6.5 Medium | ||
| Unauthenticated Arbitrary Content Deletion in Masteriyo - LMS <= 3.4.3 versions. | ||||
| CVE-2026-119702 | 2 Wordpress-extensions, Wpgraphql | 2 Wpgraphql, Wpgraphql | 2026-10-30 | 6.5 Medium |
| WPGraphQL before 2.24.1 contains a missing authorization vulnerability in the createComment mutation that allows unauthenticated attackers to comment on non-public posts by bypassing post status checks. Attackers can attach comments to draft, private, trashed, or password-protected posts to leak hidden titles via moderator notifications, enumerate post IDs, and backdate comments or mark them as pingbacks. | ||||
| CVE-2026-62056 | 2026-10-30 | 5.3 Medium | ||
| Missing Authorization vulnerability in WP ManageNinja LLC Fluent CRM fluent-crm allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Fluent CRM: from n/a through 3.2.6. | ||||
| CVE-2026-69446 | 1 Microsoft | 2 Edge Chromium, Microsoft Edge (chromium-based) | 2026-10-30 | 4.4 Medium |
| Incorrect authorization in Microsoft Edge (Chromium-based) allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-54852 | 2026-10-30 | 5.3 Medium | ||
| Missing Authorization vulnerability in miniOrange Page Restriction WordPress (WP) page-and-post-restriction allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Page Restriction WordPress (WP): from n/a through 1.6.1. | ||||
| CVE-2026-50000 | 2026-10-30 | 5 Medium | ||
| SecureDrop is an open-source whistleblower submission system that media organizations can use to securely accept documents from, and communicate with anonymous sources. From 2.5.0 until 2.16.0, the `Journalist Interface` can accept an `API session` token against the `web UI` because its `SessionInterface` keeps a mutable session key prefix that changes with each request and persists across requests. API and web sessions were separated in `Redis` starting in version 2.5.0, but prefix corruption confuses those session namespaces. An attacker who already has access to the secret `Journalist Interface` onion address, the required authentication access and a recent nonexpired `API session` token can reuse that token against the `web UI` until its natural expiry, at most eight hours. The corrupted prefix can also prevent logout from deleting the correct `Redis` session, although normal expiry still applies. A compromised journalist can access encrypted submissions and perform broad actions on source submissions, but this issue does not expose plaintext submissions or affect the running system's availability. This issue is fixed in version 2.16.0. | ||||
| CVE-2026-27063 | 2026-10-30 | 5.3 Medium | ||
| Missing Authorization vulnerability in Kit Kit (formerly ConvertKit) convertkit allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Kit (formerly ConvertKit): from n/a through 3.4.7. | ||||
| CVE-2026-119087 | 2026-10-30 | 4.3 Medium | ||
| The Content Egg – Affiliate Product Importer & Price Comparison plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 12.0.0 This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with author-level access and above, to create posts attributed to another user's account — typically an administrator — by supplying an admin-owned preset_id, causing wp_insert_post to record the administrator as post_author. This includes the ability to create published posts when the attacker already holds publish_posts capability for the preset's post type, resulting in administrator-attributed published content created by a lower-privileged user. | ||||
| CVE-2026-119059 | 2026-10-30 | 4.3 Medium | ||
| The Content Egg plugin for WordPress is vulnerable to unauthorized modification of data due to a missing per-post capability check on the ajaxUpdateProducts() function in versions up to, and including, 12.0.0. The handler verifies a static nonce ('contentegg_metabox') and the generic 'edit_posts' capability, but trusts the attacker-supplied $_POST['post_id'] verbatim and never calls current_user_can('edit_post', $post_id) — the per-object check that its sibling save_post handler saveMeta() correctly performs. This makes it possible for authenticated attackers, with contributor-level access and above, to modify Content Egg product data (_cegg_data_*) and update-timestamp post meta on arbitrary posts, including those owned by administrators. | ||||
| CVE-2026-118091 | 2026-10-30 | 5.3 Medium | ||
| Missing Authorization vulnerability in WPFunnels Team WPFunnels wpfunnels allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPFunnels: from n/a through 3.13.5. | ||||
| CVE-2026-116387 | 2026-10-30 | 5.3 Medium | ||
| Missing Authorization vulnerability in Brainstorm Force SureForms sureforms allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects SureForms: from n/a through 2.12.9. | ||||
| CVE-2026-115601 | 2026-10-30 | 5.3 Medium | ||
| Missing Authorization vulnerability in WP Desk Custom Price for WooCommerce custom-price-for-woocommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Custom Price for WooCommerce: from n/a through 1.1.29. | ||||
| CVE-2026-110732 | 2026-10-30 | 7.5 High | ||
| The AI Engine – The Chatbot, AI Framework & MCP for WordPress plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 3.8.6 This is due to the MCP module's OAuth 2.1 Dynamic Client Registration endpoint (/wp-json/mcp/v1/oauth/register) being registered with a permission_callback of __return_true, allowing an unauthenticated user to register an active OAuth client with an attacker-controlled redirect URI. This makes it possible for unauthenticated attackers to obtain an administrator-bound MCP access token, and thereby full administrator-level control through the MCP tools (including user creation and option updates), once an administrator approves the attacker's client on the OAuth consent screen. The consent page is additionally served without X-Frame-Options or Content-Security-Policy frame-ancestors, so that approval can be obtained via clickjacking. | ||||
| CVE-2026-109891 | 2026-10-30 | 6.4 Medium | ||
| Missing Authorization vulnerability in weDevs Happy Addons for Elementor happy-elementor-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Happy Addons for Elementor: from n/a through 3.50.1. | ||||
| CVE-2026-109592 | 2026-10-30 | 4.3 Medium | ||
| The OpenStation: Desktop Windows, Dock & Virtual Desktops for WP Admin plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.1.16. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify arbitrary other users' placement rows (position, sort order, parent folder, and meta) and read serialized metadata — including title, permalink, and post status — of the entities those orphaned placements reference. Exploitation requires at least one orphaned placement to exist — a state produced naturally by the plugin's own trash cascade, which marks a parent folder as trashed while leaving child placements' parent_id intact — and the attacker must first self-enable OpenStation via the save-openstation AJAX endpoint, which requires only the 'read' capability held by every default WordPress role. This was also independently found by the OpenStation team. | ||||
| CVE-2026-105931 | 1 Apache | 1 Pulsar | 2026-10-30 | N/A |
| The Apache Pulsar broker exposes a transaction administration REST API under /admin/v3/transactions. When authentication and authorization are enabled, most of the read endpoints of this API verify only that the request is authenticated and that the broker serves the requested topic or transaction coordinator. They do not check whether the caller is permitted to access the tenant, namespace or topic whose data is returned. The endpoints that modify state, which abort a transaction or scale the transaction coordinators, correctly require super-user access and are not affected. As a result, any authenticated user, including one that has been granted no permissions, can read transaction coordinator and transaction information belonging to other tenants. This includes the list of transaction coordinators with the broker service URLs that serve them, transaction coordinator statistics and internal statistics, transaction metadata including the names of the topics and subscriptions a transaction involves and the principal that opened it, the list of long-running transactions on a transaction coordinator, transaction buffer and pending acknowledgement statistics and internal statistics for any topic and subscription, and whether a given message position of a subscription is currently held in a pending transactional acknowledgement. The disclosure of transaction metadata and statistics can only occur when transaction support is enabled in the broker (transactionCoordinatorEnabled, which is disabled by default). When transaction support is disabled, these endpoints return no transaction data; the only residual effect is that one endpoint's error response can reveal whether a named topic exists in another tenant. The impact is limited to disclosure of transaction-related metadata and statistics across tenant boundaries. The issue does not allow reading message contents, modifying or aborting transactions, or changing any configuration. This issue affects Apache Pulsar versions from 2.8.0 before 4.0.14 and from 4.1.0 before 4.2.5. - 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 do not use Pulsar transactions should keep transaction support disabled. Where transactions are required, restricting network access to the broker's admin HTTP endpoints to trusted administrative clients reduces the exposure. | ||||
| CVE-2026-105927 | 1 Apache | 1 Pulsar | 2026-10-30 | N/A |
| The Apache Pulsar WebSocket service allows a WebSocket consumer to configure a dead letter policy through query parameters of the consumer endpoint, including the deadLetterTopic parameter that names the topic to which messages are written after the maximum number of redeliveries is exceeded. When authorization is enabled, the WebSocket service checks only that the connecting user holds the CONSUME permission on the subscribed topic. It does not check whether the user holds the PRODUCE permission on the topic named in deadLetterTopic. The dead letter messages are then written by the WebSocket service using its own broker client identity rather than the identity of the connecting user. As a result, an authenticated user who holds the CONSUME permission on at least one topic can cause messages to be written to a topic of their choosing in any existing namespace, including namespaces belonging to other tenants, provided the role used by the WebSocket service to connect to the brokers is authorized to produce to that topic and the topic accepts a producer that registers no schema. The dead letter producer created by the WebSocket service registers no schema, so it is rejected when the target topic has a schema and schema validation is enforced for that topic or its namespace; this setting is not enabled by default. The same user is refused when attempting to produce to that topic directly. Where automatic topic creation is enabled, which is the default, the named topic is created if it does not already exist. The issue can only be triggered when the WebSocket service is enabled, either in the broker (webSocketServiceEnabled, which is disabled by default) or as a standalone WebSocket proxy. The impact is unauthorized injection of messages into topics the user is not permitted to produce to. The user can determine the content of the injected messages when they also control the messages on the subscribed topic. The issue does not allow reading, modifying or deleting existing messages in the target topic. Injected messages carry the dead letter message properties and a dead letter producer name, so they can be distinguished from messages produced normally; however, the values of these properties are not authenticated and should not be relied upon to establish the origin of a message. Whether an injected message has further consequences depends on how the applications consuming the target topic process it. Repeated injection also consumes storage and backlog capacity in the target namespace. This issue affects Apache Pulsar versions from 2.3.0 before 4.0.14 and from 4.1.0 before 4.2.5. - 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 do not require the WebSocket service should disable it. Where the WebSocket service is required, restricting network access to it and limiting the permissions granted to the role the WebSocket service uses to connect to the brokers to the namespaces WebSocket clients are intended to access reduces the exposure. | ||||
| CVE-2026-105926 | 1 Apache | 1 Pulsar | 2026-10-30 | N/A |
| The Pulsar broker serves two schema commands on its binary protocol: GetSchema, which returns the schema registered for a topic, and GetOrCreateSchema, which registers a new schema version for an existing topic. The broker handled both commands after checking only that the client connection was authenticated. Unlike the broker's other topic commands, such as those for creating producers and consumers or for looking up topics, these two commands did not check whether the authenticated client was authorized for the target topic. The Pulsar REST API endpoints for schemas were not affected. An authenticated client without any permission on the target topic, namespace or tenant could use these commands to: - read the schema registered for a topic in another namespace or tenant, disclosing the schema definition such as record field names and types. Message payloads are not disclosed. - register a new schema version on an existing topic in another namespace or tenant. The topic's schema compatibility and schema auto-update policies still apply. The issue does not allow message data to be read or modified, but a registered schema version can cause legitimate producers and consumers of that topic to fail with schema incompatibility errors until the schema is corrected by an administrator. The standard Pulsar client performs an authorized topic lookup before it sends these commands, so the missing check could not be observed when testing with the standard client. A client that implements the binary protocol directly is not required to perform that lookup first. This issue is relevant only to deployments that have authentication and authorization enabled. The GetSchema command is affected from Apache Pulsar 2.2.0, and the GetOrCreateSchema command from Apache Pulsar 2.5.0. After the fix, the broker requires the lookup permission on the topic for GetSchema and the produce permission on the topic for GetOrCreateSchema. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different. This issue affects Apache Pulsar versions from 2.2.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.0 before 4.2.5. - 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/. | ||||
| CVE-2026-104948 | 1 Enterprisedb | 1 Warehousepg | 2026-10-30 | N/A |
| WarehousePG (WHPG) 6.27.1 through 6.27.6 and 7.2.1 through 7.6.0 are affected by a missing authorization vulnerability (CWE-862) in the built-in cluster expansion functions gp_expand_lock_catalog() and gp_expand_bump_version(). Any authenticated database role can run them, and neither checks privileges. A low-privileged user can call gp_expand_lock_catalog() inside an open transaction to block all catalog changes across the cluster for every user, superusers included, until that transaction ends, which in practice requires a superuser to terminate the session. Blocked changes include DDL, temporary table creation, GRANT and CREATE ROLE. The same user can call gp_expand_bump_version() repeatedly. Each call disconnects sessions that hold temporary tables, with a FATAL error on their next catalog change, and makes every other session rebuild its segment connections. | ||||
| CVE-2026-104947 | 1 Enterprisedb | 1 Warehousepg | 2026-10-30 | N/A |
| WarehousePG (WHPG) 7.2.1 through 7.6.0 is affected by a missing authorization vulnerability (CWE-862) in the built-in function gp_log_backend_memory_contexts(). Any authenticated database role can run this function without a GRANT. It also gets around the superuser restriction that PostgreSQL places on the underlying pg_log_backend_memory_contexts() function. A low-privileged user can force the segment backends of any other session, superuser sessions included, to write their memory context details to the segment server logs, which the attacker cannot read. Those details can include query text from other users' cached plans, and the call can be repeated to generate large amounts of log output. WarehousePG 6.x is not affected. | ||||