What looked like a harmless feature — editing a member’s join date — ended up exposing a deeper issue where a Group Leader could control roles of other members. For this finding, I was awarded a $1,000 bounty + $100 retest bonus. Let’s break it down.

Understanding the Target

ExampleCenter has a Groups feature where users collaborate in smaller units. Each group has a clear role hierarchy:

• Member → basic access
• Leader → manages group-level actions
• Manager/Admin → controls structure, permissions, and roles

Importantly:

Only Managers or Admins are supposed to change roles.

The UI enforces this strictly.

As a Group Leader, you can:

• Edit member details (like join date)
• Manage basic group activities

But you cannot:

• Promote someone to Leader
• Demote other Leaders
• Change role hierarchy

At least… that’s what the UI says.

The Flaw: Role Manipulation via Parameter Tampering

While testing allowed actions for a Group Leader, I noticed something interesting. There was an endpoint used to edit member details, like the join date. A normal request looked like this:

POST /groups/2915300/members/47858856 HTTP/2
Host: groups.examplecenteronline.com

_method=patch&authenticity_token=okWay1Dq0tmWC6_Veno_tBg1dA74-LbtLIVXYR4wl304efBVL9R7MUwjhmRna910MmE5K_Q1IBgnDxK6wrgsKA&page=1&membership%5Bjoined_at%5D=2026-01-08T00%3A00%3A00

Pretty standard. But here’s where things got interesting 👇

What if we add one more parameter? which i saw in admin/manger role assigning request

membership[role]=leader

• Example payload: _method=patch membership[joined_at]=2026-01-08T00:00:00 membership[role]=leader

That’s it and send the request

No special endpoint, No admin permission, No extra authentication, Just one additional parameter.

Result?

• Request → 200 OK
• Target user → Promoted to Leader

And it didn’t stop there…You could also:

• Demote existing leaders to members by changing membership[role]= member
• Reassign leadership roles
• Completely control group hierarchy

All from a Group Leader account

What’s Actually Happening?

This is a classic parameter tampering + broken authorization issue.

The backend:

• Validates that the request is valid because leader is allowed to send the request but doesnot have member role parameter✅
• Validates membership exists because request is allowed but didn’t check is or which parameter is allowed with that request with that role permissions✅
• But does not validate who is allowed to change roles ❌

So when the server sees: membership[role]=leader it blindly trusts it.

Even though:

• The UI blocks this action
• The role should be restricted
• The user lacks permission

The Real Issue

This is not just about a missing check.

This is about:

Backend trusting client-controlled parameter and input for a security-critical action.

The UI tried to protect it. But the API didn’t. And as always:

If it’s only protected in the UI, it’s not protected.

Impact

This vulnerability allows a Group Leader to manipulate the role structure of a group without proper authorization. By exploiting this behavior, a user can promote arbitrary members to leadership roles or demote existing leaders, effectively taking control over how the group is managed.

In real-world scenarios, this breaks the intended permission boundaries within collaborative environments. Group roles often define trust, responsibility, and access levels, so allowing unauthorized role changes can lead to misuse, confusion, or even intentional disruption.

An attacker could assign leadership privileges to themselves or others, override existing leadership, and alter the internal structure of the group without visibility or approval from administrators. This undermines the principle of least privilege and weakens trust in the platform’s permission model.

Bounty & Program Response

Reported: January 22, 2026

Triaged: January 23, 2026

Bounty Awarded: $1,000 + $100 retest bonus

During retesting:

• The request still returned 200 OK
• But role changes were properly blocked ✅

Fix confirmed.

Key Takeaways

• Never trust client-controlled parameters for authorization decisions
• UI restrictions are not security controls
• Always test “allowed actions” for hidden parameters
• Small inputs can lead to big privilege escalations
• Parameter tampering is still one of the most underrated attack vectors

Conclusion

This bug perfectly shows how a normal feature + one hidden parameter = full control.

No complex exploit, No brute force, No advanced techniques,Just understanding:

• What the system allows
• What it hides
• And what it forgets to validate

That’s where the real bugs are.

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!

This bug was about what happens after access is revoked, not while it exists. For this finding, I was awarded an $800 bounty + $100 retest bonus. Let’s break it down.

Understanding the Target

ExampleCenter is a multi-product SaaS platform where organizations manage different workflows like people, scheduling, calender, groups and home dashboard internal collaboration. If the user have any permission for any product of platform that user can access home dashboard where task and resources shared in organization

Each user is assigned product-level permissions, and once those permissions are removed, the expectation is simple:

The user should lose access immediately even home dashboard access too.

From a security perspective, deprovisioning = complete access revocation.

That includes:

• Logging in
• Accessing dashboards
• Viewing shared resources
• Performing any action

But this assumption is where things started to break.

The Flaw: Session Remains Valid After Deprovisioning

While testing permission models, I noticed something interesting:

• If a user is fully deprovisioned, they cannot log in again ✅
• But… if they already have an active session, it still works ❌

This means:

The system blocks new authentication but does not invalidate existing sessions.

So even after:

