SSRF — CraftedSignal Threat Feed

PixelYourSite Pro WordPress Plugin SSRF Vulnerability (CVE-2026-7049)

hello@craftedsignal.io — Sat, 02 May 2026 06:16:04 +0000

CVE-2026-7049 is a server-side request forgery (SSRF) vulnerability found in the PixelYourSite Pro WordPress plugin. Specifically, all versions up to and including 12.5.0.1 are affected. This vulnerability allows unauthenticated attackers to send requests to arbitrary internal or external resources, as viewed from the web server. Although the fetched response bodies are not directly returned to the attacker (making it a blind SSRF), the application parses these responses internally, creating opportunities for reconnaissance and potentially for exploiting vulnerable internal services. Successful exploitation could expose sensitive information or allow unauthorized modification of internal systems.

Attack Chain

An unauthenticated attacker identifies the scan_video parameter as an SSRF entry point.
The attacker crafts a malicious HTTP request targeting the WordPress server with the vulnerable PixelYourSite Pro plugin. The request includes the scan_video parameter set to a URL pointing to an internal resource (e.g., internal IP address or hostname).
The WordPress server receives the malicious request.
The PixelYourSite Pro plugin processes the request and initiates an HTTP request to the URL specified in the scan_video parameter.
The WordPress server makes a request to the internal resource.
The response from the internal resource is received by the WordPress server.
The PixelYourSite Pro plugin parses the response body, potentially revealing information about the internal service.
Depending on the targeted internal service and the attacker’s crafted request, the attacker might be able to modify information or execute commands on the internal service, even though the response is not directly returned to the attacker.

Impact

Successful exploitation of CVE-2026-7049 allows an unauthenticated attacker to perform reconnaissance of internal network resources. The blind nature of the SSRF limits the attacker’s immediate visibility into the response, but internal parsing of the response allows for potential information disclosure and exploitation of vulnerable internal services. The scope of the impact depends heavily on the configuration of the internal network and the services exposed.

Recommendation

Upgrade the PixelYourSite Pro plugin to a version greater than 12.5.0.1 to patch CVE-2026-7049.
Deploy the Sigma rule Detect Suspicious PixelYourSite Pro SSRF Attempts to monitor for exploitation attempts targeting the scan_video parameter.
Review and restrict internal network access to sensitive services to mitigate the potential impact of SSRF vulnerabilities.

n8n-mcp SDK Embedder SSRF Vulnerability via IPv6 Bypass

hello@craftedsignal.io — Thu, 30 Apr 2026 18:12:54 +0000

The n8n-mcp library, when embedded as an SDK, contains a server-side request forgery (SSRF) vulnerability. The vulnerability lies in the SSRFProtection.validateUrlSync() function, specifically within the N8NDocumentationMCPServer constructor, getN8nApiClient(), and validateInstanceContext() methods. This synchronous validator lacks IPv6 checks, allowing IPv4-mapped IPv6 addresses (e.g., http://[::ffff:169.254.169.254]) to bypass existing protections against cloud metadata, localhost, and private IP ranges. An attacker who can control the n8nApiUrl parameter can exploit this flaw to force the server to make HTTP requests to internal or external services. This issue affects deployments embedding n8n-mcp as an SDK using N8NDocumentationMCPServer or N8NMCPEngine with user-supplied InstanceContext on versions v2.47.4 through v2.47.13. Version v2.47.14 and later contain the patch for this vulnerability.

Attack Chain

An attacker identifies a vulnerable n8n-mcp deployment embedding the SDK and using a user-supplied InstanceContext.
The attacker crafts a malicious n8nApiUrl containing an IPv4-mapped IPv6 address, such as http://[::ffff:169.254.169.254].
The attacker supplies the crafted n8nApiUrl to the vulnerable N8NDocumentationMCPServer constructor or getN8nApiClient() method.
The validateInstanceContext() function calls SSRFProtection.validateUrlSync() to validate the URL.
The validateUrlSync() function fails to properly validate the IPv4-mapped IPv6 address.
The server issues an HTTP request to the attacker-specified target using the bypassed URL.
The x-n8n-api-key header is forwarded to the attacker-controlled target.
The response body from the target is returned to the attacker, allowing the attacker to gather sensitive information from internal services or cloud metadata endpoints.

Impact

Successful exploitation of this SSRF vulnerability allows an attacker to perform unauthorized actions, such as accessing sensitive information from cloud metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), RFC1918 private networks, or localhost services. The attacker can also gain access to the n8nApiKey, which is forwarded in the x-n8n-api-key header, potentially leading to further compromise of the n8n instance. This vulnerability impacts deployments embedding n8n-mcp as an SDK between versions v2.47.4 and v2.47.13.

Recommendation

Upgrade n8n-mcp to version v2.47.14 or later to patch the vulnerability as described in the advisory.
Implement a network-level block on outbound traffic from the n8n-mcp process to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local 169.254.0.0/16, and cloud metadata endpoints as a defense-in-depth measure.
Deploy the Sigma rule Detect N8N MCP SSRF Attempt via IPv6 Bypass to identify exploitation attempts by detecting outbound connections to internal IPs using IPv6 mapped IPv4 address.

Gotenberg Unauthenticated SSRF Vulnerability

hello@craftedsignal.io — Thu, 30 Apr 2026 17:24:55 +0000

Gotenberg version 8.29.1, as distributed in the default gotenberg/gotenberg:8 Docker image, contains an unauthenticated Server-Side Request Forgery (SSRF) vulnerability. Discovered on April 4, 2026, this flaw allows an attacker with network access to the Gotenberg instance to specify an arbitrary URL via the Gotenberg-Webhook-Url request header, forcing the server to make outbound HTTP POST requests. This is a blind SSRF vulnerability, where the attacker cannot directly read the response body, but can infer information based on the success or failure of the request. The vulnerability exists due to an insecure default in the FilterDeadline function, which, when unconfigured, permits all webhook URLs. The impact includes internal network probing, forced POST requests to internal services, and cloud metadata interaction.

Attack Chain

The attacker identifies a vulnerable Gotenberg instance exposed on the network (default port 3000).
The attacker crafts an HTTP POST request to the /forms/chromium/convert/url endpoint.
The attacker includes the Gotenberg-Webhook-Url header, setting it to an internal IP address and port (e.g., http://192.168.1.10:8080/).
The attacker may also set the Gotenberg-Webhook-Error-Url to an attacker-controlled server to monitor for request failures.
Gotenberg’s FilterDeadline function fails to properly validate the supplied webhook URL due to an insecure default.
Gotenberg makes an outbound HTTP POST request to the specified internal IP address and port using the retryablehttp client, potentially retrying the request up to 4 times.
If the internal target responds with a 2xx status code, the attacker infers that the host and port are open and accepting POST requests. The error URL is NOT called.
If the internal target responds with a 4xx/5xx status code, times out, or rejects the connection, the attacker receives a request at the Gotenberg-Webhook-Error-Url endpoint, indicating the port is likely closed or the service is unavailable.

Impact

The SSRF vulnerability in Gotenberg 8.29.1 allows attackers to probe internal networks, potentially mapping out internal infrastructure by observing the success or failure of requests. Attackers can also force Gotenberg to send POST requests to internal services that perform actions upon receiving such requests, potentially triggering unintended behavior. Although the attacker cannot directly read response bodies, the ability to determine reachability and trigger actions makes this a significant security risk. The retry mechanism amplifies the probing effect, as each request generates up to 4 attempts.

Recommendation

Apply the recommended configuration to either set --env GOTENBERG_API_WEBHOOK_ALLOW_LIST or --env GOTENBERG_API_WEBHOOK_DENY_LIST to restrict or block internal ranges to mitigate the SSRF vulnerability.
Monitor web server logs for POST requests to /forms/chromium/convert/url with the Gotenberg-Webhook-Url header containing suspicious internal IP addresses or domains using the provided Sigma rule.
Deploy the Sigma rule to detect suspicious outbound network connections originating from the Gotenberg process to internal IP ranges or cloud metadata endpoints.

OpenClaw QQ Bot Media Download SSRF Vulnerability

hello@craftedsignal.io — Wed, 29 Apr 2026 12:00:00 +0000

OpenClaw, a QQ Bot platform, is susceptible to a server-side request forgery (SSRF) vulnerability. This flaw exists in versions prior to 2026.4.8 within the media download paths of the QQ Bot functionality. Specifically, the vulnerability allows attackers to bypass existing SSRF protections. By exploiting unprotected media fetch endpoints, malicious actors can potentially gain unauthorized access to internal resources and circumvent established allowlist policies. This vulnerability poses a significant risk to the confidentiality and integrity of systems and data accessible from the OpenClaw server. Successful exploitation can lead to information disclosure, denial of service, or even remote code execution on internal systems, depending on the accessible resources.

Attack Chain

The attacker identifies an OpenClaw instance running a version prior to 2026.4.8.
The attacker crafts a malicious URL targeting the QQ Bot media download functionality. This URL contains a payload designed to exploit the SSRF vulnerability.
The attacker injects the malicious URL into the QQ Bot’s media download path, bypassing expected SSRF protections.
OpenClaw processes the crafted URL without proper validation, initiating a request to an attacker-controlled internal resource.
The OpenClaw server makes a request to the specified internal resource, potentially exposing sensitive information or triggering unintended actions.
The internal resource responds to the OpenClaw server, and the response is potentially relayed back to the attacker or used to further compromise the system.
The attacker gains unauthorized access to internal resources or sensitive data due to the successful SSRF attack.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-41914) can lead to the disclosure of sensitive information from internal systems, potentially affecting all users and services dependent on the compromised OpenClaw instance. The severity is amplified by the potential to bypass existing SSRF protections, increasing the attack surface and difficulty of detection. Impact ranges from information disclosure to potential compromise of other internal services, depending on the specific internal resources accessible from the OpenClaw server.

Recommendation

Upgrade OpenClaw to version 2026.4.8 or later to patch the SSRF vulnerability (CVE-2026-41914).
Deploy the Sigma rule Detect Suspicious OpenClaw SSRF Attempt to identify potential exploitation attempts targeting the vulnerable media download paths.
Implement strict network segmentation to limit the impact of a successful SSRF attack by restricting access to sensitive internal resources from the OpenClaw server.

ChatGPTNextWeb NextChat Server-Side Request Forgery Vulnerability

hello@craftedsignal.io — Tue, 28 Apr 2026 12:00:00 +0000

A server-side request forgery (SSRF) vulnerability, identified as CVE-2026-7177, affects ChatGPTNextWeb NextChat up to version 2.16.1. The vulnerability resides within the proxyHandler function in the app/api/[provider]/[...path]/route.ts file. Publicly available exploits demonstrate that a remote attacker can manipulate this function to make unauthorized requests to internal resources. The project maintainers were notified, but have not yet responded to the issue, increasing the risk of widespread exploitation. This vulnerability allows attackers to potentially access sensitive information or internal services that are not intended to be exposed to the internet.

Attack Chain

An attacker identifies a NextChat instance running a vulnerable version (<= 2.16.1).
The attacker crafts a malicious HTTP request targeting the app/api/[provider]/[...path]/route.ts endpoint.
The crafted request manipulates the proxyHandler function parameters.
The proxyHandler function, without proper validation, forwards the manipulated request to an internal server or resource.
The internal server processes the request as if it originated from the NextChat server itself.
The internal server returns the response to the NextChat server.
The NextChat server forwards the response from the internal server back to the attacker.
The attacker gains access to potentially sensitive information or can interact with internal services due to the SSRF vulnerability.

Impact

Successful exploitation of this SSRF vulnerability allows attackers to potentially access internal resources, including sensitive data or internal services not intended for public access. While the CVSS score is 7.3 (HIGH), the impact is limited to information disclosure and limited modification/availability of resources. The number of affected instances is currently unknown. If successfully exploited, attackers could potentially use the compromised NextChat instance as a proxy to further compromise the internal network.

Recommendation

Apply input validation and sanitization to the proxyHandler function within app/api/[provider]/[...path]/route.ts to prevent malicious manipulation (Reference: CVE-2026-7177).
Monitor web server logs for unusual requests targeting the app/api endpoint with potentially malicious parameters (See example Sigma rule below).
Implement network segmentation to restrict access from the NextChat server to only necessary internal resources (General security best practice related to SSRF).
Deploy the Sigma rules provided to detect exploitation attempts against NextChat instances.

Typecho <= 1.3.0 Server-Side Request Forgery Vulnerability (CVE-2026-7025)

hello@craftedsignal.io — Sun, 26 Apr 2026 08:17:46 +0000

Typecho is vulnerable to a server-side request forgery (SSRF) vulnerability (CVE-2026-7025) affecting versions up to 1.3.0. The vulnerability resides in the Service::sendPingHandle function within the var/Widget/Service.php file, specifically impacting the Ping Back Service Endpoint component. An attacker can remotely trigger this vulnerability by manipulating the X-Pingback/link argument. Publicly available exploits exist, increasing the risk of exploitation. The vendor was notified but did not respond. This vulnerability allows an attacker to potentially make arbitrary HTTP requests from the server, leading to information disclosure or further compromise.

Attack Chain

The attacker identifies a Typecho instance running a vulnerable version (<= 1.3.0).
The attacker crafts a malicious HTTP request targeting the Pingback service endpoint.
The malicious request includes a manipulated X-Pingback or link argument pointing to an attacker-controlled server or internal resource.
The Service::sendPingHandle function processes the request and attempts to fetch the resource specified in the X-Pingback/link argument.
Due to the SSRF vulnerability, the Typecho server makes an outbound HTTP request to the attacker-specified URL.
The attacker’s server logs the incoming request from the Typecho server, confirming the SSRF vulnerability.
The attacker could potentially use this SSRF vulnerability to scan internal networks, read sensitive files, or interact with internal services.
Successful exploitation could lead to information disclosure, further exploitation of internal services, or denial-of-service attacks.

Impact

Successful exploitation of CVE-2026-7025 can allow an attacker to perform unauthorized actions on the internal network of the Typecho server. This includes port scanning, accessing internal services, and potentially reading sensitive data. The number of affected installations is unknown, but any Typecho instance running version 1.3.0 or earlier is vulnerable. The impact is limited to the permissions of the Typecho web server process, but can expose sensitive internal services that are not directly accessible from the internet.

Recommendation

Apply input validation and sanitization to the X-Pingback/link argument to prevent arbitrary URL inclusion, mitigating CVE-2026-7025.
Monitor web server logs for suspicious requests containing unusual URLs in the X-Pingback header, which can indicate SSRF attempts.
Implement network segmentation to limit the impact of potential SSRF attacks by restricting the web server’s access to internal resources.
Deploy the Sigma rule Detect Suspicious X-Pingback Header to identify potential SSRF attempts targeting the Pingback service.
Audit outbound network connections from the web server to detect unauthorized access to internal resources as a result of SSRF.

WWBN AVideo SSRF Vulnerability (CVE-2026-41055)

hello@craftedsignal.io — Wed, 22 Apr 2026 12:00:00 +0000

WWBN AVideo, an open-source video platform, is vulnerable to Server-Side Request Forgery (SSRF) in versions 29.0 and below. The vulnerability, identified as CVE-2026-41055, stems from an incomplete fix in the LiveLinks proxy. While the fix introduced isSSRFSafeURL() validation, it fails to address Time-of-Check Time-of-Use (TOCTOU) vulnerabilities related to DNS rebinding. This flaw allows attackers to bypass the intended SSRF protection by manipulating DNS responses between the validation check and the actual HTTP request, potentially redirecting traffic to internal, sensitive endpoints. The vulnerability can be remediated by applying the updated fix found in commit 8d8fc0cadb425835b4861036d589abcea4d78ee8. Exploitation could lead to information disclosure or unauthorized access to internal services.

Attack Chain

Attacker identifies an AVideo instance running a vulnerable version (<= 29.0).
Attacker crafts a malicious URL targeting the AVideo LiveLinks proxy feature.
The malicious URL is designed to leverage DNS rebinding techniques.
The AVideo server first validates the URL using isSSRFSafeURL(), which initially resolves to a safe, external IP address.
After validation, but before the HTTP request is made, the DNS record for the malicious URL is altered to point to an internal IP address.
The AVideo server, due to the TOCTOU vulnerability, now makes an HTTP request to the attacker-controlled internal IP address.
The attacker gains access to internal resources or services through the AVideo server.
Attacker exfiltrates sensitive data or pivots to other internal systems.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-41055) in WWBN AVideo could allow attackers to access sensitive internal resources that are not intended to be exposed to the public internet. An attacker could potentially read internal configuration files, access databases, or even execute commands on internal systems, depending on the exposed services. The specific impact will vary depending on the organization’s internal network configuration and the services running behind the AVideo server.

Recommendation

Upgrade WWBN AVideo to a version containing the complete SSRF fix, referencing commit 8d8fc0cadb425835b4861036d589abcea4d78ee8.
Implement network segmentation to limit the impact of potential SSRF vulnerabilities by restricting access from the AVideo server to only necessary internal resources.
Deploy the Sigma rule Detect Suspicious AVideo SSRF Attempt to detect potential exploitation attempts via web server logs.
Monitor web server logs for unusual outbound connections from the AVideo server to internal IP addresses based on the network_connection log source.

Moxi Blog v2 <= 5.2 Server-Side Request Forgery Vulnerability

hello@craftedsignal.io — Mon, 20 Apr 2026 10:16:44 +0000

Moxi Blog v2, a blogging platform, is vulnerable to a server-side request forgery (SSRF) vulnerability (CVE-2026-6625) in versions up to 5.2. The vulnerability resides within the LocalFileServiceImpl.uploadPictureByUrl function of the Picture Storage Service component. This flaw allows a remote attacker to potentially force the server to make HTTP requests to arbitrary domains, including internal services, potentially exposing sensitive information or allowing unauthorized actions. The vulnerability has been publicly disclosed, making it crucial to address this issue to prevent potential exploitation. The vendor has been notified but has not responded.

Attack Chain

The attacker identifies a Mogu Blog v2 instance running a vulnerable version (<= 5.2).
The attacker crafts a malicious HTTP request targeting the uploadPictureByUrl function.
Within the crafted request, the attacker provides a URL pointing to an internal resource or an external server controlled by the attacker.
The Mogu Blog server processes the request and attempts to retrieve the resource specified in the URL via an HTTP GET request.
If the targeted URL points to an internal service, the server may inadvertently expose sensitive information (e.g., internal API keys, service configurations).
If the targeted URL points to an external server controlled by the attacker, the server may leak information about itself (e.g., internal IP address, software versions).
The attacker analyzes the response from the server to gather sensitive information or identify further attack vectors.

Impact

Successful exploitation of this SSRF vulnerability could allow an attacker to scan internal networks, access internal services not exposed to the public internet, potentially read sensitive data, or leverage the server as a proxy to attack other systems. This can lead to information disclosure, unauthorized access to internal resources, and further compromise of the Mogu Blog infrastructure. The number of affected installations is unknown, but all instances of Mogu Blog v2 up to 5.2 are potentially vulnerable.

Recommendation

Inspect web server logs for requests containing URLs to internal IP addresses (e.g. 127.0.0.1, 192.168.x.x, 10.x.x.x) in the cs-uri-query field using a webserver log rule.
Monitor network connections originating from the Mogu Blog server to unusual or internal destinations, using a network_connection Sigma rule.
Implement input validation and sanitization for the uploadPictureByUrl function to prevent the server from making requests to untrusted URLs.
Apply any available patches or updates from the vendor to address CVE-2026-6625 (though no vendor response was noted).

Movary SSRF Vulnerability (CVE-2026-40348)

hello@craftedsignal.io — Sat, 18 Apr 2026 00:16:38 +0000

Movary, a self-hosted web application for tracking and rating movies, is susceptible to a Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-40348) in versions prior to 0.71.1. This flaw allows authenticated users to manipulate the /settings/jellyfin/server-url-verify endpoint to initiate server-side HTTP requests to arbitrary internal targets. The application uses the Guzzle HTTP client to send requests based on a user-supplied URL, to which /system/info/public is appended. The absence of input validation on the target URL allows attackers to bypass intended restrictions and access internal network resources. This vulnerability enables threat actors to perform internal reconnaissance activities such as host discovery, port scanning, and service fingerprinting. Successful exploitation can lead to further compromise by exposing internal administrative interfaces or cloud metadata endpoints.

Attack Chain

An attacker authenticates to the Movary web application with a valid user account.
The attacker crafts a malicious URL targeting an internal resource, such as http://127.0.0.1/.
The attacker sends a POST request to /settings/jellyfin/server-url-verify with the crafted URL as the serverUrl parameter.
The Movary server receives the request and appends /system/info/public to the user-provided URL.
The Movary server uses the Guzzle HTTP client to initiate an HTTP request to the modified URL (e.g., http://127.0.0.1/system/info/public).
The internal service at the targeted IP address responds to the Movary server.
Based on the HTTP response code and content, the attacker can infer the existence and status of internal services. This allows for port scanning and service fingerprinting.
The attacker leverages discovered services to escalate privileges, potentially accessing sensitive data or internal administrative panels.

Impact

Successful exploitation of the SSRF vulnerability (CVE-2026-40348) in Movary can enable attackers to discover internal network infrastructure and identify vulnerable services. This can allow attackers to gain unauthorized access to sensitive information, pivot to other internal systems, or perform other malicious activities. Although no specific victim count is given, the impact of this vulnerability is potentially high for any organization using a vulnerable version of Movary.

Recommendation

Upgrade Movary to version 0.71.1 or later to patch the SSRF vulnerability (CVE-2026-40348).
Deploy the Sigma rule Detect Movary SSRF Attempt to identify potential exploitation attempts in web server logs.
Implement network segmentation and access controls to restrict access to sensitive internal services, limiting the impact of potential SSRF attacks.

Flowise SSRF Protection Bypass via Unprotected Built-in HTTP Modules

hello@craftedsignal.io — Thu, 16 Apr 2026 21:50:12 +0000

Flowise, a low-code platform for building custom automation workflows, is susceptible to a Server-Side Request Forgery (SSRF) protection bypass. This vulnerability stems from the application’s incomplete implementation of SSRF defenses. While axios and node-fetch libraries are secured with an HTTP_DENY_LIST, the built-in Node.js modules http, https, and net are permitted within the NodeVM sandbox without any equivalent restrictions. An authenticated attacker can exploit this oversight in Flowise version 3.0.13 and earlier to make arbitrary HTTP requests to internal network resources. This issue allows bypassing intended security controls and potentially accessing sensitive information, such as cloud provider metadata services.

Attack Chain

The attacker authenticates to a Flowise instance using a valid API key or session.
The attacker crafts a malicious JavaScript payload designed to exploit the custom function feature.
The malicious payload imports the built-in http module.
The payload constructs an HTTP request targeting an internal resource, such as the AWS metadata service at 169.254.169.254.
The request includes a header to obtain an IAM token: 'X-aws-ec2-metadata-token-ttl-seconds': '21600'.
The payload uses the obtained IAM token to request temporary AWS credentials from the metadata service.
The custom function executes the code within the NodeVM sandbox, bypassing the intended SSRF protection.
The attacker retrieves the temporary AWS credentials from the metadata service, potentially leading to unauthorized access to AWS resources.

Impact

Successful exploitation of this SSRF vulnerability can have significant consequences. Attackers can steal temporary IAM credentials from cloud provider metadata services, granting them unauthorized access to other cloud resources. Furthermore, they can scan internal networks to discover services and identify additional attack targets. The ability to reach databases, admin panels, and other internal APIs that should not be externally accessible poses a severe security risk, potentially leading to data breaches or system compromise. All Flowise deployments where HTTP_DENY_LIST is configured for SSRF protection are vulnerable, while deployments without it are already generally vulnerable to SSRF.

Recommendation

Apply the necessary patches to Flowise to remediate the SSRF vulnerability as described in GHSA-xhmj-rg95-44hv.
Deploy the following Sigma rule to detect exploitation attempts involving the http module targeting common cloud metadata endpoints: Flowise SSRF Using HTTP Module.
Enable logging of HTTP requests originating from the Flowise server to aid in identifying and investigating potential SSRF attacks.
Review and harden network segmentation to limit the impact of potential SSRF vulnerabilities.
Consider disabling the custom function feature if it is not essential to the functionality of the Flowise deployment.

Webkul Krayin CRM SSRF Vulnerability (CVE-2026-38527)

hello@craftedsignal.io — Wed, 15 Apr 2026 12:00:00 +0000

CVE-2026-38527 details a Server-Side Request Forgery (SSRF) vulnerability affecting Webkul Krayin CRM version 2.2.x. The vulnerability is located in the /settings/webhooks/create component. An attacker can exploit this flaw by crafting a malicious POST request that forces the server to make requests to internal resources. This can be leveraged to scan internal network infrastructure, potentially revealing sensitive information or accessing internal services that are not meant to be exposed to the outside world. The vulnerability was published on April 14, 2026. Exploitation requires the attacker to be able to send POST requests to the affected endpoint.

Attack Chain

An attacker identifies a Webkul Krayin CRM instance running version 2.2.x.
The attacker crafts a POST request targeting the /settings/webhooks/create endpoint.
The POST request includes a malicious payload in the body, designed to trigger an SSRF vulnerability. This payload could involve specifying a URL for the webhook to call back to.
The vulnerable server processes the crafted POST request and attempts to create a new webhook.
The server-side component incorrectly handles or sanitizes the URL provided for the webhook callback.
As part of the webhook creation process, the server initiates an HTTP request to the attacker-controlled URL or internal resource specified in the crafted POST request.
The server successfully connects to the specified resource, potentially revealing information about the internal network or services.
The attacker analyzes the response from the internal service or server to gather sensitive information, such as internal hostnames, open ports, or service versions.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-38527) can allow an attacker to enumerate internal network resources, potentially identifying sensitive services and systems. This information can be used to further compromise the target environment, potentially leading to data breaches or system compromise. While the specific number of affected organizations is unknown, any organization using a vulnerable version of Webkul Krayin CRM is at risk.

Recommendation

Apply the necessary patch or upgrade to a version of Webkul Krayin CRM that resolves CVE-2026-38527.
Implement strict input validation and sanitization on all user-supplied data, especially URLs, to prevent SSRF attacks.
Monitor web server logs for suspicious requests to the /settings/webhooks/create endpoint, looking for unusual URLs or request patterns, using the provided Sigma rule.
Implement network segmentation to limit the impact of potential SSRF attacks by restricting access to sensitive internal resources.
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.

Kyverno SSRF Vulnerability in CEL HTTP Library

hello@craftedsignal.io — Tue, 14 Apr 2026 22:37:20 +0000

A Server-Side Request Forgery (SSRF) vulnerability has been identified in Kyverno’s CEL HTTP library (pkg/cel/libs/http/), affecting versions >= 1.16.0. This flaw allows users with permissions to create namespace-scoped policies to bypass intended restrictions and make arbitrary HTTP requests from the Kyverno admission controller. This can lead to unauthorized access to internal Kubernetes services in other namespaces, cloud metadata endpoints such as 169.254.169.254 (allowing credential theft), and the exfiltration of sensitive data by embedding it in policy error messages. The vulnerability stems from a lack of URL validation in the http.Get() and http.Post() functions used within CEL policies, contrasting with the namespace enforcement present in the resource.Lib. The reported vulnerability was tested and confirmed on Kyverno v1.16.2 deployed via Helm chart 3.6.2.

Attack Chain

An attacker gains the ability to create NamespacedValidatingPolicy resources within a specific Kubernetes namespace. This could be achieved through compromised credentials, misconfigured RBAC, or other privilege escalation methods.
The attacker crafts a malicious NamespacedValidatingPolicy that utilizes the http.Get() or http.Post() function within a CEL expression. The crafted policy is applied to the target Kubernetes cluster.
The CEL expression within the policy is designed to make an HTTP request to an internal service (e.g., internal-api.kube-system.svc.cluster.local) or a cloud metadata endpoint (169.254.169.254).
The crafted NamespacedValidatingPolicy is triggered by a specific event, such as the creation of a ConfigMap within the attacker’s namespace, which matches the matchConstraints defined in the policy.
The Kyverno admission controller executes the CEL expression, making the HTTP request to the specified internal service or cloud metadata endpoint.
The HTTP response from the internal service or cloud metadata endpoint is captured by the CEL expression.
The attacker crafts a messageExpression within the NamespacedValidatingPolicy to include the captured data in a validation error message.
The validation error message, containing the exfiltrated data, is returned to the user, effectively leaking sensitive information.

Impact

This SSRF vulnerability allows attackers with limited, namespace-scoped privileges to access sensitive data within a Kubernetes cluster. This includes the ability to access services in other namespaces, potentially compromising sensitive configurations or secrets. Access to cloud metadata endpoints (169.254.169.254) allows the theft of IAM credentials, leading to further escalation of privileges within the cloud environment. Successful exploitation breaks namespace isolation, undermining the security model of Kyverno and Kubernetes.

Recommendation

Deploy the Sigma rule to detect suspicious usage of http.Get or http.Post function in NamespacedValidatingPolicy resources in your SIEM and tune for your environment.
Monitor network connections originating from the Kyverno pods, specifically looking for connections to internal Kubernetes services or cloud metadata endpoints (169.254.169.254), using the network_connection log source.
Apply the suggested fix by adding namespace and URL restrictions to pkg/cel/libs/http/http.go in Kyverno, similar to how resource.Lib enforces namespace boundaries as per the advisory.
Upgrade Kyverno to a patched version >= 1.17 when available, addressing the CVE-2026-4789.

SiYuan Zero-Click NTLM Theft and Blind SSRF via Mermaid Diagrams

hello@craftedsignal.io — Sat, 11 Apr 2026 12:00:00 +0000

