CVE-2026-50127: Server-Side Request Forgery Bypass via IPv6 Transition Prefixes in Weblate

Weblate is a web-based translation and localization platform that integrates with popular Version Control Systems (VCS). Because it automatically pulls and pushes localized resources from external source code repositories, it accepts and resolves arbitrary user-supplied repository URLs. To prevent users from leveraging Weblate to perform internal network scans or access confidential cloud-metadata endpoints, developers introduced the VCS_RESTRICT_PRIVATE configuration setting.

When VCS_RESTRICT_PRIVATE is active, Weblate is designed to evaluate resolved target IP addresses and block outbound connections if the destination resolves to private, local, or loopback networks. However, versions starting from 5.15 up to (but excluding) 2026.6 suffer from a logical validation bypass that subverts this restriction.

The core of the vulnerability lies in Weblate's outbound security filter, which failed to account for transitional IPv6 environments. By providing hostnames that resolve to transition-wrapped IPv4 targets, attackers can make Weblate's validation filter perceive the destination as globally routable while the host's operating system connects directly to a private internal target.

To validate whether an IP address belongs to a public, globally routable network, Weblate's outbound filter historically relied on the Python standard library's ipaddress module. The application parsed resolved hostnames into IP address structures and then checked the .is_global property. If this property returned True, Weblate assumed the connection was safe to establish.

This architecture creates a critical security gap when handling IPv6 transitional prefixes that encapsulate underlying IPv4 addresses. For example, the RFC 6052 NAT64 prefix 64:ff9b::/96 is classified as globally routable by Python's ipaddress library because it is intended for internet-scale routing translation. However, on host operating systems or networks where NAT64 translation is active, routing packets to 64:ff9b::/96 forces the local network layer to extract the last 32 bits and route the packet to the encoded IPv4 address.

Because the Python library only evaluates the overall IPv6 wrapper prefix, Weblate's application-layer security policy approves the connection. Subsequently, the operating system-layer connection code decodes the IPv6 address and connects to the private destination. This dynamic introduces a Time-of-Check to Time-of-Use discrepancy between application logic and OS-level routing execution.

The vulnerable code path inside weblate/utils/outbound.py checked the global routing status using a simple boolean validation helper:

# Vulnerable IP validation function
def _is_public_ip(value: str) -> bool:
    address = _parse_ip(value)
    return address is not None and address.is_global

Because standard IPv6 transition prefixes return True for .is_global, an attacker-supplied hostname resolving to [64:ff9b::a9fe:a9fe] bypassed this function. To eliminate this issue, the security patch implemented a recursive unwrapping routine called _unwrap_ipv6_transition:

# Patched unwrapping routine in weblate/utils/outbound.py
def _unwrap_ipv6_transition(
    address: ipaddress.IPv4Address | ipaddress.IPv6Address,
) -> ipaddress.IPv4Address | ipaddress.IPv6Address:
    if not isinstance(address, ipaddress.IPv6Address):
        return address
    if address.ipv4_mapped is not None:
        return address.ipv4_mapped
    if address in _NAT64_PREFIX: # 64:ff9b::/96
        return ipaddress.IPv4Address(address.packed[-4:])
    if address in _IPV4_COMPAT: # ::0.0.0.0/96
        embedded = ipaddress.IPv4Address(address.packed[-4:])
        if int(embedded) != 0:
            return embedded
    return address

Once unwrapped, the inner IPv4 address is parsed recursively. This ensures that hidden local addresses, such as loopback (127.0.0.1) or link-local targets (169.254.169.254), are identified and restricted correctly.

To exploit this vulnerability, an attacker must have network-level or UI-level access to endpoints that trigger outbound network queries, such as the repository creation wizard or repository update webhooks. Additionally, the target environment must support IPv6-to-IPv4 translation or transition encapsulation mechanisms.

In a cloud environment like AWS, an attacker identifies the target resource as the AWS Instance Metadata Service (IMDSv1) at address 169.254.169.254. This target IPv4 is represented in hexadecimal as a9fe:a9fe. Using standard NAT64 formatting, the attacker constructs the target IPv6 equivalent: 64:ff9b::a9fe:a9fe (or 64:ff9b::169.254.169.254).

The attacker enters this custom IP format into Weblate's repository URL configuration interface. During validation, Weblate's validator checks [64:ff9b::a9fe:a9fe] and permits the connection because the prefix evaluates as global. During connection establishment, the operating system converts the destination back to the targeted private IP address and completes the SSRF chain.

The impact of a successful SSRF attack via CVE-2026-50127 varies based on the configuration of the targeted local network. In cloud environments where Weblate is hosted, attackers can query internal metadata endpoints. This exposes cloud service account credentials, access tokens, and sensitive system parameters.

Furthermore, attackers can use Weblate's connection engine as an internal proxy to scan adjacent servers or run raw HTTP queries against unauthenticated database interfaces, local administrative panels, or microservices sharing the host network space. This can lead to horizontal privilege escalation or absolute backend database compromise.

The official CVSS v3.1 score is evaluated at 5.9 (Medium), reflecting the high attack complexity (AC:H). This rating stems from the requirement that the local host system or target container network must support or enable translation layers to route IPv6 transition targets to internal IPv4 addresses.

The primary remediation strategy is upgrading Weblate instances to version 2026.6 or higher. This release integrates strict recursive address unwrapping. It explicitly flags and drops transition addresses wrapping non-public internal targets before establishing connections.

If immediate software upgrades are not possible, host administrators must apply external firewalls or drop policies. Configuring local container firewall boundaries (using iptables or equivalent utilities) to block outgoing traffic targeting 64:ff9b::/96, 2002::/16, and ::0.0.0.0/96 isolates the application from these translation routes.

It is important to evaluate any custom translation settings used within internal environments. If your network configuration uses a custom Network-Specific Prefix (NSP) for NAT64 translation (such as 2001:db8:nat64::/96), Weblate's standard blocklist will not automatically recognize it. In these customized network configurations, additional host-level firewalls must be maintained to prevent bypasses.