• Removing all product access which remove all access even home dashboard access too
• Making the account effectively “inactive”

The user could still:

• Access the Home dashboard not other products access like people, schedulings and etc
• View previously shared resources
• Interact with existing data

All through the same session cookie.

What’s Actually Happening?

This is a classic session invalidation issue.

The backend:

• Checks permissions during login ✅
• But does not revalidate session authorization state ❌

So once a session is issued, it remains trusted — even if:

• The user’s role changes
• Permissions are revoked
• Access is completely removed

In simple terms:

The system trusts the session more than the current user state.

Steps To Reproduce:

Setup

1. Create a user in an organization
2. Grant access to any product (e.g., People, Services, Calendar)
3. Log in as the user in examplecenter or home and keep the session active by not log-in out

Step 1: Remove All Product Access

1. Log in as an admin
2. Remove all product permissions from the user
3. Save changes and you will see the home access of that user go to (no access)

Step 2: Verify Login Is Blocked

1. Log to the user account in different or new browser
2. Observe: • Login fails with “Email or phone not found”

Step 3: Reuse Existing Session

1. Use the same session from Setup step 3 , the orignal session is still active
2. Continue browsing using the existing cookies/session
3. Observe: • User still accesses Home • User can view shared resources • Authorization checks succeed despite full deprovisioning

Why This Matters (Real-World Scenario)

Imagine this:

An employee leaves a company.

Admin removes all access immediately.

But…

• The employee still has a browser open
• Their session is still active
• They can still access internal dashboards, tasks, or shared data

Even if limited, this creates

• A security gap during offboarding
• A window for data exposure
• A false sense of access revocation

This is especially risky in:

• Insider threat scenarios
• Sensitive environments
• Compliance-driven systems

Impact

This vulnerability allows a fully deprovisioned user to retain access through an already established session, even though the system considers the account inactive.

While new logins are correctly blocked, the existing session continues to function without revalidation. This creates a gap where a user who should have zero access can still interact with parts of the system such as the Home dashboard and previously shared resources.

In real-world environments, this weakens the reliability of access revocation processes. Organizations rely on immediate access removal during role changes or employee offboarding, but this behavior introduces a delay where access still exists unintentionally.

Even if the accessible data is limited, the issue breaks the fundamental security expectation that permission removal equals immediate access termination, which can lead to trust and compliance concerns.

Bounty & Program Response

Reported: January 17, 2026

Triaged: January 22, 2026

Severity: Medium

Bounty Awarded: $800 + $100 retest bonus

During retesting, the fix ensured:

• Sessions are properly invalidated
• Access is revoked consistently

Key Takeaways

• Session invalidation is just as important as authentication
• Permission checks must be enforced continuously, not just at login
• Deprovisioning should immediately terminate all active sessions
• Always test post-auth scenarios, not just access control entry points
• Many real bugs exist in state transitions, not just endpoints

Conclusion

This bug is a perfect example of how security is not just about granting access — but also about removing it properly.

Everything looked correct from the UI:

• User removed ✅
• Login blocked ✅

But internally:

• Session still alive ❌

That small gap is where real vulnerabilities exist.

As bug hunters, these edge cases — what happens after access changes — often lead to the most interesting findings.

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!

In this case, I discovered a cross-product authorization issue where any authenticated user — even without Calendar or Groups access — could retrieve internal Calendar form configurations using a simple API query.

For this finding, I was awarded a $750 bounty. Let’s break it down.

Understanding the Target

The platform provides multiple interconnected products like:

• Calendar → manages events and forms
• Groups → manages user group structures
• People / Services → manage people and services

One important feature is Calendar Forms, which can be configured to:

• Be accessible only to specific group types so they can create events on specific dates
• Restrict who can submit event requests for calender dates
• Define internal workflows like: Approval groups, event owners and custom confirmation emails for events created in calendar

👉 Logically, only:

• Users in those groups
• Or users with Calendar permissions

should be able to access this data.

Where It Got Interesting

While testing role-based access, I noticed something subtle:

• A low-privileged user couldn’t access Calendar UI
• Couldn’t view forms
• Had no group membership

But I started wondering:

“What if the API only checks the group_type_id, not the user?”

That’s where everything opened up.

The Flaw: Cross-Product Authorization Bypass

The vulnerable endpoint:

GET /calendar/v2/forms/?where[form_group_types][group_type_id]=<group_type_id>

The issue:

• The API accepts any valid group_type_id
• But does NOT verify: If the user belongs to that group, if the user has Calendar access or if the user has any permission to view forms

👉 It only trusts the relationship between objects, not the user.

Steps to Reproduce

Step 1: Use a Low-Privilege Account

Example roles:

• Services → Scheduler (Viewer)
• People → Workflow-only

Confirm:

• No Calendar access
• No Groups access
• No group membership

Step 2: Capture Session

Login and grab the authenticated session cookie.

Step 3: Send API Request

GET /calendar/v2/forms/?include=form_group_types
&where[form_group_types][group_type_id]=502324
&where[status]=open

Step 4: Observe Response

✅ Server returns 200 OK

