CVE mới & PoC public

1105 CVE

• CVE-2026-110803 Cao 8.7 CWE-400 22/10 02:16

  VaadinService.requestEnd() in Vaadin Framework 8 locks the session and then reads the v-uiId request parameter outside the block that releases the lock. A request carrying a non-numeric v-uiId makes Integer.parseInt throw while the session lock is held, so the lock is never released and the container thread returns to its pool still owning it. Every later request to that session then blocks forever in VaadinService.lockSession(), and repeating the request exhausts the thread pool and takes the application down. No authentication is required: a session cookie, which any client obtains with a single request, is enough. Vaadin 10 and later are not affected, because Flow releases the lock in a finally block and does not read that parameter there, and Vaadin Framework 7 is not affected either. Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include: Product version Vaadin Framework 8.16.0 - 8.32.1 Mitigation Upgrade to 8.32.2 Vaadin Framework 7 and Vaadin 10 and later do not carry this behaviour and need no upgrade for this issue. Artifacts Maven coordinates / Vulnerable versions / Fixed version com.vaadin:vaadin-server / 8.16.0 - 8.32.1 / >=8.32.2 com.vaadin:vaadin-server-mpr-jakarta / 8.18.0 - 8.32.1 / >=8.32.2

• CVE-2026-107588 Cao 8.4 CWE-79 22/10 02:16

  Vaadin Charts renders charts with the Highcharts library and pins an exact version of it, 9.2.2 in Vaadin 22 to 24 and 12.2.0 in Vaadin 25, so an application cannot remove these vulnerabilities by upgrading Highcharts on its own. Highsoft disclosed several vulnerabilities in that library that are reachable through the chart configuration: writes to Object.prototype through dotted series.keys paths, and cross-site scripting through credits.href, through breadcrumbs.style, through HTML text parsing while printing, and through xlink:href attributes in exported charts. An application is affected where data an attacker controls reaches the chart configuration, for example through additionalOptions, through updateConfiguration(), or through text options that accept markup. The fixed Vaadin versions apply Highsoft's recommended workarounds to the bundled Highcharts when it loads, and keep the same Highcharts version. Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include: Product version Vaadin 22.0.0 - 23.6.15 Vaadin 24.0.0 - 24.4.23 Vaadin 24.5.0 - 24.7.15 Vaadin 24.8.0 - 24.9.22 Vaadin 24.10.0 - 24.10.10 Vaadin 25.0.0 - 25.2.9 Vaadin 25.3.0 Mitigation Upgrade to 23.6.16 Upgrade to 24.4.24 Upgrade to 24.7.16 Upgrade to 24.9.23 Upgrade to 24.10.11 Upgrade to 25.2.10 Upgrade to 25.3.1 or newer Please note that Vaadin versions 10-13 and 15-22 are no longer supported and you should update either to the latest 23, 24, 25 version. Artifacts Maven coordinates / Vulnerable versions / Fixed version com.vaadin:vaadin / 22.0.0 - 23.6.15 / >=23.6.16 com.vaadin:vaadin / 24.0.0 - 24.4.23 / >=24.4.24 com.vaadin:vaadin / 24.5.0 - 24.7.15 / >=24.7.16 com.vaadin:vaadin / 24.8.0 - 24.9.22 / >=24.9.23 com.vaadin:vaadin / 24.10.0 - 24.10.10 / >=24.10.11 com.vaadin:vaadin / 25.0.0 - 25.0.13 / >=25.2.10 com.vaadin:vaadin / 25.1.0 - 25.1.13 / >=25.2.10 com.vaadin:vaadin / 25.2.0 - 25.2.9 / >=25.2.10 com.vaadin:vaadin / 25.3.0 / >=25.3.1 com.vaadin:vaadin-charts-flow / 22.0.0 - 23.6.15 / >=23.6.16 com.vaadin:vaadin-charts-flow / 24.0.0 - 24.4.22 / >=24.4.24 com.vaadin:vaadin-charts-flow / 24.5.0 - 24.7.14 / >=24.7.15 com.vaadin:vaadin-charts-flow / 24.8.0 - 24.9.22 / >=24.9.23 com.vaadin:vaadin-charts-flow / 24.10.0 - 24.10.10 / >=24.10.11 com.vaadin:vaadin-charts-flow / 25.0.0 - 25.0.13 / >=25.2.10 com.vaadin:vaadin-charts-flow / 25.1.0 - 25.1.13 / >=25.2.10 com.vaadin:vaadin-charts-flow / 25.2.0 - 25.2.9 / >=25.2.10 com.vaadin:vaadin-charts-flow / 25.3.0 / >=25.3.1 com.vaadin:vaadin-charts-flow-svg-generator / 21.0.0 - 23.6.15 / >=23.6.16 com.vaadin:vaadin-charts-flow-svg-generator / 24.0.0 - 24.4.22 / >=24.4.24 com.vaadin:vaadin-charts-flow-svg-generator / 24.5.0 - 24.7.14 / >=24.7.15 com.vaadin:vaadin-charts-flow-svg-generator / 24.8.0 - 24.9.22 / >=24.9.23 com.vaadin:vaadin-charts-flow-svg-generator / 24.10.0 - 24.10.10 / >=24.10.11 com.vaadin:vaadin-charts-flow-svg-generator / 25.0.0 - 25.0.13 / >=25.2.10 com.vaadin:vaadin-charts-flow-svg-generator / 25.1.0 - 25.1.13 / >=25.2.10 com.vaadin:vaadin-charts-flow-svg-generator / 25.2.0 - 25.2.9 / >=25.2.10 com.vaadin:vaadin-charts-flow-svg-generator / 25.3.0 / >=25.3.1 npm packages npm package / Vulnerable versions / Fixed version @vaadin/charts / 22.0.0 - 23.6.6 / >=23.6.7 @vaadin/charts / 24.0.0 - 24.4.18 / >=24.4.19 @vaadin/charts / 24.5.0 - 24.7.12 / >=24.7.13 @vaadin/charts / 24.8.0 - 24.9.18 / >=24.9.19 @vaadin/charts / 24.10.0 - 24.10.6 / >=24.10.7 @vaadin/charts / 25.0.0 - 25.0.13 / >=25.2.14 @vaadin/charts / 25.1.0 - 25.1.14 / >=25.2.14 @vaadin/charts / 25.2.0 - 25.2.13 / >=25.2.14 @vaadin/charts / 25.3.0 / >=25.3.1

• CVE-2026-105945 Cao 7.7 CWE-22 22/10 02:16

  The Pulsar Packages Management Service can be configured to store packages on the local filesystem of the broker by using the filesystem storage provider. Package names consist of a type, tenant, namespace, name and version. Authorization of package operations is based only on the tenant and namespace, while the storage location of a package is derived from all of these components. The version component of a package name was not validated, so it could contain URL-encoded path separators and parent directory references. The filesystem storage provider resolved such a version to a location belonging to a package in a different tenant or namespace. Because that location is inside the configured storage directory, the containment check that the filesystem storage provider performs in recent releases did not prevent the access. An authenticated user who has the packages permission on any namespace could use this to download, overwrite or delete packages stored in other tenants or namespaces for which the user has no permission. Packages overwritten or deleted in this way may be used by Pulsar Functions, Sources or Sinks, so the issue can affect the integrity and availability of these components. If authentication is disabled, the operations are available to any client that can reach the broker's admin REST API. This issue only affects deployments in which package management is enabled with the broker setting enablePackagesManagement and the filesystem storage provider (FileSystemPackagesStorageProvider) is configured with the setting packagesManagementStorageProvider. Package management is disabled by default, and the default storage provider, which stores packages in Apache BookKeeper, is not affected. This issue affects Apache Pulsar versions from 2.10.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/.

