Threats affecting pkg:github/evershopcommerce/evershop

EverShop versions from 1.2.2 up to but not including 2.2.1 have a missing authorization vulnerability in the customer address API. This flaw allows unauthenticated attackers who know valid customer and address UUIDs to add, modify, or delete other customers' saved shipping addresses via POST, PATCH, or DELETE requests to the /api/customers/:customer_id/addresses endpoint. The vulnerability is fixed in version 2.2.1.

EverShop is a TypeScript-first eCommerce platform. Versions prior to 2.1.1 have a vulnerability in the "Forgot Password" functionality. When specifying a target email address, the API response returns the password reset token. This allows an attacker to take over the associated account. Version 2.1.1 fixes the issue.

A Denial of Service (DoS) vulnerability in evershop 2.1.0 and prior allows unauthenticated attackers to exhaust the application server's resources via the "GET /images" API. The application fails to limit the height of the use-element shadow tree or the dimensions of pattern tiles during the processing of SVG files, resulting in unbounded resource consumption and system-wide denial of service.

CVE-2025-67427 is a Blind Server-Side Request Forgery (SSRF) vulnerability affecting evershop version 2.1.0 and earlier. It allows unauthenticated attackers to exploit the "GET /images" API endpoint by manipulating the "src" query parameter to force the server to initiate arbitrary HTTP or HTTPS requests. This occurs due to insufficient validation of the input, enabling attackers to make requests to internal or external network resources without authentication or user interaction. The vulnerability has a CVSS score of 6.5, indicating medium severity, primarily impacting confidentiality and integrity but not availability. No known exploits are currently in the wild, and no official patches have been released yet. European organizations using evershop 2.1.

EverShop 2.0.1 allows a remote unauthenticated attacker to upload arbitrary files and create directories via the /api/images endpoint. The endpoint is accessible without authentication by default, and server-side validation of uploaded files is insufficient. This can be abused to upload arbitrary content (including non-image files) which could impersonate user/admin login panels (exfiltrating credentials) and to perform a denial-of-service attack by exhausting disk space.