General Contact Form Security & Risk Analysis

The general-contact-form plugin v1.7 presents a mixed security posture. On the positive side, it has a very small attack surface with only one entry point (a shortcode) and no known vulnerabilities in its history. Furthermore, it doesn't appear to have external dependencies or perform file operations, which are common vectors for exploitation.

However, the static analysis reveals significant concerns. A high percentage of its SQL queries (64%) are not using prepared statements, indicating a potential for SQL injection vulnerabilities. More critically, a substantial number of taint analysis flows (6 out of 9) are flagged as high severity with unsanitized paths, strongly suggesting that user-supplied data is not being properly validated or sanitized before being used in sensitive operations. Additionally, a concerning 0% of output is properly escaped, creating a high risk of Cross-Site Scripting (XSS) vulnerabilities. The absence of nonce and capability checks, while not directly indicating an exploit on AJAX or REST APIs (as there are none), means that if such features were added in the future without proper checks, the plugin would be immediately vulnerable.

Given the lack of historical CVEs, it's possible these issues haven't been exploited yet or are mitigated by the plugin's limited functionality. However, the static analysis findings, particularly the unsanitized taint flows and lack of output escaping, point to significant inherent security weaknesses that could be exploited. The lack of prepared statements in SQL queries further exacerbates these risks. The plugin's strengths lie in its minimal attack surface and clean vulnerability history, but these are overshadowed by the critical coding practices observed in the static analysis.