T05 · Unauthorized Access and Privilege Escalation
- Location
index.py:29- Finding
Overprivileged Gmail Access Through Domain-Wide Delegation
- Content
View full analysis
Vulnerability Details
File Location:
index.py, lines 29–33
Vulnerability Type: Excessive delegated permissions and violation of least privilege
Risk Level: HighVulnerable Code
python SCOPES = ['https://www.googleapis.com/auth/gmail.modify'] credentials = service_account.Credentials.from_service_account_info( self.service_account, scopes=SCOPES, subject=self.user_email ) self.gmail = build('gmail', 'v1', credentials=credentials)Technical Analysis
The application creates Google Workspace credentials using a service account with domain-wide delegation and impersonates the user specified by
self.user_email. It requests the broadgmail.modifyOAuth scope.The implemented workflow sends messages and searches for bounce and unsubscribe messages. It does not need general mailbox modification privileges. The delegated
gmail.modifyscope permits substantially more access than required, including reading mailbox content and modifying mailbox state.Because domain-wide delegation bypasses ordinary per-user consent, compromise or unauthorized use of the service-account credential would allow an attacker to assume the configured user's delegated Gmail privileges. Whether other domain users could also be impersonated depends on the Google Workspace delegation policy and service-account authorization configured outside this repository.
Attack Path
- An attacker obtains access to the Google service-account credential used by the application. The configured credential location is disclosed in
config/settings.json, although the credential itself is not included in the audited project. - The attacker constructs delegated Google credentials using the service account and an authorized Workspace user as the impersonation subject.
- The attacker requests the already authorized
gmail.modifyscope. - The attacker uses Gmail API operations beyond the application's legitimate sending and search requirements.
- Within the per ...[truncated 916 chars]
- An attacker obtains access to the Google service-account credential used by the application. The configured credential location is disclosed in
- Remediation
View remediation
Remediation Suggestions
- Replace
gmail.modifywith the minimum scopes required:- Use
https://www.googleapis.com/auth/gmail.sendfor message delivery. - Add only the narrowest Gmail read or metadata scope that supports the required bounce and unsubscribe searches.
- Use
- If Gmail's available narrow scopes cannot support the search workflow, separate sending and inbox processing into distinct identities or services so the bulk sender does not retain mailbox-modification access.
- Restrict Google Workspace domain-wide delegation to explicitly approved OAuth scopes and dedicated campaign identities.
- Use a dedicated campaign mailbox rather than a general-purpose employee mailbox.
- Store the service-account credential in a managed secret store with strict filesystem and IAM controls. Do not expose it through source control, logs, command output, or broadly readable paths.
- Rotate the service-account key and review Google Workspace audit logs for unauthorized impersonation or mailbox activity.
- Where supported, replace long-lived service-account keys with workload identity federation or another short-lived credential mechanism.
- Add automated tests or deployment checks that reject OAuth scopes broader than the documented operational requirements.
- Replace