CVE-2025-10329: Unmark SSRF Vulnerability

CVE-2025-10329 Overview

A Server-Side Request Forgery (SSRF) vulnerability has been identified in cdevroe Unmark, an open-source bookmarking application. The vulnerability exists in the /application/controllers/Marks.php file, where improper validation of the url argument allows attackers to manipulate server-side requests. This flaw can be exploited remotely by authenticated users to force the server to make requests to internal or external resources that would otherwise be inaccessible.

Critical Impact

Attackers can leverage this SSRF vulnerability to probe internal network infrastructure, access internal services, bypass firewall restrictions, and potentially exfiltrate sensitive data from internal systems.

Affected Products

• Unmark up to version 1.9.3
• All installations using the vulnerable Marks.php controller
• Self-hosted Unmark instances with network access to internal resources

Discovery Timeline

• September 12, 2025 - CVE-2025-10329 published to NVD
• September 16, 2025 - Last updated in NVD database

Technical Details for CVE-2025-10329

Vulnerability Analysis

This Server-Side Request Forgery (SSRF) vulnerability resides within the Marks.php controller file in the Unmark application. The vulnerability is classified under CWE-918 (Server-Side Request Forgery). When users submit URLs to be bookmarked, the application fetches metadata from those URLs server-side. However, insufficient validation of the url parameter allows attackers to submit crafted URLs that target internal resources.

The vulnerability requires low-privilege authentication to exploit, meaning any registered user of an Unmark instance could potentially leverage this flaw. Once exploited, the attacker can use the vulnerable server as a proxy to access internal services, cloud metadata endpoints, or other restricted resources that the server has network access to.

Root Cause

The root cause of this vulnerability is inadequate input validation and sanitization of the url argument in the Marks.php controller. The application fails to properly validate URLs before making server-side HTTP requests, allowing attackers to specify internal IP addresses, localhost references, cloud metadata endpoints (such as 169.254.169.254), or other internal network resources. Without proper allowlist-based URL validation or blocking of private IP ranges, the application blindly processes and fetches content from attacker-controlled URLs.

Attack Vector

The attack is network-based and can be launched remotely by any authenticated user of the Unmark application. An attacker exploits this vulnerability by manipulating the url parameter when creating or editing bookmarks. The exploitation flow involves submitting specially crafted URLs that point to internal resources, causing the server to make requests on behalf of the attacker.

Common attack scenarios include:

• Accessing cloud provider metadata services to retrieve instance credentials
• Port scanning internal network services
• Accessing internal administrative interfaces
• Retrieving data from internal databases or APIs
• Bypassing IP-based access controls

The vulnerability is documented in publicly available proof-of-concept materials. See the GitHub SSRF PoC for technical details on the exploitation methodology.

Detection Methods for CVE-2025-10329

Indicators of Compromise

• Unusual outbound HTTP requests from the Unmark application server to internal IP ranges (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x)
• Requests to cloud metadata endpoints such as 169.254.169.254 or metadata.google.internal
• Bookmark entries containing internal URLs, localhost references, or private IP addresses
• Abnormal patterns in web server access logs showing requests to internal services

Detection Strategies

• Implement network monitoring to detect HTTP requests from the Unmark server to internal IP ranges or metadata endpoints
• Deploy web application firewall (WAF) rules to identify and block SSRF attack patterns in the url parameter
• Monitor application logs for failed or successful attempts to access internal resources
• Use SentinelOne Singularity Platform to detect anomalous network behavior from web application servers

Monitoring Recommendations

• Enable verbose logging on the Unmark application to capture all URL fetch operations
• Configure network egress monitoring to alert on connections to internal IP ranges from web servers
• Implement DNS query logging to detect resolution of internal hostnames from the application server
• Establish baseline network behavior for the Unmark server and alert on deviations

How to Mitigate CVE-2025-10329

Immediate Actions Required

• Restrict network access from the Unmark server to internal resources using firewall rules
• Implement URL validation at the network or WAF level to block requests containing internal IP addresses
• Consider temporarily disabling the bookmark URL fetching functionality until a patch is available
• Audit existing bookmarks for suspicious internal URL entries

Patch Information

The vendor was contacted about this disclosure but did not respond. As of the last update on September 16, 2025, no official patch has been released. Organizations should implement the workarounds listed below and monitor for future vendor updates. Additional technical details are available at VulDB #323755.

Workarounds

• Implement server-side URL validation using an allowlist approach to only permit requests to known external domains
• Block outbound requests to RFC1918 private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) from the Unmark server
• Disable or restrict access to the URL fetching functionality in the Marks.php controller
• Deploy the Unmark application in an isolated network segment with no access to sensitive internal resources

# Example iptables rules to block SSRF to internal networks
# Block requests to private IP ranges from the web server
iptables -A OUTPUT -d 10.0.0.0/8 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner www-data -j DROP