Export limit exceeded: 412944 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (412944 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-76295 | 2026-10-21 | 4.3 Medium | ||
| In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and Splunk Secure Gateway versions below 3.10.12, 3.9.26, and 3.8.73, a user who does not hold the "admin" or "power" Splunk roles could view dashboard and report listings beyond the requested filter scope while remaining within objects that the user can access. The vulnerability is possible because Splunk Secure Gateway does not neutralize special characters in values before it creates filters for dashboard and report requests. For more information see About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access) in the Splunk documentation. | ||||
| CVE-2026-76294 | 2026-10-21 | 4.3 Medium | ||
| In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the "admin" or "power" Splunk roles could move field extractions or field transformations to apps for which the user does not have read access. The vulnerability is possible because the Representational State Transfer (REST) API does not validate destination app access before it processes field extraction and field transformation move operations. For more information see Use the Field extractions page (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/10.6/use-the-settings-pages-for-field-extractions-in-splunk-web/use-the-field-extractions-page) and Manage knowledge object permissions (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/10.6/get-started-with-knowledge-objects/manage-knowledge-object-permissions) in the Splunk documentation. | ||||
| CVE-2026-76293 | 2026-10-21 | 7.2 High | ||
| In Splunk Enterprise versions below 10.4.3, 10.2.8, 10.0.11, and 9.4.16, a user that holds a role with the edit_manager_xml capability could execute arbitrary operating-system commands using the permissions of the user account running Splunk Enterprise by opening the affected configuration in the Splunk Web Manager page. The vulnerability is possible because Splunk Web evaluates user-controlled expressions from Manager XML without sufficiently restricting the expression syntax. | ||||
| CVE-2026-76292 | 2026-10-21 | 6.5 Medium | ||
| In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and Splunk Secure Gateway versions below 3.10.12, 3.9.26, and 3.8.73, a low-privileged user that does not hold the "admin" Splunk role or the "sc_admin" Splunk Secure Gateway role could read mobile alert notification data for other users through Splunk Secure Gateway App Key Value Store (KV Store) Representational State Transfer (REST) API endpoints. The vulnerability is possible because the affected Splunk Secure Gateway App Key Value Store collections do not enforce user-level authorization for read requests. For more information see About the app key value store (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/administer-the-app-key-value-store/about-the-app-key-value-store) and About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access) in the Splunk documentation. | ||||
| CVE-2026-76291 | 2026-10-21 | 8.8 High | ||
| In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user that holds a role with the schedule_search capability could bypass the expected safeguards in the scheduled search workflow. The user could then run risky Search Processing Language (SPL) commands that disclose or alter Splunk Enterprise data or disrupt Splunk Enterprise availability. The vulnerability is possible because the Splunk Enterprise search scheduler does not apply SPL safeguards for risky commands to scheduled searches. For more information see SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.6/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) in the Splunk documentation. For more information see authorize.conf (https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.6/configuration-file-reference/10.6.0-configuration-file-reference/authorize.conf) in the Splunk documentation. | ||||
| CVE-2026-76290 | 2026-10-21 | 7.5 High | ||
| In Splunk Enterprise versions below 10.4.4, 10.2.8, and 10.0.11, an unauthenticated user could send repeated requests to the Edge Processor package download endpoint in the Splunk Pipeline Builders app. The requests could cause the Splunk daemon to consume excessive system resources and potentially stop responding. The vulnerability is possible because the endpoint accepts package download requests without authentication and reads and base64-encodes the complete package in memory for each request. After upgrading, prepare all existing Edge Processor instances, turn on authentication for Edge Processor package downloads, and restart Splunk Enterprise. For more information, see Enable authentication for Edge Processor package downloads (https://help.splunk.com/en/data-management/process-data-at-the-edge/use-edge-processors-for-splunk-enterprise/10.4/administer-edge-processors/enable-authentication-for-edge-processor-package-downloads). | ||||
| CVE-2026-76289 | 2026-10-21 | 6.5 Medium | ||
| In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the "admin" or "power" Splunk roles could make the Splunk Enterprise instance unavailable to other users by sending a request to the Representational State Transfer (REST) API endpoint for lookup table files. The affected instance requires a restart to restore service. The vulnerability is possible because the endpoint does not limit resource use when it processes response field selections. For more information see Endpoints reference list (https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.4/introduction/endpoints-reference-list) and About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access) in the Splunk documentation. | ||||
| CVE-2026-76288 | 2026-10-21 | 7.5 High | ||
| In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, an unauthenticated user could send a single crafted request to the Splunk Web JavaScript logger endpoint and cause Splunk Web to stop responding to requests. Splunk Web remains unavailable until Splunk Enterprise is restarted. The vulnerability is possible because Splunk Web does not limit request-header parsing before processing the request. | ||||
| CVE-2026-76287 | 2026-10-21 | 5.4 Medium | ||
| In Splunk Enterprise versions below 10.4.4, a user that holds a role with the preview_data_management_pipeline capability or edit_data_management_pipeline_job capability could read or delete Data Management SPL2 preview jobs and results outside their ownership scope. The vulnerability is possible because the Data Management Representational State Transfer (REST) API verifies the required capability but does not verify that the requested preview job belongs to the requester. The affected Data Management REST API is available only when the Edge Processor feature is turned on. The Edge Processor feature is turned off by default. For more information see Set up a data management control plane (https://help.splunk.com/en/splunk-enterprise/process-data-at-the-edge/use-edge-processors-for-splunk-enterprise/10.4/getting-started/set-up-a-data-management-control-plane) and Getting sample data for previewing data transformations (https://help.splunk.com/en/splunk-enterprise/process-data-at-the-edge/use-edge-processors-for-splunk-enterprise/10.4/working-with-pipelines/getting-sample-data-for-previewing-data-transformations) in the Splunk documentation. | ||||
| CVE-2026-114441 | 1 Oretnom23 | 1 Php-travel-agency-system | 2026-10-21 | 7.3 High |
| A weakness has been identified in oretnom23 php-travel-agency-system. This issue affects some unknown processing of the file admin/update.php. This manipulation of the argument action/full_name/visa_no/hiden/title/description/page_id/user causes sql injection. The attack may be initiated remotely. The exploit has been made available to the public and could be used for attacks. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-98869 | 1 Linux | 1 Linux Kernel | 2026-10-21 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Infer zext_dst based on static register liveness analysis As reported in the thread [1], the verifier's 32-bit operations zero extension logic is broken. This logic is responsible for correct semantics of 32-bit operations on s390 architecture. According to BPF semantics, operation `w1 += 1` is supposed to zero extend the upper half of the register `r1`. On s390 the JIT relies on the verifier emitting explicit zero extension before such operations. The verifier attempts to minimize the amount of zero extensions inserted by tracking whether upper halves of the 64-bit registers are ever used. Previously such tracking worked as follows: - bpf_reg_state->subreg_def field was set by do_check_insn() for each operation defining lower but not the upper halves of the register. - Whenever an operation reading the whole register was verified, the verifier checked register's subreg_def and set bpf_insn_aux_data->zext_dst flag as true via a call to mark_insn_zext() function. - After the verification was complete, a special pass bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations with bpf_insn_aux_data->zext_dst set as true by adding explicit zero extension. Note that the logic above relies on bpf_reg_state->subreg_def, which is a property of a current verifier state. Before the commit [2] two additional steps happened: - The verifier tracked upper and lower register halves' liveness as flags REG_LIVE_READ{32,64} in bpf_reg_state->live. - The function propagate_liveness() called mark_insn_zext() in order to transfer the knowledge about which registers have their upper halves alive (and thus might require zero extension). The commit [2] removed the two steps described above, hence making possible a situation like below: - The register's upper half is set and is used on some verification path P1 and the register happens not to be marked as precise. - The checkpoint C is created while processing some instruction between register initialization and usage. - On some other verification path P2 the register's upper half is not initialized and that path ends hitting the checkpoint C. - In such a case the register's initialization on path P2 would lack zext_dst mark, making it possible for the program to inject an arbitrary value in the register's upper half. This commit replaces subreg_def based logic with computing zext_dst statically, as a part of the bpf_compute_live_registers() analysis: - The analysis now tracks usage of upper and lower halves of the registers separately. - If some instruction defines a 32-bit subregister, but not the whole register, *and* the upper half of the register is alive after that instruction, the instruction is marked as zext_dst. There is one notable drop in precision: whenever a BPF subprogram is called, all 64 bits of parameter registers are presumed to be used. The assumption is that such a drop in precision would not inflict a noticeable performance penalty. [1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/ [2] commit 107e16979905 ("bpf: disable and remove registers chain based liveness") | ||||
| CVE-2026-97206 | 1 Nlnetlabs | 1 Unbound | 2026-10-21 | 7.5 High |
| NLnet Labs Unbound, 1.22.0 up to and including version 1.26.1, contains a DNS-over-QUIC (DoQ) lifetime bug reachable by a remote DoQ client under multi-threaded operation. A client-triggered QUIC path migration can enter stream/connection cleanup while a mesh reply still retains a pointer to the DoQ stream. Cleanup frees the DoQ stream and when the pending mesh reply later completes it dereferences a stale pointer leading to a crash. | ||||
| CVE-2026-94300 | 1 Isc | 2 Bind, Bind 9 | 2026-10-21 | 8.1 High |
| Replaying GSS-TSIG signed UDP messages can result in memory corruption in "`named`". An attacker who can capture a previously signed UDP message can replay it while the negotiated TSIG key is still valid. By also sending crafted queries to a zone the attacker controls, the attacker may potentially achieve remote code execution. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.29, 9.21.0 through 9.21.26, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.29-S1. | ||||
| CVE-2026-97313 | 1 Isc | 2 Bind, Bind 9 | 2026-10-21 | 7.5 High |
| A recursive BIND server that receives a query with recursion desired (RD=1) followed by a non-recursive query (RD=0) may exit with an assertion failure, resulting in a denial of service. To be vulnerable, the BIND server must allow recursive queries and have at least two RPZ zones configured: one with the default setting of "recursive-only yes", and the other with "recursive-only no". This issue affects BIND 9 versions 9.16.0 through 9.18.50, 9.20.0 through 9.20.29, 9.21.0 through 9.21.26, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.29-S1. | ||||
| CVE-2026-89052 | 2026-10-21 | N/A | ||
| A hardcoded cryptographic key management vulnerability exists in Archer C6 due to the use of a universal cryptographic key shared across devices. An attacker who obtains an encrypted configuration file or other protected credential data can recover plaintext credentials. Successful exploitation may allow unauthorized disclosure of sensitive information, including administrative credentials. | ||||
| CVE-2026-114440 | 1 Oretnom23 | 1 Php-travel-agency-system | 2026-10-21 | 7.3 High |
| A vulnerability was identified in oretnom23 php-travel-agency-system. This affects an unknown part of the file admin/delete.php. The manipulation of the argument costomer_id/ticket_id/payment_id/id/document_id/salary_id/emp_id/user_id leads to sql injection. The attack can be initiated remotely. The exploit is publicly available and might be used. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-114076 | 1 Triggerdotdev | 1 Trigger.dev | 2026-10-21 | 5.4 Medium |
| Trigger.dev before 4.5.2 contains a blind server-side request forgery vulnerability that allows authenticated tenants to make the webapp server send POST requests to internal hosts by setting an unvalidated webhook alert channel URL. Attackers can point the webhook at internal services or cloud metadata addresses and trigger alerts to scan internal hosts, send state-changing POSTs, or reach IMDSv1 via redirects. | ||||
| CVE-2026-114079 | 1 Triggerdotdev | 1 Trigger.dev | 2026-10-21 | 5.4 Medium |
| Trigger.dev before 4.5.6 contains an improper authorization vulnerability that allows holders of lower-trust environment API keys to cancel other environments' deployments because DeploymentService.getDeployment scopes lookups by projectId only. Attackers with a dev, preview, or CI secret key can POST to the deployment cancel endpoint to cancel in-progress production deployments within the same project. | ||||
| CVE-2026-114080 | 1 Triggerdotdev | 1 Trigger.dev | 2026-10-21 | 5 Medium |
| Trigger.dev before 4.5.2 contains a blind server-side request forgery vulnerability that allows authenticated project members to make the server send requests by setting unvalidated alert-channel webhook URLs. Attackers can create alert channels pointing to loopback, internal, or cloud metadata addresses, then trigger alerts to probe internal service reachability and send signed POST requests. | ||||
| CVE-2026-106053 | 2026-10-21 | N/A | ||
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||