• CVE-2026-105942 Cao 7.7 CWE-863 22/10 02:16

  When a configured proxy role sends a request to the broker on behalf of another user (the original principal), the broker is designed to authorize both the proxy role and the original principal and to allow the request only if both are authorized, so that the original principal cannot exceed its own permissions. Two flaws weakened this check. First, the original principal was authorized with the proxy's authentication data instead of its own. On the admin REST API of the broker and the functions worker, this applied to every proxied request. On the Pulsar binary protocol, it applied when the proxy did not forward the client's credentials to the broker, which was the default of the Pulsar proxy in the affected versions. Authorization providers that resolve permissions from the role name only, such as the default authorization provider, are not affected by this flaw. The multi-role token authorization provider (MultiRolesTokenAuthorizationProvider), added in Apache Pulsar 2.8.1, resolves roles from the role claim of the token in the authentication data it is given. When a proxy authenticates to the broker with its own token, the original principal was therefore authorized with all roles in the proxy's token. If any of those roles is a superuser or tenant admin role, any user whose requests are forwarded by that proxy can perform operations that need those permissions without holding them. Custom authorization providers that use the authentication data could be affected in a similar way. Second, independently of the authorization provider, the tenant admin check of a proxied admin REST API request succeeded without checking the original principal when the proxy role was itself an admin role of the tenant. In deployments where a proxy role is a tenant admin, including with the default authorization provider, any user whose requests are forwarded by that proxy could perform tenant administration operations on that tenant. This behavior is present from 2.8.4 in the 2.8.x releases, from 2.9.3 in the 2.9.x releases, and from 2.10.1 onwards. Deployments that use neither the multi-role token authorization provider nor a custom provider that uses the authentication data are not affected by the first flaw, and with the multi-role token authorization provider, neither are deployments whose proxies do not authenticate to the broker with a token. Deployments in which no proxy role is listed as an admin role of a tenant are not affected by the second flaw. A proxy role that is a superuser but is not listed as a tenant admin does not trigger it, because the tenant admin check of the built-in authorization providers only considers the tenant's admin roles; this can differ for custom authorization providers that treat superusers as tenant admins. In fixed versions, both the proxy role and the original principal are authorized for each proxied request, and the original principal is authorized only with its own authentication data. With the multi-role token authorization provider, the roles of a forwarded token are used for the original principal only when that token authenticates as the original principal; otherwise only the original principal's role name is used. For tenant admin checks, the proxy role and the original principal must each be a superuser or a tenant admin of the tenant. This issue affects Apache Pulsar versions from 2.8.1 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/.

• CVE-2026-105937 Cao 8.7 CWE-862 22/10 02:16

  Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic's managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths. As a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user's own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different. The user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic's ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic's schema, subject to the schema compatibility settings; existing schema versions are not replaced. In addition, the shadow topic's managed ledger applies its own retention, trimming, offloading and deletion to the source topic's ledgers. This can permanently delete the source topic's ledger data from BookKeeper and from tiered storage, regardless of the source topic's own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic's ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators. This issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation. - 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/. In the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic. Affected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals.

• CVE-2026-105934 Cao 7.2 CWE-862 22/10 02:16

  The Apache Pulsar broker admin REST API provides a truncate operation for persistent topics (DELETE /admin/v2/persistent/{tenant}/{namespace}/{topic}/truncate). Truncating a topic moves all subscription cursors of the topic to the end of the topic and deletes the topic's inactive ledgers. Truncating a non-partitioned topic, or a single partition addressed by its partition name, correctly requires the tenant admin role or the superuser role. When the operation is requested for the name of a partitioned topic, the broker does not apply this tenant admin check to the caller. Instead, it truncates each partition using the broker's own internal admin client, which authenticates with the broker's configured client credentials rather than the caller's identity. Each per-partition truncate request is still checked for the tenant admin role or the superuser role, but against the broker's internal identity instead of the caller. The partitions are therefore truncated only when the broker's configured client role is a superuser or an admin of the target tenant, which is the usual configuration when authorization is enabled. As a result, when that condition holds, an authenticated user who is not a tenant admin can truncate any partitioned topic on which the user has lookup permission. Caller authentication and lookup permission alone are not sufficient: if the broker's internal identity lacks tenant admin or superuser authorization for the target tenant, the per-partition requests are rejected. With the default authorization provider, lookup permission is granted by produce or consume permission on the topic or its namespace. A user with no permissions on the topic cannot trigger the issue. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different. Truncating a partitioned topic this way moves the cursors of all subscriptions on every partition to the end of the topic, so any unacknowledged backlog is skipped and is no longer delivered to consumers. It also deletes eligible older ledgers of each partition regardless of the namespace's configured retention policy, so messages stored in those ledgers can be permanently lost. The ledger currently being written is not deleted by the truncate operation. The issue does not allow reading message contents or changing permissions or configuration, and it does not give access to topics on which the user has no lookup permission. 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 can reduce exposure by restricting network access to the broker's admin REST API (/admin/v2) to trusted administrative clients.

• CVE-2025-55702 Cao 7.0 CWE-444 22/10 02:16

  When a client sends a POST with Expect: 100-continue and the origin answers before reading the body, Apache Traffic Server parses the unread body left on the client connection as the next request. An attacker behind a front-end proxy that shares connections to Traffic Server can use this to smuggle requests past the front end and desynchronize responses for other users. This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0. Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.

• CVE-2026-92210 Cao 7.2 CWE-918 22/10 01:17

  NoMachine nxhtd Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to initiate arbitrary server-side requests on affected installations of NoMachine. Authentication is not required to exploit this vulnerability. The specific flaw exists within the web service, which listens on UDP port 4443 by default. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to initiate requests in the context of the service account. Was ZDI-CAN-31619.

• CVE-2026-92209 Cao 7.8 CWE-331 22/10 01:17

  NoMachine Redis Improper Authentication Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of NoMachine. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the authentication mechanism controlling access to the Redis database. The issue results from using insufficient entropy in the generation of credentials. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the service account. Was ZDI-CAN-30984.

• CVE-2026-92208 Cao 8.8 CWE-122 22/10 01:17

  NoMachine mDNS Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of NoMachine. Authentication is not required to exploit this vulnerability. The specific flaw exists within the parsing of mDNS resource records. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-30982.

• CVE-2026-92207 Cao 8.8 CWE-94 22/10 01:17

  MindsDB OpenBBtable Code Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of MindsDB. Authentication is required to exploit this vulnerability. The specific flaw exists within the OpenBBtable class. The issue results from the lack of proper validation of a user-supplied string before using it to execute Python code. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-28388.

• CVE-2026-92206 Cao 8.8 CWE-470 22/10 01:17

  CrewAI crewAI Framework Agent Loading Unsafe Reflection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of CrewAI crewAI. User interaction is required to exploit this vulnerability in that the target must load a malicious agent configuration from the repository. The specific flaw exists within the load_agent_from_repository function. The process does not properly restrict a user-supplied argument before using it to import a module. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-28387.

• CVE-2026-92204 Cao 7.7 CWE-918 22/10 01:17

  Airbyte OneDrive Connector _get_shared_drive_object Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to initiate arbitrary server-side requests on affected installations of Airbyte. Authentication is required to exploit this vulnerability. The specific flaw exists within the _get_shared_drive_object method. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to disclose information in the context of the service account. Was ZDI-CAN-28216.

• CVE-2026-92203 Cao 7.7 CWE-918 22/10 01:17

  Airbyte SharePoint Connector _get_shared_drive_object Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to initiate arbitrary server-side requests on affected installations of Airbyte. Authentication is required to exploit this vulnerability. The specific flaw exists within the implementation of the _get_shared_drive_object method. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to disclose information in the context of the service account. Was ZDI-CAN-28215.

• CVE-2026-92202 Cao 7.8 CWE-427 22/10 01:17

  Luxion KeyShot BIP File Parsing Uncontrolled Search Path Element Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Luxion KeyShot. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of BIP files. The issue results from loading a library from an unsecured location. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-29268.