fuyang_lipengjun platform CVE-2025-7936

Exploitation requires authenticated access to the fuyang_lipengjun platform. An attacker must first obtain valid user credentials (username and password) to log into the application or possess an active session cookie, as evidenced by the PR:L (Privileges: Low) requirement in the CVSS vector. The queryPage function must be accessible within the application's controller routing. No special configuration or non-default settings are documented as required; the vulnerability exists in standard deployments. The SQL injection payload is injected via the beanName or methodName parameters in the queryPage request. The limiting factor is mandatory prior authentication; unauthenticated remote exploitation is not possible. Additionally, the impact is constrained to the calling user's data access scope within the application's permission model, as indicated by the Scope:Not Changed (S:N) aspect of the CVSS vector.

The risk assessment presents a significant contradiction between CVSS score and real-world exploitation likelihood. The CVSS v4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L) yields a score of 2.1, reflecting mandatory authentication (PR:L), remote network access, and limited impact scope. However, multiple risk signals contradict this low severity rating: publicly available exploit code exists, exploitation probability is marked as possible (E:P), and the CVSS impact metrics show confidentiality, integrity, and availability impacts are all present (VC:L/VI:L/VA:L), not absent. The EPSS score of 0.07% (22nd percentile) indicates low probability of exploitation in the wild, suggesting this is a low-visibility or narrowly-targeted vulnerability. The requirement for prior authentication significantly limits real-world risk compared to an unauthenticated SQL injection. This appears to be a legitimate but low-impact vulnerability: SQL injection exists and is exploitable, but authentication gating and limited impact scope reduce practical urgency. Organizations using this platform should prioritize patching over more critical vulnerabilities, but this should not be neglected given the availability of exploit code.

An authenticated platform user crafts a malicious HTTP request to the queryPage endpoint with a specially-crafted beanName or methodName parameter containing SQL metacharacters (e.g., ' OR '1'='1). The application concatenates this unsanitized input directly into a SQL query and executes it against the backend database. An attacker could extract sensitive data from the database, modify records, or in some cases execute arbitrary code depending on database permissions and SQL dialect. Publicly available exploit code demonstrates this attack path, making reliable reproduction possible for any user with valid platform credentials.