$500 Bounty: Unauthorized Folder Creation with Null Name

Hey everyone, In this write-up, I’ll share a simple but impactful bug I found in a SaaS recruitment platform that allowed me to create a folder with a null name.

The result? The folder became completely inaccessible to all users — including the attacker and legitimate collaborators — effectively causing a denial-of-service (DoS) for that project.

For this bug, I was awarded a $500 bounty. \

Understanding the Feature

The platform allows users to create folders, share them with others, and manage candidates or projects collaboratively.

Normally, folders require a valid string name to function. But during testing, I discovered that the backend didn’t enforce strict validation on the name field.

This oversight opened the door for a quirky but impactful issue.

The Flaw: Null Folder Name

By intercepting the API request during folder creation or update, I noticed that the name field could be manipulated.

Original request while creating a folder:

PUT /api/recruiter/cart/1f378efc-4bd4–4691-ac78-acf19371da88 HTTP/2 Host: app.examplecorp.com Content-Type: application/json

{ “name”: “Test Folder”, “description”: “”, “jobDescriptionUrl”: “” }

I modified the payload to set “name”: null:

PUT /api/recruiter/cart/1f378efc-4bd4–4691-ac78-acf19371da88 HTTP/2 Host: app.examplecorp.com Content-Type: application/json

{ “name”: null, “description”: “”, “jobDescriptionUrl”: “” }

Response: 200 OK — folder successfully updated.

Verifying the Issue

• When I navigated back to the UI, the folder was no longer accessible.
• Other authorized users also couldn’t access or manage it.
• Since the system had no valid identifier for the folder name, it effectively broke access for everyone.

This created a persistent denial-of-service (DoS) for that shared resource

Impact

• Denial-of-Service → A project or shared folder could be made permanently inaccessible.
• Data Lockout → Users lost access to their stored candidates, notes, or shared resources inside the folder.
• Improper Input Validation → Backend trusted null without sanitizing it.

Timeline

• Day 1 — Report submitted.
• Day 5 — Initially marked out of scope (DoS).
• Same Day — Reopened for program review.
• Later — Triaged and $500 bounty awarded 🎉.

Lessons Learned

• Even small validation issues can lead to real impact.
• Always sanitize input values before processing.
• Don’t assume “simple” bugs won’t be rewarded — this one earned me $500 despite being easy to exploit

Final Thoughts

This was a great reminder that low-effort tests can sometimes reveal high-value issues.

If you’re hunting:

👉 Try sending edge-case values (null, “”, “ “, special characters).

👉 Test how the system behaves when mandatory fields are missing or invalid.

Until next time, happy hacking! 🐞⚡

Connect and Engage

💬 What’s your experience with race condition bugs?

Follow me on Twitter: @a13h1_

Keep clapping, commenting, and sharing your thoughts — your support motivates me to share more real bug bounty stories!