🔳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.

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.

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

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

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

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.