starred/documenso

Fork 0

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

[GH-ISSUE #2461] Bug Report: Account Deletion Without Password Confirmation — No Re-Authentication Required to Delete Account #684

New issue

Closed

opened 2026-02-26 18:48:03 +03:00 by kerem · 7 comments

kerem commented

2026-02-26 18:48:03 +03:00

Owner

Originally created by @Cyberheroes1010 on GitHub (Feb 9, 2026).
Original GitHub issue: https://github.com/documenso/documenso/issues/2461

Issue Description

Reported by: Vikash Gupta
Severity: High
Category: Authentication / Authorization / Business Logic / Insecure Account Management
Summary

The account deletion flow allows a user (or an attacker who can trigger the request) to delete an account without requiring the current password, re-authentication, or strong secondary verification (MFA/OTP). Because deletion is a destructive, high-impact operation, the absence of password confirmation enables account takeover, denial-of-service against users, data loss, and abuse via CSRF/parameter tampering or session theft.

Steps to Reproduce

STEP TO REPRODUCED
1- Go to URL :- https://app.documenso.com/signin
2- Login & Go to profile & You see delete account
2- Click on Delete Account & All data

BOOOM! Account delete without authentication !!
Impact

Expected Behavior

🗑️ Unauthorized Account Deletion / Denial-of-Service: An attacker who obtains a session, forges a request, or tampers with parameters (or even uses CSRF) can permanently delete a user’s account.

🔐 Account Takeover Facilitation: Deleting an account may be used as a cleanup step by attackers after takeover or as a step to block recovery for the legitimate owner.

📉 Permanent Data Loss: User data (profiles, content, billing history) may be irreversibly removed if deletion is immediate and hard-deletes data.

⚖️ Compliance & Legal Risk: Inconsistent deletion processes can conflict with regulated data-retention or erasure policies (GDPR — but also must be able to prove proper consent/authorization for deletion).

🔁 Operational Overhead: High support burden for manual restores, investigations, and remediation after unauthorized deletions.

🧩 Trust & Reputation Damage: Users expect destructive actions to require strong proofs; lack of it undermines platform trust.

Business Impact

💼 Customer Churn / Business Disruption: Loss of user data and inability to recover accounts lead to churn and potential SLA violations.

💸 Financial Exposure: Deletion of billing or contract records may cause billing disputes, refunds, or revenue impact.

⚖️ Regulatory Exposure: Improper deletion authorization or evidence of negligent controls could trigger regulatory action or fines.

🛠️ Support & Engineering Cost: Manual account recovery, incident response, and root-cause fixes increase operational costs.

🔍 Public Relations Risk: High-profile or repeated incidents can damage brand reputation and user confidence.

CVSS v3.1 (recommended)

Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Score: 8.8 — High

Vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Rationale: Network-exploitable destructive action with no re-authentication. Results in high confidentiality/integrity/availability impact for affected accounts.
Root Cause (likely)

Current Behavior

Deletion endpoint trusts an authenticated session or token without checking session freshness or requiring password re-entry.

Lack of server-side re-authentication, MFA, or secondary confirmation for destructive operations.

Endpoint may accept unauthenticated or poorly validated requests (susceptible to CSRF or parameter tampering).

Missing or weak audit/logging and lack of a safe "pending deletion" workflow (hard delete applied immediately).

UI-only protections without corresponding server-side checks; relying on client behavior for security.

Recommended Remediation (High priority)

Require Re-Authentication (Password) Before Deletion

    Always require the current password (or an equivalent recent authentication) to perform account deletion. Treat deletion as a privileged action.

Enforce Strong Secondary Verification for High-Risk Accounts

    For accounts with elevated access or sensitive data, require MFA confirmation (OTP, authenticator) before allowing deletion.

Use a Pending Deletion Workflow (Soft-Delete + Grace Period)

    Mark accounts as pending_deletion and delay irreversible deletion (e.g., 7–30 days). During the grace period allow easy self-restore and notify the old email.

Confirm via Existing Email & Provide Cancel Option

    Send an explicit email to the account owner (current email) with a secure cancel/revert link and only finalize deletion after confirmation or after expiry of the grace period.

Protect Endpoints from CSRF & Parameter Tampering

    Ensure deletion endpoints require CSRF tokens, use SameSite cookies, and validate request origin/Referer. Reject requests containing unexpected parameters.

Enforce Endpoint-Level Authorization & Freshness

    Check session age and require recent authentication (reauth) or token freshness for destructive actions. Reject stale sessions.

Log, Audit & Alert

    Log deletion initiation requests, confirmations, IPs, user agents, and outcome. Alert on suspicious patterns (multiple deletions from same IP, mass deletions).

Require Human Review for High-Risk Cases

    For enterprise/admin accounts or bulk-deletion requests, require manual review or secondary approval.

Provide Clear UX & Explicit Warnings

    Make the deletion flow explicit, require typed confirmation (e.g., enter email or “DELETE”), and show consequences clearly.

Implement Recovery & Forensics Procedures

    Ensure backups and procedures exist to recover accidentally or maliciously deleted data; maintain audit trails for forensic analysis.

Conclusion

Allowing account deletion without password confirmation is a serious security and business risk: it permits unauthorized destructive actions, data loss, and potential cover-up after account takeover. Implement re-authentication, strong verification, soft-delete with grace periods, CSRF protections, and thorough logging immediately to mitigate risk and protect user data.

Reported by: Vikash Gupta

Screenshots (optional)

Operating System [e.g., Windows 10]

Browser [e.g., Chrome, Firefox]

firefox

Version [e.g., 2.0.1]

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 @Cyberheroes1010 on GitHub (Feb 9, 2026). Original GitHub issue: https://github.com/documenso/documenso/issues/2461 ### Issue Description Reported by: Vikash Gupta Severity: High Category: Authentication / Authorization / Business Logic / Insecure Account Management Summary The account deletion flow allows a user (or an attacker who can trigger the request) to delete an account without requiring the current password, re-authentication, or strong secondary verification (MFA/OTP). Because deletion is a destructive, high-impact operation, the absence of password confirmation enables account takeover, denial-of-service against users, data loss, and abuse via CSRF/parameter tampering or session theft. ### Steps to Reproduce STEP TO REPRODUCED 1- Go to URL :- https://app.documenso.com/signin 2- Login & Go to profile & You see delete account 2- Click on Delete Account & All data BOOOM! Account delete without authentication !! Impact <img width="1919" height="953" alt="Image" src="https://github.com/user-attachments/assets/92d0ca21-1b9d-4da8-a2d4-67dd4e0e255e" /> ### Expected Behavior 🗑️ Unauthorized Account Deletion / Denial-of-Service: An attacker who obtains a session, forges a request, or tampers with parameters (or even uses CSRF) can permanently delete a user’s account. 🔐 Account Takeover Facilitation: Deleting an account may be used as a cleanup step by attackers after takeover or as a step to block recovery for the legitimate owner. 📉 Permanent Data Loss: User data (profiles, content, billing history) may be irreversibly removed if deletion is immediate and hard-deletes data. ⚖️ Compliance & Legal Risk: Inconsistent deletion processes can conflict with regulated data-retention or erasure policies (GDPR — but also must be able to prove proper consent/authorization for deletion). 🔁 Operational Overhead: High support burden for manual restores, investigations, and remediation after unauthorized deletions. 🧩 Trust & Reputation Damage: Users expect destructive actions to require strong proofs; lack of it undermines platform trust. Business Impact 💼 Customer Churn / Business Disruption: Loss of user data and inability to recover accounts lead to churn and potential SLA violations. 💸 Financial Exposure: Deletion of billing or contract records may cause billing disputes, refunds, or revenue impact. ⚖️ Regulatory Exposure: Improper deletion authorization or evidence of negligent controls could trigger regulatory action or fines. 🛠️ Support & Engineering Cost: Manual account recovery, incident response, and root-cause fixes increase operational costs. 🔍 Public Relations Risk: High-profile or repeated incidents can damage brand reputation and user confidence. CVSS v3.1 (recommended) Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H Score: 8.8 — High Vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H Rationale: Network-exploitable destructive action with no re-authentication. Results in high confidentiality/integrity/availability impact for affected accounts. Root Cause (likely) ### Current Behavior Deletion endpoint trusts an authenticated session or token without checking session freshness or requiring password re-entry. Lack of server-side re-authentication, MFA, or secondary confirmation for destructive operations. Endpoint may accept unauthenticated or poorly validated requests (susceptible to CSRF or parameter tampering). Missing or weak audit/logging and lack of a safe "pending deletion" workflow (hard delete applied immediately). UI-only protections without corresponding server-side checks; relying on client behavior for security. Recommended Remediation (High priority) Require Re-Authentication (Password) Before Deletion Always require the current password (or an equivalent recent authentication) to perform account deletion. Treat deletion as a privileged action. Enforce Strong Secondary Verification for High-Risk Accounts For accounts with elevated access or sensitive data, require MFA confirmation (OTP, authenticator) before allowing deletion. Use a Pending Deletion Workflow (Soft-Delete + Grace Period) Mark accounts as pending_deletion and delay irreversible deletion (e.g., 7–30 days). During the grace period allow easy self-restore and notify the old email. Confirm via Existing Email & Provide Cancel Option Send an explicit email to the account owner (current email) with a secure cancel/revert link and only finalize deletion after confirmation or after expiry of the grace period. Protect Endpoints from CSRF & Parameter Tampering Ensure deletion endpoints require CSRF tokens, use SameSite cookies, and validate request origin/Referer. Reject requests containing unexpected parameters. Enforce Endpoint-Level Authorization & Freshness Check session age and require recent authentication (reauth) or token freshness for destructive actions. Reject stale sessions. Log, Audit & Alert Log deletion initiation requests, confirmations, IPs, user agents, and outcome. Alert on suspicious patterns (multiple deletions from same IP, mass deletions). Require Human Review for High-Risk Cases For enterprise/admin accounts or bulk-deletion requests, require manual review or secondary approval. Provide Clear UX & Explicit Warnings Make the deletion flow explicit, require typed confirmation (e.g., enter email or “DELETE”), and show consequences clearly. Implement Recovery & Forensics Procedures Ensure backups and procedures exist to recover accidentally or maliciously deleted data; maintain audit trails for forensic analysis. Conclusion Allowing account deletion without password confirmation is a serious security and business risk: it permits unauthorized destructive actions, data loss, and potential cover-up after account takeover. Implement re-authentication, strong verification, soft-delete with grace periods, CSRF protections, and thorough logging immediately to mitigate risk and protect user data. Reported by: Vikash Gupta ### Screenshots (optional) <img width="1919" height="953" alt="Image" src="https://github.com/user-attachments/assets/65d5481d-acd9-469c-a588-dddf094c1fdf" /> ### Operating System [e.g., Windows 10] 1 ### Browser [e.g., Chrome, Firefox] firefox ### Version [e.g., 2.0.1] 1 ### 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. - [x] I have included relevant environment information. - [x] I have included any relevant screenshots. - [x] I understand that this is a voluntary contribution and that there is no guarantee of resolution. - [x] I want to work on creating a PR for this issue if approved

kerem

2026-02-26 18:48:03 +03:00

closed this issue
added the
💰 Rewarded

status: triage
labels

kerem commented

2026-02-26 18:48:03 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Feb 9, 2026):

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 (Feb 9, 2026): 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 commented

