-Infinity
0

Vendor Risk Score

See how wger compares to other vendors in security performance

View Risk Score →
Severity
5.1
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

wger before 2.6 (affected versions <= 2.5.0) contains an open redirect vulnerability in the trainerlogin view (wger/core/views/user.py). After a trainer enters impersonation mode, the view redirects to the user-supplied 'next' GET parameter via HttpResponseRedirect() without validating it with urlhasallowedhostandscheme(). An attacker who delivers a crafted link to an authenticated trainer can redirect the trainer's browser to an attacker-controlled domain, enabling phishing and leaking the wger URL structure (including the impersonated user's userpk) via the Referer header.

First published (updated )
Severity
7.6
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L

Summary

wger exposes a global configuration edit endpoint at /config/gym-config/edit implemented by GymConfigUpdateView. The view declares permissionrequired = 'config.changegymconfig' 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 getownerobject(), 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 permissionrequired = 'config.changegymconfig', 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

python patternsgymconfig = [ path('edit', gymconfig.GymConfigUpdateView.asview(), name='edit'), ]

urlpatterns = [ path( 'gym-config/', include((patternsgymconfig, 'gymconfig'), namespace='gymconfig'), ), ]

This resolves to:

/config/gym-config/edit

Root cause

The view declares a permission but does not enforce it

File: wger/config/views/gymconfig.py

python class GymConfigUpdateView(WgerFormMixin, UpdateView): model = GymConfig fields = ('defaultgym',) permissionrequired = 'config.changegymconfig' successurl = reverselazy('gym:gym:list') title = gettextlazy('Edit')

def getobject(self): return GymConfig.objects.get(pk=1)

The permission string exists, but WgerFormMixin does not check permissionrequired.

The project’s permission mixin exists but is not used

File: wger/utils/genericviews.py

python class WgerPermissionMixin: permissionrequired = False loginrequired = False

def dispatch(self, request, args, kwargs): if self.loginrequired or self.permissionrequired: if not request.user.isauthenticated: return HttpResponseRedirect( reverselazy('core:user:login') + f'?next={request.path}' )

if self.permissionrequired: haspermission = False if isinstance(self.permissionrequired, tuple): for permission in self.permissionrequired: if request.user.hasperm(permission): haspermission = True elif request.user.hasperm(self.permissionrequired): haspermission = True

if not haspermission: 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/genericviews.py

python class WgerFormMixin(ModelFormMixin): def dispatch(self, request, args, kwargs): self.kwargs = kwargs self.request = request

if self.ownerobject: ownerobject = self.ownerobject['class'].objects.get(pk=kwargs[self.ownerobject['pk']]) else: try: ownerobject = self.getobject().getownerobject() except AttributeError: ownerobject = False

if ownerobject and ownerobject.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/gymconfig.py

python class GymConfig(models.Model): defaultgym = models.ForeignKey( Gym, verbosename=('Default gym'), # ... null=True, blank=True, ondelete=models.CASCADE, ) # No getownerobject() method

Because GymConfig does not implement getownerobject(), WgerFormMixin catches AttributeError and sets ownerobject = False, skipping any access restriction.

Security impact

This is not a cosmetic setting: GymConfig.save() performs installation-wide side effects.

File: wger/config/models/gymconfig.py

python def save(self, args, kwargs): if self.defaultgym: UserProfile.objects.filter(gym=None).update(gym=self.defaultgym)

for profile in UserProfile.objects.filter(gym=self.defaultgym): user = profile.user if not isanygymadmin(user): try: user.gymuserconfig except GymUserConfig.DoesNotExist: config = GymUserConfig() config.gym = self.defaultgym 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 successurl = reverselazy('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:

bash defaultgymid= None profilesgymnull= 1

After a low-privileged user submitted the form setting defaultgym to gym id 1:

bash defaultgymid= 1 profilesgymnull= 0

Recommended fix

Ensure permission enforcement runs before the form dispatch.

Using the project mixin (order matters):

python class GymConfigUpdateView(WgerPermissionMixin, WgerFormMixin, UpdateView): permissionrequired = 'config.changegymconfig' loginrequired = True

Alternatively, use Django’s PermissionRequiredMixin (and LoginRequiredMixin) directly.

Conclusion

The view explicitly declares permissionrequired = 'config.changegymconfig', 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" />

1 / 2
Source: GitHub
First published (updated )
Severity
5.1
XSS
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Stored XSS via Unescaped License Attribution Fields

Summary

The AbstractLicenseModel.attributionlink property in wger/utils/models.py constructs HTML strings by directly interpolating user-controlled fields (licenseauthor, licensetitle, licenseobjecturl, licenseauthorurl, licensederivativesourceurl) without any escaping. The resulting HTML is rendered in the ingredient view template using Django's |safe filter, which disables auto-escaping. An authenticated user can create an ingredient with a malicious licenseauthor value containing JavaScript, which executes when any user (including unauthenticated visitors) views the ingredient page.

Severity

High (CVSS 3.1: ~7.6)

- Low-privilege attacker (any authenticated non-temporary user) - Stored XSS — persists in database - Triggers on a public page (no authentication needed to view) - Can steal session cookies, perform actions as other users, redirect to phishing

CWE

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Affected Components

Vulnerable Property File: wger/utils/models.py:88-110

python @property def attributionlink(self): out = '' if self.licenseobjecturl: out += f'<a href="{self.licenseobjecturl}">{self.licensetitle}</a>' else: out += self.licensetitle # NO ESCAPING out += ' by ' if self.licenseauthorurl: out += f'<a href="{self.licenseauthorurl}">{self.licenseauthor}</a>' else: out += self.licenseauthor # NO ESCAPING out += f' is licensed under <a href="{self.license.url}">{self.license.shortname}</a>' if self.licensederivativesourceurl: out += ( f'/ A derivative work from <a href="{self.licensederivativesourceurl}">the ' f'original work</a>' ) return out

Unsafe Template Rendering File: wger/nutrition/templates/ingredient/view.html

- Line 171: {{ ingredient.attributionlink|safe }} - Line 226: {{ image.attributionlink|safe }}

Writable Entry Point File: wger/nutrition/views/ingredient.py:154-175

python class IngredientCreateView(WgerFormMixin, CreateView): model = Ingredient formclass = IngredientForm # includes licenseauthor field

URL: loginrequired(ingredient.IngredientCreateView.asview()) — any authenticated non-temporary user.

Form fields (from wger/nutrition/forms.py:295-313): includes licenseauthor (TextField, maxlength=3500) — no sanitization.

Models Affected

6 models inherit from AbstractLicenseModel: - Exercise, ExerciseImage, ExerciseVideo, Translation (exercises module) - Ingredient, Image (nutrition module)

Only the Ingredient and nutrition Image models' attribution links are currently rendered with |safe in templates.

Root Cause

1. attributionlink constructs raw HTML by string interpolation of user-controlled fields without calling django.utils.html.escape() or django.utils.html.formathtml() 2. The template renders the result with |safe, bypassing Django's auto-escaping 3. The licenseauthor field in IngredientForm has no input sanitization 4. The setauthor() method only sets a default value if the field is empty — it does not sanitize user-provided values

Reproduction Steps (Verified)

Prerequisites - A wger instance with user registration enabled (default) - An authenticated user account (non-temporary)

Steps

1. Register/login to a wger instance

2. Create a malicious ingredient via the web form at /en/nutrition/ingredient/add/: - Set Name to any valid name (e.g., "XSS Form Verified") - Set Energy to 125, Protein to 10, Carbohydrates to 10, Fat to 5 (energy must approximately match macros) - Set Author(s) (licenseauthor) to: <img src=x onerror="alert(document.cookie)"> - Submit the form — the form validates and saves successfully with no sanitization

3. View the ingredient page (public URL, no auth needed): - Navigate to the newly created ingredient's detail page - The XSS payload executes in the browser

Verified PoC Output

The rendered HTML in the ingredient detail page (line 171 of ingredient/view.html) contains:

html <small> by <img src=x onerror=alert(1)> is licensed under <a href="https://creativecommons.org/licenses/by-sa/3.0/deed.en">CC-BY-SA 3</a> </small>

The <img> tag with onerror handler is injected directly into the page DOM and executes JavaScript when the browser attempts to load the non-existent image.

Alternative API Path (ExerciseImage)

For users who are "trustworthy" (account >3 weeks old + verified email):

bash Upload exercise image with XSS in licenseauthor curl -X POST https://wger.example.com/api/v2/exerciseimage/ \ -H "Authorization: Token <token>" \ -F "exercise=1" \ -F "image=@photo.jpg" \ -F 'licenseauthor=<img src=x onerror="alert(document.cookie)">' \ -F "license=2"

Note: ExerciseImage's attributionlink is not currently rendered with |safe in exercise templates, but the data is stored with XSS payloads and would execute if any template renders it with |safe in the future. The API serializer also returns the unescaped attributionlink data, which could cause XSS in API consumers (mobile apps, SPAs).

Impact

- Session hijacking: Steal admin session cookies to gain full control - Account takeover: Modify other users' passwords or email addresses - Data theft: Access other users' workout plans, nutrition data, and personal measurements - Worm-like propagation: Malicious ingredient could inject XSS that creates more malicious ingredients - Phishing: Redirect users to fake login pages

Suggested Fix

Replace the attributionlink property with properly escaped HTML using Django's formathtml():

python from django.utils.html import formathtml, escape

@property def attributionlink(self): parts = []

if self.licenseobjecturl: parts.append(formathtml('<a href="{}">{}</a>', self.licenseobjecturl, self.licensetitle)) else: parts.append(escape(self.licensetitle))

parts.append(' by ')

if self.licenseauthorurl: parts.append(formathtml('<a href="{}">{}</a>', self.licenseauthorurl, self.licenseauthor)) else: parts.append(escape(self.licenseauthor))

parts.append(formathtml( ' is licensed under <a href="{}">{}</a>', self.license.url, self.license.shortname ))

if self.licensederivativesourceurl: parts.append(formathtml( '/ A derivative work from <a href="{}">the original work</a>', self.licensederivativesourceurl ))

return marksafe(''.join(str(p) for p in parts))

Alternatively, remove the |safe filter from the templates and escape in the property, though this would break the anchor tags.

References

- Django Security: Cross Site Scripting (XSS) protection - Django formathtml() documentation - OWASP: Stored Cross-Site Scripting

1 / 2
Source: GitHub
First published (updated )
Severity
4.3
EPSS
0.03%
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Summary

RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet return all users' repetition config data because their getqueryset() calls .all() instead of filtering by the authenticated user. Any registered user can enumerate every other user's workout structure.

Details

wger/manager/api/views.py:499 and :518:

python VULNERABLE class RepetitionsConfigViewSet(viewsets.ModelViewSet): def getqueryset(self): return RepetitionsConfig.objects.all()

class MaxRepetitionsConfigViewSet(viewsets.ModelViewSet): def getqueryset(self): return MaxRepetitionsConfig.objects.all()

Every sibling viewset in the same file correctly filters by user. For example, WeightConfigViewSet at line 459:

python CORRECT — how it should work def getqueryset(self): return WeightConfig.objects.filter( slotentryslotdayroutineuser=self.request.user )

The same user filter is present on SetsConfig, RestConfig, RiRConfig, and their Max variants — only RepetitionsConfig and MaxRepetitionsConfig are missing it.

PoC

python import requests

BASE = "http://localhost" headers = {"Authorization": "Token YOURTOKEN"} # any registered user

r = requests.get(f"{BASE}/api/v2/repetitions-config/", headers=headers) print(r.json()) # returns ALL users' repetition configs, not just your own

r = requests.get(f"{BASE}/api/v2/max-repetitions-config/", headers=headers) print(r.json()) # same — all users' max repetition configs

Registration is open by default. Sequential IDs allow full enumeration.

Impact

Any authenticated user can read other users' repetition and max-repetitions configs, exposing workout structure (slot entry IDs, iteration values, operations, step counts, repeat flags, requirements JSON). This is a broken object-level authorization (BOLA/IDOR) vulnerability — the same class of issue as OWASP API1.

Fix: Add the same user filter used by every other config viewset: python def getqueryset(self): return RepetitionsConfig.objects.filter( slotentryslotdayroutineuser=self.request.user )

1 / 2
Source: GitHub
First published (updated )
Severity
3.5
EPSS
0.03%
AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

Summary

Five routine detail action endpoints check a cache before calling self.getobject(). Cache keys are scoped only by pk — no user ID is included. When a victim has previously accessed their routine via the API, an attacker can retrieve the cached response for the same PK without any ownership check.

Details

wger/manager/api/views.py — five actions follow this pattern (lines 134–201):

python @action(detail=True) def datesequencedisplaymode(self, request, pk=None): cachekey = makeroutineapidatesequencedisplaycachekey(pk) cached = cache.get(cachekey) if cached: return Response(cached) # returned WITHOUT calling self.getobject() # only reaches ownership check on cache miss routine = self.getobject() ...

Cache key construction in wger/utils/cache.py:89–106:

python def makeroutineapidatesequencedisplaycachekey(routineid): return f"routine-api-date-sequence-display-{routineid}" # No user ID in key

Cache TTL: 1 month (4 604800 seconds, settingsglobal.py:461).

Affected endpoints: GET /api/v2/routine/{pk}/date-sequence-display/ GET /api/v2/routine/{pk}/date-sequence-gym/ GET /api/v2/routine/{pk}/structure/ GET /api/v2/routine/{pk}/logs/ GET /api/v2/routine/{pk}/stats/

PoC

1. Victim (user A) visits GET /api/v2/routine/5/structure/ → response cached under key "routine-api-structure-5" 2. Attacker (user B) visits GET /api/v2/routine/5/structure/ → cache hit → returns user A's routine structure without any ownership check

Requires the victim to have previously accessed the endpoint (cache must be populated). Once populated, the cache entry is valid for 1 month.

Impact

An attacker with a registered account can retrieve another user's routine details — workout day sequences, exercise structure, training logs, and statistics — from cache without ownership verification.

Fix: Include the user ID in the cache key: python def makeroutineapidatesequencedisplaycachekey(routineid, userid): return f"routine-api-date-sequence-display-{userid}-{routineid}"

Or move self.getobject() before the cache lookup so ownership is always verified first.

1 / 2
Source: GitHub
First published (updated )
Severity
4.3
EPSS
0.03%
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Summary

Three nutritionalvalues action endpoints fetch objects via Model.objects.get(pk=pk) — a raw ORM call that bypasses the user-scoped queryset. Any authenticated user can read another user's private nutrition plan data, including caloric intake and full macro breakdown, by supplying an arbitrary PK.

Details

DRF detail actions do not automatically apply queryset filtering — the action must call self.getobject() to enforce object-level permissions. These three endpoints skip that and go directly to the ORM:

wger/nutrition/api/views.py:

python line 301 — NutritionPlanViewSet plan = NutritionPlan.objects.get(pk=pk) # VULNERABLE — no user check

line 356 — MealViewSet meal = Meal.objects.get(pk=pk) # VULNERABLE

line 403 — MealItemViewSet mealitem = MealItem.objects.get(pk=pk) # VULNERABLE

The correct pattern used in the same file at LogItemViewSet (line 438):

python LogItem.objects.get(pk=pk, planuser=self.request.user) # CORRECT

Affected endpoints: GET /api/v2/nutritionplan/{pk}/nutritionalvalues/ GET /api/v2/meal/{pk}/nutritionalvalues/ GET /api/v2/mealitem/{pk}/nutritionalvalues/

PoC

python import requests

BASE = "http://localhost" Attacker's token (any registered user) headers = {"Authorization": "Token ATTACKERTOKEN"}

Read victim's nutrition plan — enumerate pk starting from 1 for pk in range(1, 100): r = requests.get( f"{BASE}/api/v2/nutritionplan/{pk}/nutritionalvalues/", headers=headers ) if r.statuscode == 200: data = r.json() print(f"Plan {pk}: {data}") # Returns: energy (kcal), protein, carbohydrates, carbohydratessugar, # fat, fatsaturated, fiber, sodium

No interaction from the victim required. Registration is open by default. PKs are sequential integers.

Impact

Any authenticated user can read other users' private dietary and health data: - Daily caloric intake - Protein, carbohydrate, fat, fiber, and sodium intake - Full meal composition and ingredient quantities

This data is sensitive health information users expect to be private.

Fix: Replace direct ORM calls with self.getobject(), which applies the viewset's user-scoped queryset and object-level permissions automatically. Or add an explicit user filter: NutritionPlan.objects.get(pk=pk, user=self.request.user).

1 / 2
Source: GitHub
First published (updated )
Severity
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Improper Restriction of Excessive Authentication Attempts in GitHub repository wger-project/wger prior to 2.2.

First published (updated )
Severity
8.8
CSRF
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Cross Site Request Forgery (CSRF) vulnerability in wger Project wger Workout Manager 2.2.0a3 allows a remote attacker to gain privileges via the user-management feature in the gym/views/gym.py, templates/gym/resetuserpassword.html, templates/user/overview.html, core/views/user.py, and templates/user/preferences.html, core/forms.py components.

1 / 2
First published (updated )
Severity
5.4
XSS
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

Cross Site Scripting vulnerability in wger Project wger Workout Manager v.2.2.0a3 allows a remote attacker to gain privileges via the licenseauthor field in the add-ingredient function in the templates/ingredients/view.html, models/ingredients.py, and views/ingredients.py components.

1 / 2
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203