We coined the poisoned tenant attack in 2023; in 2026, someone used it on us

Three years ago, we published the poisoned tenant attack as part of the Browser and Identity Attacks matrix. Last week, someone used it to target Push Security employees and customers through OpenAI's organization invitation feature. This post breaks down what happened, explores what the payoff is for an attacker, and connects the incident to a broader pattern of SaaS platform abuse that is accelerating across the industry.

What happened

The invitation

In recent weeks, several Push Security team members have received multiple waves of emails from OpenAI inviting them to join an organization called "Push Security Inc". 

The emails came from OpenAI's legitimate notification address (noreply@tm.openai.com), passed all standard email authentication checks, and referenced our company by name. They looked exactly like a routine organizational invitation because, technically, they were one.

The invitations were sent by various accounts registered under email addresses that had no affiliation with Push. 

OpenAI's invitation email did include a warning — "The inviter's email domain, gmail.com, does not match your domain, pushsecurity.com" — but that's a single line in an otherwise completely legitimate-looking email from a trusted platform. The invitation targeted specific employees by their work email addresses, suggesting the attacker had done some reconnaissance on our team. 

One click, no credentials

After discussing internally we decided to investigate further by accepting the invite. The acceptance was instant (one click, no credentials or additional authentication). This was particularly notable because it was done from an entirely separate browser to my typical work profile. I wasn’t already logged into ChatGPT from the browser, but clicking the email link was all it took to join my account to the attacker's organization. 

I landed on a confirmation page telling me I'd been added to "Push Security Inc."

What the attacker had set up

Within the organization, the attacker's account appeared under the name of Push's CEO. 

It's something of a rite of passage for new Push employees to receive scam texts from someone impersonating Adam, usually with an urgent request that inevitably leads to gift cards. But creating a fully configured SaaS tenant under a CEO's name and inviting specific employees into it is a different level of effort entirely.

All invited team members had been assigned the "Owner" role, giving them full administrative access to the organization. A Visa credit card was attached to the billing account.

The response

We spotted the attack straight away and raised the alarm internally before deciding to investigate. Several Push employees had been invited to the tenant but either hadn’t seen the emails, or the wrong email address had been added for the employee. 

By joining the tenant, I was able to see the other employees that had been added, enabling us to speak to each employee to confirm. We could also see that they hadn’t joined the tenant since they were all “invite pending” status. Confirming that nobody had joined (and thus used) the platform was the extent of investigation required. 

We also implemented mail rules to block similar invites from reaching Push employees in future. 

What's the payoff for an attacker?

