Problem Statement:
SecuScan is described as a "plugin-driven platform for running security scans" covering "recon, web, cloud, container, and reporting workflows," with plugin metadata and parser code living in plugins/. Security scanning tools of this shape commonly work by constructing shell commands to invoke underlying scanners (e.g., nmap, subfinder, nikto) with a user-supplied target (domain/IP/URL) interpolated into the command string. If any plugin does this via string concatenation into subprocess.run(..., shell=True) (or equivalent) instead of a properly escaped/whitelisted argument list, a malicious or malformed scan target (e.g., target.com; rm -rf / or backtick/$() injection) could result in arbitrary command execution on the machine running SecuScan.
Note: I could not directly confirm this from the README alone — this needs verification by opening a representative plugin's execution code in backend/secuscan or plugins/ before filing, since the actual severity depends entirely on implementation details (whether shell=True is used, whether inputs are validated/escaped, whether an allowlist of characters is enforced on scan targets).
Proposed Solution (once confirmed):
Audit every plugin invocation path for subprocess/os.system calls with shell=True or f-string/concatenated command construction.
Replace with subprocess.run([...], shell=False) using an argument list, and add strict input validation on target fields (valid IP/hostname/URL regex) before any plugin executes.
Add a regression test asserting a shell-metacharacter-laden target (e.g., containing ;, |, `, $()) is rejected before reaching any subprocess call.
Document the sanitization approach in SECURITY.md.
Impact: For a tool explicitly built to run scans against user-supplied targets, command injection would be the single most severe possible vulnerability class — worth flagging and auditing early even if the current implementation turns out to already be safe.
Problem Statement:
SecuScan is described as a "plugin-driven platform for running security scans" covering "recon, web, cloud, container, and reporting workflows," with plugin metadata and parser code living in plugins/. Security scanning tools of this shape commonly work by constructing shell commands to invoke underlying scanners (e.g., nmap, subfinder, nikto) with a user-supplied target (domain/IP/URL) interpolated into the command string. If any plugin does this via string concatenation into subprocess.run(..., shell=True) (or equivalent) instead of a properly escaped/whitelisted argument list, a malicious or malformed scan target (e.g., target.com; rm -rf / or backtick/$() injection) could result in arbitrary command execution on the machine running SecuScan.
Note: I could not directly confirm this from the README alone — this needs verification by opening a representative plugin's execution code in backend/secuscan or plugins/ before filing, since the actual severity depends entirely on implementation details (whether shell=True is used, whether inputs are validated/escaped, whether an allowlist of characters is enforced on scan targets).
Proposed Solution (once confirmed):
Audit every plugin invocation path for subprocess/os.system calls with shell=True or f-string/concatenated command construction.
Replace with subprocess.run([...], shell=False) using an argument list, and add strict input validation on target fields (valid IP/hostname/URL regex) before any plugin executes.
Add a regression test asserting a shell-metacharacter-laden target (e.g., containing ;, |, `, $()) is rejected before reaching any subprocess call.
Document the sanitization approach in SECURITY.md.
Impact: For a tool explicitly built to run scans against user-supplied targets, command injection would be the single most severe possible vulnerability class — worth flagging and auditing early even if the current implementation turns out to already be safe.