Results at a glance
Case flow
- 01Inventory signup domains
Identify every domain authorized for autonomous registration.
- 02Verify current ownership
Compare allowlists with registrar and DNS ownership records.
- 03Remove stale trust
Delete expired, typo, campaign, and legacy domains immediately.
- 04Monitor continuously
Alert when an approved domain approaches expiration or changes ownership.
Many large organizations configure their Slack workspaces to allow autonomous registration. This feature enables employees to join the company workspace automatically without waiting for an explicit invite, relying instead on a verified corporate email domain (e.g., matching @company.com).
While reviewing this onboarding feature, I identified a widespread systemic risk. The vulnerability doesn’t stem from a flaw in Slack’s codebase, but rather from an administrative oversight: companies abandoning or forgetting to renew the domains authorized to register users.
If an organization allows signups from a domain that has expired or contains a typo, an attacker can buy that domain, set up mail routing, and instantly gain entry into the internal workspace.
How the Attack Works
The exploitation process relies on finding a mismatch between active Slack signup configurations and actual domain ownership.
1. Target and Feature Identification
An attacker identifies a target's workspace URL—often mirroring the company name (e.g., https://target.slack.com). By appending /join/signup to the URL, they can check if open registration is enabled.
https://target.slack.com/join/signupIf active, the page displays the specific email domains permitted to register, such as @targetgroup.com.
2. Domain Availability Verification
The attacker checks the registration status of the allowed domain via WHOIS lookups or registrar searches (like GoDaddy). In surprisingly many cases, companies use secondary domains, promotional domains, or legacy branding for Slack routing that they eventually let expire, unaware that the Slack signup gate remains wide open.
3. Infiltration
If the domain is available, the attacker purchases it for a nominal fee, configures a wildcard MX record or a catch-all email server, and heads back to the Slack signup page. By registering with any alias under the purchased domain, they receive the verification code and seamlessly authenticate into the workspace.
Impact
The consequences of an outsider gaining full internal member status are severe:
Information Disclosure: Access to historical channel logs, pinned documents, internal credentials, and private keys often shared carelessly in chat.
Corporate Directory Exposure: Full visibility into employee names, titles, and email addresses, providing a perfect map for targeted spear-phishing.
Social Engineering & Internal Phishing: The ability to message employees from a trusted internal profile, bypass external email banners, and upload malicious payloads directly into active chat threads.
The Scope of the Issue
This methodology is highly scalable and can be automated across thousands of bug bounty targets. Furthermore, the risk isn't exclusive to Slack; it applies to any enterprise collaboration platform (such as Microsoft Teams or Zoom) that permits open domain-based registration.
I have identified and reported this flaw across multiple bug bounty programs, resulting in rapid triages and resolutions as organizations race to clean up their legacy signup rules.
For more security research insights and write-ups, follow me on Twitter: @siratsami71.
Could the same assumption be hiding in your attack surface?
Test the exact trust boundary—and the paths around it—with evidence-led manual security assessment.
Discuss a security assessment
