# Critical Logic Flaw in DueDate Handling Leads to System‑Wide Task Deletion

### How a Single Due Date Broke an Entire Task System

Hello, folks! It’s Mr‑Dix again, a soldier from the `BountyOrDie` squad, and today I’m back with a fresh write‑up for you — and yeah, this one escalated way more than expected 😅.

So let’s jump straight into it.

Today’s story is about an interesting **logic vulnerability** I found in the Task Management module. At first glance, it looked harmless. A simple task creation flow… what could possibly go wrong? Turns out: *everything*.

***

#### Task Management?

The application provides an *All Tasks* section where users can manage their daily work. Pretty standard stuff:

* Create tasks
* Assign details
* Set a due date (past or future)
* Track progress

<figure><img src="/files/isuq4ZunVMDfpbsFtYNW" alt=""><figcaption></figcaption></figure>

Each task includes a `DueDate` parameter, which the backend happily accepts and processes.

Or at least… that’s what it *should* do.

<figure><img src="/files/y1I5ZjgZggwbXZnvReuj" alt=""><figcaption></figcaption></figure>

***

#### The DueDate Parameter

Under normal conditions, `DueDate` accepts valid date values and everything works fine. But while testing input handling, I started wondering:

> What happens if the backend receives a **date that shouldn’t exist at all**?

So naturally, I tried breaking it.

***

#### Let’s Break It 😈

<figure><img src="/files/DySlZFe0V2vBVnwpBdqJ" alt=""><figcaption></figcaption></figure>

Here’s what I did:

1. Logged in as a **regular user** with access to *All Tasks*.
2. Created a new task through the UI.
3. Intercepted the task creation request.
4. Modified the `DueDate` parameter to an invalid value:

```json
POST /manager/api/v4/taskHistories HTTP/2
"DueDate": "0000-08-09"
```

5. Sent the request to the server.

***

#### What Happened Next?

The server immediately responded with:

`500 Internal Server Error`

<figure><img src="/files/0hy2WLJJ9n5pg4PaiDX0" alt=""><figcaption></figcaption></figure>

At this point, I expected maybe a failed task creation or a validation error.

Nope.

After refreshing the page, things started falling apart:

* The *All Tasks* section stopped working and showed an error.
* **All existing tasks were gone**.
* Not just mine — tasks belonging to:
  * Other users
  * Admins
  * Even the organization owner
* Trying to create new tasks?
  * They “submit” successfully…
  * But never appear.
* The entire task management module becomes unusable.

At this point, the system basically entered a **dead state**.

One malformed request. Total collapse.

<figure><img src="/files/UQzIC6uONth65QmlkrYv" alt=""><figcaption></figcaption></figure>

***

#### Impact (aka: Why This Is Bad)

Any authenticated user can:

* Trigger a **Denial of Service** against the *All Tasks* section
* Cause **mass deletion of tasks** across the entire organization
* Completely break task creation and management

This is a textbook **logic flaw with a cascading failure** — a single bad input turns into a system‑wide meltdown.

* Availability? Gone.&#x20;
* Integrity? Gone.&#x20;
* Business feature? Gone.

***

#### Why This Matters

This is a **single‑request kill switch** for a core feature. No special permissions. No admin access. No warning.

Just one invalid `DueDate`.

***

#### Final Thoughts

The backend should never allow malformed input to:

* Trigger destructive database operations
* Affect global application state
* Break functionality for every user

Yet here we are.

That’s the story for today. Hope you found this write‑up useful&#x20;

<figure><img src="/files/vBQTk6wYdQICKa53d144" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://get-bountyordie.gitbook.io/get-bountyordie-docs/our-write-ups/web-pentest-write-ups/critical-logic-flaw-in-duedate-handling-leads-to-system-wide-task-deletion.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.