And exposes:

• Form name & description
• Custom confirmation email content
• Event owner (person ID)
• Approval group IDs
• Default calendar
• Tags & group associations

👉 All of this without any Calendar or Group permissions

Why This Matters

At first glance, this may look like “just metadata”…

But in real-world systems, this data is highly valuable.

This vulnerability allows any authenticated user to enumerate internal Calendar forms across the organization and gain visibility into how workflows are structured. It exposes operational details such as approval chains, responsible personnel, and internal communication templates like custom confirmation emails.

Even though no direct modification is possible, this level of access breaks the intended separation between products. It allows users with completely unrelated roles to map internal processes, identify key users, and understand how event approvals and workflows operate behind the scenes.

Over time, this kind of information disclosure can be used to support further attacks, social engineering, or privilege escalation attempts.

Root Cause

The issue comes down to a classic mistake

• ❌ Backend validates object relationship (group_type_id)
• ❌ Does NOT validate user entitlement
• ❌ No cross-product permission enforcement

👉 Trusting object references instead of user permissions

Bounty & Program Response

• Reported: Jan 24, 2026
• Triaged: Valid
• Severity: Medium (4.3)
• Bounty: $750
• Status: Resolved

Key Takeaways

• Never trust object filters (group_type_id) as authorization
• Always validate user → object relationship
• Cross-product integrations are high-risk areas
• Metadata exposure ≠ low impact (it builds attack surface)
• Think beyond UI: “What happens if I call this directly?”

Conclusion

This bug is a great example of how authorization can silently fail across product boundaries. Everything looked secure in isolation:

• Calendar was restricted
• Groups were restricted

But when combined through the API… The trust model broke completely and that’s where the bug lived.

Connect and Engage

Follow me on Twitter: @a13h1_

In this case, I found a business logic + BOLA (Broken Object Level Authorization) issue in an event registration system where I was able to mix data across different selections and even different events — something the platform strictly tries to prevent.

For this finding, I was awarded $500 bounty + $100 retest bonus. Let’s break it down.

Understanding the Target (Where the Idea Came From)

The platform works like a typical event registration system:

• Each event has multiple selections (e.g., Standard, VIP, Test)
• Each selection has:
• Its own add-ons
• Its own attendee questions
• These are supposed to be tightly scoped:
• Selection → controls what you can choose
• Event → controls what data belongs

So logically:

If you choose Selection A, you should only be able to use its add-ons and questions.

Where it got interesting 👇

While testing registrations, I wasn’t trying to break auth directly.

I was thinking:

“What if the backend is trusting IDs instead of validating relationships?”

That’s where everything changed.

The Flaw: Trusting Client-Supplied Object IDs

The API accepts a request like:

PATCH /registrations/v2/events/{event_id}/reservations/{reservation_id}
Host:

{"data":{"attributes":{"add_on_elections_changed":true}},"included":[{"type":"AddOnSelection","attributes":{"attendee_id":140709947,"add_onable_type":"AddOn","add_onable_id":"878858","quantity":1,"_destroy":false}},{"type":"Answer","attributes":{"attendee_id":140709947,"answers":["cs"],"question_id":4832223}}]}

Inside the request, you can send:

• add_onable_id
• question_id

Now here’s the problem:

👉 The backend does NOT verify:

• If the add-on belongs to the selected option
• If the question belongs to the same event
• If both belong to the same scope at all

It simply trusts whatever IDs you send.

How I Actually Found It (Real Thought Process)

At first, everything looked fine in the UI perfectly restricted.

But I asked:

“UI is restricting… but is API enforcing?”

So I intercepted the request and tested something simple:

• Take add-on from another selection
• Inject it into current request

Boom… it worked.

Then I pushed further:

“What if I go cross-event?”

And yeah… it still worked.

That’s when I knew:

👉 This is not just logic issue — this is BOLA + broken validation

Steps to Reproduce

Scenario 1: Cross-Selection Injection

1. Create an event with:

• Selection A (Standard)
• Selection B (Test)

1. Start registration with Selection A
2. Intercept request and modify:

{
  "included": [
    {
      "type": "AddOnSelection",
      "attributes": {
        "add_onable_id": "ADDON_FROM_SELECTION_B"
      }
    },
    {
      "type": "Answer",
      "attributes": {
        "question_id": "QUESTION_FROM_SELECTION_B"
      }
    }
  ]
}

Send request

✅ Result: Registration succeeds with invalid mapping

Scenario 2: Cross-Event Injection (More Interesting)

1. Create:

• Event A
• Event B

1. Start registration for Event A
2. Inject:

