Skip to main content

Shopware CVE-2026-48013

MEDIUM
Server-Side Request Forgery (SSRF) (CWE-918)
2026-06-04 https://github.com/shopware/shopware GHSA-gq96-5pfx-f4vc
4.1
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
4.1 MEDIUM
AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
High
User Interaction
None
Scope
Changed
Confidentiality
Low
Integrity
None
Availability
None

Lifecycle Timeline

3
Source Code Evidence Fetched
Jun 04, 2026 - 20:04 vuln.today
Analysis Generated
Jun 04, 2026 - 20:04 vuln.today
CVE Published
Jun 04, 2026 - 19:36 nvd
MEDIUM 4.1

DescriptionGitHub Advisory

Summary

The /api/_action/media/external-link endpoint allows authenticated admin users to make server-side HTTP HEAD requests to arbitrary internal IP addresses. While the parallel uploadFromURL flow validates target IPs against private/reserved ranges via FileUrlValidator, the linkURL flow only performs a URL format check (regex for http:// or https:// prefix), allowing SSRF to internal network services and cloud metadata endpoints.

Details

The vulnerability is an inconsistency between two URL-handling flows in MediaUploadService.

Vulnerable path (external-link):

MediaUploadV2Controller::externalLink() at src/Core/Content/Media/Api/MediaUploadV2Controller.php:66 takes a user-supplied url parameter and passes it to MediaUploadService::linkURL() at src/Core/Content/Media/Upload/MediaUploadService.php:134.

linkURL() calls getContentSizeFromValidExternalUrl($url) at line 159, which only validates via validateExternalUrl():

php
// src/Core/Content/Media/Upload/MediaUploadService.php:207-212
public static function validateExternalUrl(string $url): void
{
    if (!preg_match('/^https?:\/\/.+/', $url)) {
        throw MediaException::invalidUrl($url);
    }
}

Then makes a server-side HEAD request with no IP filtering:

php
// src/Core/Content/Media/Upload/MediaUploadService.php:292-300
private function getContentSizeFromValidExternalUrl(string $url): int
{
    $this->validateExternalUrl($url);

    $headers = $this->httpClient->request('HEAD', $url)->getHeaders();
    if (!\array_key_exists('content-length', $headers)) {
        throw MediaException::fileNotFound($url);
    }

    return (int) $headers['content-length'][0];
}

Protected path (upload_by_url):

In contrast, uploadFromURL uses FileFetcher::fetchFromURL() which calls FileUrlValidator::isValid():

php
// src/Core/Content/Media/File/FileFetcher.php:64
if ($this->enableUrlValidation && !$this->fileUrlValidator->isValid($url)) {
    throw MediaException::illegalUrl($url);
}

FileUrlValidator::isValid() resolves the hostname via gethostbyname() and validates the IP against private and reserved ranges using filter_var() with FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE. This protection is entirely absent from the linkURL flow.

Impact

An authenticated admin user can:

  1. Probe cloud metadata services - HEAD requests to 169.254.169.254 reveal whether cloud metadata endpoints exist and leak content-length values
  2. Scan internal networks - Differentiate open/closed/filtered ports on internal hosts (10.x, 172.16.x, 192.168.x) based on response timing and error types
  3. Leak internal service information - The fileSize field stored in the database reflects the content-length header from internal services
  4. Redirect-based escalation - Symfony HttpClient follows redirects by default (max_redirects=20), allowing an attacker-controlled external server to redirect the HEAD request to arbitrary internal destinations

Impact is limited to information disclosure via HEAD requests. The admin authentication requirement (PR:H) reduces exploitability, but in multi-tenant or compromised-credential scenarios this allows network reconnaissance from the server's perspective.

Recommended Fix

Apply FileUrlValidator to the linkURL flow, consistent with the uploadFromURL flow. In MediaUploadService:

php
// src/Core/Content/Media/Upload/MediaUploadService.php

// Add constructor dependency:
private readonly FileUrlValidatorInterface $fileUrlValidator;

// In getContentSizeFromValidExternalUrl(), add IP validation:
private function getContentSizeFromValidExternalUrl(string $url): int
{
    $this->validateExternalUrl($url);

    if (!$this->fileUrlValidator->isValid($url)) {
        throw MediaException::illegalUrl($url);
    }

    $headers = $this->httpClient->request('HEAD', $url)->getHeaders();
    if (!\array_key_exists('content-length', $headers)) {
        throw MediaException::fileNotFound($url);
    }

    return (int) $headers['content-length'][0];
}

Additionally, consider setting max_redirects: 0 on the HttpClient request to prevent redirect-based SSRF bypasses.

AnalysisAI

Server-side request forgery in Shopware's media subsystem allows authenticated admin users to make arbitrary HTTP HEAD requests to internal network addresses and cloud metadata endpoints via the /api/_action/media/external-link endpoint. The root cause is an inconsistency between two URL-handling flows in MediaUploadService: the uploadFromURL flow correctly validates resolved IPs against private/reserved ranges, while the linkURL flow only checks that the URL begins with http:// or https://. Exploiting this, an admin can probe cloud metadata services, enumerate internal ports, and leak content-length values from internal services; no public exploit has been identified at time of analysis, and a vendor-released patch exists in version 6.7.10.1.

Technical ContextAI

Shopware is a PHP-based e-commerce platform built on Symfony. The affected packages are composer/shopware/core and composer/shopware/platform (CPE: pkg:composer/shopware_core, pkg:composer/shopware_platform). The vulnerability is classified as CWE-918 (Server-Side Request Forgery). The root cause is a missing security control: MediaUploadV2Controller::externalLink() (MediaUploadV2Controller.php:66) accepts a url parameter and routes it through MediaUploadService::linkURL() (MediaUploadService.php:134), which calls validateExternalUrl() - a static method that only applies a regex check for http:// or https:// prefixes. The sibling flow uploadFromURL uses FileFetcher::fetchFromURL(), which delegates to FileUrlValidator::isValid(), resolving the hostname via gethostbyname() and filtering against private/reserved IP ranges using filter_var() with FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE. This protection layer is entirely absent from the linkURL code path. Additionally, Symfony HttpClient follows up to 20 redirects by default, meaning an attacker-controlled external server can redirect HEAD requests to arbitrary internal destinations, bypassing hostname-level controls.

RemediationAI

Upgrade shopware/core and shopware/platform to version 6.7.10.1 or later, which aligns the external-link endpoint's URL validation with the existing upload-from-url flow by applying FileUrlValidator to the linkURL code path. The static MediaUploadService::validateExternalUrl() method is deprecated in this release in favor of the new assertValidExternalUrl() method; see UPGRADE-6.8.md for migration details. The vendor release is available at https://github.com/shopware/shopware/releases/tag/v6.7.10.1 and the advisory is at https://github.com/shopware/shopware/security/advisories/GHSA-gq96-5pfx-f4vc. If immediate patching is not possible, a compensating control is to restrict access to the /api/_action/media/external-link endpoint at the web server or API gateway level for all but trusted admin IP ranges, reducing the network attack surface despite the PR:H requirement. Additionally, consider configuring the Symfony HttpClient instance used in this flow with max_redirects: 0 to prevent redirect-based SSRF bypasses, at the trade-off of breaking any legitimate media linking workflows that rely on URL redirects.

More in PHP

View all
CVE-2012-1823 CRITICAL POC
9.8 May 11

sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not

CVE-2016-1555 CRITICAL POC
9.8 Apr 21

(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear

CVE-2024-11680 CRITICAL POC
9.8 Nov 26

ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C

CVE-2025-49113 CRITICAL POC
9.9 Jun 02

Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au

CVE-2017-9841 CRITICAL POC
9.8 Jun 27

Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c

CVE-2025-0108 HIGH POC
8.8 Feb 12

Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers

CVE-2021-25298 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2021-25296 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2013-4983 CRITICAL POC
10.0 Sep 10

The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows

CVE-2023-6553 CRITICAL POC
9.8 Dec 15

The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1

CVE-2024-46506 CRITICAL POC
10.0 May 13

NetAlertX (formerly PiAlert) versions 23.01.14 through 24.x before 24.10.12 allow unauthenticated command injection thro

CVE-2024-8353 CRITICAL POC
9.8 Sep 28

The GiveWP - Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to PHP Object Injection in all

Share

CVE-2026-48013 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy