GHSA-2q2q-jr9g-v9rf CVE-2026-55228 PYSEC-2026-3942
Weblate has IDOR in GroupViewSet that allows authenticated project manager to gain unauthorized read access to any private project
- Severity
- 8.1 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.45%
- Chance of exploitation in the next 30 days. Higher than 38.96% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-639 Authorization Bypass Through User-Controlled Key
- Fix
2026.7- Upgrade weblate to this version or later
Description
Impact
The API did not properly handle project- and workspace-scoped teams and allowed setting invalid configurations, including granting access to projects the user has no access to.
Patches
References
Parts of this issue were independently reported by four reporters:
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| weblate | < 2026.7 |
2026.7 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
weblate PyPI → 2026.7
- pip
pip install --upgrade "weblate>=2026.7"- poetry
poetry add "weblate>=2026.7"- uv
uv add "weblate>=2026.7"
Severity breakdown
CVSS 3.1 8.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weakness
CWE-639: Authorization Bypass Through User-Controlled Key
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
How to prevent it
- Architecture and Design: For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- Architecture and Design, Implementation: Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
- Architecture and Design: Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-2p9g-x3cv-5hh4 Private Weblate projects vulnerable to observable object existence disclosure via globally scoped object lookups | Medium | Also affects weblate |
| GHSA-vmfc-9982-2m45 Weblate SSRF: outbound URL guard misses some private ranges | Medium | Also affects weblate |
| GHSA-6wxc-8mgq-w26m Weblate: Stored HTML injection in editor search preview | Medium | Also affects weblate |
| GHSA-5cmv-3rc4-7279 Weblate vulnerable to XSS via crafted Markdown | Medium | Also affects weblate |
| GHSA-gcg5-86jr-f7jg Weblate Vulnerable to Private Translation Enumeration via Screenshot API | Medium | Also affects weblate |
| GHSA-cwcx-382v-8m9g Weblate Vulnerable to Authenticated SSRF via Project Backup Import bypassing validate_repo_url | High | Also affects weblate |
| GHSA-6j8j-4qp3-36p2 Weblate Doesn't Invalidate API Token on Password Change | Medium | Also affects weblate |
| GHSA-ffgh-3jrf-8wvh Weblate: Prefix-Based Repository Boundary Check Bypass via Symlink/Junction Path Prefix Collision | Medium | Also affects weblate |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor