Total
408859 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-79912 | 2026-08-26 | 7.5 HIGH | 8.3 HIGH | ||
| A vulnerability was detected in TOTOLINK N600R 4.3.0cu.7647_B20210106. The impacted element is the function getCurrentTime of the file /cgi-bin/cstecgi.cgi. Performing a manipulation of the argument ntp_server results in command injection. The attack can be initiated remotely. The exploit is now public and may be used. | |||||
| CVE-2026-79792 | 2026-08-26 | 5.1 MEDIUM | 5.6 MEDIUM | ||
| A flaw has been found in zackees transcribe-anything up to 4.1.0. Affected is the function ytdlp_download of the file src/transcribe_anything/ytldp_download.py of the component Yt-dlp Download. This manipulation of the argument url causes os command injection. The attack may be initiated remotely. The attack's complexity is rated as high. The exploitability is told to be difficult. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet. | |||||
| CVE-2026-18328 | 2026-08-26 | N/A | 7.2 HIGH | ||
| The Forminator Forms – Contact Form, Payment Form & Custom Form Builder plugin for WordPress is vulnerable to DOM-Based Reflected Cross-Site Scripting via the 'error_description' parameter in all versions up to, and including, 1.57.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The vulnerability is only triggerable on pages hosting a Forminator form configured to use the Stripe Checkout Sessions payment API, which became the default in 1.56.0. | |||||
| CVE-2026-18323 | 2026-08-26 | N/A | 7.2 HIGH | ||
| The Forminator Forms – Contact Form, Payment Form & Custom Form Builder plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Radio Field (Save and Continue Draft) in all versions up to, and including, 1.57.0.2 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This is exploitable because the Save-and-Continue draft submission AJAX endpoint is registered as nopriv, allowing unauthenticated attackers to bypass radio field option-membership validation and persist a crafted payload that, when rendered on the Submissions admin page, is auto-executed via the bundled Inputmask library's data-attribute callback binding. | |||||
| CVE-2026-75977 | 2026-08-26 | N/A | 8.8 HIGH | ||
| The Mang Board WP plugin for WordPress is vulnerable to Missing Authorization via Authentication Cookie Forgery in all versions up to, and including, 2.3.7. This is due to flawed HMAC generation in the mbw_get_hash_key() function that uses the current user's identity instead of the cookie username parameter when a WordPress user is logged in, combined with insufficient validation in mbw_validate_auth_cookie(). This makes it possible for authenticated attackers, with subscriber-level access and above, to forge administrator authentication cookies and change administrator passwords to achieve complete site takeover. | |||||
| CVE-2026-78864 | 2026-08-26 | 6.5 MEDIUM | 6.3 MEDIUM | ||
| A vulnerability was determined in liketrek TREK up to 3.0.22. The affected element is the function journeyService.updateEntry of the file server/src/nest/journey/journey.controller.t of the component Journey Entry Update. This manipulation causes sql injection. It is possible to initiate the attack remotely. Upgrading to version 3.1.0 is sufficient to fix this issue. It is recommended to upgrade the affected component. | |||||
| CVE-2026-18512 | 2026-08-26 | N/A | 6.4 MEDIUM | ||
| The TranslatePress – Translate Multilingual sites with AI Translation plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Approved Comment Body Rendered in Translation Editor Strings Dropdown in all versions up to, and including, 3.2.6 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | |||||
| CVE-2026-76391 | 1 Splunk | 1 Ai Toolkit | 2026-08-26 | N/A | 8.3 HIGH |
| In Splunk AI Toolkit versions below 6.0.0, a user who does not hold the "admin" or "power" Splunk roles could run searches with system-level privileges, access all relevant data, affect system integrity, and read or delete search jobs belonging to other users through Agent Run History. The improper privilege management is possible because the Agent Run History handler replaces the calling user session key with a system authentication token before it performs search operations. For more information see AI Toolkit Agent Launchpad (https://help.splunk.com/en/splunk-enterprise/apply-machine-learning/use-ai-toolkit/6.0.0/ai-toolkit-connections-containers-and-agents/ai-toolkit-agent-launchpad) in the Splunk documentation. | |||||
| CVE-2026-76367 | 1 Splunk | 1 Soar | 2026-08-26 | N/A | 4.0 MEDIUM |
| In Splunk SOAR versions below 8.6.0, a user who holds the "Incident Commander" Splunk SOAR role could store JavaScript in a note and run it in the browser of another user when that user opens the note. The stored Cross-Site Scripting (XSS) vulnerability is possible because Splunk SOAR can treat existing note content as Hypertext Markup Language (HTML) without sanitizing that content when the note format changes. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "Incident Commander" Splunk SOAR role should not be able to exploit the vulnerability at will. For more information see Manage roles and permissions in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) in the Splunk documentation. | |||||
| CVE-2026-76355 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 7.5 HIGH |
| In Splunk Enterprise 10.4 versions below 10.4.2, an unauthenticated user could retrieve the information contained in Edge Processor pipeline configurations through a Representational State Transfer (REST) API endpoint when Edge Processor is turned on. The vulnerability does not affect versions prior to 10.4. The vulnerability exists because the Edge Processor service endpoint lacks authentication controls. For more information see System architecture of the Edge Processor solution (https://help.splunk.com/en/splunk-enterprise/process-data-at-the-edge/use-edge-processors-for-splunk-enterprise/10.4/how-the-edge-processor-solution-works/system-architecture-of-the-edge-processor-solution) in the Splunk documentation. | |||||
| CVE-2026-76344 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 7.7 HIGH |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could write dispatch metadata to an arbitrary location on the host by supplying a crafted search identifier to a Representational State Transfer (REST) API endpoint and affect system integrity on the host. The vulnerability is possible because Splunk Enterprise does not validate the search identifier before using it to create a dispatch directory. 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-76343 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 6.5 MEDIUM |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could execute attacker-chosen Structured Query Language (SQL) queries through the Data Orchestration jobs endpoint, allowing for access to substantially all data stored by Data Orchestration, including jobs owned by other users and stored connection credentials. The vulnerability is possible because Data Orchestration builds a database query from user-controlled job filter values without using parameterized queries. 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-76342 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 5.4 MEDIUM |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store risky Search Processing Language (SPL) commands in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the commands when that user opens the dataset in the Table Editor. The commands run using the permissions of the second user and could expose all relevant data and modify lookup files. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands to the field-summary search that it runs for the Initial Data step. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. | |||||
| CVE-2026-76341 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 5.4 MEDIUM |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store attacker-controlled Search Processing Language (SPL) in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the SPL when that user opens the dataset in the Table Editor. The SPL runs using the permissions of the second user and could expose all relevant data and modify limited data on the search head. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands when it prepares the dataset initial data. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Define initial data for a new table dataset (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/9.4/create-and-edit-table-datasets/define-initial-data-for-a-new-table-dataset), SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands), and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. | |||||
| CVE-2026-76340 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 5.3 MEDIUM |
| In Splunk Enterprise 10.4 versions below 10.4.2, an unauthenticated user could cause Splunk Enterprise to reload token-signing keys through the Representational State Transfer (REST) API. The vulnerability does not affect Splunk Enterprise versions below 10.4. The vulnerability is possible because the REST API does not require authentication or the change_authentication capability for the token-key reload action. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. | |||||
| CVE-2026-76339 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 5.4 MEDIUM |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could inject arbitrary Search Processing Language (SPL) commands through the geostats command. The injected SPL runs with the permissions of another authenticated user after that user initiates the attacker-controlled geostats search in Splunk Web. The injected SPL could expose all relevant data available to the second user, including stored credentials, and modify lookup files that the second user has permission to change. The vulnerability is possible because the geostats command does not sufficiently validate input before Splunk Enterprise processes it. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who does not hold the "admin" or "power" Splunk roles should not be able to exploit the vulnerability at will. For more information see geostats (https://help.splunk.com/en/splunk-enterprise/spl-search-reference/10.0/search-commands/geostats) in the Splunk documentation. | |||||
| CVE-2026-76337 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 5.3 MEDIUM |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could read JavaScript files outside the Splunk Web static directory. The vulnerability is possible because Splunk Web does not restrict static file requests to the configured static directory. | |||||
| CVE-2026-76336 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 7.1 HIGH |
| In Splunk Enterprise versions below 10.4.2 and 10.2.6, a user who does not hold the "admin" or "power" Splunk roles could delete all Search Processing Language 2 (SPL2) modules across all apps and users on the instance through the SPL2 module management Representational State Transfer (REST) API. This could delete exported datasets and functions, affect system integrity, and cause partial service disruption. The vulnerability does not affect Splunk Enterprise versions below 10.2. The vulnerability is possible because the SPL2 module management REST API does not sufficiently authorize and validate module deletion requests. For more information see Manage SPL2 modules (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/multiple-searches-in-an-spl2-module/manage-spl2-modules) and Module permissions (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions) in the Splunk documentation. | |||||
| CVE-2026-76333 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 7.1 HIGH |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store a Dashboard Studio workflow action with a crafted Uniform Resource Locator (URL). When another authenticated user selects the stored action from Event Actions and selects Continue, attacker-controlled JavaScript runs in the browser of that user. This could expose data or actions available through Splunk Web to that user. The vulnerability is possible because Dashboard Studio does not sufficiently validate workflow-action URLs before processing them. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. | |||||
| CVE-2026-76329 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 6.4 MEDIUM |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could trick a user who holds the "admin" Splunk role into opening a crafted link to Monitoring Console. When that user opens the link, Splunk Enterprise runs attacker-controlled Search Processing Language (SPL) using the permissions of that user. The injected SPL could expose data available to that user or modify lookup data. The vulnerability is possible because Monitoring Console does not sufficiently validate data used to build dashboard searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The unauthenticated user should not be able to exploit the vulnerability at will. | |||||