CVE-2026-3057 identifies a SQL injection vulnerability in the pearProjectApi software, specifically affecting versions 2.8.0 through 2.8.10. The vulnerability resides in the dateTotalForProject function located in application/common/Model/Task.php within the Backend Interface component. The issue arises from improper validation and sanitization of the projectCode parameter, which is directly incorporated into SQL queries. This flaw enables remote attackers to inject malicious SQL code, potentially allowing unauthorized access to or manipulation of the backend database. The attack vector requires no authentication or user interaction, increasing the risk of exploitation. The vulnerability has been publicly disclosed with an available exploit, though no confirmed active exploitation in the wild has been reported. The vendor was notified early but has not issued a patch or response, leaving users exposed. The CVSS 4.0 base score is 5.3, reflecting medium severity due to the ease of remote exploitation and potential impact on confidentiality, integrity, and availability of data. The lack of a patch necessitates immediate mitigation efforts by affected organizations to reduce risk.

The SQL injection vulnerability in pearProjectApi can have significant impacts on organizations using affected versions. Attackers exploiting this flaw can execute arbitrary SQL commands, leading to unauthorized data disclosure, data modification, or deletion. This compromises the confidentiality and integrity of sensitive project data managed by the API. Additionally, attackers could disrupt service availability by corrupting database contents or causing application crashes. Since the vulnerability requires no authentication or user interaction, it can be exploited remotely and at scale, increasing the threat surface. Organizations relying on pearProjectApi for project management or backend operations may face operational disruptions, data breaches, and compliance violations. The lack of vendor response and patch availability further exacerbates the risk, potentially leading to prolonged exposure and increased likelihood of exploitation.

Given the absence of an official patch, organizations should implement immediate compensating controls. First, apply strict input validation and sanitization on the projectCode parameter at the application or web server level to block malicious payloads. Employ web application firewalls (WAFs) with custom rules targeting SQL injection patterns specific to the vulnerable endpoint. Restrict network access to the Backend Interface component to trusted IPs or internal networks only, reducing exposure to remote attacks. Monitor logs for unusual database queries or error messages indicative of injection attempts. Consider deploying database activity monitoring tools to detect and alert on suspicious SQL commands. If feasible, isolate or disable the vulnerable function temporarily until a patch is available. Engage in active threat intelligence sharing to stay informed about emerging exploits. Finally, plan for an upgrade or patch deployment once the vendor releases a fix or consider alternative software solutions if the vendor remains unresponsive.