漏洞與事件處理

產品漏洞報告

也參考

如果您曾使用 AI 發現 Weblate 的安全問題，請閱讀 使用 AI 建立 issues。

Weblate 開發團隊堅定致力於以負責任的方式回報及揭露安全性相關問題。我們採用並遵循旨在及時提供 Weblate 安全性更新的原則。

產品弱點回報涵蓋 Weblate 原始碼、發行產物及已記載的 Weblate 安全性特性中所發生的安全性問題，無法取代特定部署環境的營運事件回應。

Reports concerning the separately distributed Weblate Client (wlc) are evaluated against the wlc threat model, which documents its intended trust boundaries, supported security properties, and explicit non-goals.

Weblate 的一般錯誤大多會回報至公開的 GitHub 問題追蹤器；但由於安全性問題十分敏感，請勿以這種方式公開回報。

如果您認為在 Weblate 中發現可能影響安全性的問題，請將問題說明寄至 security@weblate.org、使用 GitHub，或透過 HackerOne 提交。

自行託管環境的營運者若認為其部署環境中的事件是由 Weblate 產品弱點所致，應採用此處理程序。部署環境的圍堵、復原、客戶通知、提供者呈報及其他部署環境專用的事件回應，仍由營運者負責。

A member of the security team will respond to you within 48 hours, and depending on what action is taken, you may get more follow-up emails. Suspected active exploitation and severe security incidents receive immediate internal attention under Incident reporting. Acknowledging a report or completing an investigation does not postpone reporting deadlines.

備註

傳送加密的報告

如果想傳送加密電子郵件（選用），請使用 security@weblate.org 的公開金鑰，ID 為 8EA7 6E43 0976 3323 C2E3 D5A0 C472 9F23 8A80 EA93.

這把公開金鑰可透過常用金鑰伺服器、WKD 或 直接從 weblate.org 取得。

提示

Weblate depends on third-party components for many things. In case you find a vulnerability affecting one of those components in general, please report it directly to the respective project. If it also affects a shipped Weblate artifact or a Weblate deployment, report that impact to Weblate through the private channels above.

其中包括：

• Django

• Django REST 框架

• Python Social Auth

也參考

• 在 Weblate 中回報問題

Weblate 營運服務的事件

影響 Hosted Weblate、Dedicated Weblate 或其他由 Weblate s.r.o. 營運之部署環境的營運事件，會依 Weblate 事件回應計畫 處理。

若這類事件同時涉及 Weblate 產品弱點，弱點回報及公開公告會依本頁的產品弱點回報處理程序與 漏洞揭露政策 處理。

自託管部署事件

自行託管 Weblate 部署環境的營運者，須負責其部署環境的事件回應處理程序，包括圍堵、復原、通知及提供者專用的呈報。由 Weblate 營運的 Weblate 事件回應計畫 可作為參考，但不是針對第三方部署環境維護的事件回應計畫。

如果自行託管環境中的事件疑似由 Weblate 產品弱點所致，請使用上述產品弱點回報處理程序加以回報。

漏洞揭露政策

Weblate publishes a security advisory alongside a release containing a vulnerability fix at https://github.com/WeblateOrg/weblate/security/advisories. Advisories identify affected versions, impact, severity, and steps users can take to remediate the vulnerability.

Technical details may be delayed when publishing them would create greater security risks than benefits while users apply the fix. The incident handler records the reason and a review date in the private incident note. This does not delay authority reports or protective advice users need.

Authority reporting

Weblate adopts the following reporting timelines as a voluntary policy baseline for actively exploited Weblate product vulnerabilities and severe product-security incidents. This includes affected shipped dependencies and incidents learned about through self-hosted deployments. Severe security incidents affecting Weblate-operated services also follow this baseline.

報告	Deadline
Early warning	Without undue delay, within 24 hours of awareness.
Main notification	Without undue delay, within 72 hours of awareness.
Final report for an actively exploited vulnerability	Within 14 days after a corrective or mitigating measure becomes available.
Final report for a severe incident	Within one calendar month after the main incident notification.

Hours include weekends and holidays. Acknowledgment, incident declaration, handover, or completion of an investigation does not restart these clocks. When an event involves both active exploitation and a severe incident, track both reporting obligations and final-report deadlines.

These timelines follow the European Commission reporting guidance. The incident handler records whether mandatory or voluntary reporting applies and uses the corresponding route. For CRA reporting, the Single Reporting Platform routes notifications to the coordinating CSIRT and ENISA. This policy does not determine Weblate's regulatory role or claim compliance; see 產品與聯絡資訊.

For classification, submission steps, and private incident records, see Incident reporting.

User notifications

Weblate informs impacted users of active exploitation or severe security incidents without undue delay, including available mitigations and corrective actions. Where appropriate, warnings address all users. Known affected contacts, including Hosted and Dedicated Weblate customers, receive e-mail notifications. Public GitHub security advisories provide warnings and updates for self-hosted users whose contact details are not known.

Initial warnings can provide protective advice before a fix or detailed vulnerability disclosure is ready. Authority reporting, user warnings, and publication of technical details proceed separately as needed.

Personal-data breaches also require a separate assessment of notifications to affected individuals, even when there is no active exploitation or severe product-security incident.