How I Found an Application Resurrection Vulnerability (Deletion Bypass)

How I Found an Application Resurrection Vulnerability (Deletion Bypass)

When testing access control and state management in web applications, common logic flaws often hide in lifecycle transitions. Specifically: what happens to downstream permissions and pending API requests when an object is deleted?

In this article, I'll walk through a state-validation bypass I discovered in TARGET 's application management backend that allowed lower-level administrators to resurrect previously deleted applications by replaying stale modification requests.

The Flaw at a Glance

When an organization administrator deletes an application, the frontend UI removes the application, rendering it inaccessible via standard navigation.

However, the backend API endpoint responsible for editing application metadata (/account/<ACCOUNT_ID>/app/<APP_ID>) verified user authorization without checking the target application's active lifecycle state. As a result, replaying a captured POST/PUT edit request would succeed, restoration of access would occur, and the deleted application would effectively be resurrected.

The Attack Scenario

This vulnerability introduces a business logic inconsistency between organization-level privileges and application-level permissions.

• Account A: Organization Owner / Administrator
• Account B: Invited user granted the lower-level App Admin role

[Account A] Deletes Application  ---> Application marked deleted in UI
                                                    |
[Account B] Replays Old Request  -------------------> Backend accepts state edit
                                                    |
[Result] Application Restored   <--- Application resurrected in DB/UI

[Account A] Deletes Application  ---> Application marked deleted in UI
                                                    |
[Account B] Replays Old Request  -------------------> Backend accepts state edit
                                                    |
[Result] Application Restored   <--- Application resurrected in DB/UI

Step-by-Step Reproduction

• Setup Roles: Account A creates an organization and an application, inviting Account B as an App Admin.
• Capture Baseline Request: Account B modifies the application name in the UI, capturing the legitimate HTTP edit request in Burp Suite, and forwards it to Repeater.
• Execute Deletion: Account A (Organization Owner) deletes the application from the dashboard.
• Verify Deletion State: Account A and B confirm the application is gone. Navigating to the direct URL yields an error:
• Could not obtain App data because of a technical problem. Please contact support.
• Replay & Resurrect: Account B goes to Burp Repeater and replays the previously captured edit request against the deleted <APP_ID>.

Key Findings & HTTP Response

Upon replaying the request, the backend failed to return a 404 Not Found or 410 Gone error. Instead, it responded with 200 OK and returned the application payload:

JSON

HTTP/1.1 200 OK
Content-Type: application/json
{
  "app_id": "12345",
  "name": "Resurrected_App_Name",
  "created_at": "2026-08-15T04:26:00Z",
  "status": "active"
}

HTTP/1.1 200 OK
Content-Type: application/json
{
  "app_id": "12345",
  "name": "Resurrected_App_Name",
  "created_at": "2026-08-15T04:26:00Z",
  "status": "active"
}

Refreshing the UI showed that the application had been restored into an operational state, allowing Account B to effectively override the deletion enforced by the Organization Owner.

Root Cause & Remediation

• Root Cause: The backend authorization layer checked whether Account B had rights to modify the application, but lacked a secondary check ensuring the resource wasn't soft-deleted or marked inactive.
• Fix: Ensure backend endpoints enforce strict state validation before applying updates:
• IF application.is_deleted == True: RETURN 404_NOT_FOUND

Disclosure Timeline

• Aug 15, 2026: Vulnerability identified and reported with PoC video.
• Aug 15, 2026: Additional impact escalated (deletion bypass / state resurrection).
• Aug 16, 2026: Support responded marking the report as a duplicate of a previously known issue.

_Even though the report was marked as a duplicate, highlighting logic flaws like resource resurrection serves as a useful reminder: _always validate object states alongside user permissions on every API request.