CVE-2026-47684: Sync-in Server SSRF via IPv4-Mapped IPv6 Bypass

Technical summary

The vulnerability resides in the private IP blocklist regex applied to the URL download feature in Sync-in Server. On dual-stack systems, the regex pattern fails to match IPv4-mapped IPv6 addresses in the format ::ffff:x.x.x.x, which are semantically equivalent to their IPv4 counterparts. An authenticated attacker can craft a URL using an IPv4-mapped IPv6 address pointing to private IP space (127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to trigger Server-Side Request Forgery (SSRF). This allows bypassing intended network segmentation controls that rely on the blocklist to prevent access to sensitive internal services.

Business impact

Organizations using Sync-in Server for file sharing face a confidentiality risk. An authenticated user can exploit this to exfiltrate sensitive data from internal services that are accessible to the Sync-in Server instance but isolated from external users. This is particularly concerning in environments where the application server can reach databases, internal APIs, metadata repositories, or other backend systems. The attacker requires a valid account but can then probe and interact with internal infrastructure without proper authorization, potentially disclosing configuration details, credentials, or service banners that aid further compromise.

Affected systems

Sync-in Server versions prior to 2.3.0 are affected. The vulnerability only manifests on systems with dual-stack networking enabled (both IPv4 and IPv6 active). Single-stack IPv4-only deployments are not vulnerable. Organizations running older versions should prioritize inventory and patching, especially those with internet-facing Sync-in Server instances and trusted-user populations that include contractors, partners, or employees with broad network access.

Exploitability

Exploitation requires a valid user account (PR:L in the CVSS vector), placing this within the reach of insider threats or compromised user accounts. No special tools are needed—a simple HTTP client and knowledge of the target's internal IP space suffice. The attack complexity is low; the attacker need only craft a URL with an IPv4-mapped IPv6 address and trigger a download operation. However, effective exploitation depends on what internal services are reachable from the Sync-in Server and whether those services expose sensitive data or actions via HTTP. This is not a wormable vulnerability and does not affect unauthenticated users.

Remediation

Upgrade Sync-in Server to version 2.3.0 or later, which corrects the private IP blocklist regex to properly recognize and block IPv4-mapped IPv6 addresses. If immediate patching is not feasible, disable the URL download feature entirely or restrict it to allowlisted domains. Review user account access—remove unnecessary privileges and audit logs for suspicious download requests using IPv6 URLs or unusual internal IP targets. Consider network segmentation to limit what internal services the Sync-in Server instance can reach.

Patch guidance

Apply version 2.3.0 or any subsequent release. Verify the fix by testing URL downloads with both standard IPv6 and IPv4-mapped IPv6 addresses pointing to private IP ranges to confirm they are now blocked. After patching, restart the Sync-in Server service and validate that file sharing functionality continues to work as expected for legitimate external URLs. Document the patch date and version for audit trails.

Detection guidance

Monitor Sync-in Server access logs for URL download requests containing IPv6 addresses, especially those with the ::ffff: prefix. Flag requests targeting private IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, ::1, fc00::/7). Review authentication logs to identify which accounts initiated suspicious downloads. Network-level detection: inspect outbound HTTP/HTTPS traffic from Sync-in Server to internal IP addresses and correlate with download feature usage. Baseline normal behavior first to avoid false positives from legitimate internal integrations.

Why prioritize this

This vulnerability merits HIGH priority because it enables authenticated SSRF with high confidentiality impact (CVSS 7.7). Unlike many SSRF issues, it crosses system boundaries (S:C) and affects the confidentiality of data accessible to the compromised service. The requirement for authentication limits blast radius but does not eliminate risk—many organizations grant file-sharing platform access broadly. Dual-stack environments are increasingly common, expanding the vulnerable footprint. Organizations with internet-facing Sync-in Server and sensitive internal services reachable from it should patch immediately.

Risk score, explained

The CVSS 3.1 score of 7.7 (HIGH) reflects: network-based attack surface (AV:N), low attack complexity (AC:L), and low privileges required (PR:L). The confidentiality impact is high (C:H)—the attacker can read data from internal services—while integrity and availability remain unaffected (I:N, A:N). The scope is changed (S:C), meaning the attacker can impact resources beyond the security scope of the vulnerable component, such as backend databases or APIs. This score appropriately captures the risk to organizations with internal data exposure but does not account for business context (what internal services exist, how sensitive they are, or how many users have access).

Frequently asked questions