CVE-2026-62249

Executive Summary

CVE-2026-62249 is a broken access control vulnerability in Weblate, a web-based continuous localization platform, affecting all versions prior to 2026.7. An authenticated user with access to any project can retrieve the change history of restricted components within that project through nested API change endpoints, effectively bypassing component-level access controls enforced on direct component views. The vulnerability results in unauthorized disclosure (CWE-200) of restricted component data, including source and translated string content, with a CVSS base score of 4.3 (medium severity). Given the low complexity of the attack (requiring only low-privilege authentication and no user interaction), enterprises using self-hosted Weblate instances should prioritize upgrading to version 2026.7 or implementing access review controls in the interim.

Technical Analysis

Vulnerability Class: Broken Access Control (specifically, failure to enforce object-level authorization on nested API endpoints), categorized under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

Affected Component: Weblate's REST API change history functionality. The platform provides both a web UI and a comprehensive set of REST API endpoints for programmatic management of translation projects, components, and their change histories. The vulnerability resides in the nested API change endpoints — API routes that allow users to retrieve change records for components via project-scoped URLs.

Mechanism: The core flaw is an inconsistent application of authorization checks across different code paths. The Weblate web application enforces component-level access control on direct component views — that is, when a user directly navigates to or queries a restricted component's page or its dedicated API endpoint, the application verifies that the requesting user holds sufficient permissions (e.g., "view component" privilege) for that specific component. However, when the same component's changes are accessed through a nested endpoint under a project (e.g., a URL structure where a project's changes include related component changes), the access control checks applied to the direct component views are not enforced. The nested endpoints therefore inherit only the project-level access check (the user being a member of the project) and skip the per-component permission evaluation.

This is a classic "horizontal privilege escalation via misconfigured routing" flaw: an authenticated user with basic project membership can enumerate metadata and content belonging to restricted components that the project administrator intended to be visible only to a designated sub-team.

Data Exposed: The NVD description states that the exposed data can include:

• The restricted component's identity (name, slug, or other identifying metadata)
• Translation and unit links
• Change payload fields, including source or translated string content in the target, old, and details values

The target and old fields in Weblate's change records typically contain the new and previous values of a translation unit, meaning full translation string content can be exfiltrated. The details field may contain additional context, such as user account names who made changes, timestamps, and other metadata.

API Context (based strictly on available data): The NVD description mentions "nested API change endpoints" generically, without specifying exact URL patterns. Per accuracy rules, we note that no specific endpoint paths, function names, or parameter names were disclosed in the CVE description or CNA title. The vulnerability is understood at the class level: project-scoped API change queries do not apply component-level permission checks.

Exploitation Scenarios

Preconditions:

• The attacker must have a valid, authenticated account on the target Weblate instance.
• The attacker must be a member of a project that contains at least one restricted component (a component with access control settings more restrictive than the project-level default).
• The Weblate instance must expose the REST API (default enabled in most deployments).
• Target version must be prior to 2026.7.

No public PoC exists for this CVE, and no Nuclei template or exploit code has been observed. The attack chain below is inferred from the vulnerability class and the NVD description.

Step 1 — Reconnaissance / Target Identification: The attacker authenticates to the Weblate instance and identifies projects for which they have membership. Using the legitimate API — for instance, querying project metadata or list endpoints to enumerate available projects — the attacker maps out the organization's localization structure. The attacker identifies a project containing components they are not authorized to view (potentially by noticing a discrepancy between components listed in the project view versus those visible via direct API calls, or by prior knowledge of the organization's team structure).

Step 2 — Flaw Trigger: The attacker crafts a request to the nested API change endpoint for the target project. Rather than querying the restricted component directly (which would trigger the proper access control check and return a 403 Forbidden), the attacker requests the change history for the entire project, or for a parent resource that aggregates component changes. Because the nested endpoints skip component-level access checks, the response includes change records for the restricted component alongside those for accessible components.

