Skip to main content
A Leader in the 2026 Gartner® Magic Quadrant™ for Endpoint Protection. Six years running.Find Out Why
CVE Vulnerability Database
Vulnerability Database/CVE-2026-50127

CVE-2026-50127: Weblate Auth Bypass Vulnerability

CVE-2026-50127 is an authentication bypass flaw in Weblate that allows attackers to circumvent private range restrictions via IPv6 and IPv4 addresses. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2026-50127 Overview

CVE-2026-50127 affects Weblate, a web-based localization platform used by software teams to manage translations through version control system (VCS) integrations. The vulnerability resides in the VCS_RESTRICT_PRIVATE setting, which is intended to block requests to internal network ranges and prevent Server-Side Request Forgery (SSRF) attacks against VCS repositories. The restriction logic fails to account for transitional IPv6 ranges, multicast addresses, and certain semi-private IPv4 ranges. Attackers can supply addresses in these overlooked ranges to bypass the private range filter and reach internal services. The flaw is classified under CWE-918: Server-Side Request Forgery (SSRF).

Critical Impact

An unauthenticated network attacker can bypass Weblate's private range restrictions to interact with internal hosts via the VCS request handler, potentially exposing sensitive metadata or internal services.

Affected Products

  • Weblate versions 5.15 through versions before 2026.6
  • Self-hosted Weblate installations relying on VCS_RESTRICT_PRIVATE
  • Hosted Weblate deployments prior to upgrade to 2026.6

Discovery Timeline

Technical Details for CVE-2026-50127

Vulnerability Analysis

Weblate integrates with remote VCS providers such as Git and Mercurial to synchronize translations. The VCS_RESTRICT_PRIVATE configuration enforces an address allowlist intended to reject requests targeting private IP ranges. This filter underpins Weblate's SSRF defense for repository URLs supplied by project administrators or, in some deployments, lower-privileged users.

The restriction logic enumerates well-known private ranges but omits several IP categories. Transitional IPv6 ranges such as IPv4-mapped IPv6 addresses (::ffff:0:0/96), 6to4 (2002::/16), and Teredo (2001::/32) can encapsulate private IPv4 addresses while presenting as public IPv6. Multicast ranges (224.0.0.0/4, ff00::/8) and semi-private IPv4 blocks (for example 100.64.0.0/10 carrier-grade NAT space) are also not filtered. Requests crafted with these representations pass the check and are dispatched by the VCS client.

Root Cause

The root cause is incomplete denylist coverage in the network address validation routine. The original implementation evaluated only canonical private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, loopback, and link-local) without normalizing IPv6 transitional encodings or rejecting multicast and shared-address-space ranges. Because validation occurs on the supplied URL representation rather than the resolved socket address, equivalent destinations expressed in alternative formats evade the filter.

Attack Vector

An attacker with the ability to configure a repository URL submits a VCS endpoint pointing at a bypass-capable address. Examples include an IPv4-mapped IPv6 address such as [::ffff:169.254.169.254] to reach cloud instance metadata services, a 6to4 address that decodes to an RFC1918 host, or a multicast destination. Weblate initiates an outbound VCS clone or fetch against the attacker-specified address, returning response data or error contents that can disclose internal service details. The attack does not require authentication in deployments that expose project creation to anonymous or low-privileged users.

No verified public exploit code is available. Refer to Weblate Pull Request #19768 for the corrective patch and validated address ranges.

Detection Methods for CVE-2026-50127

Indicators of Compromise

  • Outbound VCS connections from Weblate workers to IPv6 addresses in ::ffff:0:0/96, 2002::/16, or 2001::/32 ranges
  • Repository configurations referencing multicast addresses or 100.64.0.0/10 hosts
  • Access logs showing VCS clone or fetch attempts against cloud metadata endpoints such as 169.254.169.254 reached via IPv6 encoding

Detection Strategies

  • Inspect Weblate application logs for git, hg, or svn operations targeting non-routable destinations encoded in transitional IPv6 formats
  • Correlate egress firewall telemetry with Weblate worker process identifiers to detect anomalous internal connections
  • Audit project and component repository URLs in the Weblate database for addresses outside expected provider ranges

Monitoring Recommendations

  • Enable egress logging on Weblate hosts and alert on connections to RFC1918, metadata service, and multicast destinations
  • Monitor for new repository creation events followed by immediate VCS fetch failures, which can indicate probing
  • Track Weblate version inventory and flag instances on 5.15 through pre-2026.6 releases

How to Mitigate CVE-2026-50127

Immediate Actions Required

  • Upgrade Weblate to version 2026.6 or later, which contains the corrected address validation logic
  • Restrict project and repository creation permissions to trusted administrators until the upgrade is applied
  • Place Weblate workers behind an egress proxy that enforces an allowlist of external VCS providers

Patch Information

The fix is included in the Weblate 2026.6 release and merged in pull request #19768. The patch extends VCS_RESTRICT_PRIVATE to reject IPv4-mapped IPv6 addresses, 6to4 and Teredo ranges, multicast addresses, and semi-private IPv4 blocks. Review the GHSA-vmfc-9982-2m45 advisory for the full list of newly blocked ranges.

Workarounds

  • Deploy network-level egress filtering that blocks Weblate workers from reaching internal subnets, cloud metadata endpoints, and multicast destinations
  • Disable anonymous and self-service project creation until the upgrade is applied
  • Route VCS traffic through a forward proxy that resolves and validates the final socket address against a strict allowlist
bash
# Example egress restriction using iptables on a Weblate worker 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 169.254.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner weblate -d 100.64.0.0/10 -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner weblate -d ::ffff:0:0/96 -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner weblate -d 2002::/16 -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner weblate -d ff00::/8 -j REJECT

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne