What is the CVSS score of CVE-2025-60641?

CVE-2025-60641 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. EPSS exploitation probability: 0.4%.

Vfront CVE-2025-60641

MEDIUM

SQL Injection (CWE-89)

2025-10-16 cve@mitre.org

Deserialization Path Traversal SQLi Denial Of Service RCE PHP

6.5

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

vuln.today AI

8.1 HIGH

AC:H reflects the gadget-chain dependency required for high-impact exploitation; PR:N confirmed by unauthenticated POST surface; full C/I/A reflects RCE potential when chains are present.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

Low

Availability

None

Lifecycle Timeline

Analysis Generated

Jul 05, 2026 - 04:11 vuln.today

DescriptionCVE.org

The file mexcel.php in the Vfront 0.99.52 codebase contains a vulnerable call to unserialize(base64_decode($_POST['mexcel'])), where $_POST['mexcel'] is user-controlled input. This input is decoded from base64 and deserialized without validation or use of the allowed_classes option, allowing an attacker to inject arbitrary PHP objects. This can lead to malicious behavior, such as Remote Code Execution (RCE), SQL Injection, Path Traversal, or Denial of Service, depending on the availability of exploitable classes in the Vfront codebase or its dependencies.

AnalysisAI

PHP object injection in Vfront 0.99.52's mexcel.php endpoint exposes an unauthenticated POST parameter directly to unserialize() without class restrictions, enabling remote attackers to instantiate arbitrary PHP objects. Depending on exploitable gadget chains present in the Vfront codebase or its PHP dependencies, this can escalate to remote code execution, SQL injection, path traversal, or denial of service. No public exploit has been identified at time of analysis, and EPSS places exploitation probability at 0.40% (32nd percentile), consistent with the absence of a CISA KEV listing.

Technical ContextAI

Vfront 0.99.52 is a legacy PHP-based business management application. The vulnerable file mexcel.php passes the HTTP POST parameter 'mexcel' through base64_decode() and then directly into PHP's native unserialize() function with no allowed_classes whitelist - a protection available since PHP 7.0 that would prevent object instantiation entirely. The root cause is CWE-502 (Deserialization of Untrusted Data), though NVD catalogues this under CWE-89 (SQL Injection), which is more accurately one possible downstream impact rather than the root cause - a notable classification discrepancy. Exploitation via PHP object injection relies on 'gadget chains': sequences of PHP magic methods (__wakeup, __destruct, __toString, etc.) within classes loaded at deserialization time that can be chained to produce harmful effects. Common gadget-chain-rich libraries such as Symfony, Guzzle, Doctrine, or Monolog, if bundled with Vfront's dependencies, substantially elevate the severity of this flaw beyond the base deserialization capability. No CPE string was provided in the available intelligence.

Affected ProductsAI

Vfront version 0.99.52 is the confirmed affected version per the CVE description, with the vulnerability residing in the file mexcel.php. No additional affected version ranges have been confirmed from available data, and no CPE string was provided. No official vendor advisory or security bulletin has been identified; the sole reference is the NVD entry at https://xancatos.org/cve202560641. Whether prior or later versions of Vfront share this vulnerable code pattern has not been independently confirmed.

RemediationAI

No vendor-released patch has been identified at time of analysis. The primary code-level fix is to replace the unsafe unserialize(base64_decode($_POST['mexcel'])) call in mexcel.php with a safe alternative: either pass an empty allowed_classes array (unserialize($data, ['allowed_classes' => false])) to prevent PHP object instantiation while preserving scalar deserialization, or replace the entire mechanism with json_decode() if the use case permits - note that switching serialization formats requires corresponding changes to any client-side code generating the payload. As an immediate compensating control, access to mexcel.php should be restricted at the web server level via .htaccess deny rules or an nginx location block, accepting the trade-off of disabling the Excel-related functionality until a code fix is applied. WAF rules blocking POST requests with base64-encoded PHP serialized object patterns (O: prefix after decode) targeting this endpoint provide an additional detection and blocking layer. Refer to https://xancatos.org/cve202560641 for the published advisory.