CVE-2026-81035 in Midday
Summary
by MITRE • 08/26/2026
Midday allows any member of a team to delete it. The delete procedure in apps/api/src/trpc/routers/team.ts authorises the caller with the team-access helper, which returns true for every row in the team-membership table irrespective of the role it records, and the data-layer function it calls re-checks the same helper and nothing else. The neighbouring procedures that remove or update a member in the same router each resolve the caller's role and refuse the request unless it is owner, so the check exists in the file and is not applied to deletion. Member is the role an invited user receives, so any invitee can remove the team and every record scoped to it, and the deletion enqueues the cleanup job with the stored bank-connection tokens, which the job then uses against the connected providers. The update procedure in the same router carries no role check either.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in the Midday application represents a critical Broken Access Control flaw within its team management API layer, specifically located in the delete and update procedures for teams. This issue stems from an inconsistent implementation of authorization logic where the system fails to enforce appropriate privilege levels before allowing destructive actions on shared resources. The core technical defect lies in the use of a generic helper function named team-access which is invoked during the deletion process. Unlike other operations within the same router, such as removing or updating member roles, this helper does not inspect the specific role associated with the user's membership record. Instead, it returns true for any row present in the team-membership table, effectively treating all members, including those with minimal privileges like invitees, as having full administrative control over the entire team entity.
This inconsistency creates a severe authorization bypass scenario where users who have only been invited to join a team can execute actions reserved exclusively for owners or administrators. While the codebase contains role-checking logic in neighboring procedures that correctly restricts member removal and updates to owner-level permissions, this safeguard is entirely absent from the deletion workflow. The data-layer function responsible for executing the delete operation re-validates access using the same flawed helper rather than performing a distinct check against the user's actual role attributes. This oversight allows any authenticated team participant to permanently destroy the team structure, leading to catastrophic data loss and operational disruption for all other members who rely on that workspace.
The impact of this vulnerability extends beyond simple data deletion due to the specific nature of the Midday application as a financial tool integrating with banking providers. When a malicious or compromised member deletes a team, the system enqueues a cleanup job designed to handle resource teardown. This job utilizes stored bank-connection tokens associated with the deleted entity to interact directly with external payment service providers. Consequently, an attacker exploiting this flaw can not only erase internal records but also potentially trigger unauthorized disconnections from banking services or expose sensitive financial credentials during the cleanup process. The lack of role verification in the update procedure further exacerbates the risk by allowing arbitrary modifications to team configurations without proper oversight, widening the attack surface for privilege escalation and data tampering.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, as the application fails to enforce required administrative privileges before performing sensitive operations. It also maps directly to MITRE ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate but insufficiently privileged credentials to perform actions beyond their intended scope. The failure is rooted in a logical error rather than a technical bug in the underlying framework, highlighting the importance of rigorous code review practices that ensure authorization checks are consistently applied across all related endpoints within a module.
To mitigate this risk, immediate remediation requires refactoring the deletion and update procedures to explicitly verify the caller's role against an allow-list containing only owner or administrator privileges. The generic team-access helper should be deprecated for sensitive operations in favor of granular permission checks that inspect the specific row data from the team-membership table. Additionally, implementing a soft-delete mechanism with audit logging can provide recovery options and traceability for destructive actions. Security testing procedures must include automated regression tests to ensure that future changes do not reintroduce inconsistent authorization logic across different API endpoints within the same router.