starred/documenso

Fork 0

mirror of https://github.com/documenso/documenso.git synced 2026-04-24 21:36:01 +03:00

[GH-ISSUE #2190] Bug Bounty Report: Security Risk - Application Access Maintained After OAuth Revocation #635

New issue

Open

opened 2026-02-26 18:47:51 +03:00 by kerem · 1 comment

kerem commented

2026-02-26 18:47:51 +03:00

Owner

Originally created by @NH-Limon on GitHub (Nov 13, 2025).
Original GitHub issue: https://github.com/documenso/documenso/issues/2190

Issue Description

Note: I was awarded a $500 reward for reporting the same vulnerability to other companies. They marked this as valid and attempted to fix the bug.

Summary:
Revoking an application's access via the OAuth provider's settings should terminate the session in the main application. However, users are still logged in if the session remains active despite the OAuth disconnection.

Steps to Reproduce

Steps to Reproduce:

Log in to https://app.documenso.com/ via Google OAuth.
Let's say an attacker hijacked your OAuth session, or you logged in to another device not owned by you and forgot to log out from there after using the account, and you wanted to destroy the OAuth session there.
Go to the Google OAuth provider’s settings from your Google account and revoke the application’s access.
You will see that, even after the OAuth provider disconnects, the session remains valid and doesn't terminate.

Expected Behavior

Mitigation:
If a user’s OAuth access is revoked, force the application session to require re-authentication using OAuth. This ensures unauthorized sessions cannot continue.

Current Behavior

Impact:
This flaw allows users or attackers with an active session to retain access even after OAuth access is revoked, creating a significant security risk and bypassing expected session termination mechanisms.

Screenshots (optional)

No response

Operating System [e.g., Windows 10]

No response

Browser [e.g., Chrome, Firefox]

No response

Version [e.g., 2.0.1]

No response

Please check the boxes that apply to this issue report.

I have searched the existing issues to make sure this is not a duplicate.
I have provided steps to reproduce the issue.
I have included relevant environment information.
I have included any relevant screenshots.
I understand that this is a voluntary contribution and that there is no guarantee of resolution.
I want to work on creating a PR for this issue if approved

Originally created by @NH-Limon on GitHub (Nov 13, 2025). Original GitHub issue: https://github.com/documenso/documenso/issues/2190 ### Issue Description Note: I was awarded a $500 reward for reporting the same vulnerability to other companies. They marked this as valid and attempted to fix the bug. Summary: Revoking an application's access via the OAuth provider's settings should terminate the session in the main application. However, users are still logged in if the session remains active despite the OAuth disconnection. ### Steps to Reproduce Steps to Reproduce: 01. Log in to https://app.documenso.com/ via Google OAuth. 02. Let's say an attacker hijacked your OAuth session, or you logged in to another device not owned by you and forgot to log out from there after using the account, and you wanted to destroy the OAuth session there. 03. Go to the Google OAuth provider’s settings from your Google account and revoke the application’s access. 04. You will see that, even after the OAuth provider disconnects, the session remains valid and doesn't terminate. ### Expected Behavior Mitigation: If a user’s OAuth access is revoked, force the application session to require re-authentication using OAuth. This ensures unauthorized sessions cannot continue. ### Current Behavior Impact: This flaw allows users or attackers with an active session to retain access even after OAuth access is revoked, creating a significant security risk and bypassing expected session termination mechanisms. ### Screenshots (optional) _No response_ ### Operating System [e.g., Windows 10] _No response_ ### Browser [e.g., Chrome, Firefox] _No response_ ### Version [e.g., 2.0.1] _No response_ ### Please check the boxes that apply to this issue report. - [x] I have searched the existing issues to make sure this is not a duplicate. - [x] I have provided steps to reproduce the issue. - [ ] I have included relevant environment information. - [ ] I have included any relevant screenshots. - [ ] I understand that this is a voluntary contribution and that there is no guarantee of resolution. - [ ] I want to work on creating a PR for this issue if approved

kerem added the

Stale

status: triage

labels

2026-02-26 18:47:51 +03:00

kerem commented

2026-02-26 18:47:52 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Nov 13, 2025):

Thank you for opening your first issue and for being a part of the open signing revolution!

One of our team members will review it and get back to you as soon as it possible 💚

Meanwhile, please feel free to hop into our community in Discord

@github-actions[bot] commented on GitHub (Nov 13, 2025): Thank you for opening your first issue and for being a part of the open signing revolution! <br /> One of our team members will review it and get back to you as soon as it possible 💚 <br /> Meanwhile, please feel free to hop into our community in [Discord](https://documen.so/discord)

kerem referenced this issue

2026-02-26 19:31:48 +03:00

[PR #640] [MERGED] fix: improve the validation message for documenso app #1091

kerem referenced this issue

2026-02-26 19:31:48 +03:00

[PR #638] [CLOSED] fix: improve the validation message for the documenso app #1093

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/documenso#635

No description provided.

Rows
Columns