| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Use of uninitialized resource in GPU in Google Chrome prior to 151.0.7922.169 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| In Cisco Talos Intelligence for Enterprise Security Cloud versions below 1.0.3, a user that holds a role with the get_talos_enrichment capability could send a crafted request to the Talos intelligence enrichment Representational State Transfer (REST) API endpoint and cause the instance to make an outbound request to an attacker-controlled server. The request could expose tokens that compromise all relevant data and system integrity in the Splunk instance. The vulnerability is possible because the Talos intelligence enrichment REST endpoint accepts the destination for authenticated Splunk management requests from request data. For more information see Deploy Cisco Talos Intelligence for Splunk Enterprise Security (https://help.splunk.com/en/splunk-enterprise-security-8/user-guide/8.0/introduction/deploy-cisco-talos-intelligence-for-splunk-enterprise-security-cloud-only) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.9, 3.9.23, and 3.8.70, a user who does not hold the "admin" or "power" Splunk roles could use crafted report notification data to cause Splunk Secure Gateway to send a request to the Splunk Enterprise Representational State Transfer (REST) API using a system-level session token and modify the Splunk platform configuration. The user could then obtain a session token without a password and use it to access all relevant data and affect system integrity. The vulnerability is possible because Splunk Secure Gateway does not validate decoded report notification identifiers before using them to construct requests to the Splunk Enterprise REST API. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.9, 3.9.23, and 3.8.70, a user who does not hold the "admin" or "power" Splunk roles could use Server-Side Request Forgery (SSRF) in report notifications to send system-authenticated requests to internal Splunk services, which could allow for changes to Search Head Cluster state and a denial of service. The vulnerability is possible because Splunk Secure Gateway does not validate report notification path values before it sends internal requests. |
| Koel is a free, open-source music streaming solution. Prior to 9.7.0, the Subsonic-compatible createInternetRadioStation.view and updateInternetRadioStation.view routes accept an authenticated user's streamUrl without the SafeUrl and HasAudioContentType checks used by the regular radio API. app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php and app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php pass the stored URL through app/Services/RadioService.php to app/Services/Radio/RadioStreamProxy.php, where RadioStreamProxy::openStream() calls fopen($url, 'r', false, $context). Streaming /radio/stream/{id} returns the upstream response body, allowing access to loopback, RFC1918, Docker bridge, metadata, or other internal HTTP services reachable from the Koel server. This issue is fixed in version 9.7.0. |
| An issue in Squirro Cognitive Search < 3.14.2 allows a remote attacker to execute arbitrary code via a crafted payload to the password reset function. |
| A blind SSRF attack in DataHub v.1.5.0.1 allows a remote attacker to execute arbitrary code via the server retrieving an image from a crafted URL, and it fails to return the content or any errors directly. |
| An issue in JeecgBoot v.3.9.2 allows a remote attacker to execute arbitrary code via the files Parameter in JeecgBoot AI Chat Module |
| In Splunk Enterprise versions below 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could trick an authenticated user into running arbitrary Search Processing Language (SPL) commands using the permissions of the authenticated user through a crafted Splunk Web link. The SPL commands could access all relevant data. The vulnerability does not affect Splunk Enterprise 10.4 versions and above. The vulnerability is possible because Splunk Web substitutes form token values supplied through the Uniform Resource Locator (URL) into SPL searches without neutralizing them. 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. For more information see Token reference (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/simple-xml-dashboards/10.2/simple-xml-reference/token-reference) in the Splunk documentation. |
| FUXA is a web-based Process Visualization (SCADA/HMI/Dashboard) software. Prior to 1.3.2, the DEVICE_WEBAPI_REQUEST and DEVICE_PROPERTY Socket.IO handlers in server/runtime/index.js omit isSocketWriteAuthorized and accept attacker-controlled property.address or endpoint connection data. A remote unauthenticated attacker can make server/runtime/devices/httprequest/index.js call axios.get against arbitrary HTTP or HTTPS destinations, connect to reachable OPC UA or ODBC services, and receive results through the corresponding Socket.IO event. This read SSRF oracle can expose cloud instance metadata, internal administrative services, industrial endpoints, and ODBC data reachable from the FUXA host, including when secureEnabled is true. This issue is fixed in version 1.3.2. |
| Missing input validation in the threat intelligence feed parser in the OpenSearch Security Analytics plugin might allow an authenticated remote user to perform server-side request forgery and read local files via a crafted URL parameter to the threat intel source configuration endpoint. |
| Dell OpenManage Enterprise, versions prior to 4.7.0, contains a Server-Side Request Forgery (SSRF) vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Information exposure. |
| The scanFeedsResolver in packages/api/src/resolvers/subscriptions/index.ts passes the caller-supplied url straight to axios.get(url, rssParserConfig()) with no address validation. The same file guards the subscribe path with validateUrl(), which rejects private and reserved ranges through the private-ip library, and createPageSaveRequest applies the same check, so the omission is specific to this resolver. An authenticated user can direct the server to request arbitrary internal endpoints. The response is parsed as a feed or as HTML and the resolver returns the resulting url, title, description and type fields, so disclosure is limited to feed-shaped metadata and to link elements advertising RSS or Atom feeds; requests that do not parse still distinguish reachable ports from unreachable ones through the resulting error. |
| Lightdash stores the webhook URL supplied with a scheduled delivery and later posts to it from sendWebhook in packages/backend/src/clients/GoogleChat/GoogleChatClient.ts and in packages/backend/src/clients/MicrosoftTeams/MicrosoftTeamsClient.ts. In affected versions both call fetch on the stored URL directly. The validatePublicHttpUrl helper in packages/backend/src/utils/ssrfProtection.ts, used for MCP server URLs, is not applied on either path, and the webhook fields carry no server-side URL constraint. A user able to create or trigger a scheduled delivery can therefore direct the server to issue POST requests to private, loopback and link-local addresses, including cloud metadata endpoints, and can distinguish reachable internal services from unreachable ones through the resulting errors. The upstream response is never returned to the requester; on a failure status its body is written to the server log instead. Version 1.146.4 routes both clients through postSchedulerWebhook from packages/backend/src/utils/schedulerWebhookValidation rather than calling fetch directly. |
| The Drag and Drop Multiple File Upload for Contact Form 7 WordPress plugin before 1.3.9.9 does not validate the final name of an uploaded file after stripping characters from it, allowing unauthenticated users to defeat its file type restrictions and execute arbitrary code on the server. |
| In Splunk SOAR versions below 8.6.0, a user who holds the "Automation Engineer" role could run arbitrary Structured Query Language (SQL) statements against the Splunk SOAR database and create, read, update, or delete all data in the database. The vulnerability is possible because Splunk SOAR playbook automation data APIs incorporate user-supplied input into database queries without proper neutralization. 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. |
| In Splunk SOAR versions below 8.6.0, a user with the "Administrator" role could use the /rest/support/connectivity/.../check_connectivity endpoint to make Splunk SOAR initiate outbound network connections to arbitrary destinations and determine whether internal hosts and ports are reachable. The Server-Side Request Forgery (SSRF) is possible because the connectivity check REST API does not sufficiently validate the destination before Splunk SOAR connects to it. For more information see Manage roles and permissions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-on-premises) in the Splunk documentation. |
| The Eventin WordPress plugin before 4.1.21 does not validate a user-supplied webhook URL stored on events nor verify event ownership, allowing users with contributor-level access and above to trigger blind server-side requests to arbitrary hosts. |
| A code injection vulnerability exists in Epiphany when the user invokes form autofill from the context menu on a page containing a malicious HTML form.
In embed/web-process-extension/resources/js/ephy_autofill.js, getSelector() builds a CSS selector by directly interpolating an element's id attribute:
path.unshift(`#${el.id}`);
When the user selects an autofill entry, the browser process in embed/ephy-web-view.c previously constructed JavaScript using sprintf with the selector embedded in single quotes:
EphyAutofill.fill(PAGE_ID, 'SELECTOR', FILL_CHOICE);
Because SELECTOR comes from attacker-controlled page content and is not escaped, a crafted id such as a'); PAYLOAD; var _=(' breaks out of the string literal and executes arbitrary JavaScript when the script is evaluated.
The injected code runs in Epiphany's private autofill script world, which hosts EphyAutofill credential APIs and password manager save/request handlers. The reporter demonstrated a proof of concept that injects credentials into another domain and uses Ephy.permissionsManager to enumerate domains with special permissions. Full exfiltration of all saved passwords was not demonstrated but may be possible given the privileges of this context.
Exploitation requires the victim to visit a malicious page, right-click on a form field, and choose an Autofill context menu item. This is a deliberate user action but does not require installing software or entering credentials manually.
Affected versions: Epiphany >= 47.beta.
Fixed upstream in epiphany 50.6 and 49.9 via merge request !2147, which replaces sprintf-based script evaluation with a WebKit user message and jsc_value_object_invoke_method() passing the selector as a typed string argument.
Upstream report: https://gitlab.gnome.org/GNOME/epiphany/-/issues/2921 |
| XML Injection vulnerability in joshnuss xml_builder (XmlBuilder module) allows Content Spoofing, XML Injection.
This vulnerability is associated with program files lib/xml_builder.ex and program routines XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.element/1, XmlBuilder.element/2, XmlBuilder.element/3.
Element names, attribute names, and doctype identifiers are interpolated verbatim into the serialized XML output without validation or escaping of structural characters (<, >, ", ', &). An attacker who can influence a name argument (for example, an element name derived from a JSON object key or an HTTP form field name) can inject arbitrary XML markup including extra elements, comments, and event-handler attributes into the output document.
This issue affects xml_builder: from 0.0.1 before 2.4.1. |
