Hi Everyone! While testing a SaaS platform (ExampleCenter), I discovered an authorization bypass vulnerability that allowed a low-privileged user (Calendar Viewer) to access automation configurations, execution history, and webhook payloads data that should only be available to admins.

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
None

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!