{
  "included": [
    {
      "type": "AddOnSelection",
      "attributes": {
        "add_onable_id": "ADDON_FROM_EVENT_B"
      }
    },
    {
      "type": "Answer",
      "attributes": {
        "question_id": "QUESTION_FROM_EVENT_B"
      }
    }
  ]

Complete registration

✅ Result:

• Event A registration
• Data from Event B

Why This is Actually Dangerous (Not Just “Weird Behavior”)

At first glance, this feels like:

“Okay, just data mismatch…”

But it’s deeper.

This breaks core assumptions of the system:

• Events are supposed to be isolated
• Selections define constraints
• Add-ons control pricing & eligibility

Now all of that can be bypassed.

Impact (Real World Thinking)

This vulnerability allows attackers to create registrations that do not respect the boundaries defined by event organizers. Instead of selecting valid options, they can inject add-ons and questions from completely unrelated contexts.

This leads to inconsistent and corrupted registration data where an event contains configurations that were never intended for it. If add-ons are tied to pricing, access levels, or eligibility rules, this could allow users to bypass restrictions or manipulate event behavior in unintended ways.

From an operational perspective, this creates confusion for event managers reviewing registrations, as the data no longer reflects the actual event setup. It also breaks trust in the system’s integrity, since the backend accepts relationships that should never exist.

Root Cause

Simple but dangerous:

• ❌ Backend does NOT validate object relationships
• ❌ Trusts client-supplied IDs
• ❌ UI is the only layer enforcing restrictions

Classic case of:

“Frontend secure ≠ Backend secure”

Bounty & Program Response

• Reported: Jan 3, 2026
• Triaged: Accepted
• Severity: Low
• Bounty: $500 + $100 retest
• Fix: Backend validation added

Key Takeaways

• Always test object relationships, not just access
• IDs are dangerous if not scoped properly
• UI restrictions mean nothing without backend validation
• BOLA bugs are often hidden inside “valid flows”
• Think like: “Can I mix things that shouldn’t mix?”

Conclusion

This bug wasn’t about accessing something unauthorized directly.

It was about breaking the logic of how things are supposed to work together. And honestly, these are my favorite types of bugs because they don’t scream vulnerability…

👉 You have to think your way into them

Connect and Engage

💬 What’s your experience with race condition bugs?

Follow me on Twitter: @a13h1_

For this finding, I was awarded a $500 bounty + $75 retest bonus. 🚀

At first glance, this might look like a low-impact issue, but when you think about how it can be abused in real-world scenarios, it becomes much more interesting.

Understanding the Target

ExampleCenter has a Registrations + Payment system where users can:

• Make payments
• View receipts
• Send receipt emails

There is a feature where users can send payment receipts to specific people, which is expected to be a user-initiated action.

This means:

• The action should be intentional
• It should be protected against unauthorized triggers

The Thought Process

While exploring the payment flow, I noticed something important:

The request to send a receipt was a simple POST request

It was authenticated via cookies

But I didn’t see any CSRF protection

That immediately raised a red flag:

“What if this request can be triggered from another website?”

The Flaw: Missing CSRF Protection

The endpoint responsible for sending receipts:

POST /payments/{payment_id}/send_receipt

• No CSRF token required
• Accepts authenticated requests
• Relies only on session cookies

Proof of Concept

I created a simple HTML page:

<html>
  <body>
    <form action="https://examplecenter.com/payments/20457373/send_receipt">
      <input type="hidden" name="payment[person_ids_to_notify]" value="43547544" />
    </form>

    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

What Happens

If a logged-in user visits this page:

👉 The request is automatically sent

👉 The server accepts it

👉 Receipt emails are triggered

No:

• User interaction
• Confirmation
• Warning

Root Cause

The issue exists because:

• The endpoint relies only on cookie-based authentication
• No CSRF token validation is implemented
• Backend assumes every request is intentional

👉 Classic CSRF vulnerability

Impact

This vulnerability allows attackers to abuse authenticated users to send payment receipt emails without authorization.

Practical impact includes:

• Receipt email spam sent to unintended recipients.
• Confusion or social engineering opportunities (users receiving unexpected receipts).
• Loss of trust in transactional email accuracy.
• Potential misuse by attackers to harass or mislead recipients.

While this issue does not expose sensitive payment data or modify financial records, it enables unauthorized execution of a user-initiated action and constitutes a valid CSRF vulnerability.

Bounty & Program Response

• Reported: Jan 3, 2026
• Triaged: Jan 6, 2026
• Bounty: $500 + $75 bonus
• Retest: Fix confirmed

Key Takeaways

• Always check for CSRF on state-changing actions
• If request works with:Only cookies , No token It’s likely vulnerable
• Even “non-critical” actions can be abused
• Never trust browser-origin requests blindly

Personal Insight

This bug came from a very simple habit:

“Whenever I see a POST request… I try to replay it without a CSRF token.”

That one habit alone can lead to a lot of findings.

Conclusion

This vulnerability highlights how missing CSRF protection can allow attackers to silently trigger actions on behalf of users.

Even though the action here was “just sending emails,” it still breaks user trust and system integrity — which is exactly what security controls are meant to protect.

Always remember:

If a request changes something… it must verify that the user actually intended it.

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!

For this finding, I was awarded a $750 bounty + $100 retest bonus. This bug is a great example of how token-based access without proper validation can completely break a permission model.

Understanding the Target

ExampleCenter provides a Calendar + Forms system with Automations.

These automations:

• Trigger workflows
• Execute actions (e.g., create notes, send data)
• Store execution history
• Include webhook payloads

👉 This is sensitive operational data, not meant for low-privileged users

Permission Model (Expected)

• Admin → Full access to automations
• Editor -> Can edit events, resources and automations
• Viewer → No access to automations can view events and resources

From the UI:

❌ Calendar Viewer cannot see:

• Automations
• Automation configs
• Execution history

So everything looked secure… on the surface.

The Thought That Led to the Bug

While exploring APIs, I noticed something interesting:

There was an endpoint generating an encrypted parameter (_e).

That made me think:

“What if this token is reusable… and not tied to permissions?”

Because i say the automation access api’s require _e token if it is the same _e token which is generating to access automations

Step 1: Generating the Token

Even as a Calendar Viewer, I could request:

GET /api/calendar/v2/forms/{form_id}/encrypted_param HTTP/2
Host: api.examplecenter.com

Response:

{
  "data": {
    "attributes": {
      "trigger_resource": "ENCRYPTED_TOKEN_HERE"
    }
  }
}

👉 I now had a valid _e token

Step 2: Accessing Automations

Using the same Viewer session + _e token:

GET /api/webhooks/v2/automation_subscriptions?_e=ENCRYPTED_TOKEN HTTP/2
Host: api.examplecenter.com

Result

👉 200 OK — Data returned successfully

I was able to access:

• Automation names
• Trigger configurations
• Operation definitions
• Admin identities (who created automation)
• Internal workflow logic

Step 3: Accessing Execution History

Then I pushed further 👇

GET /api/webhooks/v2/automation_subscriptions/{id}/events?_e=ENCRYPTED_TOKEN HTTP/2

Result

Full automation execution history exposed

Including:

• Event payloads
• Webhook data
• User IDs
• Timestamps
• Delivery responses

Root Cause

• Backend APIs do not enforce role-based authorization checks
• Permission enforcement is performed at the UI layer only
• Encrypted _e tokens can be generated and reused by unauthorized roles
• Automation and webhook endpoints trust possession of _e token without verifying user permissions

Why This Is Dangerous

This isn’t just “data leakage” — it exposes internal system logic

Sensitive Exposure

• Automation workflows
• Admin activity
• System behavior

Intelligence Leak

• How system triggers events
• Internal structure of workflows
• Business logic insights

Webhook Payload Exposure

• Raw event data
• User references
• Internal identifiers

Impact

Confidentiality

• Exposure of internal automation data

Privacy

• User-related data inside payloads

Security Model Break

• Viewer → Admin-level visibility

👉 Complete breakdown of privilege separation

Bounty & Program Response

• Reported: Jan 17, 2026
• Triaged: Jan 20, 2026
• Severity: Medium
• Bounty: $750 + $100 bonus
• Retest: Fix confirmed

Key Takeaways

• Never trust tokens alone for authorization
• Always validate: User role, Resource ownership
• Test: Hidden endpoints, Token generation APIs
• UI restrictions ≠ backend security
• If you see reusable tokens → test everywhere

Personal Insight

This bug came from a simple curiosity:

“If I can generate this token… where else can I use it?”

That single question exposed an entire internal automation system.

Conclusion

This vulnerability shows how dangerous it is when backend systems rely on tokens without validating user permissions.

Even though the UI correctly restricted access, the API allowed a low-privileged user to access admin-level operational data — breaking the entire security model.

Always remember:

Access control should never depend only on “having a token” — it must verify “who is using it.”

Until next time — happy hacking! 🚀

Connect and Engage

💬 Comment your experience with business logic 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!

For this finding, I was awarded a $800 bounty + $100 retest bonus. At first, this looked like a simple endpoint issue but once I explored it deeper, it turned into a classic IDOR with enumeration potential. Let’s break it down.

Understanding the Target

ExampleCenter provides a People/Form system where organizations collect data through forms.

These forms often contain:

• Personal documents
• IDs
• Consent forms
• Sensitive user information

Access control is supposed to ensure that:

• Only authorized users can view form submissions
• Attachments are restricted to users with proper permissions

I tested using a Viewer-level account, which:

• ❌ Cannot access target forms
• ❌ Cannot view submissions
• ❌ Cannot download attachments via UI

So from the UI perspective — everything looked secure.

The Thought That Triggered the Bug

While inspecting network traffic, I noticed that file downloads were happening via a direct endpoint.

That made me think:

“What if the backend only checks the attachment ID… and not the actual permissions?”

So I decided to test it manually.

The Flaw: Direct Access to Attachments

I crafted a request using a valid session of a Viewer user:

GET /form_submission_value/{attachment_id}/attachments?attachment_name={attachment_name} HTTP/2
Host: api.examplecenter.com
Cookie: session=<viewer_session>

What I Expected vs What Happened

I expected to get 403 Forbidden or Access denied error but Actual i get 200 OK — File Downloaded Successfully

Even though:

• I had no access to the form
• I couldn’t see the submission in UI

👉 I could still download the attachment

The Missing Piece: Enumeration

The analyst asked an important question:

“How do you get the attachment name?”

And this is where the bug becomes more interesting 👇

Enumeration Possibility

• attachment_id → sequential
• attachment_name → guessable / enumerable
• No rate limiting on endpoint

👉 This allows brute-force / enumeration attacks

An attacker can:

• Iterate IDs
• Try common file names
• Extract valid attachments

Why This Matters

Even if enumeration requires effort, the impact is serious because:

👉 Once valid parameters are found → full file access

Root Cause

This was a classic IDOR:

Backend authorization relies only on object reference (attachment_id and attachment_name)

Missing checks;

• Does user have access to form?
• Does user have access to submission?
• Is this attachment allowed for this user?

👉 No authorization validation

Impact

This vulnerability leads to:

Confidentiality Impact

• Access to sensitive documents and images
• Exposure of personal user data

Data Exposure

• IDs
• Medical forms
• Private submissions

Privacy Risk

• Violation of user trust
• Unauthorized data disclosure

Bounty & Program Response

• Reported: Jan 6, 2026
• Clarification: Enumeration explained
• Triaged: Jan 13, 2026
• Severity: Medium (CVSS-based)
• Bounty: $800 + $100 bonus
• Retest: Fix confirmed

Key Takeaways

• Always test direct download endpoints
• IDORs often hide behind: File downloads, Media access & Attachments
• Don’t stop at “need one parameter” — test enumeration
• Lack of rate limiting can turn low bugs into real exploits
• Even partial control over parameters = potential data exposure

Personal Insight

This bug came from a very simple mindset:

“If I can’t access it in UI… can I still fetch it directly?”

That question alone leads to many real-world bugs.

Conclusion

This vulnerability highlights how dangerous it is to rely only on object identifiers without proper authorization checks.

Even though the UI correctly restricted access, the backend allowed direct retrieval of sensitive files completely bypassing access controls.

These types of bugs are very common, especially in systems handling uploads and documents.

Always remember:

If an endpoint returns a file… it MUST verify who is asking for it if not u got the bounty.

Until next time — happy hacking! 🚀

Connect and Engage

💬 Comment your best experience with IDOR bugs!

Follow me on Twitter: @a13h1_

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

The issue allowed me to assign workflow cards to any user ID — including non-existent users or users from another organization using a direct API request.

For this finding, I was awarded a $1,000 bounty + $150 retest bonus. This is one of those bugs that doesn’t look “critical” at first glance, but once you understand the behavior — it becomes really dangerous.

Understanding the Target

ExampleCenter has a workflow system where tasks (cards) are assigned to users.

Each card:

• Belongs to a workflow
• Has an assigned user
• Is visible based on assignment

From the UI, everything is strictly controlled:

👉 You can only assign cards to:

• Users in the same organization
• Users who have access to the workflow

So naturally, I assumed this was properly enforced everywhere.

The Small Observation

While working with workflows, I noticed something:

When assigning a card, the UI only shows a filtered list of valid users who have access to workflow.

That made me think:

“Is this restriction enforced in the backend… or just in the UI?”

This is a very common place where bugs hide.

The Flaw: Assigning Cards to Arbitrary User IDs

I intercepted the request responsible for reassigning a workflow card and modified the assignee_id.

Request

PATCH /api/people/v2/workflows/{workflow_id}/cards/{card_id} HTTP/2
Host: api.examplecenter.com
Authorization: Bearer <user_token>
Content-Type: application/json

{
  "data": {
    "attributes": {
      "assignee_id": "random_or_external_user_id"
    }
  }
}

What I Expected vs What Happened

Expected

❌ Validation error (400/403)

❌ Only valid users allowed

Actual

👉 200 OK — Assignment Successful

Now Here’s Where It Gets Interesting 👇

Depending on what ID I used, different strange behaviors happened:

Case 1: Non-Existent User ID

• Card assigned successfully
• UI shows: “Assigned to: Loading…”
• Card disappears from normal views

👉 The card still exists… but no one can access it

Case 2: User from Another Organization

• Assignment accepted
• Card not visible to anyone in the current org

👉 Cross-tenant reference created

Case 3: Valid User (Same Org but No Access)

• Assignment succeeds
• User cannot see the card
• Other users lose visibility

👉 Card becomes effectively hidden

The Real Problem (Why This Is Dangerous)

At first glance, the program asked:

“Isn’t this just like deleting the card?”

And honestly, that’s a fair question.

But here’s the key difference 👇

Deletion

• Visible action
• Logged
• Recoverable
• Easy to detect

This Bug (Orphaning)

• Silent
• Not obvious
• Hard to trace
• Breaks system logic and assign to another organization user which is outside the feature boundary

What Actually Happens

• Card still exists in database
• Workflow counts still include it
• UI cannot resolve assignee
• Users lose access

👉 Result: Orphaned card

Root Cause

This was a classic trust-of-client issue:

Backend did NOT validate assignee_id

Missing checks:

• Does user exist?
• Is user in same org?
• Does user have workflow access?

👉 API blindly trusted input

Impact

This bug leads to multiple serious issues:

Security Impact

• Unauthorized workflow manipulation
• Cross-tenant reference injection assigning cards to cross organization user

Operational Impact

• Cards disappear silently
• Workflow becomes inconsistent
• Admins cannot track issues

Integrity Impact

• Workflow state corruption
• Reporting becomes inaccurate
• System assumptions break

Logic-Level DoS

• Cards become inaccessible
• Workflows partially “freeze”

Bounty & Program Response

• Reported: Jan 8, 2026
• Discussion: Clarified impact with analyst
• Triaged: Jan 13, 2026
• Bounty: $1,000 + $150 bonus
• Retest: Fix confirmed (API now returns validation error 422)

Key Takeaways

• Always test ID-based parameters (like assignee_id)
• Don’t assume UI restrictions = backend validation
• Test for: Non-existent IDs , Cross-tenant IDs , Unauthorized users
• Logic bugs can be as dangerous as traditional vulnerabilities
• Silent failures are often more dangerous than visible ones

Personal Insight

This bug came from a very simple thought:

“What happens if I assign this to something that shouldn’t exist?”

That curiosity turned a normal feature into a workflow-breaking vulnerability.

Conclusion

This vulnerability shows how dangerous it is to trust client-side filtering for security decisions.

Even though the UI enforced strict rules, the backend allowed invalid assignments — leading to orphaned workflow states, hidden data, and operational disruption.

Sometimes the most impactful bugs are not about hacking systems…

but about breaking their logic assumptions.

Until next time — happy hacking! 🚀

Connect and Engage

💬 Share your experience with logic level DOS bugs?

Follow me on Twitter: @a13h1_

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

For this finding, I was awarded a $2,000 bounty + $150 retest bonus.

This is one of those bugs where everything looks perfectly secure from the UI… but completely breaks at the backend. Let’s walk through how I found it.

Understanding the Target

ExampleCenter provides a calendar management system where organizations manage:

• Events
• Rooms & resources
• People scheduling
• Conflict resolution

The permission model is clearly defined:

• Viewer → Read-only access
• Editor -> Limited edit and manage resources permissions
• Administrator → Full control over calendar

From a Viewer account, I verified:

• ❌ Cannot edit rooms
• ❌ Cannot manage resources
• ❌ Cannot access permission settings

So far, everything looked correctly restricted.

The Thought That Changed Everything

While testing, I noticed something important:

👉 The UI completely hides permission management for non-admin users

But from experience, I’ve learned:

If the UI hides something… it doesn’t mean the API is protected

So I asked myself:

👉 What if I directly hit the permission API?

The Flaw: Full Privilege Escalation via API

I intercepted a request related to permissions from admin account and modified it while logged in as a Viewer and use it.

Crafted Request

PATCH /api/calendar/v2/permissions/{my_user_id} HTTP/2
Host: api.examplecenter.com
Authorization: Bearer <viewer_token>
Content-Type: application/json

{
  "data": {
    "type": "PersonPermissions",
    "attributes": {
      "permissions_level": "Administrator",
      "product_permissions": {
        "editRooms": true,
        "editResources": true,
        "editPeople": true,
        "resolvesConflicts": true
      }
    }
  }
}

What I Expected vs What Happened

Expected

❌ 403 Forbidden

❌ Unauthorized action

Actual

👉 200 OK

And after refreshing the UI…

👉 I was now a Calendar Administrator

What Access Did I Get?

After escalation, I gained full control over the calender system:

• ✅ Manage rooms
• ✅ Manage resources
• ✅ Edit people permissions
• ✅ Resolve conflicts
• ✅ Modify calendar settings

This wasn’t partial access —

👉 This was full administrative takeover of the calendar system

Root Cause

This vulnerability existed because:

Authorization checks were implemented only in the UI, not in the backend API

The endpoint: /api/calendar/v2/permissions/{id}

Did NOT validate:

• User role
• Permission boundaries
• Authorization to modify permissions

👉 Any authenticated user could modify their own permission object

Impact

This is a textbook critical privilege escalation:

Security Impact

• Viewer → Administrator escalation
• Full control over calendar system
• Ability to modify permissions of others

Operational Impact

• Manipulate or delete events
• Disrupt scheduling workflows
• Abuse conflict resolution

Business Risk

• Complete breakdown of permission model
• Unauthorized administrative control
• Potential internal misuse or disruption

Bounty & Program Response

• Reported: Jan 16, 2026
• Triaged: Jan 20, 2026
• Severity: Critical → High (final CVSS classification)
• Bounty: $2,000 + $150 retest bonus
• Retest: Fix confirmed (API now properly returns 403)

Key Takeaways

• Never trust UI-based restrictions — always test backend APIs
• Permission endpoints are high-value targets
• Always test: Role upgrades, Self-permission changes, Hidden admin endpoints
• If you can modify your own permission object → it’s game over
• Always compare: What UI allows and What API allows

Personal Insight

This bug came from a very simple question:

“Can I modify my own permissions directly?”

Sometimes the most critical bugs don’t come from complex techniques —

they come from testing basic assumptions properly.

Conclusion

This vulnerability highlights a critical flaw in many SaaS applications:

👉 Mismatch between frontend restrictions and backend authorization

Even though the UI correctly restricted access, the backend API allowed full privilege escalation — completely breaking the security model.

As a hunter, always remember:

The UI is just a suggestion — the API is the truth.

Until next time — happy hacking! 🚀

Connect and Engage

💬 What’s your experience with Privilege escalation bugs?

Follow me on Twitter: @a13h1_

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

For this discovery, I was awarded a $700 bounty along with a $100 bonus for retesting. Let’s explore how this bug worked, how I exploited it, and why it was important.

Understanding the Target

ExampleCenter is a SaaS platform used for managing teams, scheduling, and workflows within organizations. It follows a role-based access control model:

• Editors/Admins → Can manage teams, structure, and permissions
• Schedulers → Can only assign people to existing teams

To maintain proper security boundaries, only Editors and Admin should be able to:

• Create teams
• Copy teams
• Assign team leaders
• Modify team configurations

The UI correctly enforces this restriction by displaying:

“Only editors can create teams.”

At this point, everything looked correct.

But from experience, I’ve learned one important thing:

If something is blocked in the UI… it doesn’t mean it’s blocked in the backend.

The Moment of Curiosity

Instead of stopping there, I opened Burp and started looking at how the application was communicating with the backend.

I noticed that when switching tabs or loading team-related data, the app was calling certain API endpoints. That gave me an idea:

What if the team creation functionality still exists in the API, but is just hidden in the UI?

So I decided to test it manually by accessing the team creation api from higher level user account and use via scheduler user.

The Flaw: Backend Didn’t Enforce Authorization

I crafted a request to the team creation endpoint using my Scheduler account token:

POST /api/services/v2/service_types/{id}/teams HTTP/2
Host: api.examplecenter.com
Authorization: Bearer <scheduler_token>
Content-Type: application/json

{
  "data": {
    "type": "team",
    "attributes": {
      "name": "SchedulerTeam",
      "copy_team_members": true,
      "secure_team": true,
      "team_leader_ids": [attacker_id]
    }
  }
}

I honestly expected a 403 Forbidden.

But instead…

👉 200 OK — Team Created Successfully

Not only that:

• The team was created
• I was assigned as Team Leader

At that moment, it was clear:

This wasn’t just a UI issue — this was a full authorization bypass.

Going Deeper: How Far Can This Go?

Once I confirmed the initial bug, I started exploring how much control I actually had.

1. Copy Existing Teams

I noticed a parameter:

"copy_from": "<team_id>"

So I tried cloning an existing team.

👉 Result:

• Full team structure copied
• Members and configurations inherited
• I could assign myself as leader

This turned the bug from simple bypass → structured privilege escalation

2. Assigning Leadership

By modifying:

"team_leader_ids": [my_user_id]

I could:

• Assign myself as leader
• Assign other users as leaders

👉 Basically controlling hierarchy inside the system

3. Mass Team Creation

Then I tested limits…

• No rate limiting
• No restrictions

👉 I could create hundreds of teams quickly

This could:

• Flood the system
• Break workflows
• Create administrative chaos

4. Duplicate Team Names

Another small but interesting issue:

• Same team name allowed multiple times
• No uniqueness validation

👉 Leads to confusion + potential misuse

Root Cause

This bug came down to one classic mistake:

Authorization was enforced only in the UI, not in the backend API

• UI → correctly restricts Scheduler
• API → blindly accepts request

This mismatch is exactly where most BAC (Broken Access Control) bugs live.

Impact

This wasn’t just theoretical it had real-world implications:

Security Impact

• Privilege escalation (Scheduler → Admin-like control)
• Unauthorized structural changes
• Self-assigned leadership roles

Operational Impact

• Mass team creation → workflow disruption
• Duplicate teams → confusion
• Increased cleanup overhead

Business Risk

• Breaks trust in role-based permissions
• Violates least privilege principle
• Could enable misuse or internal abuse

Bounty & Program Response

• Reported: Dec 20, 2025
• Triaged: Jan 5, 2026
• Severity: High → Medium
• Bounty: $700 + $100 bonus
• Retest: Fix confirmed (API now returns 403)

Key Takeaways

• Never trust UI restrictions always test the API
• Backend authorization is the real security layer
• Privilege escalation often hides in: Create , Copy ND Assign operations
• Missing rate limits can amplify impact
• Observing API calls / JS endpoints can reveal hidden attack surfaces

Conclusion

This bug is a perfect example of how frontend restrictions can create a false sense of security.

From the UI, everything looked secure.

But under the hood, the API allowed a low-privileged user to perform admin-level actions.

These kinds of vulnerabilities are extremely common in modern SaaS platforms — especially where complex role systems exist.

As a hunter, always ask:

👉 “What if the backend doesn’t care?”

Until next time — happy hacking! 🚀

Connect and Engage

💬 What’s your experience with PE bugs?

Follow me on Twitter: @a13h1_

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

$800 Bounty: Privilege Escalation via API — From Scheduler to Team Admin was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.