Modèle de menace Weblate

Scope: Core Weblate web application, its interactions with user browsers, backend components (web server, WSGI, database, datastore, Celery), and integration with external VCS.

Assumptions: Standard Weblate deployment with typical components (nginx/Apache, granian/Gunicorn/uWSGI, PostgreSQL, datastore, Celery) and user roles (unauthenticated user, authenticated user, reviewer, project manager, administrator, project-scoped API token).

Webhook endpoints for some VCS integrations are intentionally compatibility-oriented and can accept unauthenticated deliveries from supported forges. Weblate therefore treats webhook-triggered repository updates as a deployment-hardened interface rather than a cryptographically authenticated one by default.

Until native authenticated integrations are available for these platforms, webhook abuse resistance depends on compensating controls such as reverse-proxy rate limiting, request size limits, minimizing public exposure, and monitoring.

System description and scope

Weblate is an open-source web-based localization platform built on Django. It integrates tightly with Git repositories to manage translations and offers CI/CD-style features for automation, hooks, and VCS synchronization.

Authorization in Weblate is not limited to instance-wide administrator versus regular user access. Permissions can be delegated per site, project, component, language, glossary, or other scope, including dedicated VCS, translation memory, screenshot, review, and project access management permissions. Project-scoped API tokens can also be granted team memberships and permissions similar to users.

Assets:

• Confidentiality: Translation strings, API keys/credentials for VCS integration, user credentials (passwords, 2FA secrets), user personal data (email, name), session tokens, audit logs, private project data.

• Integrity: Translation string content, VCS repository integrity, project and component configurations, user permissions, audit logs.

• Availability: Weblate web interface, VCS integration, database access, background task processing.

• Authenticity/Non-repudiation: Translation commit history, user attribution for translations, audit logs of administrative actions.

Conceptual data flow diagram

Trust boundaries

• Internet ↔ Web server: Public internet traffic interacting with the first line of defense.

• Webhook source ↔ Web server: External code hosting services or other callers invoking repository hooks, sometimes with unauthenticated endpoints enabled per project.

• Web server ↔ Weblate application: Communication between the reverse proxy/web server and the application logic.

• Weblate application ↔ Database: Application logic accessing persistent and cached data.

• Weblate application ↔ Logging: Application logic creating logs.

• Weblate application ↔ Internal VCS repository: Application logic interacting with its local copy of the VCS repository.

• Weblate application ↔ External VCS repository: Weblate reaching out to external code hosting platforms.

• Privileged user configuration ↔ Outbound network: Project and integration settings can cause Weblate to initiate connections to external VCS hosts or other services.

• Imported backup archive ↔ Weblate application/filesystem: Backup restore processes attacker-controlled archive contents, metadata, and VCS state.

• Unauthenticated caller ↔ Authenticated user/token: Different privilege levels for browser, API, and webhook access.

• Authenticated user/token ↔ Project manager/reviewer/VCS manager: Delegated project- and component-scoped permissions create additional privilege boundaries inside the application.

Threat identification

Component/Interaction	STRIDE threat category	Threat description	Impact potentiel
serveur Web (nginx/Apache)	DoS	Deni de service : l’attaquant innonde le server web avec des requêtes rendant ainsi Weblate non disponible.	Accès perdu pour traduire.
	Divulgation d’informations	Configuration exposure: Misconfigured server exposes sensitive files (e.g., config files, private keys).	Publication de données confidentielles, architecture interne.
	Falsification	Injection de requête malveillante : l’attaquant injecte des données malveillantes dans les entêtes HTTP ou le corps des requêtes.	Potential for SQL injection, XSS, or other injections if not properly handled by the backend.
Webhook handling	Usurpation d’identité	Forged webhook delivery: An attacker submits a fake webhook payload to trigger repository updates or other automation, especially when unauthenticated hooks are enabled.	Unauthorized repository synchronization, noisy task execution, or follow-on abuse of automation paths.
	Falsification	Payload manipulation or replay: An attacker replays or modifies webhook payloads so Weblate processes repository states or branches different from the legitimate event.	Unexpected updates, repository confusion, or misuse of privileged VCS credentials.
	DoS	Hook flooding: An attacker sends excessive webhook requests or oversized payloads, overwhelming request handling or background workers.	Weblate slowdown or unavailability.
	Divulgation d’informations	Repository enumeration via webhook responses: An attacker probes webhook payloads and learns whether repositories, branches, or components exist based on response metadata.	Disclosure of private project structure, enabled hooks, or component identifiers.
	Rejet	Limited webhook attribution: Hook-triggered updates are recorded as coming from a service bot rather than a forge-authenticated principal.	Reduced forensic confidence when investigating malicious or disputed hook activity.
Application Weblate	Usurpation d’identité	Usurpation d’identité : l’attaquant prend la main sur la session d’un utilisateur légitime (par exemple en substituant la session, en compromettant les données confidentielles).	Traduction non autorisée, accès au dépôt.
(WSGI/Celery)	Falsification	Modification non autorisée de traductions : Utilisateur malveillant ou faille exploitée permettant de modifier les traductions, les configurations des projets, ou celles de l’intégration du VCS.	Traductions incorrectes, constructions cassées, RCE via les hook VCS.
	Falsification	VCS integration manipulation: Attacker manipulates Weblate’s interaction with the VCS (e.g., injecting malicious commands via crafted repository URLs if not sanitized, leading to RCE).	Injection de code dans les projets cible, données exfiltrées.
	Rejet	Unattributed changes: Malicious changes are made without proper attribution to the user or system responsible.	Difficulty in auditing and accountability.
	Divulgation d’informations	Sensitive data leakage: SQL injection, insecure API endpoints, or errors disclose sensitive data (e.g., other users” translations, VCS credentials, server information).	Privacy breach, intellectual property theft.
	Divulgation d’informations	VCS credentials exposure: Weblate’s stored VCS credentials (SSH keys, tokens) are accessed by an attacker.	Direct access to integrated code repositories.
	DoS	Resource exhaustion: Excessive background tasks or inefficient database queries triggered by an attacker lead to system slowdown or crash.	Weblate unavailability.
	Elevation of privilege	Role escalation: A regular translator gains administrative privileges.	Complete system compromise.
	Elevation of privilege	Command injection: Arbitrary code execution due to improper input validation in repository URLs or add-ons.	System compromise, data exfiltration.
