CVE-2026-77573: Weblate DNS Rebinding SSRF Vulnerability

CVE-2026-77573 Overview

CVE-2026-77573 is a server-side request forgery (SSRF) vulnerability in Weblate, a web-based continuous localization platform used to manage software translations. The flaw affects versions prior to 2026.8 and stems from a time-of-check to time-of-use (TOCTOU) condition [CWE-367] between hostname validation and the DNS resolution performed by external Version Control System (VCS) clients. An authenticated user with permission to manage component repository URLs can leverage DNS rebinding to bypass the VCS_RESTRICT_PRIVATE protection and reach internal VCS-compatible services.

Critical Impact
Attackers with repository-management privileges can force Weblate to connect to internal or private-network VCS services during clone, fetch, or push operations, potentially exposing private repository contents.

Affected Products

Weblate versions prior to 2026.8
Installations that permit untrusted repository hostnames
Deployments configured with VCS_RESTRICT_PRIVATE=True

Discovery Timeline

2026-08-26 - CVE-2026-77573 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-77573

Vulnerability Analysis

Weblate performs a first DNS lookup to validate that a configured repository hostname resolves to a public address. The subsequent VCS client, such as Git or Mercurial, performs its own independent DNS lookup when opening the network connection. An attacker who controls the authoritative DNS response for the supplied hostname can return a public address during Weblate's validation, then return an internal address (for example, 127.0.0.1, 169.254.169.254, or an RFC1918 range) when the VCS client resolves the same name moments later.

Once the VCS operation proceeds, Weblate reaches internal services on behalf of the attacker. If those services expose Git, Mercurial, or similar protocols, private repository contents can be cloned into a Weblate component and rendered back to the attacker through the platform.

Root Cause

The root cause is a classic TOCTOU flaw [CWE-367]. Hostname validation and the actual network connection rely on separate DNS resolutions, and Weblate cannot enforce address pinning on external VCS client processes. VCS_RESTRICT_PRIVATE therefore protects only the validation step and not the connection itself.

Attack Vector

Exploitation requires a Weblate account permitted to manage component repository URLs and control of an authoritative DNS server. The attacker configures a short TTL record pointing to a public IP, registers the hostname as a component repository, and triggers a clone, fetch, push, or update. Between validation and connection, the DNS record is re-pointed to an internal address.

text

// Patch note from docs/changes.rst — fix(vcs): prevent repository DNS rebinding
* VCS operations now bind protected Git connections to validated public
  addresses and fail closed for clients which cannot enforce that binding.

Source: WeblateOrg/weblate commit 3f31f094

Detection Methods for CVE-2026-77573

Indicators of Compromise

Component repository URLs that reference unfamiliar external hostnames with unusually short DNS TTL values.
Outbound VCS connections from the Weblate host to internal RFC1918 addresses, loopback, or cloud metadata endpoints such as 169.254.169.254.
Repeated DNS lookups for the same hostname within short intervals immediately before Git or Mercurial process execution.

Detection Strategies

Correlate Weblate audit logs for component create, update, and repository-change events with subsequent outbound network flows to private ranges.
Inspect DNS query logs for repository hostnames that resolve to both public and private addresses within a single session.
Monitor Git and Mercurial child processes spawned by Weblate for target hosts outside the expected VCS providers.

Monitoring Recommendations

Enable verbose VCS operation logging in Weblate and forward it to a centralized log platform for retention and search.
Alert on any Weblate egress traffic destined to private CIDR blocks, link-local addresses, or cloud metadata IPs.
Baseline the set of legitimate repository hostnames and alert on newly introduced external DNS providers.

How to Mitigate CVE-2026-77573

Immediate Actions Required

Upgrade Weblate to version 2026.8 or later, which binds protected Git connections to validated public addresses and fails closed for clients that cannot enforce binding.
Audit existing components for repository URLs added by non-administrator users and remove any pointing to untrusted or unknown hostnames.
Restrict the permission to manage component repository URLs to a small set of trusted administrators.

Patch Information

The fix is delivered in Weblate 2026.8. See the GitHub Security Advisory GHSA-45m9-pf98-8jmq and the remediation commit 3f31f094. The patch pins protected Git connections to the address validated during hostname checking and refuses to proceed when the client cannot honor that binding. The advisory also warns that arbitrary SSH options in trusted administrator configuration can alter connection routing and override VCS_RESTRICT_PRIVATE address pinning.

Workarounds

Place the Weblate application behind an egress proxy or firewall that blocks outbound connections to RFC1918, loopback, and cloud metadata ranges.
Disable or tightly restrict the ability for non-administrators to create or modify component repository URLs until the upgrade is applied.
Review and minimize custom SSH options in trusted administrator configuration, since those can override the address pinning provided by VCS_RESTRICT_PRIVATE.

bash

# Example egress restriction using iptables on the Weblate host
iptables -A OUTPUT -m owner --uid-owner weblate -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner weblate -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner weblate -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner weblate -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner weblate -d 169.254.0.0/16 -j REJECT