CVE-2026-35478
InvenTree API Token Forgery Allows Full User Impersonation
Publication date: 2026-04-08
Last updated on: 2026-04-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| inventree_project | inventree | From 0.16.0 (inc) to 1.2.6 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | 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. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability affects the InvenTree inventory management system versions from 0.16.0 up to but not including 1.2.7. It allows any authenticated user to create a valid API token for any other user in the system, including administrators and superusers, by specifying the target user's ID in a POST /api/user/tokens/ request.
The generated token can then be used immediately to authenticate as the targeted user via the API from any network location, without requiring any further interaction or permissions.
This flaw has low attack complexity, requires only low privileges, and no user interaction, making it a serious security issue.
How can this vulnerability impact me? :
The vulnerability can lead to significant security impacts including high confidentiality and integrity loss.
- An attacker with any authenticated user account can impersonate any other user, including administrators and superusers.
- The attacker can gain full API access as the targeted user from any network location.
- This can result in unauthorized access to sensitive data, modification of data, and potentially disruption of services.
The availability impact is considered low, but the confidentiality and integrity impacts are high.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, you should upgrade your InvenTree installation to version 1.2.7 or later, as the issue is fixed in versions 1.2.7 and 1.3.0.
No workarounds are available, so applying the patch by upgrading is the immediate and recommended step.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows any authenticated user to create a valid API token for any other user, including administrators and superusers, enabling full API authentication as the targeted user without further interaction.
Such unauthorized access can lead to high confidentiality and integrity loss, which may result in exposure or unauthorized modification of sensitive data.
Consequently, this flaw could negatively impact compliance with data protection standards and regulations like GDPR and HIPAA, which require strict controls over access to personal and sensitive information.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves an authenticated user creating a valid API token for any other user by sending a POST request to /api/user/tokens/ with the target user's ID in the user field.
To detect exploitation attempts on your network or system, you can monitor for unusual POST requests to the /api/user/tokens/ endpoint that include user IDs other than the authenticated user's own ID.
Suggested commands to help detect such activity include:
- Using network traffic monitoring tools like tcpdump or Wireshark to filter POST requests to /api/user/tokens/.
- Example tcpdump command: tcpdump -A -s 0 'tcp port 80 or tcp port 443' | grep '/api/user/tokens/'
- Checking application logs for POST requests to /api/user/tokens/ where the user field differs from the authenticated user.
- Example grep command on server logs: grep 'POST /api/user/tokens/' /path/to/inventree/logs/* | grep -v 'user_id=<authenticated_user_id>'
Note that no specific detection commands or tools are provided in the available resources, so these suggestions are based on the nature of the vulnerability and typical monitoring practices.