Unauthenticated Blind SSRF in Evershop Image Processing Middleware

The vulnerability resides in the @evershop/evershop package, specifically within the route handling logic for image retrieval and processing. Modern e-commerce platforms frequently implement dynamic image resizing and optimization endpoints to serve assets appropriate for different device viewports. In Evershop, the GET /images endpoint serves this function, accepting a src query parameter intended to point to product images.

However, the application lacks sufficient validation on the input provided to the src parameter. It implicitly trusts user-supplied URLs, passing them to a server-side HTTP client to fetch the resource. This behavior creates a Server-Side Request Forgery (SSRF) condition. Because the application processes the request and typically returns the image data (or an error) rather than the raw HTTP response body of the target, this is classified as a Blind SSRF.

While the attacker cannot directly read the content of the internal response in many cases, they can infer the state of internal ports and services based on side channels. These side channels include response time (latency analysis), HTTP status codes (e.g., a 200 OK from the proxy vs a 500 Internal Error), and error messages generated by the application when the backend fetch fails.

The root cause of CVE-2025-67427 is Improper Input Validation (CWE-20) leading to SSRF (CWE-918). The vulnerable code path accepts the src parameter from the HTTP query string and uses it directly as the target for an outbound network request without ensuring the destination is an authorized resource.

In a secure implementation, an image proxy should strictly allowlist domains (e.g., only the store's own domain and trusted CDNs) or sanitize the input to ensure it represents a relative path on the local filesystem. Evershop's implementation permitted absolute URIs (starting with http:// or https://).

When the server receives a request like /images?src=http://127.0.0.1:22, the NodeJS backend attempts to establish a TCP connection to localhost on port 22. If the port is open, the connection succeeds (likely followed by a protocol mismatch error since SSH is not HTTP). If the port is closed, the connection is refused immediately. This discrepancy in connection handling leaks information about the internal network topology to the attacker.

The vulnerability exists because the image middleware acts as an open proxy. Below is a conceptual representation of the vulnerable logic flow versus the remediation pattern.

Vulnerable Logic (Conceptual):

// Middleware handling /images
app.get('/images', async (req, res) => {
  const imageUrl = req.query.src;
  
  // VULNERABILITY: No validation of the protocol or hostname
  // The server blindly fetches whatever URL is provided
  try {
    const response = await fetch(imageUrl);
    const buffer = await response.buffer();
    res.set('Content-Type', response.headers.get('content-type'));
    res.send(buffer);
  } catch (error) {
    res.status(500).send('Error fetching image');
  }
});

Remediation Pattern:

The fix involves validating that the src is either a relative path or belongs to a strict allowlist of domains.

app.get('/images', async (req, res) => {
  const imageUrl = req.query.src;
 
  // FIX: Parse the URL and validate the hostname
  try {
    const parsedUrl = new URL(imageUrl, 'http://localhost'); // Handle relative paths
    
    const allowedDomains = ['evershop.io', 'cdn.trusted.com'];
    const isRelative = !imageUrl.startsWith('http');
    
    if (!isRelative && !allowedDomains.includes(parsedUrl.hostname)) {
      return res.status(403).send('Forbidden: External domain not allowed');
    }
 
    // Proceed with fetch only if validation passes
    // ...
  } catch (e) {
    return res.status(400).send('Invalid URL');
  }
});

The actual fix in Evershop likely enforces that the requested resource resides within the expected application storage directories or strictly limits the protocol and host to prevent arbitrary outbound connections.

An attacker can exploit this vulnerability to perform internal reconnaissance or Denial of Service.

Scenario 1: Internal Port Scanning

The attacker iterates through common internal ports to map the infrastructure.

GET /images?src=http://127.0.0.1:6379 HTTP/1.1
Host: target-evershop.com

If the server responds quickly with a parsing error (e.g., "Image format not recognized"), it implies a connection was made (Port Open). If the request hangs until a timeout or returns a "Connection Refused" error, the port is likely closed. This allows mapping of Redis, SQL, or other internal services.

Scenario 2: Cloud Metadata Exfiltration

If the Evershop instance is hosted on AWS, GCP, or Azure, the attacker may target the link-local metadata address.

GET /images?src=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: target-evershop.com

While the attacker might not see the JSON response directly due to the blind nature (unless the application blindly echoes the text response assuming it's an image), this request can still trigger security alerts or, in poorly configured environments where the response is reflected in error logs or partially rendered, leak credentials.

Scenario 3: Denial of Service (DoS)

The attacker forces the server to download extremely large files or connect to a "tarpit" service that keeps the connection open indefinitely. This exhausts the Node.js event loop or available worker threads, rendering the e-commerce site unresponsive to legitimate customers.

The impact of CVE-2025-67427 is classified as Medium (CVSS 6.5) primarily due to its Blind nature, but the real-world risk depends heavily on the deployment environment.

Confidentiality: The primary risk is the exposure of internal network topology. If the application runs in a cloud environment (AWS, Azure, GCP) with an overly permissive Instance Metadata Service (IMDSv1), the vulnerability could escalate to full compromise by retrieving IAM credentials.

Integrity: Attackers can issue GET requests to internal APIs. If internal services (like Solr, Elasticsearch, or Redis) are configured without authentication on the localhost interface—a common practice—an attacker might be able to modify data or trigger administrative actions via URL parameters.

Availability: The vulnerability enables trivial Denial of Service attacks. By directing the server to fetch /dev/zero (if file protocols were supported) or large external files, attackers can saturate the server's bandwidth and memory.