starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: IDOR in Media Progress Controller #3236

New Issue
Closed
opened 2026-04-25 00:14:26 +02:00 by adam · 2 comments
adam commented 2026-04-25 00:14:26 +02:00
Owner
Copy Link
Copy Source

Originally created by @mandreko on GitHub (Feb 16, 2026).

What happened?

I was looking through the server code and noticed that the server/controllers/MeController.js does not validate the user when deleting the mediaProgresses data. This allows an attacker to delete the progress of a victim user, if they can identify the GUID of the mediaProgresses record (which is admittedly fairly difficult unless there's a leak somewhere).

I'm unsure how an attacker would get the mediaProgressId for an attacker organically, and due to it being a GUID they can't really brute-force it. Because of this, it would likely lower the severity of this finding fairly drastically. However, it is still a vulnerability in software that I use myself, so I'm hoping to make it better, even if only slightly.

What did you expect to happen?

The server code should validate that the mediaProgresses record belongs to the user making the request (or potentially an admin?)

Steps to reproduce the issue

  1. To test this, I ran audiobookshelf in a docker container using the default docker-compose.yml file, added a couple audio books to the audiobooks folder, and created a library for that folder. I then setup 2 users (user1 and user2). I logged in as user1, listened to the book for a bit, and saw that a record was created in mediaProgresses for my user (validated in sqlite with select * from mediaProgresses mp INNER JOIN users u on mp.userId = u.Id where u.username = 'user1';. I then logged out, and in a new browser session logged in as user2. Using the bearer token for user2, I crafted a request using BurpSuite to request DELETE /api/me/progress/<victim-media-progress-id>.
Image

After the request, the mediaProgresses record was missing from the database.

Audiobookshelf version

v2.32.1

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

Additional Notes

No response

Originally created by @mandreko on GitHub (Feb 16, 2026). ### What happened? I was looking through the `server` code and noticed that the `server/controllers/MeController.js` does not validate the user when deleting the `mediaProgresses` data. This allows an attacker to delete the progress of a victim user, if they can identify the GUID of the `mediaProgresses` record (which is admittedly fairly difficult unless there's a leak somewhere). I'm unsure how an attacker would get the `mediaProgressId` for an attacker organically, and due to it being a GUID they can't really brute-force it. Because of this, it would likely lower the severity of this finding fairly drastically. However, it *is* still a vulnerability in software that I use myself, so I'm hoping to make it better, even if only slightly. ### What did you expect to happen? The server code should validate that the `mediaProgresses` record belongs to the user making the request (or potentially an admin?) ### Steps to reproduce the issue 1. To test this, I ran audiobookshelf in a docker container using the default `docker-compose.yml` file, added a couple audio books to the `audiobooks` folder, and created a library for that folder. I then setup 2 users (`user1` and `user2`). I logged in as `user1`, listened to the book for a bit, and saw that a record was created in `mediaProgresses` for my user (validated in sqlite with `select * from mediaProgresses mp INNER JOIN users u on mp.userId = u.Id where u.username = 'user1';`. I then logged out, and in a new browser session logged in as `user2`. Using the bearer token for `user2`, I crafted a request using BurpSuite to request `DELETE /api/me/progress/<victim-media-progress-id>`. <img width="1319" height="651" alt="Image" src="https://github.com/user-attachments/assets/ff6451e2-7b0d-4b55-9200-8b6afaaaf4d5" /> After the request, the `mediaProgresses` record was missing from the database. ### Audiobookshelf version v2.32.1 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? None ### Logs ```shell ``` ### Additional Notes _No response_
adam added the bug label 2026-04-25 00:14:26 +02:00
adam closed this issue 2026-04-25 00:14:26 +02:00
adam commented 2026-04-25 00:14:27 +02:00
Author
Owner
Copy Link
Copy Source

@mandreko commented on GitHub (Feb 16, 2026):

I'm not entirely sure yet, but this may also affect the createBookmark and getItemListeningSessions methods as well, since I don't see access control checks in there.

@mandreko commented on GitHub (Feb 16, 2026): I'm not entirely sure yet, but this may also affect the `createBookmark` and `getItemListeningSessions` methods as well, since I don't see access control checks in there.
adam commented 2026-04-25 00:14:27 +02:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Mar 12, 2026):

Fixed in v2.33.0.

@github-actions[bot] commented on GitHub (Mar 12, 2026): Fixed in [v2.33.0](https://github.com/advplyr/audiobookshelf/releases/tag/v2.33.0).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#3236
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?