Step 3 — Payload / Execution Method: At the vulnerability-class level, this is not a code injection flaw — no SQL injection, XSS, or RCE payload is required. The "payload" is simply a legitimate, well-formed API request crafted to access the nested change history endpoint. The attacker may iterate over project IDs or slugs, use pagination parameters to page through large change histories, and use filter parameters to isolate changes belonging to the restricted component (e.g., filtering by component identifier in the query parameters if supported). The HTTP response body then contains the sensitive change records.

Step 4 — Post-Exploitation Impact: The attacker exfiltrates the exposed change history. This yields:

• Confidential data: Source and translated string content in target, old, and details fields. This may include proprietary product terminology, unreleased feature strings, legal disclaimers, or compliance-related text that the organization intended to keep restricted.
• Intelligence gathering: The change history reveals the translation workflow: which users (by username in the change metadata) are working on the restricted component, how frequently changes are made, and the current status of unreleased translation work.
• Potential further attacks: If the details fields include user account identifiers or email addresses of translators working on restricted components, the attacker could use this for targeted social engineering. Additionally, understanding the structure of restricted projects helps the attacker map out other potential API endpoints or misconfigurations to probe.

Likelihood: The attack requires no special tools beyond an HTTP client (curl, browser console, Burp Suite). The only barrier is having authenticated access to a project. The silent nature of the flaw (no error, no log anomaly beyond normal API access) makes detection challenging.

Impact Assessment

CVSS Analysis: The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N.

• Attack Vector (AV:N): Remotely exploitable over the network — no local access needed.
• Attack Complexity (AC:L): No specialized conditions or race conditions required; the attack is straightforward API usage.
• Privileges Required (PR:L): Requires only low-privilege authenticated access (standard user account with a valid project membership).
• User Interaction (UI:N): No user interaction required.
• Scope (S:U): The vulnerability does not cross a trust boundary; the impacted component is the same as the vulnerable component.
• Confidentiality Impact (C:L): Low — limited information disclosure, but the data is still sensitive (translation string content).
• Integrity (I:N) and Availability (A:N): No impact.

Business Impact:

• Confidentiality breach: Proprietary or unreleased product content can be exposed to unauthorized personnel within the organization (an insider threat vector). If the Weblate instance is multi-tenant (shared across organizations or departments), the exposure crosses logical trust boundaries.
• Regulatory risk: If the translation content includes PII, health data, or financial terms subject to privacy regulations (e.g., GDPR, HIPAA, PCI-DSS), unauthorized exposure may constitute a reportable data breach.
• Competitive intelligence loss: For companies localizing software for launch, leaked unreleased string content can reveal roadmap features.

Affected Systems: All self-hosted Weblate deployments running versions prior to 2026.7. Cloud-hosted Weblate (the weblate.org hosted service) is presumably upgraded by the vendor and thus not vulnerable, but this is not explicitly stated in the CVE data.

Blast Radius: The vulnerability is confined to authenticated users — anonymous users cannot exploit it. However, within an organization, any user with access to any project (including contractors, temporary staff, or partners given limited access) can potentially exfiltrate data from restricted components. The blast radius scales with the number of restricted components within shared projects.

EPSS Score: Not yet scored by FIRST.org; no exploit-in-the-wild evidence observed at the time of writing.

Detection Guidance

Detection of this vulnerability is challenging because exploitation does not rely on anomalous payloads or known exploit signatures — it is simply an over-permissive API query. Detection should focus on:

1. Access pattern anomalies: Users who are not members of a restricted component's access list querying project-level change history containing that component.
2. Data exfiltration signals: Unusual volume of change-history API requests from a specific user, or large responses being returned.
3. Baseline deviation: A user who normally uses the web UI suddenly making many API calls.

Refer to the exact headings below for the detection rules.

Sigma Rule

title: Weblate Nested API Change Endpoint Access Control Bypass
id: 3c17f6a9-2a8e-4b45-a31f-9d3e2a99c7b1
status: experimental
description: Detects authenticated users accessing Weblate API change history endpoints in a manner consistent with the CVE-2026-62249 nested endpoint access control bypass. This rule flags users who request project-level change history while lacking component-level permissions.
author: Valters IT Cyber Intelligence
logsource:
  category: application
  product: weblate
  service: api