SiYuan, a note-taking application, is vulnerable to a zero-click NTLM hash theft and blind SSRF exploit due to insecure configuration of Mermaid.js. The application configures Mermaid.js with securityLevel: "loose" and htmlLabels: true, which allows tags with src attributes to bypass sanitization and be injected into SVG blocks. When a user opens a note containing a malicious Mermaid diagram with a protocol-relative URL (e.g., //attacker.com/image.png), the Electron client fetches the URL. On Windows, this resolves as a UNC path, triggering SMB authentication and sending the victim’s NTLMv2 hash to the attacker. On macOS and Linux, the same diagram triggers an HTTP request to the attacker’s server, exfiltrating the victim’s IP address. The vulnerability affects SiYuan versions prior to the fix implemented after April 7, 2026. This allows for credential theft without any user interaction beyond opening a note.

Attack Chain

The attacker crafts a malicious SiYuan note containing a Mermaid diagram with a protocol-relative URL within an tag, such as .
The attacker distributes the malicious note (e.g., via sharing or a crafted .sy export).
The victim opens the note in SiYuan.
SiYuan renders the Mermaid diagram using the insecure Mermaid.js configuration.
The SVG containing the malicious tag is injected into the DOM via innerHTML.
The Electron client attempts to fetch the resource at the protocol-relative URL.
On Windows, the protocol-relative URL resolves to a UNC path (\\attacker.com\share\img.png), initiating an SMB connection.
Windows automatically sends the victim’s NTLMv2 hash to the attacker’s SMB server, or makes an HTTP request leaking victim’s IP on other platforms.

Impact

The vulnerability allows for zero-click NTLMv2 hash theft on Windows systems, where the victim only needs to open a note containing the malicious Mermaid diagram. The stolen NTLMv2 hashes can be cracked offline or used in relay attacks to gain unauthorized access to the victim’s resources. On all platforms, this vulnerability can be exploited to perform blind SSRF and leak the victim’s IP address, acting as a tracking pixel to confirm when the note was opened. This affects all SiYuan users who receive a crafted note.

Recommendation

Deploy the Sigma rule Detect SiYuan Mermaid NTLM Theft Attempt to identify SMB traffic originating from SiYuan processes attempting to connect to external IPs (network_connection log source).
Deploy the Sigma rule Detect SiYuan Mermaid SSRF Attempt to detect HTTP requests from SiYuan to external IP addresses with a suspicious URL (network_connection log source).
Monitor network traffic for SMB connections originating from SiYuan, especially to unusual or external destinations (network_connection log source).
Block the attacker’s domain (attacker.com) at the DNS resolver, as observed in the malicious Mermaid diagram example (iocs).
Upgrade SiYuan to a patched version that addresses CVE-2026-40107 to mitigate the underlying vulnerability.

Postiz SSRF Vulnerability (CVE-2026-40168)

hello@craftedsignal.io — Sat, 11 Apr 2026 12:00:00 +0000

Postiz is an AI-powered social media scheduling tool. Versions prior to 2.21.5 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability, identified as CVE-2026-40168. The vulnerability exists in the /api/public/stream endpoint. The application validates the initially supplied URL and blocks direct access to private or internal hosts. However, it fails to re-validate the final destination after HTTP redirects. This flaw enables an attacker to bypass the initial validation by providing a public HTTPS URL that redirects to an internal resource. Successful exploitation can lead to information disclosure, internal service enumeration, and potentially further compromise of the Postiz infrastructure. The vulnerability was reported and patched in version 2.21.5.

Attack Chain

The attacker identifies the vulnerable /api/public/stream endpoint in Postiz.
The attacker crafts a malicious URL. This URL is a valid, publicly accessible HTTPS URL.
The malicious URL is designed to redirect the request to an internal resource (e.g., http://127.0.0.1:8080/).
The attacker submits the crafted URL to the /api/public/stream endpoint.
Postiz server-side application validates the initial URL, which passes because it’s a public HTTPS address.
The Postiz server-side application follows the HTTP redirect from the attacker-controlled URL.
The request is redirected to the internal resource (e.g., http://127.0.0.1:8080/).
The Postiz server makes a request to the internal resource, potentially revealing sensitive information or enabling further exploitation.

Impact

Successful exploitation of CVE-2026-40168 allows an attacker to perform Server-Side Request Forgery (SSRF) attacks against the Postiz application. This can lead to the exposure of sensitive internal resources, such as configuration files, internal APIs, or databases. An attacker might be able to enumerate internal services, read sensitive data, or even perform actions on behalf of the Postiz server. The severity of the impact depends on the nature of the accessible internal resources and could range from information disclosure to remote code execution.

Recommendation

Upgrade Postiz to version 2.21.5 or later to patch CVE-2026-40168 as referenced in the Postiz release notes.
Implement strict URL validation and sanitization on the /api/public/stream endpoint. Ensure that validation occurs both before and after any HTTP redirects.
Deploy the Sigma rule to detect suspicious requests to the /api/public/stream endpoint that may indicate SSRF attempts.
Monitor web server logs for unusual HTTP requests originating from the Postiz server to internal IP addresses or private network ranges.

Chamilo LMS SSRF Vulnerability in Social Wall Feature

hello@craftedsignal.io — Sat, 11 Apr 2026 12:00:00 +0000

Chamilo LMS, a learning management system, is vulnerable to Server-Side Request Forgery (SSRF) in versions prior to 1.11.38 and 2.0.0-RC.3. This vulnerability resides in the Social Wall feature, specifically the read_url_with_open_graph endpoint. By supplying a crafted URL via the social_wall_new_msg_main POST parameter, an authenticated attacker can force the Chamilo LMS server to make arbitrary HTTP requests. This SSRF can be leveraged to probe internal services, perform port scanning on the internal network, and potentially access sensitive cloud instance metadata. The vulnerability was patched in versions 1.11.38 and 2.0.0-RC.3. Defenders should prioritize patching and monitoring for suspicious outbound HTTP requests originating from the Chamilo LMS server.

Attack Chain

An attacker authenticates to the Chamilo LMS platform with valid user credentials.
The attacker crafts a malicious URL targeting an internal service or resource.
The attacker initiates a POST request to the read_url_with_open_graph endpoint.
The POST request includes the crafted URL within the social_wall_new_msg_main parameter.
The Chamilo LMS server, without proper validation, processes the POST request.
The server then makes an HTTP request to the attacker-supplied URL.
If the URL targets an internal service, the attacker may gain unauthorized access or information.
Successful exploitation allows the attacker to scan internal ports and potentially access cloud instance metadata, leading to further reconnaissance or lateral movement.

Impact

Successful exploitation of this SSRF vulnerability could allow an attacker to gain unauthorized access to internal services and data within the organization’s network. An attacker could use this vulnerability to enumerate internal systems, gather sensitive information, and potentially escalate privileges within the network. This could also lead to lateral movement, data exfiltration, or other malicious activities. The severity of the impact depends on the sensitivity of the internal services exposed and the attacker’s objectives.

Recommendation

Upgrade Chamilo LMS to version 1.11.38 or 2.0.0-RC.3 or later to patch CVE-2026-31941.
Implement network segmentation to limit the impact of potential SSRF attacks.
Monitor web server logs for POST requests to /main/social/social_wall/social_wall.ajax.php with unusual URLs in the social_wall_new_msg_main parameter to detect potential exploitation attempts.
Deploy the Sigma rule to detect requests with unusual URLs to social_wall.ajax.php.

PraisonAI SSRF Vulnerability via Unvalidated Webhook URL

hello@craftedsignal.io — Thu, 09 Apr 2026 22:16:35 +0000

PraisonAI, a multi-agent teams system, is susceptible to a Server-Side Request Forgery (SSRF) vulnerability affecting versions prior to 4.5.128. The vulnerability resides in the /api/v1/runs endpoint, which accepts a webhook_url parameter in the request body without proper validation. This allows an unauthenticated attacker to specify an arbitrary URL, causing the PraisonAI server to send an HTTP POST request to that URL upon job completion. This flaw enables attackers to target internal services, cloud metadata endpoints, and other network-adjacent resources, potentially leading to information disclosure, privilege escalation, or denial-of-service. Organizations using affected versions of PraisonAI should upgrade to version 4.5.128 or later to mitigate this risk.

Attack Chain

An unauthenticated attacker identifies a PraisonAI instance running a version prior to 4.5.128.
The attacker crafts a malicious HTTP POST request to the /api/v1/runs endpoint.
The crafted request includes a webhook_url parameter containing a URL pointing to an internal service, cloud metadata endpoint, or external attacker-controlled server.
The PraisonAI server receives the request and queues a job.
The job completes (either successfully or with an error).
Upon completion, the server, using httpx.AsyncClient, initiates an HTTP POST request to the URL specified in the webhook_url parameter.
If the webhook_url points to an internal service, the attacker can potentially access sensitive information or trigger actions within that service.
If the webhook_url points to a cloud metadata endpoint, the attacker can retrieve cloud credentials or configuration details.

Impact

Successful exploitation of this SSRF vulnerability allows an unauthenticated attacker to force the PraisonAI server to make arbitrary HTTP POST requests. This can lead to the exposure of sensitive information from internal services or cloud metadata, potentially granting the attacker unauthorized access to systems and data. The vulnerability could also be leveraged to perform denial-of-service attacks against internal resources. While the exact number of affected organizations is unknown, any organization running a vulnerable version of PraisonAI is at risk.

Recommendation

Upgrade PraisonAI instances to version 4.5.128 or later to remediate CVE-2026-40114.
Inspect web server logs for requests to the /api/v1/runs endpoint containing suspicious webhook_url parameters to detect potential exploitation attempts. Deploy the Sigma rule to detect suspicious webhook URLs.
Monitor network traffic for unexpected outbound connections originating from the PraisonAI server to internal or external destinations, as this could indicate SSRF exploitation.

Axios NO_PROXY Hostname Normalization Bypass Leads to SSRF

hello@craftedsignal.io — Thu, 09 Apr 2026 17:32:19 +0000

Axios, a popular HTTP client for Node.js, is susceptible to a NO_PROXY bypass vulnerability due to incorrect hostname normalization. This flaw, confirmed in version 1.12.2 and affecting all versions prior to 1.15.0, arises from the application’s failure to properly handle hostnames with trailing dots (e.g., localhost.) or IPv6 literals (e.g., [::1]) when evaluating NO_PROXY rules. Instead of performing normalization as recommended by RFC standards, Axios conducts literal string comparisons. This oversight allows attackers to circumvent intended NO_PROXY configurations and force requests through an attacker-controlled proxy, even when loopback or internal services are meant to be protected. The vulnerability could be exploited to bypass SSRF mitigations, potentially enabling exfiltration of sensitive information.

Attack Chain

The attacker identifies an application using a vulnerable version of Axios and relies on NO_PROXY for loopback protection.
The attacker crafts a malicious URL targeting a loopback address (e.g., http://localhost.:8080/ or http://[::1]:8080/).
The vulnerable Axios instance processes the URL without proper hostname normalization.
Due to the lack of normalization, the NO_PROXY check fails to recognize localhost. or [::1] as loopback addresses.
Axios incorrectly routes the request through a configured proxy server, which could be controlled by the attacker.
The attacker-controlled proxy receives the request and can forward it to the intended internal service.
The internal service responds to the proxy.
The attacker-controlled proxy captures the response data, potentially containing sensitive information, and can exfiltrate it.

Impact

Applications that depend on NO_PROXY settings to safeguard loopback or internal access are vulnerable to SSRF attacks. Attackers can exploit this flaw to force Axios to send local traffic through an attacker-controlled proxy server. This bypasses SSRF mitigations that rely on NO_PROXY rules, allowing the potential exfiltration of sensitive information from internal services via the compromised proxy. The number of affected applications is potentially large, given the widespread use of Axios in Node.js environments. Successful exploitation could lead to unauthorized access to sensitive internal resources and data breaches.

Recommendation

Upgrade Axios to version 1.15.0 or later to address the vulnerability (CVE-2025-62718).
Deploy the Sigma rule Detect Axios SSRF via NO_PROXY Bypass to identify attempts to exploit this vulnerability.
Inspect web server logs for requests containing loopback addresses with trailing dots or bracketed IPv6 literals to identify potential exploitation attempts.

Plane Project Management Tool SSRF Vulnerability (CVE-2026-39843)

hello@craftedsignal.io — Thu, 09 Apr 2026 16:16:31 +0000

Plane is an open-source project management tool. Versions prior to 1.3.0 are vulnerable to a Server-Side Request Forgery (SSRF) vulnerability, tracked as CVE-2026-39843. This vulnerability stems from an incomplete fix for GHSA-jcc6-f9v6-f7jw. An authenticated attacker with low privileges can exploit this vulnerability by supplying a crafted HTML page containing a tag that redirects to a private IP address when using the “Add link” functionality. The vulnerability exists within the fetch_and_encode_favicon() function, which uses requests.get(favicon_url, ...) and follows redirects by default. This allows the attacker to force the server to make requests to internal resources. The vulnerability is resolved in version 1.3.0.

Attack Chain

Attacker authenticates to a Plane instance with low-privilege credentials.
Attacker crafts a malicious HTML page containing a tag in the section. The href attribute of this tag points to a redirect URL.
The redirect URL points to a private IP address or internal service (e.g., http://192.168.1.100/).
The attacker uses the “Add link” functionality in Plane to add the crafted HTML page’s URL to a project or task.
Plane’s fetch_and_encode_favicon() function attempts to fetch the favicon from the supplied URL.
Due to the redirect in the malicious HTML page, the server-side request is redirected to the private IP address specified in the href attribute.
The server fetches content from the internal resource.
The attacker can view the response from the internal resource, potentially revealing sensitive information or allowing further exploitation.

Impact

Successful exploitation of this SSRF vulnerability allows an authenticated, low-privilege attacker to read internal resources that the Plane server has access to. This could lead to the exposure of sensitive data, such as configuration files, internal API endpoints, or other confidential information. The number of potential victims is equal to the number of organizations using vulnerable versions of the Plane project management tool. The severity of the impact depends on the sensitivity of the information exposed and the attacker’s ability to leverage the exposed information for further attacks.

Recommendation

Upgrade Plane to version 1.3.0 or later to patch CVE-2026-39843.
Monitor web server logs for requests originating from the Plane application to internal IP addresses, especially those in the private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Use the Sigma rule Detect Plane SSRF via Internal IP Request to identify such requests.
Implement network segmentation and restrict the Plane server’s access to only necessary internal resources.
Consider implementing additional input validation and sanitization measures to prevent the injection of malicious URLs.

mcp-from-openapi SSRF Vulnerability via Untrusted OpenAPI Specifications

hello@craftedsignal.io — Wed, 08 Apr 2026 19:22:53 +0000

The mcp-from-openapi library, up to version 2.1.2, is susceptible to Server-Side Request Forgery (SSRF) attacks. This vulnerability arises from the library’s use of @apidevtools/json-schema-ref-parser to dereference $ref pointers in OpenAPI specifications without implementing any URL restrictions or custom resolvers. By crafting malicious OpenAPI specifications, an attacker can exploit this flaw to force the library to fetch internal network addresses, cloud metadata endpoints (like http://169.254.169.254/), or local files using file:///etc/passwd. This occurs during the initialize() call when processing the OpenAPI definition. Defenders should be aware that applications utilizing mcp-from-openapi to process potentially untrusted OpenAPI specifications are at risk.

Attack Chain

An attacker crafts a malicious OpenAPI specification containing $ref pointers to internal resources, cloud metadata endpoints, or local files.
The application using mcp-from-openapi receives this crafted OpenAPI specification, for example, via user upload or network request.
The OpenAPIToolGenerator.initialize() function is called, triggering the $ref dereferencing process.
The json-schema-ref-parser library, lacking proper configuration, fetches the resources specified in the malicious $ref pointers.
If the $ref points to a cloud metadata endpoint (e.g., http://169.254.169.254/), the server attempts to retrieve sensitive cloud credentials.
If the $ref points to an internal service, the server probes the internal network, potentially revealing information about available services.
If the $ref points to a local file (e.g., file:///etc/passwd), the server reads the contents of the file and includes it in the dereferenced output.
The attacker gains access to sensitive information, such as cloud credentials or internal network configurations, enabling further exploitation or lateral movement.

Impact

Successful exploitation of this SSRF vulnerability in mcp-from-openapi can have significant consequences. Attackers can steal cloud credentials by targeting metadata endpoints like http://169.254.169.254/, allowing them to compromise cloud infrastructure. The vulnerability also enables internal network scanning by probing internal services and ports, mapping out the internal network layout. Furthermore, attackers can read arbitrary files from the server’s filesystem using the file:// protocol, potentially gaining access to sensitive configuration files or credentials. The affected packages include npm/mcp-from-openapi (vulnerable: <= 2.1.2), npm/@frontmcp/sdk (vulnerable: <= 1.0.3), and npm/@frontmcp/adapters (vulnerable: <= 1.0.3).

Recommendation

Upgrade mcp-from-openapi to a patched version if available, or implement a patch to restrict URL resolution as described in the suggested fix.
Implement input validation on OpenAPI specifications before processing them with mcp-from-openapi to prevent malicious $ref values, mitigating CVE-2026-39885.
Monitor network connections originating from processes running mcp-from-openapi, alerting on connections to internal network addresses or cloud metadata endpoints using the network connection rule below.
Deploy the Sigma rule that detects access to local files via the file:// protocol to your SIEM and tune it for your environment.

IBM Verify and Security Verify Access Container Server-Side Request Forgery Vulnerability (CVE-2026-1343)

hello@craftedsignal.io — Wed, 08 Apr 2026 01:16:40 +0000

IBM Verify Identity Access Container versions 11.0 through 11.0.2 and IBM Security Verify Access Container versions 10.0 through 10.0.9.1, as well as IBM Verify Identity Access versions 11.0 through 11.0.2 and IBM Security Verify Access versions 10.0 through 10.0.9.1, are vulnerable to Server-Side Request Forgery (SSRF). This flaw, identified as CVE-2026-1343, allows a remote, unauthenticated attacker to bypass the reverse proxy and access internal authentication endpoints. The vulnerability exists due to insufficient access controls on internal endpoints. Exploitation could lead to information disclosure or further compromise of the affected systems. Defenders should prioritize patching and monitoring for suspicious activity targeting internal resources.

Attack Chain

Attacker identifies a vulnerable IBM Verify Identity Access or Security Verify Access Container instance.
The attacker crafts a malicious request targeting an internal authentication endpoint.
The crafted request bypasses the reverse proxy due to inadequate access controls.
The vulnerable server processes the malicious request, unintentionally exposing internal resources.
Sensitive information about internal systems is exposed to the attacker.
The attacker uses gathered information to perform unauthorized actions or further reconnaissance.
Attacker potentially compromises user accounts or internal infrastructure.

Impact

Successful exploitation of CVE-2026-1343 can lead to unauthorized access to sensitive internal information, potentially compromising user accounts and internal systems. This can result in data breaches, privilege escalation, and further attacks within the organization. While the specific number of affected organizations isn’t available, any organization using vulnerable versions of IBM Verify Identity Access Container or IBM Security Verify Access Container is at risk.

Recommendation

Apply the patch or upgrade to a secure version of IBM Verify Identity Access Container or IBM Security Verify Access Container as described in IBM’s advisory to remediate CVE-2026-1343.
Deploy the Sigma rule Detect Suspicious Access to Internal Endpoints via Proxy Bypass to detect exploitation attempts by monitoring web server logs for abnormal requests patterns targeting internal endpoints.
Implement network segmentation to restrict access to internal resources from the internet.
Review access control configurations on the reverse proxy to ensure proper protection of internal endpoints.

WWBN AVideo SSRF Vulnerability via Incomplete CVE-2026-27732 Fix

hello@craftedsignal.io — Wed, 08 Apr 2026 00:08:47 +0000

WWBN AVideo, a video-sharing platform, is susceptible to Server-Side Request Forgery (SSRF) vulnerability due to an incomplete patch for CVE-2026-27732. The vulnerability exists in the objects/aVideoEncoder.json.php script. An authenticated uploader can provide a malicious downloadURL containing a common media extension like .mp4, .jpg, .gif, or .zip, bypassing SSRF validation. This allows the attacker to force the server to fetch internal resources. The server fetches the specified URL using url_get_contents(), stores the response as media content, and makes it accessible through the /videos/... endpoint. This vulnerability, identified as CVE-2026-39370, affects AVideo versions 26.0 and earlier. Exploitation enables exfiltration of sensitive data from internal APIs and services.

Attack Chain

An attacker logs in as a low-privilege authenticated user with upload privileges.
The attacker crafts a malicious downloadURL pointing to an internal resource (e.g., http://127.0.0.1:9998/probe.mp4).
The attacker sends a POST request to /objects/aVideoEncoder.json.php with the downloadURL and a valid format parameter (e.g., mp4).
AVideo’s downloadVideoFromDownloadURL() function extracts the extension and incorrectly skips isSSRFSafeURL() validation due to the allowlisted extension.
The server fetches the content from the attacker-controlled downloadURL using url_get_contents().
The fetched content is written into video storage.
The attacker retrieves the media metadata using GET /objects/videos.json.php?showAll=1 to obtain the videosURL.mp4.url.
The attacker downloads the media URL and recovers the content from the internal resource.

Impact

Successful exploitation allows an authenticated uploader to force the AVideo server to fetch internal resources and persist the response as media content. This Server-Side Request Forgery (SSRF) vulnerability allows internal response exfiltration from private APIs, admin endpoints, or other internal services reachable from the application host. The number of potential victims is related to the installations of AVideo with versions less than or equal to 26.0, and the sectors primarily affected are likely media and entertainment, as well as organizations utilizing AVideo for internal video hosting.

Recommendation

Apply isSSRFSafeURL() to all downloadURL inputs in objects/aVideoEncoder.json.php, regardless of file extension to remediate CVE-2026-39370.
Deploy the Sigma rule “Detect AVideo SSRF Attempt via DownloadURL” to identify potential exploitation attempts based on requests to /objects/aVideoEncoder.json.php.
Restrict upload-by-URL functionality to an explicit allowlist of trusted fetch origins.

OpenObserve SSRF via Improper IPv6 Validation

hello@craftedsignal.io — Tue, 07 Apr 2026 20:16:29 +0000

OpenObserve, a cloud-native observability platform, contains a server-side request forgery (SSRF) vulnerability (CVE-2026-39361) in versions 0.70.3 and earlier. The vulnerability resides in the validate_enrichment_url function within src/handler/http/request/enrichment_table/mod.rs. This function fails to properly block IPv6 addresses due to the Rust’s url crate returning IPv6 addresses with surrounding brackets (e.g., “[::1]”) instead of without. This allows an authenticated attacker to bypass intended restrictions and access internal services that are normally blocked from external access. Successful exploitation can lead to the retrieval of sensitive IAM credentials via AWS IMDSv1 (169.254.169.254), GCP metadata, or Azure IMDS on cloud deployments, and probing of internal network services on self-hosted deployments.

Attack Chain

An authenticated attacker identifies the validate_enrichment_url function as a potential SSRF target.
The attacker crafts a malicious URL containing an IPv6 address with surrounding brackets (e.g., http://[::1]).
The attacker submits a request to the OpenObserve server, providing the malicious URL to the validate_enrichment_url function.
The validate_enrichment_url function fails to properly validate the IPv6 address due to the brackets.
The OpenObserve server initiates a request to the attacker-specified IPv6 address, bypassing intended access restrictions.
In a cloud environment, the attacker targets the AWS IMDSv1 endpoint (169.254.169.254) to retrieve IAM credentials.
The OpenObserve server retrieves the IAM credentials from the IMDSv1 endpoint and returns them to the attacker.
The attacker uses the stolen IAM credentials to gain unauthorized access to cloud resources.

Impact

Successful exploitation of this SSRF vulnerability can lead to significant consequences, especially in cloud deployments. An attacker can retrieve sensitive IAM credentials from cloud metadata services like AWS IMDSv1 (169.254.169.254), GCP metadata, or Azure IMDS. These stolen credentials can then be used to gain unauthorized access to critical cloud resources, potentially leading to data breaches, service disruption, and financial losses. The vulnerability affects OpenObserve instances version 0.70.3 and earlier. The number of affected organizations is currently unknown, but any organization using a vulnerable version of OpenObserve is at risk.

Recommendation

Upgrade OpenObserve to a version greater than 0.70.3 to patch CVE-2026-39361.
Monitor network connections originating from OpenObserve servers to internal IP addresses such as 169.254.169.254 using the provided Sigma rule to detect potential SSRF attempts.
Implement network segmentation and access controls to limit the impact of a successful SSRF attack, restricting access from OpenObserve servers to sensitive internal services.
Consider disabling IMDSv1 and migrating to IMDSv2 on AWS EC2 instances to mitigate the risk of IAM credential theft.

text-generation-webui SSRF Vulnerability (CVE-2026-35486)

hello@craftedsignal.io — Tue, 07 Apr 2026 16:16:26 +0000

The text-generation-webui application is an open-source web interface for running Large Language Models (LLMs). Prior to version 4.3, the superbooga and superboogav2 RAG (Retrieval-Augmented Generation) extensions are susceptible to a Server-Side Request Forgery (SSRF) vulnerability. These extensions fetch user-provided URLs using the requests.get() function without proper validation. Specifically, there are no checks for URL schemes (e.g., file://, gopher://), IP address filtering, or hostname whitelisting. This lack of validation allows a malicious actor to craft URLs that target internal resources, cloud metadata endpoints (e.g., AWS, Azure, GCP), and other sensitive services. Successful exploitation can lead to the exfiltration of sensitive data, including IAM credentials, and allow an attacker to probe internal network infrastructure. Version 4.3 of text-generation-webui addresses this vulnerability.

Attack Chain

An attacker identifies an instance of text-generation-webui running a vulnerable version (prior to 4.3) with the superbooga or superboogav2 RAG extension enabled.
The attacker crafts a malicious URL targeting a cloud metadata endpoint (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/).
The attacker injects the malicious URL into a text-generation-webui RAG extension user input field.
The application, using the requests.get() function, fetches the content from the attacker-controlled URL without validation.
The cloud metadata, containing potentially sensitive information like temporary IAM credentials, is retrieved by the application.
The retrieved data is processed through the RAG pipeline.
The attacker leverages the RAG pipeline to extract the content from the application.
The attacker uses the exfiltrated credentials to access and compromise other resources within the victim’s cloud environment.

Impact

Successful exploitation of CVE-2026-35486 can have significant consequences. An attacker can potentially gain unauthorized access to cloud resources by stealing IAM credentials. This could lead to data breaches, service disruption, and financial loss. The vulnerability affects any text-generation-webui instance running a version prior to 4.3 with the vulnerable RAG extensions enabled, impacting individuals and organizations utilizing this software for LLM-based applications.

Recommendation

Upgrade text-generation-webui to version 4.3 or later to remediate the SSRF vulnerability (CVE-2026-35486).
Deploy the Sigma rule “Detect text-generation-webui SSRF Attempt” to your SIEM to detect exploitation attempts targeting cloud metadata endpoints.
Monitor web server logs for outbound connections to internal IP addresses (e.g., 169.254.169.254) originating from the text-generation-webui application.

GPT Researcher Server-Side Request Forgery Vulnerability (CVE-2026-5633)

hello@craftedsignal.io — Mon, 06 Apr 2026 08:16:39 +0000

A server-side request forgery (SSRF) vulnerability, identified as CVE-2026-5633, affects assafelovic’s gpt-researcher version 3.4.3 and earlier. The vulnerability resides within the ws Endpoint component and is triggered by manipulating the source_urls argument. This flaw allows a remote attacker to potentially force the application to make requests to arbitrary internal or external resources. A publicly disclosed exploit exists, increasing the risk of exploitation. The developers were notified through an issue report, but have not yet responded. This vulnerability is a significant concern for organizations using gpt-researcher, as it can lead to sensitive data exposure or further attacks originating from the application’s server.

Attack Chain

Attacker identifies a gpt-researcher instance running version 3.4.3 or earlier.
Attacker crafts a malicious request containing a manipulated source_urls argument. This URL points to an internal resource or an external server controlled by the attacker.
The gpt-researcher application, specifically the ws Endpoint component, processes the request without proper validation of the source_urls parameter.
The application initiates a request to the attacker-specified URL, effectively acting as a proxy.
If the URL points to an internal resource, the attacker gains access to potentially sensitive data or internal services not intended for public access.
If the URL points to an external server controlled by the attacker, the server receives the request, revealing information about the gpt-researcher instance, such as its IP address.
The attacker can then leverage this information to further compromise the server or the network it resides on, potentially leading to lateral movement or data exfiltration.

Impact

Successful exploitation of CVE-2026-5633 can allow an attacker to perform actions they are not authorized to do. This includes reading internal data, accessing internal services, or using the vulnerable server as a proxy for further attacks. While the exact number of victims is unknown, any organization using a vulnerable version of gpt-researcher is at risk. The consequences of a successful SSRF attack can range from information disclosure to full server compromise, depending on the internal resources accessible to the application.

Recommendation

Inspect web server access logs for requests containing suspicious URLs in the source_urls parameter that point to internal or unexpected external resources. This can aid in detecting ongoing exploitation attempts (logsource: webserver, product: linux/windows).
Apply input validation to the source_urls parameter to ensure that the application only makes requests to authorized and expected resources.
Monitor network connections originating from the gpt-researcher server for unusual outbound traffic to internal or external IP addresses (logsource: network_connection, product: windows/linux).
Deploy the provided Sigma rule to detect potential SSRF attempts by monitoring for suspicious URL patterns in web server logs.

Budibase REST Connector SSRF via Empty Blacklist

hello@craftedsignal.io — Sat, 04 Apr 2026 12:00:00 +0000

A critical Server-Side Request Forgery (SSRF) vulnerability exists in Budibase version 3.30.6, affecting self-hosted instances that do not explicitly configure the BLACKLIST_IPS environment variable. The vulnerability resides within the REST datasource connector and the backend-core blacklist module. Due to the absence of a default IP blacklist, the isBlacklisted() function in packages/backend-core/src/blacklist/blacklist.ts unconditionally returns false, bypassing SSRF protection. This allows users with Builder privileges or QUERY WRITE permissions to create malicious REST datasources, query internal services, and exfiltrate sensitive data, including CouchDB credentials, application data, and internal service metadata. This vulnerability impacts confidentiality, integrity, and availability, potentially leading to complete instance takeover.

Attack Chain

An attacker with Builder privileges logs into the Budibase application.
The attacker creates a new REST datasource via POST /api/datasources, configuring it to target an internal service like http://couchdb-service:5984.
The Budibase server, specifically the packages/server/src/integrations/rest.ts component, evaluates the URL against the blacklist. Due to the empty BLACKLIST_IPS, the isBlacklisted() function returns false.
The REST integration proceeds with the request using the fetch API, sending the request to the specified internal service.
The internal service (e.g., CouchDB) responds with data.
The attacker creates a query via POST /api/queries that uses the malicious REST datasource.
The attacker executes the query via POST /api/v2/queries/:id, triggering a request to the internal service.
The response from the internal service, containing sensitive data like database credentials or application data, is returned to the attacker, enabling data exfiltration or further exploitation.

Impact

Successful exploitation allows attackers to read CouchDB databases, including user credentials (bcrypt password hashes) and platform configurations. They can also modify user records, create new admin accounts, alter application data, or delete databases. The vulnerability enables resource exhaustion, database destruction, and service disruption. The vulnerability crosses the security boundary between the Budibase application layer and the infrastructure layer, granting access to CouchDB, MinIO, Redis, and other internal services.

Recommendation

Immediately set the BLACKLIST_IPS environment variable in your Budibase deployment to include at least 127.0.0.1, private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local addresses (169.254.0.0/16), and cloud metadata endpoints to mitigate the SSRF vulnerability.
Restrict BUILDER role access to only trusted users. Consider using the principle of least privilege for application-level permissions.
Deploy the Sigma rule “Detect Budibase REST Datasource Creation Targeting Internal IPs” to your SIEM and tune for your environment to detect potential exploitation attempts.
If you have unpatched instances of Budibase and have granted QUERY WRITE permissions widely, immediately audit and revoke those permissions from untrusted users.
Monitor webserver logs for unusual requests originating from the Budibase application server to internal IP addresses or services, particularly those used by CouchDB, Redis, or MinIO, to identify potential SSRF attempts.

curl_cffi SSRF Vulnerability via Redirects

hello@craftedsignal.io — Fri, 03 Apr 2026 21:36:44 +0000

The curl_cffi library, a Python binding for libcurl, is susceptible to a server-side request forgery (SSRF) vulnerability in versions prior to 0.15.0. This flaw stems from the library’s unrestricted handling of redirects, allowing attacker-controlled URLs to redirect requests to internal IP ranges and services. An attacker can exploit this behavior to access sensitive information such as cloud metadata or bypass network controls. The vulnerability is triggered because curl_cffi automatically follows redirects (CURLOPT_FOLLOWLOCATION = 1) without validating the destination. Additionally, the TLS impersonation feature in curl_cffi can further obscure malicious requests by mimicking legitimate browser traffic, potentially bypassing TLS-based filtering mechanisms. This issue is similar to other redirect-based SSRF vulnerabilities, like CVE-2025-68616.

Attack Chain

Attacker identifies a curl_cffi application vulnerable to SSRF.
The attacker crafts a malicious URL pointing to an attacker-controlled server (attacker.example).
The victim application uses curl_cffi to request the attacker-controlled URL.
The attacker’s server responds with an HTTP 302 redirect to an internal IP address (e.g., 169.254.169.254, the cloud metadata endpoint).
curl_cffi automatically follows the redirect without validation.
The request is sent to the internal IP address, bypassing external access controls.
The internal service (e.g., cloud metadata API) responds with sensitive information.
The attacker retrieves the sensitive information from the victim application’s logs or response data.

Impact

Successful exploitation of this vulnerability allows an attacker to access internal network services and sensitive cloud metadata. This can lead to the exposure of API keys, credentials, and other confidential information. The impact can range from unauthorized access to internal applications and data to potential compromise of cloud infrastructure. All applications using curl_cffi versions before 0.15.0 are vulnerable. The severity is high due to the potential for significant data breaches and infrastructure compromise.

Recommendation

Upgrade to curl_cffi version 0.15.0 or later to patch CVE-2026-33752.
Implement server-side input validation to prevent passing attacker-controlled URLs to curl_cffi.
Monitor network traffic for connections to internal IP ranges (127.0.0.1, 169.254.0.0/16) originating from processes using curl_cffi. Create a network_connection rule to detect this activity.
Inspect web server logs for HTTP 302 redirects to internal IP addresses, which could indicate SSRF attempts. Deploy a webserver rule to detect this.

prompts.chat Fal.ai SSRF Vulnerability (CVE-2026-22664)

hello@craftedsignal.io — Fri, 03 Apr 2026 21:17:09 +0000

prompts.chat, a web application, contains a server-side request forgery (SSRF) vulnerability affecting versions prior to commit 30a8f04. This flaw resides in the Fal.ai media status polling feature. An authenticated user can inject arbitrary URLs into the token parameter, causing the server to make outbound requests to attacker-controlled destinations. The vulnerability, identified as CVE-2026-22664, allows attackers to potentially extract the FAL_API_KEY from the Authorization header during these requests. Successful exploitation can result in credential theft, internal network probing, and abuse of the victim’s Fal.ai account. This vulnerability poses a significant risk as it could lead to unauthorized access and data breaches.

Attack Chain

Attacker authenticates to the prompts.chat application.
Attacker crafts a malicious URL containing a server controlled by them.
The attacker initiates a media status polling request to Fal.ai, injecting the malicious URL into the token parameter.
The prompts.chat server, lacking proper URL validation, makes an outbound HTTP request to the attacker’s server.
The request includes the Authorization header, potentially exposing the FAL_API_KEY.
The attacker’s server captures the Authorization header containing the FAL_API_KEY.
The attacker uses the stolen FAL_API_KEY to access the victim’s Fal.ai account.
The attacker performs unauthorized actions, such as data exfiltration or resource abuse.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-22664) allows attackers to steal the FAL_API_KEY, potentially impacting all users of the vulnerable prompts.chat application who utilize the Fal.ai integration. Consequences include unauthorized access to Fal.ai accounts, data breaches, internal network scans originating from the prompts.chat server, and financial losses due to resource abuse. The specific number of victims and the extent of the damage depend on the attacker’s objectives and the permissions associated with the compromised Fal.ai API key.

Recommendation

Inspect web server logs for outbound requests to unusual or suspicious domains originating from the prompts.chat server to detect potential SSRF attempts (log source: webserver).
Deploy the provided Sigma rule to detect HTTP requests containing a suspicious token parameter potentially indicative of SSRF exploitation.
Monitor network traffic for unusual outbound connections from the prompts.chat server (log source: network_connection).
Apply the patch or upgrade prompts.chat to a version after commit 30a8f04, which addresses the CVE-2026-22664 vulnerability.

Ech0 Unauthenticated Server-Side Request Forgery Vulnerability

hello@craftedsignal.io — Fri, 03 Apr 2026 03:30:53 +0000

The Ech0 application suffers from an unauthenticated Server-Side Request Forgery (SSRF) vulnerability in its website preview feature. The /api/website/title endpoint, intended to fetch website titles, accepts a fully attacker-controlled URL without authentication. This allows anyone who can reach the Ech0 instance to force the server to make HTTP/HTTPS requests to arbitrary URLs. The application lacks a host allowlist, SSRF filter, and disables TLS certificate validation (InsecureSkipVerify: true). The backend reads the full HTML body into memory, which combined with enabled HTTP redirect following and the insecure TLS setting, allows attackers to target internal services and potentially cause a denial of service. The vulnerability is present in Ech0 versions prior to 1.4.8-0.20260401031029-4ca56fea5ba4.

Attack Chain

An attacker identifies an Ech0 instance and the /api/website/title endpoint.
The attacker crafts a malicious URL targeting an internal resource or a service on the Ech0 server’s network.
The attacker sends an unauthenticated GET request to /api/website/title with the website_url parameter set to the malicious URL (e.g., http://127.0.0.1:6277/api/website/title?website_url=http://host.docker.internal:9999/poc_ssrf_proof.html).
The Ech0 server, lacking proper validation, makes an HTTP(S) request to the attacker-specified URL using internal/util/http/http.go.
If the targeted URL redirects, the Ech0 server follows the redirect due to the default http.Client behavior.
The Ech0 server reads the entire response body into memory using io.ReadAll, potentially leaking sensitive information or causing a denial of service if the response is large.
The Ech0 server parses the HTML body looking for the title and returns the title, or an error message, to the attacker.
The attacker gains access to information from internal services or causes a denial-of-service condition by exhausting server resources.

Impact

This SSRF vulnerability allows unauthenticated attackers to force the Ech0 server to make HTTP(S) requests to internal or reserved targets reachable from the server’s network. A successful attack can lead to information disclosure, such as leaking cloud metadata from 169.254.169.254-class endpoints, or access to internal services that are not exposed to the public internet. The io.ReadAll function makes the Ech0 server susceptible to denial-of-service attacks if the attacker provides a URL that returns a large response. The number of victims depends on the deployment of the Ech0 application and the accessibility of internal resources from the Ech0 server’s network.

Recommendation

Deploy the Sigma rule Detect Ech0 SSRF via Website Title API to detect attempts to exploit this vulnerability by monitoring requests to the /api/website/title endpoint with suspicious URLs.
Block access to internal metadata endpoints like 169.254.169.254 from the Ech0 server if not explicitly required, mitigating the risk of cloud metadata exposure.
Apply the patch by upgrading to Ech0 version 1.4.8-0.20260401031029-4ca56fea5ba4 or later, addressing the underlying code flaws (CVE-2026-35036).

Azure Databricks SSRF Vulnerability (CVE-2026-33107) Allows Privilege Escalation

hello@craftedsignal.io — Fri, 03 Apr 2026 00:16:05 +0000

CVE-2026-33107 describes a critical server-side request forgery (SSRF) vulnerability affecting Azure Databricks. This vulnerability allows an unauthenticated attacker to potentially elevate their privileges within the network. Successful exploitation could allow an attacker to access sensitive data, modify configurations, or potentially gain complete control over the Databricks environment. The vulnerability was published on April 2nd, 2026. Due to the nature of SSRF, this vulnerability could be exploited remotely, making it a high-risk issue for organizations utilizing Azure Databricks. This vulnerability matters because it can lead to significant data breaches, service disruption, and compromise of sensitive resources managed within the Azure Databricks environment.

Attack Chain

The attacker identifies an endpoint within the Azure Databricks environment vulnerable to SSRF.
The attacker crafts a malicious HTTP request targeting an internal resource. The request is designed to exploit the SSRF vulnerability.
The Databricks server, processing the crafted request, unwittingly sends it to the specified internal resource.
The internal resource responds to the Databricks server with data intended only for internal consumption.
The attacker leverages the SSRF vulnerability to bypass authentication or authorization checks, gaining access to the internal resource.
The attacker escalates privileges by abusing the compromised internal resource or service. This may involve modifying configurations, accessing restricted data, or executing privileged commands.
The attacker uses the elevated privileges to move laterally within the network, compromising additional resources.
The attacker achieves their final objective, such as data exfiltration, denial of service, or complete control of the Azure Databricks environment.

Impact

Successful exploitation of CVE-2026-33107 could lead to significant privilege escalation within an Azure Databricks environment. An attacker could potentially gain unauthorized access to sensitive data, modify critical system configurations, or even achieve complete control over the Databricks cluster. This could result in data breaches, service disruptions, and substantial financial losses. The exact number of potential victims and the scope of the impact would depend on the specific configurations and data stored within the targeted Azure Databricks environment. Given the critical nature of Databricks for data analytics, the impact on organizations relying on this service can be substantial.

Recommendation

Apply the security update provided by Microsoft to patch CVE-2026-33107 immediately on all Azure Databricks instances.
Implement network segmentation to limit the impact of potential SSRF exploits.
Deploy the Sigma rule Detect Suspicious Databricks Outbound Connections to identify potential SSRF attempts.
Monitor webserver logs for unusual outbound connections originating from Azure Databricks servers.
Review and restrict access to internal resources within the Azure Databricks environment.
Implement strict input validation and sanitization on all user-supplied data to prevent SSRF attacks.

Huimeicloud hm_editor Server-Side Request Forgery Vulnerability (CVE-2026-5346)

hello@craftedsignal.io — Thu, 02 Apr 2026 15:16:53 +0000

A server-side request forgery (SSRF) vulnerability has been identified in huimeicloud hm_editor, specifically affecting versions up to 2.2.3. The vulnerability resides within the client.get function in the src/mcp-server.js file, which is part of the image-to-base64 endpoint. By manipulating the url argument, a remote attacker can potentially force the server to make requests to unintended locations, including internal resources. This vulnerability, identified as CVE-2026-5346, has a CVSS v3.1 score of 7.3 and is remotely exploitable. Public exploits are available. The vendor was notified but has not responded.

Attack Chain

The attacker identifies an instance of huimeicloud hm_editor running version 2.2.3 or earlier.
The attacker crafts a malicious URL containing a payload designed to exploit the SSRF vulnerability in the image-to-base64 endpoint.
The attacker sends a request to the vulnerable endpoint (src/mcp-server.js) with the crafted url parameter.
The client.get function processes the attacker-controlled url argument without proper validation.
The server-side application initiates an HTTP request based on the manipulated URL, potentially targeting internal resources or external services.
The server receives the response from the targeted resource.
The server may process and return the data obtained from the targeted resource to the attacker or use it internally.
The attacker gains unauthorized access to internal information or leverages the server as a proxy for further attacks.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-5346) can lead to unauthorized access to internal resources, sensitive data exposure, and the ability to use the vulnerable server as a proxy for further attacks. The impact includes potential compromise of internal systems, circumvention of security controls, and data breaches. The affected component is the image-to-base64 endpoint, which may be used to process user-supplied images.

Recommendation

Apply input validation and sanitization to the url argument passed to the client.get function within the src/mcp-server.js file to prevent SSRF attacks, mitigating CVE-2026-5346.
Monitor web server logs for suspicious requests targeting the image-to-base64 endpoint (src/mcp-server.js) with unusual url parameters, using the provided Sigma rule to identify exploitation attempts.
Implement network segmentation to limit the impact of successful SSRF attacks by restricting access to internal resources from the vulnerable server.
Deploy the Sigma rule to detect attempts to exploit CVE-2026-5346, focusing on unusual URLs being passed to the image-to-base64 endpoint.

WordPress Webmention Plugin SSRF Vulnerability (CVE-2026-0686)

hello@craftedsignal.io — Thu, 02 Apr 2026 08:16:27 +0000

The Webmention plugin for WordPress, a plugin designed to facilitate webmention communications, contains a Server-Side Request Forgery (SSRF) vulnerability identified as CVE-2026-0686. This vulnerability affects all versions of the plugin up to and including 5.6.2. The vulnerability resides within the ‘MF2::parse_authorpage’ function, accessible through the ‘Receiver::post’ function. An unauthenticated attacker can exploit this flaw to force the WordPress server to make HTTP requests to arbitrary external or internal locations. This can be leveraged to gather sensitive information from internal services, bypass firewalls, or potentially modify data depending on the accessibility of internal resources. The vulnerable code was present as of April 2026 in the version 5.6.2 branch.

Attack Chain

An unauthenticated attacker crafts a malicious webmention request targeting a WordPress site running the vulnerable Webmention plugin.
The WordPress site receives the webmention request and processes it using the ‘Receiver::post’ function.
The ‘Receiver::post’ function calls the ‘MF2::parse_authorpage’ function to parse the author page URL specified in the webmention request.
The ‘MF2::parse_authorpage’ function, due to lack of proper validation, makes an HTTP request to an attacker-controlled or internal URL specified within the webmention data.
The WordPress server initiates a connection to the specified URL, potentially bypassing firewall restrictions or accessing internal services not directly exposed to the internet.
The response from the targeted URL is processed by the plugin, potentially revealing information about the internal network or services.
Depending on the targeted internal service and the attacker’s crafted request, the attacker might be able to modify data or execute commands.
Successful exploitation leads to information disclosure, internal service compromise, or potential remote code execution depending on the vulnerable internal service.

Impact

Successful exploitation of CVE-2026-0686 allows unauthenticated attackers to perform Server-Side Request Forgery attacks against WordPress sites utilizing the Webmention plugin. This can lead to the exposure of sensitive information from internal services, such as configuration files or database credentials. Furthermore, attackers could potentially leverage this vulnerability to interact with and potentially compromise other internal systems that are not directly accessible from the internet, leading to a full compromise of the affected network. While the exact number of affected WordPress installations is unknown, the widespread use of the Webmention plugin makes this a significant risk.

Recommendation

Upgrade the Webmention plugin to a version higher than 5.6.2 to patch CVE-2026-0686.
Deploy the Sigma rule “Detect Webmention SSRF Attempt via Request to Internal IP” to identify exploitation attempts in web server logs.
Monitor web server logs for unusual outbound connections originating from the WordPress server to internal IP addresses.
Implement network segmentation to limit the impact of potential SSRF attacks, restricting access from the WordPress server to only necessary internal services.

PraisonAI SSRF Vulnerability via Unvalidated api_base Parameter

hello@craftedsignal.io — Wed, 01 Apr 2026 23:22:44 +0000

PraisonAI versions 4.5.89 and earlier are vulnerable to a Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-34936) due to insufficient validation of the api_base parameter within the passthrough() function. This flaw allows an attacker to control the base URL used in HTTP requests, enabling them to target internal services, external hosts, or cloud metadata endpoints. The vulnerability arises because the api_base parameter is directly concatenated with the endpoint parameter and passed to httpx.Client.request() without any sanitization. This is triggered in the passthrough() function if the litellm primary path raises an AttributeError. This allows attackers to bypass intended access controls and potentially retrieve sensitive information or trigger unintended actions within the PraisonAI server’s network. The vulnerability was reported on April 1, 2026.

Attack Chain

An attacker identifies a PraisonAI instance running a vulnerable version (<= 4.5.89).
The attacker crafts a malicious request to the passthrough() function, providing a crafted api_base parameter.
The crafted api_base contains the address of an internal service (e.g., Redis, Elasticsearch, Kubernetes API) or the EC2 metadata service (http://169.254.169.254).
An AttributeError is triggered in the litellm primary path.
The passthrough() function, within passthrough.py, concatenates the attacker-controlled api_base with the specified endpoint.
The resulting URL is then passed to httpx.Client.request(), making an HTTP request to the attacker-specified destination.
If targeting the EC2 metadata service, the attacker can retrieve IAM credentials associated with the instance.
If targeting internal services, the attacker can potentially access sensitive data or perform unauthorized actions, due to the default AUTH_ENABLED = False setting.

Impact

Successful exploitation of this SSRF vulnerability can lead to serious consequences. On cloud infrastructure, attackers can steal IAM credentials from the EC2 metadata service (IMDSv1), potentially gaining control over the entire AWS account. Internal services within the VPC, such as Redis, Elasticsearch, and Kubernetes API, become accessible without authentication, as the Flask API server deploys with AUTH_ENABLED = False by default. This can lead to data breaches, service disruptions, or further lateral movement within the internal network. This vulnerability affects deployments of PraisonAI version 4.5.89 and earlier.

Recommendation

Upgrade PraisonAI to a version greater than 4.5.89 to patch CVE-2026-34936.
Implement input validation and sanitization on the api_base parameter within the passthrough() function to prevent SSRF attacks.
If running on AWS, disable IMDSv1 and migrate to IMDSv2 to mitigate the risk of IAM credential theft.
Implement network segmentation and access controls to restrict access to internal services from the PraisonAI server.
Deploy the following Sigma rule to detect attempts to exploit the SSRF vulnerability by monitoring for connections to the EC2 metadata service or the local loopback address.

Payload CMS SSRF Vulnerability (CVE-2026-34746)

hello@craftedsignal.io — Wed, 01 Apr 2026 20:16:26 +0000

Payload CMS, a free and open-source headless content management system, is susceptible to a Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-34746) in versions prior to 3.79.1. This flaw allows authenticated users with create or update permissions to upload-enabled collections to trigger the server to initiate outbound HTTP requests to arbitrary URLs. This vulnerability stems from insufficient validation of user-supplied URLs during the upload process. An attacker could potentially exploit this to scan internal networks, access internal services, or conduct other malicious activities. The vulnerability has been addressed in version 3.79.1 of Payload CMS.

Attack Chain

An attacker authenticates to the Payload CMS application with create or update access to an upload-enabled collection.
The attacker crafts a malicious request containing a URL intended for server-side processing via the upload functionality. This URL could point to an internal service, a file on the local system, or an external server controlled by the attacker.
The attacker submits the crafted request to the Payload CMS server through the upload mechanism.
The Payload CMS server, lacking adequate validation of the provided URL, processes the request.
The server initiates an HTTP request to the attacker-specified URL.
The server receives the response from the targeted URL.
The response is potentially processed or returned by the Payload CMS application depending on the specific implementation.
The attacker gains access to internal resources or services, or potentially uses the server as a proxy for further attacks.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-34746) can allow an attacker to perform unauthorized actions such as internal port scanning, accessing sensitive data from internal services, or leveraging the compromised server as a proxy to conduct attacks against other systems. This could lead to data breaches, service disruption, or further compromise of the affected infrastructure. Although the precise number of installations affected is unknown, organizations using versions of Payload CMS prior to 3.79.1 are vulnerable.

Recommendation

Upgrade Payload CMS to version 3.79.1 or later to patch the SSRF vulnerability (CVE-2026-34746).
Implement strict input validation on all user-supplied URLs, especially those used in upload functionality, to prevent SSRF attacks.
Monitor web server logs for unusual outbound HTTP requests originating from the Payload CMS server to detect potential SSRF exploitation. Deploy the Sigma rule detecting outbound connections from the webserver.
Implement network segmentation to limit the impact of a successful SSRF attack by restricting access to sensitive internal resources.

OpenClaw SSRF Vulnerability via Unguarded Configured Base URLs

hello@craftedsignal.io — Sun, 29 Mar 2026 15:49:23 +0000

The openclaw package, a Node.js module, contains a Server-Side Request Forgery (SSRF) vulnerability in versions 2026.3.24 and earlier. This flaw stems from an incomplete fix for CVE-2026-28476, where several channel extensions continued to use raw fetch() against configured base URLs without proper SSRF protection. This omission allows attackers to potentially manipulate configured endpoints to target blocked internal destinations, bypassing intended security measures. The vulnerability was identified and patched in version 2026.3.25 through commit f92c92515bd439a71bd03eb1bc969c1964f17acf, which routes outbound requests through fetchWithSsrFGuard. Defenders should ensure they are running version 2026.3.25 or later.

Attack Chain

Attacker identifies an openclaw instance running version 2026.3.24 or earlier.
The attacker identifies a channel extension that uses a configured base URL.
Attacker crafts a malicious configuration that redirects the base URL to an internal resource.
The vulnerable fetch() function in the channel extension makes an HTTP request to the attacker-controlled URL.
The request bypasses the SSRF guard due to the incomplete fix for CVE-2026-28476.
The targeted internal resource processes the attacker’s request.
Sensitive information from the internal resource is potentially exposed to the attacker.
Attacker exfiltrates the exposed information, completing the SSRF attack.

Impact

Successful exploitation of this SSRF vulnerability could allow an attacker to gain unauthorized access to internal resources and sensitive information. The number of potential victims is dependent on the prevalence of vulnerable openclaw instances. If successful, the attacker can read internal files, access internal services, or even potentially execute commands on internal systems, leading to data breaches or further compromise of the network.

Recommendation

Upgrade the openclaw package to version 2026.3.25 or later to incorporate the fix for CVE-2026-28476, as described in the overview.
Implement network segmentation to limit the impact of potential SSRF vulnerabilities by restricting access from the affected systems to sensitive internal resources.
Deploy the Sigma rule “Detect OpenClaw SSRF Vulnerable Versions” to identify potentially vulnerable instances of the openclaw package based on user-agent strings.
Monitor outbound network connections from openclaw instances for connections to internal IP addresses or unexpected domains, which could indicate SSRF exploitation attempts.

elecV2 elecV2P Server-Side Request Forgery Vulnerability (CVE-2026-5016)

hello@craftedsignal.io — Sat, 28 Mar 2026 22:15:58 +0000

A server-side request forgery (SSRF) vulnerability, tracked as CVE-2026-5016, has been identified in elecV2 elecV2P versions up to 3.8.3. The vulnerability lies within the eAxios function of the /mock URL handler. By manipulating the req argument, a remote attacker can potentially force the server to make requests to arbitrary internal or external addresses. This could lead to the exposure of sensitive information, internal reconnaissance, or other malicious actions. The exploit is…

LibreChat SSRF Vulnerability (CVE-2026-31943)

hello@craftedsignal.io — Sat, 28 Mar 2026 12:00:00 +0000

LibreChat, a ChatGPT clone, contains a Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-31943) in versions prior to 0.8.3. The isPrivateIP() function in packages/api/src/auth/domain.ts fails to properly detect IPv4-mapped IPv6 addresses when they are in their hex-normalized form. This flaw allows an authenticated user to bypass SSRF protection mechanisms and force the LibreChat server to make HTTP requests to internal network resources. These resources include cloud metadata…

Clerk SSRF Vulnerability in frontendApiProxy Allows Secret Key Leakage

hello@craftedsignal.io — Sat, 28 Mar 2026 12:00:00 +0000

The clerkFrontendApiProxy function in @clerk/backend versions 3.0.0 through 3.2.2, @clerk/express versions 2.0.0 through 2.0.6, @clerk/hono versions 0.1.0 through 0.1.4, and @clerk/fastify versions 3.1.0 through 3.1.4 is susceptible to a Server-Side Request Forgery (SSRF) vulnerability. This flaw enables an unauthenticated attacker to craft malicious request paths that, when processed by the proxy, result in the application’s Clerk-Secret-Key being transmitted to a server under the attacker’s control. Only applications that have explicitly enabled the frontendApiProxy feature are affected. This feature is not enabled by default, limiting the scope of potential impact. Notably, @clerk/nextjs users are not affected due to the framework’s handling of repeated slashes in request paths, which mitigates the vulnerability.

Attack Chain

An attacker identifies an application that has the frontendApiProxy feature enabled and is running a vulnerable version of @clerk/backend, @clerk/express, @clerk/hono, or @clerk/fastify.
The attacker crafts a malicious HTTP request targeting the proxy endpoint (/__clerk/ by default). The request path includes double slashes or other path manipulation techniques to bypass intended routing logic.
The vulnerable clerkFrontendApiProxy function processes the crafted request without proper sanitization or validation of the request path.
Due to the SSRF vulnerability, the proxy makes an internal request to an unintended destination, potentially including an attacker-controlled server.
The application’s Clerk-Secret-Key is inadvertently included in the headers or body of the internal request made by the proxy.
The attacker-controlled server receives the request containing the Clerk-Secret-Key.
The attacker extracts the Clerk-Secret-Key from the captured request.
With the compromised Clerk-Secret-Key, the attacker can impersonate the application, access protected resources, or perform other unauthorized actions within the Clerk ecosystem.

Impact

Successful exploitation of this SSRF vulnerability allows an attacker to obtain the Clerk-Secret-Key of a vulnerable application. While internal logs from Clerk show no evidence of active exploitation, the potential impact of a compromised secret key is significant. An attacker with the key can impersonate the application, potentially leading to unauthorized access to user data, modification of application settings, or other malicious activities. The severity is further heightened because a successful attack can occur without authentication.

Recommendation

Upgrade to the patched version of @clerk/backend (3.2.3), @clerk/express (2.0.7), @clerk/hono (0.1.5), or @clerk/fastify (3.1.5) immediately if you are using the frontendApiProxy feature.
Rotate your Clerk Secret Key in the Clerk Dashboard under API Keys after upgrading to mitigate potential compromise, as recommended by the advisory.
Audit access logs for requests to your proxy endpoint (/__clerk/ by default) containing double slashes in the path to detect potential exploitation attempts.
Deploy the Sigma rule provided below to identify requests with double slashes to the Clerk proxy endpoint.

Oxygen Theme WordPress Plugin Vulnerable to Server-Side Request Forgery (CVE-2025-12886)

hello@craftedsignal.io — Sat, 28 Mar 2026 04:16:49 +0000

The Oxygen Theme WordPress plugin, versions 6.0.8 and earlier, contains a Server-Side Request Forgery (SSRF) vulnerability (CVE-2025-12886). This flaw allows unauthenticated attackers to send crafted requests to the WordPress server, potentially forcing it to make outbound connections to internal or external resources. The vulnerability is located within the laborator_calc_route AJAX action. By exploiting this, attackers can potentially access sensitive internal resources, bypass firewall…

LinkAce Server-Side Request Forgery Vulnerability (CVE-2026-33953)

hello@craftedsignal.io — Fri, 27 Mar 2026 22:16:21 +0000

LinkAce, a self-hosted archive for collecting website links, is vulnerable to a Server-Side Request Forgery (SSRF) vulnerability in versions prior to 2.5.3. This flaw, identified as CVE-2026-33953, stems from the application’s insufficient validation of user-supplied hostnames. Although direct requests to private IP literals are blocked, the application still performs server-side requests to internal resources when referenced through an internal hostname. An authenticated user can exploit this…

Postiz App SSRF Vulnerability via Next.js

hello@craftedsignal.io — Fri, 27 Mar 2026 15:46:53 +0000

The Postiz application, a web application built with Next.js, is vulnerable to Server-Side Request Forgery (SSRF). This vulnerability (CVE-2024-34351) allows an attacker to force the server to make HTTP requests to arbitrary domains. Exploitation can lead to internal network reconnaissance, access to sensitive cloud metadata, and potential credential theft. The vulnerability affects Postiz versions 2.0.12 and earlier. Users are advised to upgrade to version 2.21.1 to mitigate the risk. The primary concern is unauthorized access to internal resources and sensitive data through manipulated server-side requests.

Attack Chain

The attacker identifies a vulnerable endpoint in the Postiz application that accepts a URL as input.
The attacker crafts a malicious URL pointing to an internal resource, such as http://169.254.169.254/latest/meta-data/.
The Postiz server, without proper validation, makes an HTTP request to the specified URL.
If successful, the server retrieves the requested data from the internal resource.
The server returns the retrieved data to the attacker in the HTTP response.
The attacker obtains sensitive information such as AWS instance metadata, including IAM roles and access keys.
The attacker uses the compromised credentials to pivot into other AWS resources or the internal network.

Impact

A successful SSRF attack can have significant consequences. Attackers can bypass firewall restrictions to scan and interact with internal network services, potentially discovering sensitive information and exploiting further vulnerabilities. Accessing cloud metadata services like AWS IMDS allows for the theft of instance credentials, enabling attackers to compromise other AWS resources and escalate their privileges. This vulnerability can lead to a full compromise of the internal network environment where Postiz is hosted, potentially impacting all services and data within that environment.

Recommendation

Upgrade Postiz to version v2.21.1 to patch the SSRF vulnerability as recommended by the vendor.
Deploy the Sigma rule “Detect SSRF Attempt to AWS IMDS” to identify attempts to access the AWS metadata service (169.254.169.254) via HTTP requests.
Monitor web server logs for unusual outbound HTTP requests to internal IP addresses and private networks, specifically those originating from the Postiz application.

mingSoft MCMS Server-Side Request Forgery Vulnerability (CVE-2026-4953)

hello@craftedsignal.io — Fri, 27 Mar 2026 15:17:02 +0000

A server-side request forgery (SSRF) vulnerability has been identified in mingSoft MCMS version 5.5.0. The vulnerability resides within the catchImage function in the net/mingsoft/cms/action/BaseAction.java file, specifically affecting the Editor Endpoint component. Attackers can remotely exploit this vulnerability by manipulating the catchimage argument. Publicly available exploits exist, increasing the risk of exploitation. Successful exploitation could allow an attacker to probe…

Spring AI BedrockProxyChatModel SSRF Vulnerability (CVE-2026-22742)

hello@craftedsignal.io — Fri, 27 Mar 2026 06:16:37 +0000

A Server-Side Request Forgery (SSRF) vulnerability has been identified in the spring-ai-bedrock-converse library within Spring AI. The vulnerability resides in the BedrockProxyChatModel component and arises during the processing of multimodal messages. Specifically, when handling user-supplied media URLs, the application fails to adequately validate these URLs. This lack of validation allows a malicious actor to inject arbitrary URLs, potentially causing the server to make unintended HTTP…

Multiple Vulnerabilities in cPanel/WHM

hello@craftedsignal.io — Tue, 24 Mar 2026 12:11:04 +0000

Multiple vulnerabilities have been identified in cPanel/WHM, a widely used web hosting control panel. An anonymous, remote attacker can exploit these vulnerabilities to compromise cPanel/WHM installations. The vulnerabilities allow an attacker to bypass security measures, perform Cross-Site Scripting (XSS) and Server-Side Request Forgery (SSRF) attacks, disclose sensitive information, and potentially execute arbitrary code on the server. These vulnerabilities pose a significant risk to organizations relying on cPanel/WHM for web hosting, potentially leading to data breaches, service disruption, and unauthorized access to sensitive systems.

Attack Chain

The attacker identifies a vulnerable cPanel/WHM instance exposed to the internet.
The attacker crafts a malicious HTTP request exploiting an identified SSRF vulnerability to probe internal network resources.
Successful SSRF exploitation allows the attacker to identify internal services and gather information about the server architecture.
The attacker leverages an XSS vulnerability by injecting malicious JavaScript code into a cPanel/WHM page.
Unsuspecting users interacting with the compromised page execute the attacker’s JavaScript code.
The attacker uses the XSS payload to steal user session cookies or credentials.
The attacker uses the stolen credentials to bypass authentication and gain unauthorized access to cPanel/WHM.
With elevated privileges, the attacker can potentially execute arbitrary code on the server, leading to full system compromise.

Impact

Successful exploitation of these vulnerabilities can lead to severe consequences. An attacker could gain unauthorized access to sensitive data, including customer databases, configuration files, and source code. XSS attacks could deface websites and phish users. SSRF attacks can expose internal network resources. Remote code execution can lead to complete server takeover and potentially impact a large number of hosted websites and services. This can result in significant financial losses, reputational damage, and legal liabilities.

Recommendation

Deploy the Sigma rule Detect Suspicious cPanel/WHM HTTP Request to identify potential SSRF attempts within cPanel/WHM webserver logs.
Deploy the Sigma rule Detect cPanel/WHM XSS Attempt to detect potential XSS payloads being injected into cPanel/WHM.
Closely monitor web server logs for unusual activity originating from cPanel/WHM servers using the webserver category.
Implement strong input validation and output encoding to prevent XSS attacks.
Harden cPanel/WHM configurations to restrict SSRF attack vectors and limit access to internal resources.

Apache CXF Multiple Vulnerabilities Allow Information Disclosure and SSRF

hello@craftedsignal.io — Tue, 24 Mar 2026 10:20:50 +0000

Apache CXF is vulnerable to multiple security flaws that can be exploited by remote attackers. Successful exploitation of these vulnerabilities can lead to sensitive information disclosure and Server-Side Request Forgery (SSRF) attacks. While the specifics of these vulnerabilities are not detailed in this brief, defenders should be aware that applications using Apache CXF may be at risk. Given the potential for significant impact, including the exposure of internal data and the ability to proxy requests through the server, this vulnerability poses a substantial threat and requires immediate attention. Defenders should investigate their exposure and patch or mitigate as soon as possible.

Attack Chain

The attacker identifies an Apache CXF endpoint exposed to the internet.
The attacker crafts a malicious request to exploit an unspecified vulnerability in Apache CXF.
If successful, the vulnerability allows the attacker to read sensitive information from the server’s memory or configuration files.
The attacker leverages a separate vulnerability to perform a Server-Side Request Forgery (SSRF) attack, forcing the server to make requests to internal resources.
The attacker uses the SSRF vulnerability to scan internal networks, identifying other vulnerable systems.
The attacker retrieves sensitive data from internal services via SSRF, such as credentials or internal API keys.
The attacker escalates the attack by leveraging the obtained credentials to access other systems.

Impact

Successful exploitation of these vulnerabilities can lead to the disclosure of sensitive information, potentially including user credentials, API keys, and internal data structures. The SSRF vulnerability can allow an attacker to access internal systems and services, leading to further compromise of the network. The impact can range from data breaches to complete system compromise, affecting all sectors that rely on Apache CXF for web service implementation.

Recommendation

Inspect web server logs for unusual request patterns targeting Apache CXF endpoints, looking for attempts to access sensitive files or internal resources.
Monitor network traffic for suspicious outbound connections originating from servers running Apache CXF, which might indicate SSRF attempts.
Implement strong input validation and output encoding mechanisms in Apache CXF configurations to prevent information disclosure and SSRF attacks.
Apply all available patches and updates for Apache CXF to remediate known vulnerabilities.

DefaultFuction Jeson-Customer-Relationship-Management-System Server-Side Request Forgery Vulnerability

hello@craftedsignal.io — Tue, 24 Mar 2026 03:16:06 +0000

A server-side request forgery (SSRF) vulnerability, identified as CVE-2026-4623, has been discovered in DefaultFuction Jeson-Customer-Relationship-Management-System up to version 1b4679c4d06b90d31dd521c2b000bfdec5a36e00. The vulnerability resides within the API Module, specifically in the /api/System.php file. An attacker can remotely manipulate the ‘url’ argument, causing the server to make requests to unintended locations. Due to the product’s continuous delivery with rolling releases, specific version details are unavailable. A patch to address the vulnerability is identified as f76e7123fe093b8675f88ec8f71725b0dd186310/98bd4eb07fa19d4f2c5228de6395580013c97476. This vulnerability poses a significant risk as it allows attackers to potentially access internal resources, bypass security controls, and potentially escalate privileges.

Attack Chain

Attacker identifies an instance of DefaultFuction Jeson-Customer-Relationship-Management-System running version <= 1b4679c4d06b90d31dd521c2b000bfdec5a36e00.
Attacker crafts a malicious HTTP request targeting the /api/System.php endpoint.
The crafted request includes the url parameter, modified to point to an internal resource or external server controlled by the attacker.
The server-side application processes the malicious request without proper validation of the url parameter.
The application initiates an HTTP request to the attacker-controlled URL or internal resource specified in the url parameter.
The server receives the response from the attacker-controlled server or internal resource.
The application may process the response, potentially exposing sensitive information or allowing further exploitation.
If successful, the attacker gains access to sensitive information, internal resources, or the ability to perform actions on behalf of the server.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-4623) can lead to the exposure of sensitive internal data, such as configuration files, database credentials, or API keys. It may also allow attackers to bypass security controls, access internal services not intended for public access, and potentially escalate privileges within the application or the underlying infrastructure. Due to lack of information on the specific scope of usage for this CRM, the total number of potential victims is unclear. Organizations utilizing this vulnerable CRM are at risk.

Recommendation

Apply the patch identified as f76e7123fe093b8675f88ec8f71725b0dd186310/98bd4eb07fa19d4f2c5228de6395580013c97476 to mitigate the CVE-2026-4623 vulnerability.
Deploy the Sigma rule “Detect Jeson CRM System.php SSRF Attempt” to your SIEM to detect exploitation attempts against the /api/System.php endpoint.
Implement strict input validation and sanitization on the url parameter within the /api/System.php endpoint to prevent malicious URL manipulation.
Monitor web server logs for suspicious requests to the /api/System.php endpoint, specifically those containing unusual or unexpected URLs in the url parameter, to identify potential exploitation attempts.

AVideo Unauthenticated Server-Side Request Forgery Vulnerability

hello@craftedsignal.io — Mon, 23 Mar 2026 17:16:51 +0000

AVideo, an open-source video platform, is affected by a critical unauthenticated Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-33502) in versions up to and including 26.0. The vulnerability exists within the plugin/Live/test.php file. An attacker can exploit this flaw to force the AVideo server to make HTTP requests to arbitrary URLs. Successful exploitation allows attackers to probe internal network services, potentially accessing sensitive internal HTTP resources, cloud metadata endpoints, and other protected assets. The patch for this vulnerability is included in commit 1e6cf03e93b5a5318204b010ea28440b0d9a5ab3. This vulnerability poses a significant risk, as it does not require authentication and can lead to the exposure of sensitive information and potential compromise of internal infrastructure.

Attack Chain

The attacker identifies an AVideo instance running a vulnerable version (<= 26.0).
The attacker crafts a malicious HTTP request targeting the plugin/Live/test.php endpoint.
The crafted request includes a URL parameter pointing to an internal resource (e.g., http://localhost/admin).
The AVideo server, without proper validation, processes the request and sends an HTTP request to the attacker-specified URL.
The server receives the HTTP response from the internal resource.
The server may return the content of the internal resource to the attacker, depending on the AVideo application logic.
The attacker analyzes the returned content, potentially gaining access to sensitive information like configuration files, API keys, or internal service endpoints.
The attacker leverages the exposed information to further compromise the AVideo instance or the internal network.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-33502) can lead to the exposure of sensitive internal resources, including configuration files, API keys, and cloud metadata. This can enable attackers to gain unauthorized access to internal systems, escalate privileges, and potentially compromise the entire infrastructure. The number of affected AVideo instances is currently unknown, but given its open-source nature, it is potentially widespread across various sectors. A successful attack can lead to data breaches, service disruption, and reputational damage.

Recommendation

Upgrade AVideo instances to a patched version containing commit 1e6cf03e93b5a5318204b010ea28440b0d9a5ab3 to remediate CVE-2026-33502.
Deploy the Sigma rule Detect AVideo SSRF Attempt via plugin Live Test to identify potential exploitation attempts targeting the vulnerable endpoint.
Implement network segmentation to restrict access to internal resources and mitigate the impact of successful SSRF exploitation.
Review webserver logs for suspicious requests to plugin/Live/test.php with unusual URL parameters (log source: webserver).

Monetr Lunch Flow SSRF Vulnerability

hello@craftedsignal.io — Thu, 02 May 2024 12:00:00 +0000

A server-side request forgery (SSRF) vulnerability was identified in the Lunch Flow integration of Monetr, affecting self-hosted instances. This vulnerability allows any authenticated user to cause the Monetr server to issue HTTP GET requests to arbitrary URLs, with the response body from non-200 upstream responses reflected back in the API error message. The URL validator on the POST /api/lunch_flow/link endpoint lacked sufficient filtering, failing to block loopback, RFC1918, link-local, or cloud-provider metadata addresses. This allows attackers to potentially access internal resources or cloud instance metadata. The vulnerability was addressed in Monetr version 1.12.5. The hosted my.monetr.app service is not affected because LunchFlow.Enabled is set to false.

Attack Chain

An attacker registers an account on a vulnerable self-hosted Monetr instance where public sign-up is enabled (AllowSignUp=true).
The attacker authenticates to the Monetr instance.
The attacker crafts a malicious POST request to the /api/lunch_flow/link endpoint, providing a URL pointing to an internal resource, such as a cloud metadata endpoint (e.g., http://169.254.169.254/latest/meta-data/).
The Monetr server, due to insufficient URL validation, accepts the malicious URL.
The Monetr server issues an HTTP GET request to the attacker-supplied URL.
The external service or internal resource responds to the Monetr server.
If the response is not a 200 OK, the Monetr server reflects the response body in the API error message within the JSON response to the attacker.
The attacker observes the reflected response body, potentially revealing sensitive information like cloud instance metadata or internal service details.

Impact

Successful exploitation of this SSRF vulnerability can lead to the exposure of sensitive information, such as cloud instance metadata (e.g., AWS EC2 IMDS). This could allow an attacker to gain unauthorized access to other cloud resources or internal systems. The vulnerable instances are self-hosted Monetr deployments running the default configuration with LunchFlow.Enabled=true and AllowSignUp=true. An attacker could also cause a denial-of-service by providing a URL that returns a very large response body, exhausting the server’s memory.

Recommendation

Upgrade to Monetr version v1.12.5 or later to patch the SSRF vulnerability. This version introduces a new config field LunchFlow.AllowedApiUrls and caps response body reads at 10 MiB.
For operators who cannot upgrade immediately, set MONETR_ALLOW_SIGN_UP=false to disable public sign-up, limiting access to the vulnerable endpoint to trusted users.
Alternatively, disable Lunch Flow entirely by setting lunchFlow.enabled: false in your config file. This will cause the vulnerable endpoints to return 404.
Implement network-level egress restrictions to limit outbound HTTP traffic from the Monetr pod/container to only lunchflow.app (or other legitimate Lunch Flow hosts), mitigating the SSRF primitive.

PhpSpreadsheet SSRF and RCE Vulnerability via IOFactory::load

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

PhpSpreadsheet, a widely used PHP library for reading and writing spreadsheet files, is susceptible to a critical vulnerability that can lead to both Server-Side Request Forgery (SSRF) and Remote Code Execution (RCE). The vulnerability stems from insufficient validation of the $filename parameter passed to the IOFactory::load function. When this parameter is user-controlled, attackers can leverage PHP wrappers such as ftp://, phar://, and ssh2.sftp:// to bypass the is_file check, leading to malicious file inclusion or arbitrary code execution. This flaw affects versions up to and including 1.30.2, as well as versions 2.0.0 through 5.5.0. Exploitation can occur even if the specified file inside the phar archive does not exist or is not a supported file type, potentially masking the attack. Due to PhpSpreadsheet’s widespread use in other popular libraries like maatwebsite/excel and sonata-project/exporter, the impact of this vulnerability is significant.

Attack Chain

An attacker crafts a malicious phar archive (exploit.xlsx) containing a PHP object with a __destruct method that executes arbitrary code via shell_exec.
The attacker hosts the malicious phar archive on a web server or makes it accessible through other means.
The attacker crafts a request to a vulnerable web application using PhpSpreadsheet, providing a phar:// URL (e.g., phar://exploit.xlsx/whatever) as the $filename parameter to IOFactory::load.
IOFactory::load attempts to load the file specified in the $filename parameter, which passes through the vulnerable is_file check.
The phar:// wrapper triggers PHP’s phar extension, which deserializes the metadata within the exploit.xlsx archive.
Deserialization of the malicious PHP object triggers the __destruct method, executing the attacker’s arbitrary code via shell_exec, achieving RCE. The code creates /tmp/poc.txt in the example.
Alternatively, the attacker provides an ftp:// URL to IOFactory::load, pointing to an attacker-controlled FTP server.
The vulnerable is_file check allows the ftp:// connection, leading to an SSRF vulnerability where the server running PhpSpreadsheet connects to the attacker’s specified FTP server.

Impact

Successful exploitation of this vulnerability can lead to a range of severe consequences. Remote Code Execution (RCE) allows an attacker to execute arbitrary commands on the server, potentially leading to complete system compromise. The SSRF vulnerability enables an attacker to probe internal network resources, potentially exposing sensitive information or allowing further attacks on internal systems. Given PhpSpreadsheet’s use in numerous web applications and frameworks, a successful attack could impact a large number of users and organizations. Example impact includes attackers gaining initial access to internal applications.

Recommendation

Apply the suggested mitigations by either checking for PHP wrappers in the filename before calling is_file or by using realpath to ensure a clean absolute path (see code snippets in the advisory).
Deploy the Sigma rule Detect_PhpSpreadsheet_Phar_Wrapper to detect attempts to exploit the RCE vulnerability by monitoring process creation events with command lines containing “phar://” and php.
Deploy the Sigma rule Detect_PhpSpreadsheet_Ftp_Wrapper to detect attempts to exploit the SSRF vulnerability by monitoring network connections with destination ports on FTP protocol (21) and file paths contain ftp.
Monitor web server logs for requests containing the phar:// or ftp:// schemes in the filename parameter to IOFactory::load.

i18next-http-middleware Prototype Pollution and Path Traversal Vulnerability

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

i18next-http-middleware versions prior to 3.9.3 are susceptible to prototype pollution, path traversal, and SSRF attacks. The vulnerability stems from the insufficient validation of the lng (language) and ns (namespace) parameters passed via HTTP requests to the getResourcesHandler and the missingKeyHandler. These handlers, intended to serve localization resources, expose attack surface because they process user-controlled input without proper sanitization. This allows attackers to manipulate object properties, access unintended files or internal services, and cause denial-of-service conditions. The vulnerability was discovered via an internal security audit. Defenders should upgrade to version 3.9.3 to remediate the risks.

Attack Chain

The attacker crafts an HTTP GET request to the /locales/resources.json endpoint, targeting the getResourcesHandler.
The request includes malicious lng and ns query parameters, such as lng=__proto__&ns=isAdmin, or ns=../../etc/passwd.
The getResourcesHandler extracts the lng and ns parameters without sufficient validation.
The lng and ns values are passed to utils.setPath(resources, [lng, ns], ...) which allows writing to the Object prototype if lng is __proto__.
The lng and ns values are passed to i18next.services.backendConnector.load(languages, namespaces, ...) to load resource bundles. With filesystem or HTTP backends, this can enable path traversal or SSRF if ns or lng contain malicious path segments.
Alternatively, the attacker sends a POST request with a body containing a malicious __proto__ key to missingKeyHandler, for example {"__proto__": {"isAdmin": true}}.
The missingKeyHandler iterates over the request body using for...in, including inherited prototype properties, and forwards the malicious data into saveMissing.
Successful exploitation leads to prototype pollution, arbitrary file access, SSRF, or denial of service.

Impact

Successful exploitation can have significant consequences. Prototype pollution allows attackers to manipulate object properties globally, leading to broken authorization checks (e.g., bypassing if (user.isAdmin)), type confusion errors, or potentially remote code execution. Path traversal enables access to sensitive files on the server, like configuration files or password databases, while SSRF allows attackers to interact with internal services. Finally, the unbounded growth of the i18next.options.ns list and repeated backend load calls can lead to denial of service due to memory and CPU exhaustion. This can impact availability of the service and potentially other services on the same host.

Recommendation

Upgrade to i18next-http-middleware version 3.9.3 or later to address the vulnerabilities.
Deploy the Sigma rules provided below to detect exploitation attempts targeting the getResourcesHandler and missingKeyHandler endpoints.
If upgrading is not immediately feasible, implement a WAF rule as a partial mitigation to block requests containing __proto__, constructor, prototype, .., or control characters in lng/ns query parameters or body keys as suggested in the advisory.

BigSweetPotatoStudio HyperChat AI Proxy Middleware Server-Side Request Forgery

hello@craftedsignal.io — Tue, 23 Jan 2024 12:00:00 +0000

A server-side request forgery (SSRF) vulnerability, identified as CVE-2026-7223, affects BigSweetPotatoStudio HyperChat up to version 2.0.0-alpha.63. The vulnerability resides in the ‘fetch’ function within the AI Proxy Middleware located at packages/core/src/http/aiProxyMiddleware.mts. By manipulating the baseurl argument, a remote attacker can force the server to make arbitrary HTTP requests to internal or external resources. This issue allows attackers to potentially access sensitive information, bypass security controls, or perform other malicious actions. The vulnerability is remotely exploitable, and a public exploit is available, increasing the risk of widespread exploitation. The project maintainers were notified but have not responded.

Attack Chain

The attacker identifies an instance of BigSweetPotatoStudio HyperChat running version 2.0.0-alpha.63 or earlier.
The attacker crafts a malicious HTTP request targeting the AI Proxy Middleware component.
The crafted request includes a manipulated baseurl argument within the request to the fetch function, pointing to an internal resource (e.g., http://localhost:8080/admin) or an external server controlled by the attacker.
The HyperChat server, without proper validation of the baseurl, uses it to make an HTTP request.
If the baseurl points to an internal resource, the server retrieves the content of that resource and sends it back to the attacker.
If the baseurl points to an external server, the server makes a request to the attacker’s server, potentially leaking sensitive information in the request headers or body.
The attacker analyzes the response from the server to gather sensitive information or identify further attack vectors.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-7223) can allow an attacker to read sensitive internal data, such as configuration files or API keys, potentially leading to full system compromise. The attacker could also use the vulnerable server as a proxy to scan internal networks or attack other internal systems. Due to the public availability of the exploit, organizations using vulnerable versions of HyperChat are at increased risk of being targeted. The CVSS v3.1 base score for this vulnerability is 7.3, indicating a high severity.

Recommendation

Apply appropriate input validation and sanitization to the baseurl argument in the AI Proxy Middleware to prevent manipulation, addressing CVE-2026-7223.
Implement network segmentation to restrict access from the HyperChat server to only necessary internal resources.
Deploy the Sigma rule “HyperChat SSRF Attempt” to detect attempts to exploit the vulnerability via HTTP request patterns.
Monitor web server logs for suspicious outbound connections originating from the HyperChat server, correlating with user input.

Royal Elementor Addons Plugin SSRF Vulnerability

hello@craftedsignal.io — Mon, 08 Jan 2024 12:00:00 +0000

The Royal Elementor Addons plugin, a popular WordPress extension, contains a Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-6229) in versions up to and including 1.7.1057. This flaw stems from inadequate validation of user-provided URLs within the render_csv_data() function. Attackers can bypass the validation by including ‘docs.google.com/spreadsheets’ in a query parameter. The vulnerability is triggered because the plugin uses these URLs in fopen() calls without implementing adequate safeguards to prevent access to internal or private network addresses. This vulnerability enables authenticated attackers with Contributor-level access or higher to craft malicious requests, potentially exposing sensitive internal data. Successful exploitation allows attackers to probe internal network resources, access configuration files, and potentially escalate attacks further.

Attack Chain

An attacker authenticates to the WordPress site with Contributor-level access or higher.
The attacker crafts a malicious HTTP request targeting the vulnerable render_csv_data() function within the Royal Elementor Addons plugin.
The malicious request includes a user-supplied URL containing ‘docs.google.com/spreadsheets’ within a query parameter to bypass initial validation checks.
The plugin’s render_csv_data() function receives the crafted URL without proper sanitization or validation against internal or private network addresses.
The fopen() function is called with the attacker-controlled URL, initiating an outbound request from the WordPress server.
If the URL points to an internal resource, the WordPress server retrieves the resource content.
The attacker receives the content of the internal resource in the response from the WordPress server.
The attacker analyzes the retrieved content for sensitive information, such as configuration files, API keys, or internal service details.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-6229) can lead to the exposure of sensitive internal information, potentially impacting all organizations using the Royal Elementor Addons plugin for WordPress version 1.7.1057 and below. This may include internal configuration files, API keys, database credentials, or other sensitive data accessible through internal services. The severity is high due to the potential for attackers to pivot from this vulnerability and further compromise the WordPress server or the internal network.

Recommendation

Upgrade the Royal Elementor Addons plugin to a version higher than 1.7.1057 to patch CVE-2026-6229.
Deploy the Sigma rule “Detect Royal Elementor Addons SSRF Attempt via URL Parameter” to identify malicious requests targeting the render_csv_data() function in your web server logs.
Implement strict network segmentation and firewall rules to limit access from the WordPress server to internal resources, mitigating the impact of potential SSRF vulnerabilities.

Nginx-UI SSRF Vulnerability via Cluster Node Proxy

hello@craftedsignal.io — Wed, 03 Jan 2024 14:30:00 +0000

Nginx-UI versions 2.3.4 and earlier contain a Server-Side Request Forgery (SSRF) vulnerability in the cluster node proxy middleware. An authenticated user can exploit this flaw by creating a malicious cluster node that points to an arbitrary internal URL, such as localhost services or cloud metadata endpoints. The vulnerability lies in the lack of validation for the node URL within the internal/middleware/proxy.go file. Successful exploitation allows attackers to bypass network segmentation, access sensitive internal resources, and potentially escalate privileges, especially when combined with other vulnerabilities like njs code injection. This issue allows attackers to reach internal services that should not be exposed.

Attack Chain

Attacker authenticates to the Nginx-UI web interface.
Attacker retrieves the node_secret via a GET request to /api/settings.
Attacker crafts a POST request to /api/nodes to create a new cluster node.
The crafted node configuration includes a malicious url parameter pointing to an internal resource (e.g., http://127.0.0.1:51820 or http://169.254.169.254).
Attacker sends an API request (e.g., GET /api/settings) with the X-Node-ID header set to the ID of the newly created malicious node.
The Nginx-UI proxy middleware (internal/middleware/proxy.go) intercepts the request and forwards it to the attacker-specified internal URL.
The request is executed on the server-side, effectively performing an SSRF attack.
Attacker gains access to internal resources, cloud metadata, or triggers internal-only njs endpoints.

Impact

Successful exploitation allows an authenticated attacker to access internal services, cloud metadata endpoints, and internal-only njs endpoints. This can lead to the theft of sensitive information such as IAM credentials, port scanning of internal networks, and ultimately, remote code execution and privilege escalation if combined with other vulnerabilities. This vulnerability bypasses network segmentation and firewalls designed to restrict inbound traffic, potentially exposing critical internal resources.

Recommendation

Deploy the Sigma rule Detect Nginx-UI SSRF via X-Node-ID Header to identify requests with the X-Node-ID header that may indicate SSRF attempts.
Deploy the Sigma rule Detect Nginx-UI Malicious Node Creation to detect the creation of cluster nodes with suspicious URLs (e.g., internal IPs).
Monitor network connections originating from the Nginx-UI server to internal IPs and cloud metadata endpoints using existing network monitoring tools.

Server-Side Request Forgery in mcp-data-vis

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

A server-side request forgery (SSRF) vulnerability has been identified in AlejandroArciniegas’ mcp-data-vis, specifically affecting versions up to commit de5a51525a69822290eaee569a1ab447b490746d. The vulnerability resides within the axios function in src/servers/web-scraper/server.js, a component responsible for handling HTTP requests. An attacker can exploit this flaw to force the server to make requests to arbitrary internal or external resources, potentially exposing sensitive information or allowing further exploitation of internal systems. The exploit has been publicly disclosed. The lack of versioning details due to the rolling release nature of the project makes it difficult to pinpoint specific affected releases.

Attack Chain

The attacker identifies an endpoint in mcp-data-vis that utilizes the vulnerable axios function within src/servers/web-scraper/server.js.
The attacker crafts a malicious HTTP request to the identified endpoint, embedding a URL that points to an internal resource (e.g., http://localhost:6379/) or an external resource controlled by the attacker in the request parameters.
The mcp-data-vis server, upon receiving the malicious request, processes the attacker-controlled URL using the axios function without proper validation or sanitization.
The axios function then initiates an HTTP request to the attacker-specified URL.
The server receives the response from the targeted resource.
If the target is an internal service, the response might contain sensitive data such as configuration files, internal service status, or API keys.
The mcp-data-vis application inadvertently returns the response from the internal/external resource to the attacker.
The attacker analyzes the response, extracts sensitive information, or leverages the SSRF vulnerability to further compromise the internal network or external targets.

Impact

Successful exploitation of this SSRF vulnerability could allow an attacker to read internal files, access internal services, and potentially gain unauthorized access to sensitive information. The lack of response from the project maintainers exacerbates the risk, leaving users vulnerable to attack. The specific impact will vary depending on the internal resources accessible from the mcp-data-vis server.

Recommendation

Inspect all HTTP requests handled by src/servers/web-scraper/server.js for potentially malicious URLs to detect exploitation attempts (see Sigma rule “Detect SSRF Attempts via HTTP Request Parameters”).
Deploy the Sigma rules provided to detect potential SSRF attempts targeting the mcp-data-vis application.
Monitor network connections originating from the mcp-data-vis server for unusual outbound traffic to internal or external resources (see Sigma rule “Detect Outbound Connections from Web Scraper Server”).

pygeoapi Unauthenticated SSRF Vulnerability in OGC API - Processes Subscriber

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

pygeoapi versions 0.23.0, 0.23.1, and 0.23.2 are vulnerable to Server-Side Request Forgery (SSRF). The vulnerability stems from the OGC API - Processes functionality, specifically how it handles the subscriber object during process execution. An unauthenticated attacker can exploit this flaw to send requests to internal HTTP services, potentially gaining access to sensitive information or triggering unintended actions within the internal network. This issue was patched in version 0.23.3 by disabling internal HTTP requests by default, unless explicitly allowed in the configuration. The patch includes the introduction of an allow_internal_requests directive for administrators who require this functionality. This vulnerability poses a significant risk to organizations using affected versions of pygeoapi.

Attack Chain

An unauthenticated attacker identifies a pygeoapi instance running a vulnerable version (0.23.0 - 0.23.2).
The attacker crafts a malicious OGC API process execution request.
Within the request, the attacker manipulates the subscriber object.
The subscriber object is configured to target an internal HTTP service by specifying the internal service’s address.
pygeoapi processes the request without proper validation of the subscriber object’s target.
pygeoapi initiates an HTTP request to the attacker-specified internal service.
The internal service responds to pygeoapi.
pygeoapi may then relay information received from the internal service back to the attacker, or the attacker might be able to trigger actions based on the SSRF.

Impact

Successful exploitation of this SSRF vulnerability allows an unauthenticated attacker to interact with internal HTTP services that should not be publicly accessible. This can lead to the disclosure of sensitive information, such as internal configurations, API keys, or customer data. The attacker may also be able to trigger actions on the internal services, potentially leading to service disruption or data manipulation. The severity of the impact depends on the nature and security posture of the internal services exposed by this vulnerability.

Recommendation

Upgrade to pygeoapi version 0.23.3 or later to remediate CVE-2026-42352.
Apply the provided patch 3a63f5b0cc6275e3ae0edb47726b13a43cdd90ef if upgrading is not immediately feasible.
If upgrading or patching is not immediately feasible, disable process-based resources in the pygeoapi configuration as a workaround.

JoeCastrom mcp-chat-studio Server-Side Request Forgery Vulnerability

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

A server-side request forgery (SSRF) vulnerability has been identified in JoeCastrom’s mcp-chat-studio, affecting versions up to 1.5.0. The vulnerability resides within the LLM Models API, specifically in the server/routes/llm.js file. An attacker can remotely exploit this flaw by manipulating the req.query.base_url argument. This allows the attacker to make arbitrary HTTP requests from the server, potentially leading to information disclosure, internal service access, or other malicious activities. The vulnerability is publicly known and actively discussed, increasing the risk of exploitation. The vendor was notified but has not yet responded.

Attack Chain

The attacker identifies an mcp-chat-studio instance running a vulnerable version (<= 1.5.0).
The attacker crafts a malicious HTTP request targeting the /routes/llm.js endpoint.
Within the request, the attacker manipulates the req.query.base_url parameter to point to an attacker-controlled server or an internal resource.
The mcp-chat-studio server processes the request and, due to the SSRF vulnerability, makes an HTTP request to the URL specified in the req.query.base_url parameter.
If the attacker controls the base_url, they can intercept the request and potentially steal sensitive information.
If the base_url points to an internal resource, the attacker may gain unauthorized access to internal services or data.
The attacker analyzes the response from the manipulated request to gather information about the internal network or services.
The attacker leverages the gained information to further compromise the mcp-chat-studio instance or the internal network.

Impact

Successful exploitation of this SSRF vulnerability can allow an attacker to read sensitive data from internal services, potentially leading to credential theft or data exfiltration. It can also be used to pivot to other internal systems, causing a wider breach. The lack of vendor response increases the risk, as no patch or mitigation is currently available. The CVSS v3.1 base score is 7.3, indicating a high severity vulnerability.

Recommendation

Monitor web server logs for requests to /routes/llm.js containing suspicious URLs in the req.query.base_url parameter using the provided Sigma rule.
Implement network segmentation to limit the impact of potential SSRF attacks by restricting access from the mcp-chat-studio server to internal resources.
Since no patch is available, consider applying a web application firewall (WAF) rule to filter requests to /routes/llm.js that contain potentially malicious URLs in the req.query.base_url parameter.

ChatGPTNextWeb NextChat SSRF Vulnerability (CVE-2026-7178)

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

A server-side request forgery (SSRF) vulnerability, identified as CVE-2026-7178, affects ChatGPTNextWeb NextChat versions up to 2.16.1. The vulnerability resides in the storeUrl function within the app/api/artifacts/route.ts file, specifically related to the Artifacts Endpoint component. An attacker can manipulate the ID argument to force the server to make requests to arbitrary internal or external resources. This issue was reported to the project maintainers but remains unpatched. The availability of a public exploit increases the risk of active exploitation. This vulnerability allows attackers to bypass network access controls, potentially accessing sensitive data or internal services.

Attack Chain

The attacker identifies an instance of ChatGPTNextWeb NextChat running a version up to 2.16.1.
The attacker crafts a malicious HTTP request targeting the /api/artifacts endpoint.
The request includes a manipulated ID parameter within the request body or query string of the HTTP request to storeUrl function.
The storeUrl function, lacking proper input validation, uses the attacker-supplied ID to construct a URL.
The NextChat server initiates an HTTP request to the attacker-controlled URL.
Depending on the crafted URL, the server may access internal resources, external websites, or cloud services.
The server receives the response from the target resource.
The attacker leverages the SSRF vulnerability to read sensitive internal data, interact with internal services, or potentially pivot to other internal systems.

Impact

Successful exploitation of CVE-2026-7178 allows an attacker to perform unauthorized actions within the network where the NextChat server is deployed. This may include reading internal files, accessing other internal applications or services, or potentially escalating privileges if the targeted internal service has its own vulnerabilities. Given the publicly available exploit, organizations using vulnerable versions of NextChat are at increased risk.

Recommendation

Upgrade ChatGPTNextWeb NextChat to a version greater than 2.16.1 to remediate CVE-2026-7178.
Deploy the Sigma rule “NextChat SSRF Attempt” to detect suspicious requests to the /api/artifacts endpoint with potentially malicious ID parameters.
Monitor web server logs for outbound connections originating from the NextChat server to unusual or internal IP addresses and domains.
Implement strict input validation on the ID parameter of the storeUrl function if immediate patching is not possible.

WeKan SSRF Vulnerability in Webhook Integration

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

WeKan, a popular open-source kanban board application, is susceptible to a server-side request forgery (SSRF) vulnerability in versions prior to 8.35. This flaw resides in the handling of webhook integration URLs, where insufficient validation allows attackers to specify arbitrary internal network addresses as webhook targets. An attacker with the ability to create or modify integrations within WeKan can exploit this vulnerability. By crafting a malicious webhook URL, they can force the WeKan server to issue HTTP POST requests to attacker-controlled internal targets, potentially exposing sensitive internal resources and data. This vulnerability can also be chained with another flaw to overwrite arbitrary comment text without authorization checks, increasing the potential for data manipulation and unauthorized access.

Attack Chain

An attacker gains access to a WeKan account with privileges to create or modify integrations.
The attacker navigates to the webhook integration settings within a WeKan board.
The attacker enters a malicious URL pointing to an internal server (e.g., http://internal.example.com/admin) in the webhook URL field.
The attacker triggers an event on the WeKan board (e.g., creating a new card, moving a card).
The WeKan server, without proper validation, sends an HTTP POST request to the attacker-specified internal URL.
The internal server receives the request, potentially revealing sensitive information about the WeKan board and its contents.
The attacker exploits response handling to overwrite arbitrary comment text without authorization checks.
The attacker gains unauthorized access to internal resources or sensitive data through the SSRF vulnerability.

Impact

Successful exploitation of this SSRF vulnerability allows attackers to potentially access internal network resources that are otherwise inaccessible from the outside. This could lead to the disclosure of sensitive information, such as internal application configurations, database credentials, or other confidential data. Furthermore, the ability to overwrite arbitrary comment text can be used to deface WeKan boards, spread misinformation, or disrupt normal operations. The CVSS v3.1 base score for this vulnerability is 8.5, indicating a high severity risk.

Recommendation

Upgrade WeKan to version 8.35 or later to remediate CVE-2026-41455.
Implement network segmentation to limit the impact of potential SSRF attacks.
Deploy the Sigma rule DetectSuspiciousWekanWebhookUrls to identify attempts to exploit this vulnerability by monitoring for requests to internal IP addresses or unusual domains.
Enable web server logging for the WeKan instance to capture details of outgoing HTTP requests.

TencentCloudBase CloudBase-MCP Server-Side Request Forgery Vulnerability (CVE-2026-7221)

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

A server-side request forgery (SSRF) vulnerability has been identified in TencentCloudBase CloudBase-MCP, affecting versions up to 2.17.0. The vulnerability resides in the openUrl function within the mcp/src/interactive-server.ts file. This flaw enables a remote attacker to manipulate the req.body.url argument passed to the open-url API Endpoint, forcing the server to make requests to arbitrary internal or external resources. Successful exploitation could lead to information disclosure, internal network scanning, or denial-of-service. The vulnerability is publicly known and actively exploitable. Users are advised to upgrade to version 2.17.1, which includes a patch (identified as 3f678a1e7bd400cd76469d61024097d4920dc6b5) to address this issue.

Attack Chain

Attacker identifies a CloudBase-MCP instance running a vulnerable version (<= 2.17.0).
Attacker crafts a malicious HTTP request targeting the openUrl API endpoint.
The malicious request includes a req.body.url parameter containing a URL pointing to an internal resource (e.g., http://localhost:8080/admin) or an external server controlled by the attacker.
The CloudBase-MCP server, without proper validation, processes the request and attempts to open the URL specified in req.body.url.
If the URL points to an internal resource, the server retrieves the content of that resource and potentially exposes it to the attacker.
If the URL points to an external server, the server makes an HTTP request to the attacker’s server, potentially leaking sensitive information like internal IP addresses or API keys.
The attacker analyzes the response from the server to gather information about the internal network or the CloudBase-MCP instance.
The attacker leverages the gathered information to further compromise the CloudBase-MCP instance or the internal network.

Impact

Successful exploitation of this SSRF vulnerability can allow attackers to read sensitive information from internal services, bypass firewall restrictions, and potentially gain unauthorized access to internal resources. This could lead to the disclosure of confidential data, compromise of internal systems, and further attacks on the organization’s infrastructure. Although the number of victims isn’t specified, any unpatched CloudBase-MCP instance is vulnerable.

Recommendation

Upgrade TencentCloudBase CloudBase-MCP to version 2.17.1 or later to apply the patch (3f678a1e7bd400cd76469d61024097d4920dc6b5) that fixes CVE-2026-7221.
Implement input validation and sanitization on the req.body.url parameter to prevent manipulation by attackers.
Monitor web server logs for suspicious requests to the openUrl API endpoint with unusual or internal URLs, and deploy the Sigma rules below.

RustFS Notification Target Admin API Authorization Bypass

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

A critical authorization bypass vulnerability exists in RustFS versions 0.0.2 and earlier, specifically within the notification target admin API endpoints (rustfs/src/admin/handlers/event.rs). These endpoints lack proper admin-action authorization, failing to call validate_admin_request. This oversight allows a non-admin user to overwrite admin-defined notification targets by name. Successful exploitation enables attackers to intercept events intended for legitimate administrators and evade audit logs. The attacker gains the ability to redirect bucket events to an attacker-controlled endpoint, potentially exfiltrating sensitive information like object keys, bucket names, user identities, and request metadata. This issue was patched in RustFS version 1.0.0-alpha.94.

Attack Chain

An attacker gains access to a RustFS account with non-admin (readonly) privileges.
The attacker crafts a PUT request to one of the notification target admin API endpoints (e.g., to create or update a notification target).
The request bypasses the intended admin authorization checks due to the missing validate_admin_request call.
The attacker overwrites an existing, admin-defined notification target, replacing the legitimate endpoint with an attacker-controlled URL.
An S3 bucket event (e.g., object creation) occurs, triggering the notification system.
RustFS sends an HTTP request containing event data to the attacker-controlled URL.
The attacker captures the exfiltrated event data, including object keys, bucket names, user identities, and request metadata.
The attacker can also delete unbound targets or silently redirect events from bound targets, further evading audit detection.

Impact

Successful exploitation of this vulnerability allows attackers to intercept sensitive data related to bucket events, potentially leading to data breaches and unauthorized access to resources. The vulnerability affects RustFS instances where non-admin users have access to the system, enabling them to manipulate notification targets intended for administrative purposes. The attacker can redirect events to an external endpoint, exposing potentially thousands of events containing sensitive information. The ability to overwrite existing notification targets allows for a persistent compromise until the vulnerability is patched.

Recommendation

Upgrade RustFS to version 1.0.0-alpha.94 or later to patch the vulnerability.
Deploy the Sigma rule “Detect RustFS Notification Target Manipulation” to identify attempts to modify notification targets via the admin API.
Monitor web server logs (cs-uri-query, cs-method) for unusual activity related to the notification target admin API endpoints to detect potential exploitation attempts.
Implement strict access control policies to limit non-admin user access to sensitive API endpoints and resources.

BidingCC BuildingAI SSRF Vulnerability (CVE-2026-7065)

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

BidingCC BuildingAI, up to version 26.0.1, is vulnerable to a server-side request forgery (SSRF) attack. The vulnerability resides within the uploadRemoteFile function located in packages/core/src/modules/upload/services/file-storage.service.ts. An attacker can remotely manipulate the url argument passed to this function to force the server to make requests to arbitrary internal or external resources. This vulnerability has been publicly disclosed and is considered exploitable. The vendor was notified of the issue, but has not responded. Successful exploitation can lead to information disclosure, internal service compromise, or other malicious activities.

Attack Chain

Attacker identifies a BidingCC BuildingAI instance running a vulnerable version (<= 26.0.1).
Attacker crafts a malicious URL containing the address of an internal resource or external server.
Attacker calls the uploadRemoteFile API endpoint, providing the crafted URL as the url argument.
The uploadRemoteFile function, without proper validation, uses the provided URL to initiate a request.
The BuildingAI server makes an HTTP request to the attacker-specified URL.
If the URL points to an internal resource, the server retrieves sensitive data from that resource.
If the URL points to an external server controlled by the attacker, the server may leak internal information (e.g., internal IP addresses) or be used for further attacks.
The attacker receives the response from the manipulated request, achieving information disclosure or a foothold for further exploitation.

Impact

Successful exploitation of the SSRF vulnerability (CVE-2026-7065) in BidingCC BuildingAI can lead to the exposure of sensitive internal information, such as configuration files, internal service endpoints, and potentially database credentials. This information can be leveraged to further compromise the BuildingAI instance or other internal systems. The impact is significant due to the potential for lateral movement and privilege escalation within the affected organization’s infrastructure. The lack of vendor response exacerbates the risk.

Recommendation

Deploy the Sigma rule provided below to detect exploitation attempts against the uploadRemoteFile endpoint (Log source: webserver).
Implement strict input validation and sanitization on the url parameter of the uploadRemoteFile function to prevent arbitrary URL requests (CVE-2026-7065).
Consider restricting outbound network access from the BuildingAI server to only necessary resources to limit the impact of successful SSRF attacks.
Monitor web server logs for unusual requests originating from the BuildingAI server to detect potential SSRF activity.

Algovate xhs-mcp Server-Side Request Forgery Vulnerability

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

A server-side request forgery (SSRF) vulnerability has been identified in Algovate xhs-mcp version 0.8.11. The vulnerability resides within the xhs_publish_content function of the MCP Interface component, specifically concerning the handling of the media_paths argument. This flaw allows a remote attacker to potentially manipulate server-side requests, gaining unauthorized access to internal resources or services. This vulnerability matters to defenders because a successful SSRF attack can lead to sensitive data exposure, internal network reconnaissance, or even further exploitation of other internal systems. The affected version is 0.8.11.

Attack Chain

Attacker identifies the vulnerable xhs_publish_content function in src/server/mcp.server.ts.
Attacker crafts a malicious request targeting the media_paths argument.
The malicious request contains a URL pointing to an internal resource or service.
The server processes the request without proper validation of the media_paths value.
The server initiates a request to the attacker-specified internal resource.
The server receives the response from the internal resource.
The server may display or utilize the data obtained from the internal resource.
Attacker gains access to sensitive information or can potentially use the server as a proxy to interact with other internal systems.

Impact

Successful exploitation of this SSRF vulnerability (CVE-2026-7417) could allow an attacker to read internal files, access internal services, or potentially pivot to other internal systems. This could result in the disclosure of sensitive data, compromise of internal infrastructure, or further exploitation. The exact scope of the impact depends on the internal resources accessible to the vulnerable server.

Recommendation

Apply any available patches or updates for Algovate xhs-mcp to address CVE-2026-7417.
Implement strict input validation and sanitization for the media_paths argument in the xhs_publish_content function.
Monitor web server logs for suspicious requests containing internal IP addresses or unusual hostnames in the media_paths parameter. Implement the “Detect Suspicious SSRF Attempt” Sigma rule to assist with detection.
Consider deploying network segmentation and access controls to limit the impact of potential SSRF attacks.