starred/documenso

Fork 0

mirror of https://github.com/documenso/documenso.git synced 2026-04-25 13:55:59 +03:00

[GH-ISSUE #2475] [Bug] Validation bypass allows creating "Ghost Recipients" (empty email) leading to broken UI state #690

New issue

Closed

opened 2026-02-26 18:48:04 +03:00 by kerem · 1 comment

kerem commented

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

Owner

Originally created by @abdulalim110 on GitHub (Feb 11, 2026).
Original GitHub issue: https://github.com/documenso/documenso/issues/2475

Issue Description

Description

I found a validation bypass in the Document Creation flow (Step 1). The frontend validation for the recipient's email can be bypassed by filling in the details and then deleting the email address before proceeding.

This results in "Ghost Recipients" being created in the system with empty email strings. Crucially, the system even generates valid signing links for these non-existent users, leading to a broken state.

Steps to Reproduce

Upload a document and proceed to Step 1: Add Recipient.
Type a valid email and name to trigger the UI state.
Delete the email address (leave it empty).
Notice that the "Next" / "Add Fields" button remains active.
Proceed to add a field and send the document.

Actual Behavior

The system accepts the empty email string.
The Dashboard displays "Ghost Avatars" (empty grey circles) with no initials or tooltip info (see screenshot).
Critical: The system generates valid signing links for recipients with no identity.
This creates rows in the database with empty email strings, which compromises data integrity and can lead to 500 Server Errors during the signing process due to missing relations.

Expected Behavior

The "Next" button should be disabled immediately if the email field becomes empty.
The backend should strictly reject the request with a 400 Bad Request if the email payload is an empty string.

Evidence

UI State (Ghost Avatars):

Reproduction Video:

https://github.com/user-attachments/assets/1ea1e181-7d64-4488-a698-141444f872d6

Steps to Reproduce

Create a new document or upload a file.
Navigate to the Add Recipients step.
Enter a valid Name and Email to satisfy the initial frontend validation (e.g., test@example.com).
Delete the email address completely from the input field (leave it empty).
Click Next or proceed to the "Add Fields" step (the system allows this bypass).
Add a signature field and click Send Document.

Expected Behavior

The system should strictly prevent the creation of a recipient without a valid email address.

Frontend: The "Next" button should be disabled immediately when the email field is cleared.
Backend: The API should reject the request with a 400 Bad Request error if the email payload is an empty string, ensuring no invalid rows are created in the database.

Current Behavior

The system accepts the empty email string and proceeds to send the document.

A "Ghost Recipient" is created in the database with an empty email.
The dashboard displays a placeholder avatar (grey circle) with no initials or tooltip information (see attached screenshot).
A valid signing link is generated for a user with no identity, compromising data integrity.

Screenshots (optional)

No response

Operating System [e.g., Windows 10]

Windows 11

Browser [e.g., Chrome, Firefox]

Chrome

Version [e.g., 2.0.1]

2.6.0

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 @abdulalim110 on GitHub (Feb 11, 2026). Original GitHub issue: https://github.com/documenso/documenso/issues/2475 ### Issue Description ## Description I found a validation bypass in the Document Creation flow (Step 1). The frontend validation for the recipient's email can be bypassed by filling in the details and then deleting the email address before proceeding. This results in "Ghost Recipients" being created in the system with empty email strings. Crucially, the system even generates valid signing links for these non-existent users, leading to a broken state. ## Steps to Reproduce 1. Upload a document and proceed to **Step 1: Add Recipient**. 2. Type a valid email and name to trigger the UI state. 3. **Delete the email address** (leave it empty). 4. Notice that the "Next" / "Add Fields" button remains active. 5. Proceed to add a field and send the document. ## Actual Behavior - The system accepts the empty email string. - The Dashboard displays "Ghost Avatars" (empty grey circles) with no initials or tooltip info (see screenshot). - **Critical:** The system generates valid signing links for recipients with no identity. - This creates rows in the database with empty email strings, which compromises data integrity and can lead to 500 Server Errors during the signing process due to missing relations. ## Expected Behavior - The "Next" button should be disabled immediately if the email field becomes empty. - The backend should strictly reject the request with a `400 Bad Request` if the email payload is an empty string. ## Evidence **UI State (Ghost Avatars):** <img width="1117" height="588" alt="Image" src="https://github.com/user-attachments/assets/0af7e270-60d0-452d-80c8-5b502ca42367" /> **Reproduction Video:** https://github.com/user-attachments/assets/1ea1e181-7d64-4488-a698-141444f872d6 ### Steps to Reproduce 1. Create a new document or upload a file. 2. Navigate to the **Add Recipients** step. 3. Enter a valid `Name` and `Email` to satisfy the initial frontend validation (e.g., `test@example.com`). 4. **Delete the email address completely** from the input field (leave it empty). 5. Click **Next** or proceed to the "Add Fields" step (the system allows this bypass). 6. Add a signature field and click **Send Document**. ### Expected Behavior The system should strictly prevent the creation of a recipient without a valid email address. - **Frontend:** The "Next" button should be disabled immediately when the email field is cleared. - **Backend:** The API should reject the request with a `400 Bad Request` error if the email payload is an empty string, ensuring no invalid rows are created in the database. ### Current Behavior The system accepts the empty email string and proceeds to send the document. - A "Ghost Recipient" is created in the database with an empty email. - The dashboard displays a placeholder avatar (grey circle) with no initials or tooltip information (see attached screenshot). - A valid signing link is generated for a user with no identity, compromising data integrity. ### Screenshots (optional) _No response_ ### Operating System [e.g., Windows 10] Windows 11 ### Browser [e.g., Chrome, Firefox] Chrome ### Version [e.g., 2.0.1] 2.6.0 ### 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:04 +03:00

closed this issue
added the
status: triage
label

kerem commented

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

Author

Owner

@github-actions[bot] commented on GitHub (Feb 11, 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 11, 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 referenced this issue

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

[PR #709] [MERGED] fix: visibility of update password & security fields using identityprovider #1128

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

No description provided.

Rows
Columns