detection:
  selection_api_changes:
    http.url_extension: "changes"
    http.method: "GET"
  selection_project_context:
    http.url|contains:
      - "/api/projects/"
      - "/changes/"
  selection_user_low_privilege:
    # Adjust based on known restricted component access lists in your environment.
    # This should be enriched with a list of users lacking component-level
    # VIEW_RESTRICTED permissions.
    user.name|not in:
      - "component_admin"
      - "localization_manager"
  timeframe: 5m
  condition: selection_api_changes and selection_project_context and selection_user_low_privilege
  fields:
    - user.name
    - http.url
    - http.response.body.bytes
    - src.ip
falsepositives:
  - Users with legitimate project-level but restricted component-level access who are intentionally querying aggregated change histories.
  - Automation scripts (CI/CD) using service accounts that legitimately retrieve project change history.
level: medium

YARA Rule

rule Weblate_ChangeHistory_AccessControlBypass
{
    meta:
        author = "Valters IT Cyber Intelligence"
        description = "Detects API responses from Weblate change history endpoints that contain references to restricted components, suggesting a potential access control bypass (CVE-2026-62249)."
        reference = "CVE-2026-62249"
        cve = "2026-62249"
        date = "2026-01-XX"
        severity = "medium"

    strings:
        $change_endpoint = "/api/projects/" ascii wide nocase
        $changes_path = "/changes/" ascii wide nocase
        $target_field = "\"target\"" ascii wide
        $old_field = "\"old\"" ascii wide
        $details_field = "\"details\"" ascii wide
        $unit_link = "/units/" ascii wide nocase
        $translation_link = "/translations/" ascii wide nocase
        $component_link = "/components/" ascii wide nocase

    condition:
        // API response to a changes endpoint
        any of ($change_endpoint, $changes_path) and
        // Contains change payload fields typical of exposed Weblate change records
        any of ($target_field, $old_field, $details_field) and
        // Contains links to translation/unit resources
        any of ($unit_link, $translation_link) and
        // For log/session analysis: this rule applies to captured HTTP response bodies
        1 of ($component_link*)
}

Note: The YARA rule above is designed for network captures or log aggregation systems that store HTTP response bodies (e.g., via a proxy or SIEM with full packet capture). It is not suitable for scanning executables.

Suricata IDS Rule

alert http any any -> any any (
    msg:"ET WEB_SPECIFIC_APPS Weblate Nested API Change Endpoint Access Control Bypass (CVE-2026-62249)";
    flow:established,to_server;
    http.method;
    http.method:"GET";
    http.uri;
    content:"/api/projects/";
    http.uri;
    content:"/changes/";
    http.uri;
    content:"/";
    distance:0;
    within:200;
    http.uri;
    pcre:"/\/api\/projects\/[^\/]+\/changes\//i";
    classtype:attempted-information-leak;
    reference:cve,2026-62249;
    sid:2026000490;
    rev:1;
    metadata:created_at 2026-01-XX, updated_at 2026-01-XX;
)

Note: This rule detects the primary pattern of exploitation — a GET request to the project-scoped change history endpoint. Because the legitimate API also uses this path, high false-positive rates are expected; this rule should be used with the post-detection logic in an IDS/IPS, not as a standalone block rule.

Elastic Detection

// EQL query for Elastic Security — detects Weblate change-history API requests
// to project-level nested endpoints, correlated with user privilege.
sequence with maxspan=5m
  [ http where process.name == "nginx" and request.method == "GET" and
    url.path : "/api/projects/*/changes/*" ]
  [ http where process.name == "nginx" and request.method == "GET" and
    url.path : "/api/projects/*" and response.status_code == 200 ]

Alternative simpler EQL (if no correlation needed):

http where process.name == "nginx"
  and request.method == "GET"
  and url.path : "/api/projects/*/changes/*"
  and user.name not in ("weblate-api-admin", "localization-manager")
  and response.status_code == 200

Splunk SPL Query

index=weblate_proxy sourcetype=access_combined
| where like(uri, "%/api/projects/%") AND like(uri, "%/changes/%")
| table _time, clientip, user, uri, status, bytes
| eval user_low_priv = if(user IN ("component_admin", "localization_manager"), "low_risk", "suspect")
| search user_low_priv="suspect"
| stats count, values(uri) as uris, earliest(_time) as first_seen, latest(_time) as last_seen by clientip, user
| where count > 10
| table clientip, user, count, first_seen, last_seen, uris

