CVE-2025-4602: Store Manager for WooCommerce File Read Flaw

CVE-2025-4602 Overview

The eMagicOne Store Manager for WooCommerce plugin for WordPress contains an arbitrary file read vulnerability affecting all versions up to and including 1.2.5. The flaw resides in the get_file() function, which fails to validate file path inputs before returning their contents. Unauthenticated attackers can read arbitrary files on the underlying server, exposing configuration files, credentials, and other sensitive data.

Exploitation requires the plugin to be running with the default credentials of 1:1, or for the attacker to otherwise possess valid credentials. WordPress sites that never changed the default password remain exposed by default. The vulnerability is tracked under [CWE-73: External Control of File Name or Path].

Critical Impact

Unauthenticated attackers can read any file readable by the web server process, including wp-config.php, which contains database credentials and authentication secrets.

Affected Products

• eMagicOne Store Manager for WooCommerce plugin for WordPress
• All versions up to and including 1.2.5
• WordPress installations using the default 1:1 plugin credentials

Discovery Timeline

• 2025-05-24 - CVE-2025-4602 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2025-4602

Vulnerability Analysis

The vulnerability is an arbitrary file read flaw in the Store Manager Connector plugin code. The get_file() function accepts a user-supplied file path parameter and returns the file contents in the HTTP response. Source inspection of class-emosmconnectorcommon.php and class-emosmcwoocommerceoverrider.php shows the handler reads the requested file without restricting access to a permitted directory or sanitizing path traversal sequences.

Because the plugin ships with default credentials of 1:1, any administrator who installs the plugin and does not change the password effectively leaves the endpoint unauthenticated from an attacker's perspective. An attacker who reaches the plugin endpoint authenticates with the default values and immediately receives file read access.

Root Cause

The root cause is missing path validation and reliance on a static default credential pair. The get_file() handler trusts attacker-controlled input as a filesystem path, and the plugin distributes a hardcoded default username and password (1:1) that many operators never rotate. Combined, these two design flaws turn an authenticated administrative feature into an unauthenticated file disclosure primitive.

Attack Vector

The attack is delivered over the network against the public WordPress endpoint exposed by the plugin. An attacker submits a request authenticating with the default 1:1 credentials and supplies a target path such as ../../../../wp-config.php. The server responds with the raw contents. Stolen database credentials and WordPress secret keys from wp-config.php enable full site takeover. A public proof of concept is available at the GitHub PoC Repository, with additional analysis on the Personal Blog CVE Analysis.

See the WordPress Plugin Code Review for the vulnerable get_file() implementation.

Detection Methods for CVE-2025-4602

Indicators of Compromise

• HTTP requests to plugin endpoints containing path traversal sequences such as ../ or absolute paths like /etc/passwd or wp-config.php
• Requests presenting Basic authentication or POST parameters using the default credential pair 1:1
• Unexpected 200 responses from plugin handlers returning large byte counts to unauthenticated clients
• Outbound connections from the WordPress host using credentials matching values found in wp-config.php after a suspicious request burst

Detection Strategies

• Inspect web server access logs for requests targeting smconnector.php and related plugin endpoints with file path parameters
• Alert on any successful plugin authentication using the literal credentials 1:1
• Apply file integrity monitoring to detect access patterns reading sensitive files like wp-config.php from the web server user context
• Correlate plugin endpoint traffic with subsequent administrator logins or new account creation

Monitoring Recommendations

• Forward WordPress and web server logs into a centralized analytics platform and retain at least 90 days of request data
• Build alerts on path traversal patterns and on requests carrying the default credential string
• Track new installations of store-manager-connector across managed WordPress fleets to identify exposed assets

How to Mitigate CVE-2025-4602

Immediate Actions Required

• Update the eMagicOne Store Manager for WooCommerce plugin to a version newer than 1.2.5 as soon as a fixed release is available from the vendor
• Change the default plugin credentials from 1:1 to a strong, unique username and password immediately
• Rotate WordPress database credentials and authentication secret keys in wp-config.php if exposure is suspected
• Audit administrator accounts and remove any unrecognized users created since the plugin was installed

Patch Information

A plugin code change is referenced in the WordPress Plugin Changeset. Site operators should verify their installed plugin version against the latest release in the WordPress plugin directory and apply updates through the WordPress admin interface. See the Wordfence Vulnerability Report for vendor-specific remediation guidance.

Workarounds

• Deactivate and remove the plugin until a patched version is installed and credentials have been rotated
• Restrict access to the plugin endpoint at the web server or WAF layer to known administrative IP addresses
• Block requests containing path traversal patterns and requests carrying Basic authentication values equal to 1:1
• Apply strict file system permissions so the web server account cannot read files outside the WordPress document root where feasible

# Example Apache rule to block default-credential exploitation attempts
<LocationMatch "/wp-content/plugins/store-manager-connector/">
    SetEnvIfNoCase Authorization "Basic MToxXC0=" block_default_creds
    Require all granted
    Require not env block_default_creds
</LocationMatch>