Insurance Management System CVE-2025-7905

Exploitation requires valid authentication credentials (PR:L - low privilege user login) to access the /insertPayment.php endpoint. The vulnerability is triggered specifically when the recipt_no parameter is submitted via the payment insertion form, and the application processes this input without escaping or parameterization. No special configuration or non-default setup is required - the vulnerability exists in the default code path. Exploitation is limited to read-based SQL injection (CWE-74 scope) on data the authenticated user's database account can access; full database compromise is constrained by the application's database user privileges. Unauthenticated attackers cannot exploit this vulnerability; a valid user account is a hard prerequisite.

This CVE presents a significant disconnect between classification severity and actual risk metrics. The CVSS v4.0 score of 2.1 (network accessible but requiring login, limited scope, low impact across confidentiality, integrity, availability) contradicts the 'critical' classification in the description - likely reflecting discoverer bias rather than objective severity. The EPSS score of 0.09% (25th percentile) suggests minimal real-world exploitation probability despite public exploit availability, indicating this is a low-priority vulnerability in practice. The requirement for PR:L (low privilege - authenticated user access) significantly constrains exploitation; attackers must first gain valid credentials, reducing the attack surface dramatically. The AT:N (no attack timing required) and AC:L (low complexity) factors confirm that once authenticated, exploitation is straightforward, but the authentication gate makes this primarily an insider-risk or post-compromise escalation concern. The SC:N/SI:N/SA:N (no scope change, integrity/availability unavailable) further limits impact - attackers can read data but not modify database structure or shut down the system. Organizations using this legacy system should prioritize patching to eliminate this vector, but treat it as a medium-term rather than immediate critical threat unless the application stores highly sensitive data or is exposed to untrustworthy users.

An authenticated user (employee or contractor with login credentials) submits a crafted HTTP POST request to /insertPayment.php with a malicious SQL payload in the recipt_no parameter, such as recipt_no=1' OR '1'='1. The unsanitized input is directly concatenated into a SQL query, allowing the attacker to execute arbitrary SELECT commands to extract customer data, policy details, or payment information from the database. Publicly available exploit code (referenced on GitHub) demonstrates this attack pattern.