A sensitive data exposure vulnerability in the UPS Shipping Module (upsshipping) for PrestaShop, in all known versions up to and including 2.4.0, allows remote unauthenticated attackers to retrieve XML log files containing UPS API credentials, shipper account numbers and customer personal data through predictable URLs in the modules/upsshipping/logs/ directory. The vendor (Agence Web 360) is defunct and no patch will be released.

Summary

  • CVE ID: CVE-2026-39079
  • Published at: 2026-05-18
  • Advisory source: labs.esokia.com (esokia.com)
  • Platform: PrestaShop
  • Product: upsshipping
  • Impacted release: all versions (through at least 2.4.0) - no fixed version, vendor defunct
  • Product author: Agence Web 360
  • Weakness: CWE-552 (primary), CWE-532 (contributing), CWE-295 (secondary)
  • Severity: high (8.6)

Description

The modules/upsshipping/logs/ directory ships without any access control mechanism. There is no .htaccess file anywhere in the module, and the logs/ directory is the only subdirectory without the blank index.php guard. As a result, any file written to that directory is directly reachable over HTTP without authentication.

Filenames written by the module follow a deterministic pattern based on time():

UPSRatingApi-request-{unix_timestamp}.xml
UPSShippingApi-request-{unix_timestamp}.xml
UPSTrackingApi-request-{unix_timestamp}.xml

(and their -response- counterparts). Enumeration of historical files is therefore trivial.

In lib/UPSBaseApi.php, the catch (Exception $e) block of the SOAP call writes the full request and response to disk unconditionally, regardless of the $this->log debug flag. Every UPS API error (invalid tracking number, timeout, validation rejection, and so on) leaves a record on disk containing the full SOAP envelope, including the UPSSecurity header with the merchant’s UPS API credentials in clear text.

The clearLogs() routine intended to remove files older than 30 minutes does not run reliably. On a confirmed affected instance, the directory contained 2,381,841 XML files (~ 8.7 GB) spanning February 2023 to April 2026.

Example of the data exposed in a single request file (values redacted):

<ns3:Username>XXXXXX</ns3:Username>
<ns3:Password>XXXXXX</ns3:Password>
<ns3:AccessLicenseNumber>XXC2BB3311XXXXXX</ns3:AccessLicenseNumber>
<ns2:ShipperNumber>3XYXXX</ns2:ShipperNumber>
<ns2:TaxIdentificationNumber>FR00819XXXX</ns2:TaxIdentificationNumber>
<ns2:Name>Customer Name</ns2:Name>
<ns2:Phone><ns2:Number>460768XXXXXX</ns2:Number></ns2:Phone>
<ns2:AddressLine>Västervägen XX</ns2:AddressLine>
<ns2:City>Vindeln</ns2:City>
<ns2:PostalCode>922 31</ns2:PostalCode>
<ns2:CountryCode>SE</ns2:CountryCode>

A secondary weakness exists in lib/UPSLocatorApi.php, where TLS certificate validation is disabled (CURLOPT_SSL_VERIFYPEER=0, CURLOPT_SSL_VERIFYHOST=0), enabling man-in-the-middle interception of Locator API traffic (CWE-295).

The vendor (Agence Web 360, Golfe-Juan, France) is confirmed defunct: the domain agence-web-360.com is listed for sale, the Facebook page has been inactive since 2016, and prior contact attempts over the past years received no response. The module is no longer maintained and no fix will be released.

CVSS base metrics

  • Attack vector: network
  • Attack complexity: low
  • Privilege required: none
  • User interaction: none
  • Scope: changed
  • Confidentiality: high
  • Integrity: none
  • Availability: none

Vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

The Scope is rated as Changed because the exposed credentials and technical data belong to a separate security authority (the merchant’s UPS account / UPS API platform), alongside customer personal data subject to GDPR.

Possible malicious usage

  • Retrieve valid UPS API credentials (Username, Password, AccessLicenseNumber) of the affected merchant
  • Retrieve the UPS shipper account number and use it to create fraudulent shipments billed to the merchant’s UPS account
  • Retrieve customer personally identifiable information (full names, postal addresses, phone numbers, order references)
  • Trigger GDPR breach-notification obligations for the affected merchant

Patch

No vendor patch will be released. The vendor is defunct and unreachable.

The only durable remediation is to fully remove the module from the PrestaShop installation. Disabling the module from the back office is not sufficient: the files remain on disk and the logs/ directory remains reachable over HTTP. The module must be uninstalled and the modules/upsshipping/ directory deleted from the filesystem.

As a temporary holding measure only, while a migration to a maintained shipping module is in progress, merchants can block public access to the logs directory at the web-server level.

Apache (modules/upsshipping/logs/.htaccess):

# Apache 2.4+
<IfModule mod_authz_core.c>
    Require all denied
</IfModule>

# Apache 2.2 fallback
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
</IfModule>

Options -Indexes -ExecCGI
<FilesMatch ".*">
    SetHandler default-handler
</FilesMatch>

nginx (inside the server block):

location ^~ /modules/upsshipping/logs/ {
    deny all;
    return 403;
}

In all cases, the existing XML log files should be purged, the UPS API credentials rotated (UPS account password and AccessLicenseNumber), and UPS account activity reviewed for unauthorized shipments. GDPR breach-notification obligations must be assessed.

Other recommendations

  • It’s highly recommended to fully remove the module since no fix will ever be released by the vendor. If the module is still required, migrate to a maintained alternative as soon as possible.
  • Inventory all installed modules and identify those whose vendor is no longer active. A module from a defunct vendor will never receive a security fix and should be removed, not merely disabled.
  • Restrict direct HTTP access to module subdirectories that should never be web-reachable (logs/, cache/, tmp/, tests/, exports/, etc.) at the web-server level, as a defense-in-depth measure independent of module-shipped .htaccess or index.php guards.
  • Review the use of verbose logging in production. Any logging mechanism that writes credentials, tokens or PII to disk should be disabled, regardless of vendor “debug flags”. When logs are unavoidable, store them outside the web root and use unpredictable filenames.
  • Activate OWASP CRS rules on your WAF to block suspicious requests targeting common module log/debug paths and to rate-limit enumeration attempts.

Timeline

Date Action
2026-03-23 Vulnerability discovered during a security audit
2026-04-01 CVE requested from MITRE (vendor notification not possible, agency defunct)
2026-05-16 MITRE assigned CVE-2026-39079
2026-05-18 Publication of the CVE by Esokia with the support of Profileo.com / 772424.com
2026-05-18 Publication on Friends-Of-Prestashop Security Advisories