CVE mới & PoC public

210 CVE

• CVE-2026-105711 Thấp 3.5 CWE-524 22/10 08:16

  GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.0 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when a merge request in a public project referenced a confidential issue from a private project, an authenticated user with no project membership could have read the confidential issue's title, due to a viewer-independent fragment cache key that incorrectly shared per-user-redacted rendered content across all users.

• CVE-2026-103515 Thấp 2.7 CWE-863 22/10 08:16

  GitLab has remediated an issue in GitLab EE affecting all versions from 19.2 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when an instance administrator locked a group's Duo availability, an authenticated user with group Owner permissions could have re-enabled AI-backed data egress to a third-party service for that group and its descendant projects, due to insufficient granularity of the admin-lock enforcement controls.

• CVE-2026-114384 Thấp 2.1 CWE-74 22/10 05:16

  A security vulnerability has been detected in itsourcecode Online Cake Ordering System 1.0. Affected is an unknown function of the file /transactionsave.php. Such manipulation of the argument del leads to sql injection. The attack can be launched remotely. The exploit has been disclosed publicly and may be used.

• CVE-2026-114381 Thấp 2.1 CWE-74 22/10 05:16

  A vulnerability was determined in itsourcecode Online Cake Ordering System 1.0. The affected element is an unknown function of the file /orderdetail.php. Executing a manipulation of the argument ID can lead to sql injection. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized.

• CVE-2026-114380 Thấp 2.1 CWE-74 22/10 04:17

  A vulnerability was found in itsourcecode Online Cake Ordering System 1.0. Impacted is an unknown function of the file /inserttrans.php. Performing a manipulation of the argument prcd results in sql injection. The attack is possible to be carried out remotely. The exploit has been made public and could be used.

• CVE-2026-114378 Thấp 2.1 CWE-74 22/10 04:17

  A vulnerability was detected in itsourcecode Online Cake Ordering System 1.0. This affects an unknown part of the file /deleteproduct.php. The manipulation of the argument ID results in sql injection. The attack may be launched remotely. The exploit is now public and may be used.

• CVE-2026-114377 Thấp 2.0 CWE-22 22/10 04:17

  A security vulnerability has been detected in leomoon-studios wiki-go up to 1.9.1. Affected by this issue is the function DeleteComment of the file internal/comments/comments.go of the component Comment Deletion Handler. The manipulation of the argument documentPath leads to path traversal. The attack may be initiated remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 1.9.2 can resolve this issue. The identifier of the patch is 224ef2a11facddef6b3a3c1f0a69156d1e574a33. It is advisable to upgrade the affected component.

• CVE-2026-114376 Thấp 2.1 CWE-22 22/10 03:17

  A weakness has been identified in leomoon-studios wiki-go up to 1.9.1. Affected by this vulnerability is the function SaveHandler/SourceHandler of the file internal/handlers/editor.go of the component API. Executing a manipulation can lead to path traversal. The attack can be launched remotely. The exploit has been made available to the public and could be used for attacks. Upgrading to version 1.9.2 addresses this issue. This patch is called 94f7e73ef8df7c58091d72d77a5e26e9fdad98b8. Upgrading the affected component is advised.

• CVE-2026-114375 Thấp 2.1 CWE-22 22/10 03:17

  A security flaw has been discovered in leomoon-studios wiki-go up to 1.9.1. Affected is the function RenameFileHandler of the file internal/handlers/files.go of the component Files Rename API. Performing a manipulation of the argument currentPath/newName results in path traversal. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. Upgrading to version 1.9.2 is able to address this issue. The patch is named 81cd12e248314a52605f0f39718c8a76272eac29. It is recommended to upgrade the affected component.

• CVE-2026-114374 Thấp 2.1 CWE-918 22/10 03:17

  A vulnerability was identified in leomoon-studios wiki-go up to 1.9.1. This impacts an unknown function of the file internal/handlers/metadata_api.go of the component fetch-metadata Endpoint. Such manipulation leads to server-side request forgery. It is possible to launch the attack remotely. The exploit is publicly available and might be used. Upgrading to version 1.9.2 will fix this issue. The name of the patch is 25498ebf5c012b870967e38eec2a1e5133fa1a83. Upgrading the affected component is recommended.

• CVE-2026-18748 Thấp 3.5 CWE-125 22/10 02:17

  The Bluetooth Classic A2DP host stores a codec Information Element (IE) in struct bt_a2dp_codec_ie, a one-byte len field plus a fixed 8-byte codec_ie[] array. When an AVDTP peer sent a codec IE longer than 8 bytes, a2dp_process_config_ind() in subsys/bluetooth/host/classic/a2dp.c copied only the first 8 bytes but assigned the full, attacker-chosen length to len, and then persisted that inconsistent structure into the application's struct bt_a2dp_stream via stream->codec_config. bt_a2dp_get_config_cb() and bt_a2dp_set_config_cb() had the same truncate-the-copy-but-keep-the-length pattern. Every later consumer trusts len. In particular the responder for an incoming AVDTP GET_CONFIGURATION, a2dp_get_config_ind(), executes net_buf_add_mem(rsp_buf, &ep->stream->codec_config.codec_ie[0], ep->stream->codec_config.len), so a paired BR/EDR peer that first sends a SET_CONFIGURATION carrying an oversized codec IE and then requests the configuration back causes the stack to read up to roughly 245 bytes past the end of the 8-byte array and transmit them in the response. codec_config is the last member of struct bt_a2dp_stream, so the read runs into memory adjacent to the application's stream object. The same inconsistency is also handed to the config_req(), reconfig_req() and get_config_rsp() application callbacks, where a natural memcpy() of len bytes performs a further out-of-bounds read. Reaching the on-air disclosure requires CONFIG_BT_CLASSIC with CONFIG_BT_A2DP, an AVDTP peer that has completed pairing (the AVDTP L2CAP channel requires BT_SECURITY_L2), and a local endpoint registered for a non-SBC codec — BT_A2DP_MPEG1/BT_A2DP_MPEG2/BT_A2DP_ATRAC/BT_A2DP_VENDOR via BT_A2DP_EP_INIT() — because the SBC branch already pins the IE length to 4 bytes. The bt_a2dp_get_config_cb() response path has no such gate and hands the lying length to any application. There is no out-of-bounds write: the net_buf tailroom check bounds the destination, so the impact is limited to disclosure of a bounded region of adjacent RAM to the peer. The fix replaces the hardcoded BT_A2DP_MAX_IE_LENGTH with the configurable CONFIG_BT_A2DP_CODEC_MAX_IE_LEN (default 8, range 4–253), sizes codec_ie[] from it, and rejects any received IE that exceeds it instead of silently truncating, so len can no longer exceed the number of valid bytes.

• CVE-2026-114266 Thấp 2.1 CWE-74 22/10 02:17

  A security vulnerability has been detected in ProjectWorlds Advanced Library Management System 1.0. This impacts the function mysqli_query of the file profile.php. The manipulation of the argument admin_id leads to sql injection. The attack is possible to be carried out remotely. The exploit has been disclosed publicly and may be used.

• CVE-2026-105938 Thấp 2.3 CWE-863 22/10 02:16

  Apache Pulsar namespaces can restrict which roles may use a subscription, either with the Prefix subscription authentication mode, which requires a subscription name to start with the role name, or by granting permission on a subscription to specific roles. Topic-level subscription operations, such as consuming, skipping messages, resetting a cursor or deleting a subscription, apply these subscription policies. Several admin REST API operations that act on subscriptions did not apply them: - the namespace-level and bundle-level clear backlog operations, both for a named subscription and for all subscriptions; - the namespace-level and bundle-level unsubscribe operations; - the topic-level operation that expires messages for all subscriptions of a topic. With the default authorization provider, the namespace-level operations require only consume permission granted on the namespace, and the expire-all operation requires only consume permission on the topic. As a result, when authentication and authorization are enabled and a namespace uses the Prefix subscription authentication mode or subscription permissions, an authenticated user with such consume permission can clear the backlog of, expire messages of, or delete a subscription that the policies would deny to that user. Tenant admin or superuser access is not required. The clear backlog operations can also be applied to the cursors used for geo-replication, so that messages not yet replicated to a remote cluster are skipped. Deployments that do not configure the Prefix subscription authentication mode or subscription permissions (the defaults) are not affected by this bypass, because consume permission on the namespace or topic already allows these operations there. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different. The impact is on the integrity of subscription state. Clearing or expiring the backlog moves the subscription's cursor forward, so unacknowledged messages are no longer delivered to the subscription's consumers. The unsubscribe operation deletes a subscription that has no connected consumers. Skipped messages can be permanently deleted once no other subscription or the namespace's retention policy keeps them. The issue does not allow reading message contents, changing permissions or policies, or accessing other namespaces, and it does not affect the availability of the broker. In fixed versions, the namespace-level and bundle-level operations for a named subscription apply the subscription policies to that subscription, and the operations for all subscriptions, when requested by a user who is not a tenant admin or superuser, only act on the subscriptions that the user may access. Clearing the backlog of geo-replication cursors requires tenant admin or superuser access. Topic-level subscription operations apply the subscription policies for all types of authentication data, including that of the anonymous user role. 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. All brokers in a cluster must be upgraded before relying on the namespace-level restrictions, because brokers that have not been upgraded do not apply them when they receive the internal per-bundle requests. 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 to trusted administrative clients.

• CVE-2026-105933 Thấp 2.3 CWE-636 22/10 02:16

  Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption. When the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied. While the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys. The condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics. In fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled. This issue affects Apache Pulsar versions from 1.22.0-incubating 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 rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing "isEncryptionRequired will be set to false" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur.

• CVE-2026-105932 Thấp 2.3 CWE-862 22/10 02:16

  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.