The attacker created an OpenAI organization, named it after our company, attached a credit card (which we believe was likely stolen — it's hard to see why a legitimate card would be used for this purpose), researched specific employees, and sent targeted invitations. That represents a non-trivial investment of effort. So what was the endgame?

Get employees using the platform — then harvest what they put into it?

An attacker who just wants to spray scam content through a trusted email channel doesn't name the organization after their target, research individual employees, or attach a credit card. 

That investment only pays off if employees actually join the organization and start using it. And on an AI platform, the data people put into prompts can be extraordinarily sensitive — source code, internal documents, customer data, security research, strategic plans.

If someone on the team had assumed "oh, we've got a company OpenAI org now" and started running work through it, the attacker would be sitting on a live feed of that activity as an org administrator with access to usage logs and API interactions.

The stolen credit card removes a friction point that might otherwise tip someone off: if there were no billing set up and employees hit a paywall when trying to use the API, they'd start asking questions internally about who created the org. A pre-funded account removes friction and the chance to discover that something is up.

SAMLjacking a poisoned tenant?

In August 2023, we published SAMLjacking a poisoned tenant, which demonstrated how an attacker could register a tenant on a SaaS platform using a target organization's name, invite employees to join it, and then leverage that foothold for further attacks — in that case, by configuring a malicious SAML identity provider to harvest credentials. The technique is cataloged in the Browser & Identity Attacks Matrix (originally the SaaS attack matrix) as an initial access technique — and when combined with SAMLjacking, it becomes a lateral movement vector too.

The gist is that once an employee has joined an attacker-controlled organization and is treating it as a legitimate company resource, the attacker has a trusted channel for further social engineering — a follow-up message asking team members to connect their SSO, or to authorize a third-party integration that requires OAuth consent.

This is exactly the attack chain we described in the original SAMLjacking post, where a poisoned tenant on a seemingly low-risk platform becomes the entry point for credential harvesting via a malicious SAML configuration.

Based on my research I don’t think this exact scenario is easily possible in the specific context of OpenAI / ChatGPT since domain verification is required in order to enable SAML. However, there are other options to consider. 

Substituting SAMLjacking for project-jacking?

We’ve recently reported on attacks like LLMShare that interestingly also abused ChatGPT — in this case, abusing chat sharing functionality to distribute both malicious instructions and convincing-looking designs that trick the user into navigating to an attacker-controlled site hosting a malicious payload. 

In the cases we observed in the wild, links were distributed via malvertising. But you could see a scenario in which shared projects or conversations are seeded with chats containing malicious links. Or even perhaps malicious instructions in shared projects (effectively a form of prompt injection). In this way, attackers could trick the user into running malicious commands that interact with other connected apps such as their email, calendar, and a long list of cloud services with access to sensitive company data. 

This isn't an isolated technique

Our experience is a specific instance of a broader trend: attackers weaponizing the invitation and notification features built into SaaS platforms to deliver social engineering through trusted channels. 

In January 2026, Kaspersky reported a cruder abuse of the same OpenAI invitation feature. When you create an OpenAI organization, the platform lets you set the organization name to any arbitrary string. Attackers exploited this by stuffing scam content directly into the org name field: fake subscription renewal notices, fraudulent phone numbers for vishing callbacks, and links to adult services. In that case, the org name was the payload, while in our case, the email was the delivery mechanism for a legitimate-looking poisoned tenant. 

In April 2026, Cisco Talos published research on what they termed "Platform-as-a-Proxy" (PaaP), documenting the same technique across GitHub and Jira — phishing lures embedded in commit messages, welcome messages, and other user-controlled fields that feed into platform-generated notification emails. At its peak, Talos estimated approximately 2.89% of emails sent from GitHub on a single day were associated with this activity.

What’s clear is that attackers are abusing SaaS platforms that let anyone create organizations, name them whatever they want, and send invitation emails through the platform's own mail infrastructure. 

What you can actually do about it

The defensive challenge with poisoned tenant attacks is that they exploit legitimate platform functionality delivered through legitimate sites. There's no malicious URL to block, no spoofed domain to detect, and no attachment to scan. The invitation email is, by every technical measure, genuine. That said, there are practical steps that reduce the risk. 

Get visibility into SaaS organization membership

Most organizations have no visibility into which SaaS platform invitations their employees are receiving or accepting. If an employee joins an attacker-controlled Slack workspace, OpenAI organization, or Jira project, the security team typically has no way to know. Any tool that provides visibility into SaaS account creation and organization membership — whether through browser telemetry, IdP monitoring, or platform API integration — closes a significant blind spot. 

Train for invitations, not just phishing

Generic phishing awareness training doesn't cover this scenario well, because the emails genuinely aren't phishing in the traditional sense. They're legitimate platform notifications carrying an illegitimate invitation. Employees need to understand that an email from OpenAI, Microsoft, GitHub, or Atlassian can be both technically authentic and part of an attack — and that joining an organization on any platform is a security-relevant action that should be verified through an internal channel before accepting.

Can you protect against domain squatting?

In some cases, you can register your organization name on a platform to prevent others from claiming it, even if you don't plan to use the platform's organizational features immediately. That said, in others you can have lots of tenants with the same name, and there are no protections around companies claiming a tenant ID impersonating your own — as in this case, where an attacker with a random email address was able to create a realistic-looking Push Security tenant. 

Lobby vendors to do better

Platform vendors need to improve invitation controls. OpenAI does include a warning when the inviter's domain doesn't match the recipient's domain, which is better than nothing — but a single line of text in an otherwise polished invitation email is easy to miss.

Platforms should consider requiring domain verification before allowing an organization to use a company's name, adding more prominent warnings for cross-domain invitations, or allowing enterprise customers to restrict which organizations their employees can join.

The bigger picture

When we published the poisoned tenant technique in 2023, it was a theoretical attack that we hadn't seen used in the wild. Three years later, we've experienced it firsthand, and the technique has moved from our attack matrix to our incident log.

The explosion of SaaS platforms in enterprise environments (particularly with the force multiplier that is AI), each with their own organization and invitation features, has created a sprawling attack surface that most security teams aren't monitoring. Every platform that lets anyone create an organization with any name and invite anyone to join it is offering attackers a trusted delivery channel.

And as AI platforms like OpenAI become standard tools in the enterprise, the value of a poisoned tenant on those platforms — with access to prompts, API usage, and potentially sensitive data — grows significantly.

It's good that we spend our days thinking about this stuff — the attack was caught quickly because the team is wary of exactly these kinds of techniques, and no data was exposed. The next organization targeted with this technique may not have that advantage, especially if the attacker's tenant sits in the background while employees unknowingly feed it data through their normal work.

IoCs

We’ve identified the following emails associated with the campaign so far (at least, in terms of the attacks directly targeting Push):

• phamvankim2133@gmail[.]com

• adam.bateman_928@faeththeraputics[.]email

• amelindashaffer99495@gmail[.]com

However, the real list is likely to be much larger. We’ve confirmed that similar messages have also been received by Push customers. But it's not like you can easily block access to the tenants themselves — they are "legit" OpenAI tenants, using the normal OpenAI domain. And since a new one is being spun up each time, no two attacks will look the same.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.