CVE-2025-32778 Overview
CVE-2025-32778 is a critical command injection vulnerability affecting Web-Check, an all-in-one OSINT tool for analyzing websites. The vulnerability exists in the screenshot API component of the Web-Check project (Lissy93/web-check), where user-controlled input via the url parameter is passed unsanitized into a shell command using the exec() function. This flaw allows remote attackers to execute arbitrary system commands on the underlying host, potentially leading to complete system compromise, file extraction, or establishment of persistent remote access.
Critical Impact
Remote attackers can execute arbitrary commands on servers running Web-Check, potentially extracting sensitive files, establishing reverse shells, or fully compromising the underlying infrastructure without authentication.
Affected Products
- Web-Check (Lissy93/web-check) - versions prior to the security patch
- Self-hosted Web-Check instances with exposed screenshot API endpoints
- Docker deployments of Web-Check with vulnerable API configurations
Discovery Timeline
- 2025-04-15 - CVE-2025-32778 published to NVD
- 2025-04-16 - Last updated in NVD database
Technical Details for CVE-2025-32778
Vulnerability Analysis
This vulnerability represents a classic command injection flaw (CWE-78) in Node.js applications. The screenshot API endpoint in Web-Check accepts a url parameter from users that is intended to capture screenshots of web pages. However, this user-supplied input is passed directly to the exec() function from Node.js's child_process module without proper sanitization or validation.
The exec() function spawns a shell to execute commands, making it inherently dangerous when processing user input. Attackers can craft malicious URL parameters containing shell metacharacters (such as ;, |, &&, $(), or backticks) to break out of the intended command context and inject arbitrary commands that execute with the privileges of the Node.js process.
Root Cause
The root cause of this vulnerability is the use of exec() instead of safer alternatives for command execution. The exec() function in Node.js invokes a shell interpreter to process the command string, which interprets special characters and allows command chaining. When user input is concatenated into this command string without proper escaping or validation, attackers can inject additional commands.
The secure fix involves replacing exec() with execFile(), which executes a specific file directly without invoking a shell. This approach properly isolates arguments and prevents shell metacharacter interpretation, eliminating the command injection vector.
Attack Vector
The attack is network-based and requires no authentication or user interaction. An attacker can send a crafted HTTP request to the screenshot API endpoint with a malicious url parameter. The payload could include commands to:
- Extract sensitive files from the server filesystem (e.g., /etc/passwd, environment variables, configuration files)
- Download and execute malicious payloads
- Establish reverse shell connections for persistent access
- Pivot to other systems on the internal network
- Exfiltrate data or deploy ransomware
import puppeteer from 'puppeteer-core';
import chromium from 'chrome-aws-lambda';
import middleware from './_common/middleware.js';
-import { exec } from 'child_process';
+import { execFile } from 'child_process';
import { promises as fs } from 'fs';
import path from 'path';
import pkg from 'uuid';
Source: GitHub Commit Update
Detection Methods for CVE-2025-32778
Indicators of Compromise
- Unusual outbound network connections from the Web-Check server process
- Unexpected child processes spawned by Node.js with shell interpreters (/bin/sh, /bin/bash)
- Web server logs containing suspicious url parameters with shell metacharacters (;, |, &&, backticks, $())
- Evidence of file access attempts to sensitive system files like /etc/passwd or .env files
Detection Strategies
- Implement web application firewall (WAF) rules to detect and block requests containing shell metacharacters in URL parameters
- Monitor Node.js process behavior for unexpected command execution or shell spawning using endpoint detection tools
- Analyze HTTP access logs for anomalous patterns in the screenshot API endpoint requests
- Deploy runtime application self-protection (RASP) solutions to detect command injection attempts in real-time
Monitoring Recommendations
- Enable detailed logging for all screenshot API requests including full URL parameters
- Set up alerts for process execution anomalies where Node.js spawns unexpected child processes
- Monitor network traffic for unusual egress connections that may indicate reverse shells or data exfiltration
- Implement file integrity monitoring on critical system files and application directories
How to Mitigate CVE-2025-32778
Immediate Actions Required
- Update Web-Check to the latest version that includes the security patch replacing exec() with execFile()
- If immediate patching is not possible, disable or restrict access to the screenshot API endpoint
- Review server logs for any indicators of exploitation attempts
- Conduct a security assessment of any Web-Check instances that may have been exposed
Patch Information
The vulnerability has been addressed in the Web-Check project by replacing the vulnerable exec() function with execFile() in the api/screenshot.js file. The fix is available in commit 0e4958aa10b2650d32439a799f6fc83a7cd46cef. Organizations should update their Web-Check installations by pulling the latest changes from the repository or deploying updated container images. For more details, see the GitHub Security Advisory GHSA-5qg5-g7c2-pfx8 and Pull Request #243.
Workarounds
- Restrict network access to the screenshot API endpoint using firewall rules or reverse proxy configurations
- Implement input validation at the reverse proxy level to reject requests containing shell metacharacters
- Run Web-Check in an isolated container environment with minimal privileges and restricted filesystem access
- Deploy Web-Check behind authentication to prevent unauthenticated access to API endpoints
# Example: Restrict screenshot API access via nginx
location /api/screenshot {
# Deny external access to vulnerable endpoint
allow 127.0.0.1;
deny all;
# Or require authentication
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://localhost:3000;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

