CVE-2026-4171
Authorization Bypass in CodeGenieApp API Endpoint via userId Manipulation
Publication date: 2026-03-16
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| codegenie | serverless-express | to 4.17.1 (inc) |
| codegenieapp | serverless-express | to 4.17.1 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-285 | The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. |
| 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?
[{'type': 'paragraph', 'content': "CVE-2026-4171 is a critical Broken Object Level Authorization (BOLA) vulnerability in CodeGenieApp serverless-express versions up to 4.17.1. The root cause is the absence of an ownership model in the TodoList management system's database schema, specifically the lack of a userId field in the TodoList DynamoDB table. This means todo lists are not linked to their creators."}, {'type': 'paragraph', 'content': "Because of this, an attacker who obtains a valid listId—possibly through leaked URLs, Referer headers, or by exploiting related vulnerabilities—can use their own authenticated session to access, modify, or delete any other user's todo lists without proper authorization checks."}, {'type': 'paragraph', 'content': 'The vulnerability arises from improper handling and manipulation of the userId argument in the API endpoint, allowing authorization bypass remotely. This leads to a complete compromise of data confidentiality, integrity, and availability.'}] [1, 2, 4]
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': "This vulnerability can have severe impacts including unauthorized access to all todo list data, modification or corruption of others' todo lists, and permanent deletion of todo lists belonging to other users."}, {'type': 'list_item', 'content': "Confidentiality: Attackers can read any user's todo list data."}, {'type': 'list_item', 'content': "Integrity: Attackers can modify or corrupt other users' todo lists."}, {'type': 'list_item', 'content': 'Availability: Attackers can delete todo lists of other users, causing data loss.'}, {'type': 'paragraph', 'content': 'The attack can be carried out remotely with low complexity and requires only low privileges, making it relatively easy for attackers to exploit once a valid listId is known.'}] [1, 2, 4]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by testing the API endpoints related to todo lists for improper authorization checks. Specifically, attempts to access, modify, or delete todo lists using valid listId values that belong to other users can reveal the authorization bypass.'}, {'type': 'paragraph', 'content': 'Suggested detection approach includes sending authenticated requests to the following endpoints with listId values not owned by the authenticated user:'}, {'type': 'list_item', 'content': 'GET /todo-lists/:listId'}, {'type': 'list_item', 'content': 'PUT /todo-lists/:listId'}, {'type': 'list_item', 'content': 'DELETE /todo-lists/:listId'}, {'type': 'paragraph', 'content': 'If these requests succeed in accessing or modifying data without ownership verification, the vulnerability is present.'}, {'type': 'paragraph', 'content': 'Example curl commands to test the vulnerability (replace <token> with a valid JWT and <listId> with a list ID not owned by the user):'}, {'type': 'list_item', 'content': 'curl -H "Authorization: Bearer <token>" https://api.example.com/todo-lists/<listId>'}, {'type': 'list_item', 'content': 'curl -X PUT -H "Authorization: Bearer <token>" -d \'{"title":"test"}\' https://api.example.com/todo-lists/<listId>'}, {'type': 'list_item', 'content': 'curl -X DELETE -H "Authorization: Bearer <token>" https://api.example.com/todo-lists/<listId>'}] [2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Modify the TodoList database schema to include a required userId attribute to establish ownership of todo lists.
- Implement strict authorization checks in the API endpoints to verify that the authenticated user owns the todo list identified by listId before allowing access or modification.
- Use DynamoDB ConditionExpressions or equivalent mechanisms to enforce ownership checks at the data access layer.
- Create a Global Secondary Index (GSI) on userId to facilitate secure querying of todo lists by their owners.
- For existing data, perform data migration to assign ownership to todo lists or archive orphaned records.
If immediate code changes are not possible, consider restricting access to the vulnerable API endpoints or replacing the affected component with an alternative product.