2026-02-26 18:48:03 +03:00

Author

Owner

@Mythie commented on GitHub (Feb 9, 2026):

Come talk to support@documenso.com

@Mythie commented on GitHub (Feb 9, 2026): Come talk to support@documenso.com

kerem commented

2026-02-26 18:48:03 +03:00

Author

Owner

@Cyberheroes1010 commented on GitHub (Feb 9, 2026):

check it sir

On Mon, Feb 9, 2026 at 8:15 PM Lucas Smith @.***> wrote:

Mythie left a comment (documenso/documenso#2461)
https://github.com/documenso/documenso/issues/2461#issuecomment-3872018447

Come talk to @.***

—
Reply to this email directly, view it on GitHub
https://github.com/documenso/documenso/issues/2461#issuecomment-3872018447,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BUKJRSOHOSE25I26PORG55D4LCMPNAVCNFSM6AAAAACUPKGV7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNZSGAYTQNBUG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

@Cyberheroes1010 commented on GitHub (Feb 9, 2026): check it sir On Mon, Feb 9, 2026 at 8:15 PM Lucas Smith ***@***.***> wrote: > *Mythie* left a comment (documenso/documenso#2461) > <https://github.com/documenso/documenso/issues/2461#issuecomment-3872018447> > > Come talk to ***@***.*** > > — > Reply to this email directly, view it on GitHub > <https://github.com/documenso/documenso/issues/2461#issuecomment-3872018447>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BUKJRSOHOSE25I26PORG55D4LCMPNAVCNFSM6AAAAACUPKGV7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNZSGAYTQNBUG4> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

kerem commented

2026-02-26 18:48:03 +03:00

Author

Owner

@Cyberheroes1010 commented on GitHub (Feb 9, 2026):

fix it issue !

@Cyberheroes1010 commented on GitHub (Feb 9, 2026): fix it issue !

kerem commented

2026-02-26 18:48:03 +03:00

Author

Owner

@Cyberheroes1010 commented on GitHub (Feb 10, 2026):

Any update?? Sir

@Cyberheroes1010 commented on GitHub (Feb 10, 2026): Any update?? Sir

kerem commented

2026-02-26 18:48:04 +03:00

Author

Owner

@Mythie commented on GitHub (Feb 10, 2026):

/tip $200

@Mythie commented on GitHub (Feb 10, 2026): /tip $200

kerem commented

2026-02-26 18:48:04 +03:00

Author

Owner

@algora-pbc[bot] commented on GitHub (Feb 10, 2026):

🎉🎈 @Cyberheroes1010 has been awarded $200 by Documenso! 🎈🎊

@algora-pbc[bot] commented on GitHub (Feb 10, 2026): 🎉🎈 @Cyberheroes1010 has been awarded **$200** by **Documenso**! 🎈🎊

kerem referenced this issue

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

[PR #684] [MERGED] fix: remove server actions #1119

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#684

No description provided.

Rows
Columns