Wazuh OSSEC Rule

<rule id="100249" level="10">
  <decoded_as>json</decoded_as>
  <field name="url">\./api/projects/.*/changes/\.</field>
  <description>Weblate access control bypass attempt: user accessed project-level change history via nested API endpoint (CVE-2026-62249)</description>
  <group>weblate,cve-2026-62249,access_control,</group>
  <mitre>
    <id>T1213</id>
  </mitre>
  <options>no_full_log</options>
</rule>

Note: The above is a Wazuh XML rule that should be placed in a custom local ruleset. It assumes Wazuh is ingesting Weblate application logs or a reverse proxy (nginx/apache) access log parsed with JSON extraction (e.g., via a decoder that outputs url and user fields).

Mitigation & Patch Guidance

Patch Confidence: 0/4 (UNPATCHED in tracked sources). While the vendor fixed the issue in version 2026.7 per the NVD description, our intelligence sources have not yet confirmed the availability of a published patch, changelog entry, or advisory. Verification against the official Weblate release notes and code repository is recommended.

Immediate Mitigations (until patch is applied):

1. Review and restrict API access: If the Weblate instance does not require API access for all project members, disable the REST API entirely (if configuration permits) or restrict API access to a specific set of service accounts using reverse proxy rules (e.g., require API keys for authenticated API calls, disable API token generation for low-privilege users).
2. Component-level monitoring: For sensitive components, enable audit logging and monitor access to their change history. Flag any user who is not on the component's access list but appears in the change history user field.
3. Least-privilege review: Audit all project memberships. Remove any user accounts that do not explicitly require access to a given project. Apply the principle of least privilege at the project level.
4. Web Application Firewall (WAF) rule: Deploy a temporary WAF rule to block or alert on GET requests to the /api/projects/*/changes/* pattern for non-admin users (as per the Suricata sample above). Expect false positives.

Patch/Upgrade Steps:

1. Verify current version: weblate --version or check the About page in the web UI.
2. If running version < 2026.7, upgrade to the latest stable release (ideally 2026.7 or newer) following the official Weblate upgrade documentation on the vendor website.
3. After upgrade, perform a regression test: as a low-privilege user, attempt to access the nested change history of a restricted component and verify a 403 response is returned.
4. Confirm the upgrade in staging before production deployment.

Long-Term Hardening:

1. Access control review process: Periodically audit component-level permissions and ensure they are aligned with data sensitivity. Documents that contain proprietary translation content should be tagged as sensitive.
2. API hardening: Enforce API access tokens with scopes that limit what endpoints a user can call, and rotate tokens regularly.
3. Network segmentation: If Weblate contains highly sensitive localization content, place the instance in an internal network segment not directly reachable from the internet; require VPN for access.
4. Logging and alerting: Ensure Weblate application logs and reverse proxy access logs are forwarded to a SIEM (Splunk, Elastic, Wazuh) for detection of anomalous API usage patterns as described above.
5. Vendor monitoring: Subscribe to the Weblate security-announcements mailing list or GitHub release feed to receive future advisories promptly.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-62249 — Official NVD entry with the description and CVSS vector referenced in this report.
2. MITRE CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-62249 — CVE record maintained by the CVE Program.
3. Weblate Official Site: https://weblate.org/ — Vendor product page; release notes for version 2026.7 should be consulted on the official Weblate site or GitHub repository (https://github.com/WeblateOrg/weblate) to confirm the fix.
4. CWE-200 (Mitre): https://cwe.mitre.org/data/definitions/200.html — Description of the weakness class.

Threat Actor Activity: At the time of writing, no known threat actor campaigns, exploit-in-the-wild evidence, or public proof-of-concept exploits have been observed for CVE-2026-62249. The vulnerability is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the low complexity of exploitation and the commonality of the underlying pattern (nested API endpoints missing access controls) should be treated as a risk indicator that exploitation attempts may emerge in the future, particularly in multi-tenant Weblate deployments.