$750 Authorization Bypass: Enumerating Calendar Forms via Group Type ID

Hi Everyone! Sometimes the most interesting bugs are not about direct access… but about connecting two features that were never meant to trust each other.

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>

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

Step 3: Send API Request

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

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_

Contents