Total
3494 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-72848 | 1 Langchain | 1 Langchain Community | 2026-08-21 | 8.6 High |
| SitemapLoader.parse_sitemap in langchain_community/document_loaders/sitemap.py applies the documented restrict_to_same_domain control only to leaf url entries. The loop over url elements filters cross-domain locations, but the loop over nested sitemap elements passes the child loc straight to self.scrape_all([loc.text], "xml"), which reaches WebBaseLoader.scrape_all and an aiohttp GET, with no domain comparison and no check for private, loopback or link-local destinations. An attacker who controls or influences an ingested sitemap can therefore point a nested sitemap entry at an internal address and make the server fetch it even when the deploying application set restrict_to_same_domain to True specifically to confine outbound requests. The fetched content is parsed and surfaces in the returned Documents, so internal responses are disclosed to the caller rather than merely requested. | ||||
| CVE-2026-54794 | 1 Dell | 1 Openmanage Enterprise | 2026-08-21 | 7.2 High |
| 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. | ||||
| CVE-2026-22681 | 1 Volcengine | 1 Openviking | 2026-08-21 | 8.5 High |
| OpenViking before 0.3.4 contains a server-side request forgery vulnerability that allows authenticated low-privilege attackers to access internal network services by submitting arbitrary URLs to the resources API endpoint. Attackers can POST a crafted URL to /api/v1/resources, causing the server to issue outbound HEAD and GET requests with redirects enabled to loopback, RFC 1918, link-local, or cloud metadata addresses, then read back responses through normal content APIs to enumerate and interact with internal services. | ||||
| CVE-2026-77066 | 1 Omnivore-app | 1 Omnivore | 2026-08-21 | 5 Medium |
| 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. | ||||
| CVE-2026-72846 | 1 Lightdash | 1 Lightdash | 2026-08-21 | 6.4 Medium |
| 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. | ||||
| CVE-2026-76361 | 1 Splunk | 2 Soar, Splunk | 2026-08-21 | 2.7 Low |
| 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. | ||||
| CVE-2026-13176 | 2 Eventin, Wordpress | 2 Eventin, Wordpress | 2026-08-21 | 2.7 Low |
| 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. | ||||
| CVE-2026-48053 | 1 Learningequality | 1 Kolibri | 2026-08-21 | 5.8 Medium |
| Kolibri is an offline-first education platform. Prior to version 0.19.4, several Kolibri API endpoints accept an unvalidated `baseurl` parameter and fetch attacker-controlled URLs from the Kolibri server, reflecting the response body back to the caller. The original report identified two endpoints on the `RemoteFacilityUser*` viewsets; remediation review found two further reflection points on the same pattern. The GET endpoint was unauthenticated. Version 0.19.4 fixes the vulnerability. | ||||
| CVE-2026-32467 | 2 Apoyl, Wordpress | 2 [aotuman] Grab Wechat Articles, Wordpress | 2026-08-21 | 6 Medium |
| Subscriber Server Side Request Forgery (SSRF) in [Aotuman] Grab WeChat Articles <= 2.0.1 versions. | ||||
| CVE-2026-32473 | 2 Deknows, Wordpress | 2 Pdf Smart Viewer For Elementor, Wordpress | 2026-08-21 | 7.2 High |
| Unauthenticated Server Side Request Forgery (SSRF) in PDF Smart Viewer for Elementor <= 1.0.4 versions. | ||||
| CVE-2026-77775 | 1 Headroom Labs | 1 Headroom | 2026-08-21 | 8.6 High |
| Headroom's LLM proxy lets a client choose the upstream destination with the x-headroom-base-url request header. _resolve_openai_upstream_base in headroom/proxy/handlers/openai.py accepts the header value, requires only that it parse with an http or https scheme and a hostname, and returns it for use as the upstream base; _select_passthrough_base_url in headroom/providers/proxy_routes.py reads the same header for the passthrough routes. No check rejects loopback, link-local, or RFC 1918 destinations, and because the component is a proxy the upstream response is returned to the caller, so the request reaches internal services and cloud metadata addresses and their responses are disclosed. The Authorization header accompanying the request is forwarded unchanged to the caller-designated host. The pip console script binds 127.0.0.1 by default, but the reference docker-compose.yml ships --host 0.0.0.0 with published ports and no required HEADROOM_PROXY_TOKEN, which the server itself warns about at startup, so a deployment following the shipped compose exposes the affected data-plane routes to the network without authentication. | ||||
| CVE-2026-77067 | 1 Omnivore-app | 1 Omnivore | 2026-08-21 | 5 Medium |
| The setWebhookResolver in packages/api/src/resolvers/webhooks/index.ts stores the caller-supplied url without any address validation, and the file imports no validation helper. When a subscribed event fires, callWebhook in packages/api/src/jobs/call_webhook.ts issues axios.request with that url, the method and Content-Type recorded on the webhook, and a JSON body carrying the event data, so an authenticated user can make the server send repeated attacker-shaped requests to internal endpoints, including link-local metadata addresses. The request is blind: callWebhook discards the result and writes only a success line or the axios error to the server log, so the response is not returned through the API. | ||||
| CVE-2026-54508 | 1 Mauriceboe | 1 Trek | 2026-08-21 | N/A |
| TREK is a collaborative travel planner. Prior to 3.1.0, TREK validates only the initial URL before native redirect following in importGoogleList() and importNaverList() in server/src/services/placeService.ts and resolveGoogleMapsUrl() in server/src/services/mapsService.ts. The affected sinks call checkSsrf() from server/src/utils/ssrfGuard.ts and then use fetch() with redirect: 'follow' instead of the DNS-pinned safeFetch() path, so a public attacker-controlled URL can redirect the server to loopback, RFC 1918, or cloud metadata addresses without revalidation. An authenticated trip member can reach the list-import routes, and any authenticated user can reach /api/maps/resolve-url, allowing blind GET requests to internal services without response-body reflection. This issue is fixed in version 3.1.0. | ||||
| CVE-2026-72860 | 1 Decolua | 1 9router | 2026-08-20 | 8.5 High |
| The POST /api/provider-nodes/validate route in 9router takes a caller-supplied baseUrl and issues server-side HTTP requests to it, guarding the destination with assertPublicUrl from src/shared/utils/ssrfGuard.js. That guard compares hostname strings only: it resolves no DNS, does not revalidate after a redirect, and its IPv4-mapped IPv6 branch is unreachable. The branch matches ^::ffff:(\d+\.\d+\.\d+\.\d+)$, but the WHATWG URL parser canonicalizes such literals to hextets before the guard runs, so new URL("http://[::ffff:127.0.0.1]/").hostname yields [::ffff:7f00:1] and the pattern is tested against a string it is never handed. Every IPv4-mapped address therefore passes, and http://[::ffff:7f00:1] and http://[::ffff:a9fe:a9fe] reach loopback and link-local metadata addresses; a hostname whose A record points at an internal address passes as well because no resolution occurs. In the custom-embedding branch the upstream response body is truncated to 200 bytes and returned to the caller whenever the upstream status is neither 2xx nor 401 nor 403, which discloses the beginning of internal responses, and the other validation types remain usable for blind internal port scanning through status and timing differences. The caller-supplied apiKey is forwarded to the internal destination as an Authorization Bearer header. A dashboard session is required by default, and none is required when requireLogin is disabled. | ||||
| CVE-2026-54491 | 1 Koel | 1 Koel | 2026-08-20 | 7.1 High |
| Koel is a free, open-source music streaming solution. Prior to 9.7.1, outbound podcast and radio fetch paths perform a point-in-time App\Helpers\Network::isPublicHost() or isSafeUrl() check without pinning the validated address, and most paths lack redirect-hop validation and do not revalidate every redirect target. PhanAn\Poddle\Poddle::fromUrl(), PodcastService::getStreamableUrl(), PodcastService::isPodcastObsolete(), App\Rules\HasAudioContentType, and App\Rules\SafeUrl can therefore follow an attacker-controlled redirect to an internal address or connect after DNS rebinding changes a public resolution to a private one. These paths are reachable through podcast and radio APIs, including createPodcastChannel, createInternetRadioStation, refreshPodcasts, apiResource podcasts, and radio/stations, allowing an authenticated user to request internal services or cloud metadata and potentially receive parsed or streamed response content. This issue is fixed in version 9.7.1. | ||||
| CVE-2026-74247 | 1 Redhat | 3 Openshift Update Service, Quay, Quay 3 | 2026-08-20 | 4.2 Medium |
| A flaw was found in Red Hat Quay. A user with FEATURE_BUILD_SUPPORT enabled and repository write access can exploit a Server-Side Request Forgery (SSRF) vulnerability within the build API. This allows the user to provide a malicious URL, causing the Quay builder to make requests to internal network addresses. Such an action could lead to the disclosure of sensitive internal information. | ||||
| CVE-2026-64849 | 2 Lfprojects, Mlflow | 2 Mlflow, Mlflow | 2026-08-20 | 9.3 Critical |
| MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. Prior to 3.15.0, the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint calls _validate_webhook_url() in mlflow/utils/validation.py only for the original URL while mlflow/webhooks/delivery.py follows redirects and re-resolves the hostname without pinning the validated address, allowing attackers to reach internal or cloud metadata services and receive response_status and response_body. This issue is fixed in version 3.15.0. | ||||
| CVE-2026-65842 | 1 Udecode | 1 Plate | 2026-08-20 | 8.2 High |
| Plate is a rich-text editor with AI and shadcn/ui. Prior to 53.3.2, @platejs/docx-io fetches remote image URLs while converting attacker-controlled HTML through htmlToDocxBlob in a server-side or privileged environment. The converter can make requests to internal network resources and include the fetched image bytes in the generated DOCX, allowing server-side request forgery with response disclosure. Applications can also incur resource consumption from attacker-selected remote responses. This issue is fixed in version 53.3.2. | ||||
| CVE-2026-64968 | 1 Atutor | 1 Atutor | 2026-08-20 | N/A |
| ATutor is vulnerable to Server-Side request forgery in import functionalities. An authenticated administrator can make the server request arbitrary internal HTTP endpoints, cloud metadata services, or local files via file:// if the PHP environment permits URL wrappers. Product is no longer actively supported and the vulnerabilities have not been fixed. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable. | ||||
| CVE-2026-54492 | 1 Koel | 1 Koel | 2026-08-20 | 4.3 Medium |
| Koel is a free, open-source music streaming solution. Prior to 9.7.0, the Subsonic-compatible createPodcastChannel.view route accepts an authenticated user's private URL because app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php does not apply the SafeUrl validation used by the regular podcast API. app/Http/Controllers/Subsonic/CreatePodcastChannelController.php passes the URL to app/Services/Podcast/PodcastService.php, where PodcastService::addPodcast() and createParser() invoke Poddle::fromUrl() during channel creation, causing immediate server-side requests to loopback, Docker bridge, or RFC1918 HTTP destinations. The confirmed impact is blind internal request execution because generic response-body exfiltration was not demonstrated through this route. This issue is fixed in version 9.7.0. | ||||