Backup import / restore	DoS	Archive amplification during restore: A crafted backup contains many members or a large aggregate uncompressed size, exhausting disk, memory, worker time, or inode capacity.	Restore-time denial of service and possible service degradation for the instance.
	Falsification	Malicious backup metadata or VCS state: A crafted backup restores misleading project metadata or unsafe repository state despite path validation and schema checks.	Corrupted restored projects, unsafe repository state, or administrative confusion.
Database/Datastore	Falsification	Data corruption: Direct access to the database allows altering translation strings, user data, or configuration.	System malfunction, data integrity loss.
	Divulgation d’informations	Sensitive data access: Unauthorized access to database/datastore exposes all stored data (credentials, translation memory, user profiles).	Major data breach.
	DoS	Database exhaustion: Attacker floods the database or datastore with queries, or consumes all memory or available connections.	Weblate unavailability.
VCS integration	Falsification	Malicious commits from Weblate: Compromised Weblate pushes malicious changes to the upstream repository.	Introduction of malware/backdoors into target projects.
	Rejet	Fake commit attribution: Weblate commits changes attributed to a wrong user (e.g., an admin forcing a commit in a translator’s name without their consent).	Accountability issues.
Outbound integrations / VCS configuration	Divulgation d’informations	Server-side request forgery or unintended internal reachability: A privileged user configures repository or integration endpoints that cause Weblate to connect to internal or otherwise restricted hosts.	Exposure of internal services, metadata endpoints, or restricted network paths.
User interaction	Usurpation d’identité	Phishing/social engineering: Attacker tricks users into revealing credentials for Weblate or linked VCS accounts.	Account compromise.
(Web UI)	Falsification	Cross-Site scripting (XSS): Malicious scripts injected into translations or user profiles execute in other users” browsers.	Session hijacking, credential theft, defacement.
	Divulgation d’informations	Clickjacking/UI redress: Attacker overlays malicious UI elements over Weblate, tricking users into unintended actions.	Unauthorized actions, data manipulation.
	Divulgation d’informations	Sensitive data in UI: Unintended exposure of sensitive data (e.g., another user’s email) in the UI due to authorization flaws.	Privacy breach.

Mitigation strategies

• Authentication & authorization:

  • Strong password policies, see Password security.

  • Enforced 2FA, see Authentification à deux facteurs.

  • Robust session management.

  • Role-based access control (RBAC) to enforce the least privilege (for example separating translation, review, VCS, translation memory, screenshot, and project access management permissions), see Contrôle d’accès.

  • Integration with external identity providers (SAML, OAuth, LDAP), see Authentification.

• Webhook security:

  • Current product limitation: webhook authenticity is not uniformly enforced in-app for all supported forge integrations.

  • Treat webhook endpoints as deployment-hardened interfaces and enable them only where necessary, see Déclencheurs de notification and Activer les points d’ancrage.

  • Deployment controls required today include reverse-proxy rate limiting, request size limits, optional source-IP filtering, minimizing public exposure, and alerting on webhook spikes.

  • Validate webhook event type and payload before triggering repository updates or tasks.

  • Future product direction is to replace compatibility webhooks with native authenticated integrations that validate source authenticity before scheduling repository updates.

• Input validation and output encoding:

  • Strict validation of all user inputs (forms, API requests, VCS URLs) to prevent injection attacks (SQL injection, command injection, XSS).

  • Context-aware output encoding for all user-supplied data displayed on the web UI to prevent XSS.

• VCS integration security:

  • Principle of least privilege for VCS credentials (e.g., read-only access where possible, limited scopes for tokens).

  • Secure storage of VCS credentials.

  • Strict sanitization and validation of all data coming from VCS (e.g., filenames, branch names, commit messages that might be displayed).

  • Secure execution of Git/Mercurial commands (avoiding shell execution with user-controlled input).

  • Document and review hostname allowlisting and private-network restrictions for outbound integrations where deployments need to constrain server-initiated connections.

• Backup import security:

  • Treat backup archives as untrusted input and validate both metadata and extracted paths.

  • Enforce aggregate archive-size and extraction-budget limits, not only per-entry checks.

  • Monitor restore failures and unusually large imports as potential abuse indicators.

• Data protection:

  • Encryption of sensitive data at rest.

  • Encryption of data in transit (TLS/SSL for all HTTP/S and VCS communication).

  • Database hardening (the least privilege for Weblate user, strong passwords).

• System hardening:

  • Regular patching of OS, Weblate, and all dependencies.

  • Principle of least privilege for Weblate user account on the OS.

  • Network segmentation (e.g., separating database and datastore from public access).

  • Use of WAF (Web Application Firewall).

• Logging and monitoring:

  • Comprehensive audit logging of all security-relevant events (logins, failed logins, permission changes, critical configuration changes, VCS operations).

  • Centralized logging and alerting for security incidents, for example Graylog log management.

• Secure development practices:

  • Code reviews with a security focus.

  • Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), see Code source de Weblate.

  • Dependency vulnerability scanning, see Dependencies.

  • Regular security audits and penetration testing.

• Error handling:

  • Generic error messages that do not reveal sensitive internal information.