Docker
CVE-2026-40474
HIGH
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L
Lifecycle Timeline
4DescriptionGitHub Advisory
Summary
wger exposes a global configuration edit endpoint at /config/gym-config/edit implemented by GymConfigUpdateView. The view declares permission_required = 'config.change_gymconfig' but does not enforce it because it inherits WgerFormMixin (ownership-only checks) instead of the project’s permission-enforcing mixin (WgerPermissionMixin) .
The edited object is a singleton (GymConfig(pk=1)) and the model does not implement get_owner_object(), so WgerFormMixin skips ownership enforcement. As a result, a low-privileged authenticated user can modify installation-wide configuration and trigger server-side side effects in GymConfig.save().
This is a vertical privilege escalation from a regular user to privileged global configuration control. The application explicitly declares permission_required = 'config.change_gymconfig', demonstrating that the action is intended to be restricted; however, this requirement is never enforced at runtime.
Affected endpoint
The config URLs map as follows.
File: wger/config/urls.py
patterns_gym_config = [
path('edit', gym_config.GymConfigUpdateView.as_view(), name='edit'),
]
urlpatterns = [
path(
'gym-config/',
include((patterns_gym_config, 'gym_config'), namespace='gym_config'),
),
]This resolves to:
/config/gym-config/edit
Root cause
The view declares a permission but does not enforce it
File: wger/config/views/gym_config.py
class GymConfigUpdateView(WgerFormMixin, UpdateView):
model = GymConfig
fields = ('default_gym',)
permission_required = 'config.change_gymconfig'
success_url = reverse_lazy('gym:gym:list')
title = gettext_lazy('Edit')
def get_object(self):
return GymConfig.objects.get(pk=1)The permission string exists, but WgerFormMixin does not check permission_required.
The project’s permission mixin exists but is not used
File: wger/utils/generic_views.py
class WgerPermissionMixin:
permission_required = False
login_required = False
def dispatch(self, request, *args, **kwargs):
if self.login_required or self.permission_required:
if not request.user.is_authenticated:
return HttpResponseRedirect(
reverse_lazy('core:user:login') + f'?next={request.path}'
)
if self.permission_required:
has_permission = False
if isinstance(self.permission_required, tuple):
for permission in self.permission_required:
if request.user.has_perm(permission):
has_permission = True
elif request.user.has_perm(self.permission_required):
has_permission = True
if not has_permission:
return HttpResponseForbidden('You are not allowed to access this object')
return super(WgerPermissionMixin, self).dispatch(request, *args, **kwargs)GymConfigUpdateView does not inherit this mixin, so none of the login/permission logic runs.
The mixin that *is* used performs only ownership checks, and GymConfig has no owner
File: wger/utils/generic_views.py
class WgerFormMixin(ModelFormMixin):
def dispatch(self, request, *args, **kwargs):
self.kwargs = kwargs
self.request = request
if self.owner_object:
owner_object = self.owner_object['class'].objects.get(pk=kwargs[self.owner_object['pk']])
else:
try:
owner_object = self.get_object().get_owner_object()
except AttributeError:
owner_object = False
if owner_object and owner_object.user != self.request.user:
return HttpResponseForbidden('You are not allowed to access this object')
return super(WgerFormMixin, self).dispatch(request, *args, **kwargs)File: wger/config/models/gym_config.py
class GymConfig(models.Model):
default_gym = models.ForeignKey(
Gym,
verbose_name=_('Default gym'),
# ...
null=True,
blank=True,
on_delete=models.CASCADE,
)
# No get_owner_object() methodBecause GymConfig does not implement get_owner_object(), WgerFormMixin catches AttributeError and sets owner_object = False, skipping any access restriction.
Security impact
This is not a cosmetic setting: GymConfig.save() performs installation-wide side effects.
File: wger/config/models/gym_config.py
def save(self, *args, **kwargs):
if self.default_gym:
UserProfile.objects.filter(gym=None).update(gym=self.default_gym)
for profile in UserProfile.objects.filter(gym=self.default_gym):
user = profile.user
if not is_any_gym_admin(user):
try:
user.gymuserconfig
except GymUserConfig.DoesNotExist:
config = GymUserConfig()
config.gym = self.default_gym
config.user = user
config.save()
return super(GymConfig, self).save(*args, **kwargs)On deployments with multiple gyms, this allows a low-privileged user to tamper with tenant assignment defaults, affecting new registrations and bulk-updating existing users lacking a gym. This permits unauthorized modification of installation-wide state and bulk updates to other users’ records, violating the intended administrative trust boundary.
Proof of concept (local verification)
Environment: local docker compose stack, accessed via http://127.0.0.1:8088/en/.
Observed behavior
An unauthenticated user can reach the endpoint via GET; POST requires authentication and redirects to login. An authenticated low-privileged user can submit the form and change the global singleton. After the save, the application redirects to success_url = reverse_lazy('gym:gym:list') (e.g. /en/gym/list), which is permission-protected; therefore the browser may display a “Forbidden” page even though the global update already succeeded.
DB evidence (before/after)
Before submission:
default_gym_id= None
profiles_gym_null= 1After a low-privileged user submitted the form setting default_gym to gym id 1:
default_gym_id= 1
profiles_gym_null= 0Recommended fix
Ensure permission enforcement runs before the form dispatch.
Using the project mixin (order matters):
class GymConfigUpdateView(WgerPermissionMixin, WgerFormMixin, UpdateView):
permission_required = 'config.change_gymconfig'
login_required = TrueAlternatively, use Django’s PermissionRequiredMixin (and LoginRequiredMixin) directly.
Conclusion
The view explicitly declares permission_required = 'config.change_gymconfig', which demonstrates developer intent that this action be restricted. The fact that it is not enforced constitutes improper access control regardless of perceived business impact.
<img width="1912" height="578" alt="Screenshot 2026-02-27 230752" src="https://github.com/user-attachments/assets/c627b404-6d9c-4477-88bd-f867d0fa09d2" />
AnalysisAI
Authenticated low-privileged users in wger can modify installation-wide gym configuration via /config/gym-config/edit due to missing permission enforcement, enabling vertical privilege escalation. The GymConfigUpdateView declares 'config.change_gymconfig' permission but inherits WgerFormMixin instead of WgerPermissionMixin, causing the permission check to never execute. Exploiting this allows attackers to manipulate default gym assignments affecting all users, with GymConfig.save() automatically reassigning user profiles and creating gym configurations tenant-wide. CVSS 7.6 (High) with network attack vector, low complexity, and low privileges required. No active exploitation (KEV) or public POC identified at time of analysis, though GitHub advisory provides detailed reproduction steps.
Technical ContextAI
The vulnerability stems from Django class-based view mixin inheritance order and method resolution. The wger project implements two mixins: WgerPermissionMixin (checks user.has_perm() against permission_required in dispatch()) and WgerFormMixin (validates object ownership via get_owner_object()). GymConfigUpdateView inherits only WgerFormMixin, which attempts ownership validation but fails gracefully when GymConfig model lacks get_owner_object() method, returning owner_object=False and skipping all access control. The permission_required attribute exists as a class variable but is never evaluated because WgerPermissionMixin.dispatch() is not in the method resolution order. This is a textbook CWE-284 (Improper Access Control) where authorization logic is defined but not executed. The GymConfig singleton (pk=1) represents installation-wide settings, and its save() method performs CASCADE operations on UserProfile and GymUserConfig tables, making this a high-impact data integrity issue in multi-tenant deployments.
RemediationAI
Apply the vendor-recommended fix by modifying GymConfigUpdateView inheritance to include WgerPermissionMixin before WgerFormMixin in the class definition: 'class GymConfigUpdateView(WgerPermissionMixin, WgerFormMixin, UpdateView)' with 'login_required = True' set. Python's method resolution order (MRO) processes mixins left-to-right, so WgerPermissionMixin.dispatch() will execute before WgerFormMixin.dispatch(), enforcing the permission_required check. Alternatively, replace custom mixins with Django's built-in PermissionRequiredMixin and LoginRequiredMixin for standards-compliant access control. Patch availability and fixed version number not confirmed in available data-monitor https://github.com/wger-project/wger/security/advisories/GHSA-xppv-4jrx-qf8m for release information. Compensating control if immediate patching is not feasible: implement reverse proxy or Django middleware to restrict /config/gym-config/edit to superuser role via HTTP 403 response; this prevents unauthorized access but does not fix the underlying authorization flaw and will conflict with legitimate administrator workflows. Workaround side effects: middleware-based blocking requires maintaining URL pattern allowlists and may break if application URL routing changes. Verify fix effectiveness by testing that low-privileged authenticated users receive HTTP 403 when accessing /config/gym-config/edit.
An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac
Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post
Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build
Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l
Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c
Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.2.169 and Application prior to version 2
An issue in Plone Docker Official Image 5.2.13 (5221) open-source software that could allow for remote code execution du
Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. Rated critical seve
Unauthenticated remote code execution in 9router (npm package) versions 0.4.30 through 0.4.36 allows network-adjacent at
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-xppv-4jrx-qf8m