> For the complete documentation index, see [llms.txt](https://h4cker404.gitbook.io/blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://h4cker404.gitbook.io/blog/writeups/its-still-working.md).

# It’s Still Working!

**Hello mates,**\
This is write-up about a bug that I *thought* was **resolved** — but turned out, **it wasn’t quite done yet**.

Sometimes, retesting a patched vulnerability feels like a formality. You assume it’s fixed and move on. But in this case, curiosity paid off.

In this write-up, I’ll walk you through how I revisited a previously reported Broken Access Control issue, only to discover a new, distinct vulnerability — caused by sending a single unexpected value: `null`.

It’s a reminder that backend validation is often trickier than it looks — and that bugs have a funny way of showing up again when you least expect them.

Let’s get into it :))

While exploring the admin settings in the ChatSpace dashboard, I found a configuration field called `password_change_interval_duration`. This field controls how often users must change their passwords — a common security policy in enterprise environments.

Naturally, I started testing different values by intercepting the PATCH request that updates this setting.

First, I tried setting the `password_change_interval_duration` to `0`.

Surprisingly, the backend accepted it without any complaints. This meant all users in the organization were now forced to reset their passwords every single day. From a malicious admin’s perspective, this could easily be abused to cause a denial of service.

<figure><img src="https://miro.medium.com/v2/resize:fit:604/1*-eZVHSJACLc7v3MCmkbxzA.png" alt="" height="477" width="483"><figcaption></figcaption></figure>

A 0-day expiration, combined with features like `use_lock_5times_wrong`, could lead to widespread lockouts. Support teams and internal users might find themselves unable to log in on a daily basis. Productivity would drop, and frustration would build quickly.

<figure><img src="https://miro.medium.com/v2/resize:fit:615/1*_zDr7uMfAHZoPHaanDSZOg.png" alt="" height="143" width="492"><figcaption></figcaption></figure>

At that point, it was clear the backend wasn’t validating this parameter properly. Any admin could manipulate global password policies beyond what was intended.

After reporting the issue, the ChatSpace team patched it by allowing only safe values: 30, 90, 180, or 365.

It seemed like the problem was **fixed**.

Press enter or click to view image in full size

<figure><img src="https://miro.medium.com/v2/resize:fit:875/1*8LZi9wQ2rXOYwlDrmrVC-A.jpeg" alt="" height="457" width="700"><figcaption></figcaption></figure>

**But then, I decided to test one more thing :))**

At this point, I wanted to see how strict the patch really was. So I tried setting the `password_change_interval_duration` to 0.

This time, the backend did the right thing — it rejected the request with a clear error message: only 30, 90, 180, or 365 were allowed. So far, so good.

Press enter or click to view image in full size

<figure><img src="https://miro.medium.com/v2/resize:fit:875/1*XdpbP1GI2rX2KjQMR03xmA.png" alt="" height="378" width="700"><figcaption></figcaption></figure>

But then I got curious.

What if I send `null`?

No number. No string. Just `null`.

I sent the request… and it went through. No error. The server responded with 200 OK.

But behind the scenes, something odd was happening.

The system interpreted null as 0 — silently. And as a result, all users across the org were now forced to reset their passwords every single day.

So the same denial-of-service scenario was back again — but this time, it slipped past the patch unnoticed.

And that’s when I realized: the bug wasn’t just unfixed. It had come back… wearing a disguise.Sure, here’s a shorter version with just the text:

Press enter or click to view image in full size

<figure><img src="https://miro.medium.com/v2/resize:fit:875/1*HYpPcCTHiQCr6ziWlBfDQw.jpeg" alt="" height="432" width="700"><figcaption></figcaption></figure>

**A bug marked as “resolved” doesn’t always mean it’s truly fixed.**

Sometimes, a small variation — like sending null instead of a number — is all it takes to bring it back.

That’s why it’s always worth retesting.

Stay curious. Recheck. Don’t assume.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://h4cker404.gitbook.io/blog/writeups/its-still-working.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.