For most of the last decade, the conversation about SaaS security focused on the apps themselves: is Salesforce hardened, is ServiceNow patched, is Microsoft 365 configured correctly. Two incidents disclosed in June 2026 are a reminder that, in 2026, the apps are rarely the soft target. The integration and identity layer that connects them is. OAuth tokens for connected apps, refresh tokens left behind by deprecated integrations, and custom API endpoints inside otherwise hardened platforms are now the backdoors attackers reach for first. This article walks through what happened in those two cases, why the pattern matters, and the practical governance playbook a mid-market company can implement to close the same gaps.
On June 11, 2026, Salesforce disabled the Klue (Battlecards) app integration after it became clear the integration had been abused to exfiltrate competitive-intelligence and pipeline data from customer Salesforce instances. The incident has been reported and analyzed by The Hacker News, Dark Reading, ReliaQuest in a threat spotlight, Obsidian Security, and the Salesforce-focused outlet Salesforce Ben.
The core mechanic, as described across those sources, is what should make every security team pause. Attackers did not exploit a flaw in Salesforce. They did not phish a Salesforce administrator. They obtained a long-lived, dormant OAuth refresh token tied to a deprecated Klue-to-Salesforce integration and used it to authenticate as the integration account. Once authenticated, they ran mass queries against the CRM, harvesting account, opportunity, and competitive-intelligence records at multiple enterprise clients. The integration was old, in some cases no longer actively used, but the token had never been revoked and the connected app remained authorized. From Salesforce's perspective, the API traffic was indistinguishable from legitimate use by an approved integration partner.
Salesforce ultimately disabled the Klue connected app to stop the bleeding. By then, the attackers had been operating through a trusted, sanctioned door.
In early June 2026, BleepingComputer reported a separate but structurally related incident: ServiceNow disclosed a security issue caused by an unauthenticated-access flaw in a Scripted REST API endpoint. The specific cause was a configuration parameter, requires_authentication, set to false on an endpoint that should have required authentication. The result was that unauthenticated HTTP requests could read customer instance data. ServiceNow remediated hosted instances as part of its response.
Again, the platform itself was not vulnerable in the classical sense. ServiceNow's authentication, RBAC, and audit capabilities were intact. A custom-built API endpoint inside the platform had been published with authentication disabled, and that single configuration choice was enough to expose data that the rest of the platform was protecting.
Two different platforms, two different mechanisms, the same lesson: the breach surface was not the core app. It was the integration and identity layer that surrounds it. In the Salesforce case, an OAuth refresh token outlived the integration that issued it. In the ServiceNow case, a custom API endpoint was published in a posture that bypassed the platform's own access controls. In both, the attackers walked through a door the customer had built, or left open, themselves.
For a mid-market company, this matters because the integration and identity layer is almost always under-governed. The core SaaS platforms are heavily scrutinized during procurement; their connected apps, custom endpoints, and machine-to-machine credentials usually are not. Most organizations cannot answer, on demand, the basic questions: how many OAuth grants are active in our Salesforce, Microsoft 365, Google Workspace, and ServiceNow tenants today; which were issued to integrations that no longer exist; which have scopes far broader than the integration ever needed; and which custom endpoints were spun up by a project team three years ago and never reviewed.
A defensible posture for the integration and identity layer comes down to five disciplines. None of them is novel. The differentiator is whether you actually run them continuously.
Every SaaS platform of any size exposes an admin view of connected apps, authorized OAuth grants, and the scopes each was granted. The first job is to pull that inventory across every platform in scope, normalize it into a single register, and keep it current. The register should record, per grant: which platform, which app, who authorized it, when, the scopes, the last time the grant was used, and the business owner accountable for it. Without this, the rest of the playbook is guesswork.
A useful test of the inventory is to pick a deprecated tool your company stopped using twelve to twenty-four months ago and check whether any of its OAuth grants are still active. In most environments we audit, the answer is yes. The Salesforce-via-Klue case is exactly this pattern at scale.
Inventory is necessary but not sufficient. The Salesforce incident as analyzed by ReliaQuest and Obsidian shows that the most dangerous tokens are the ones nobody is thinking about: long-lived refresh tokens tied to integrations that were retired without a formal decommissioning step. Treat token age and idleness as risk signals. Any refresh token tied to an integration that has not been used in, say, ninety days should be flagged for review and revocation. Any deprecated integration should trigger a written decommissioning procedure: disable the connected app on the platform side, revoke all tokens, remove the corresponding service account, and record the change in your inventory.
This is unglamorous work. It is also exactly the work that would have prevented the Klue path.
Many OAuth grants are issued with scopes far broader than the integration actually needs, often because the integration's setup wizard requested a coarse-grained role. Periodically review the scope set on every grant against what the integration documents itself as requiring, and tighten where you can. Where the platform supports it, prefer shorter access-token lifetimes and shorter refresh-token windows. The trade-off is some additional re-authentication for the integration; the benefit is that a stolen token has a smaller blast radius and a shorter window of utility for an attacker.
In the Salesforce case, the attackers' traffic looked like legitimate integration activity because the credential was legitimate. What was not legitimate was the volume and the query pattern. A connected app that historically read a few hundred records per day suddenly running mass queries against the full CRM is a behavioral anomaly, and behavioral monitoring of API traffic is what catches it. This means feeding platform audit logs and API access logs into a SIEM or detection platform, baselining normal per-app behavior, and alerting on deviations. The detection signal is rarely a single failed login; it is a known-good credential doing something it has never done before.
The ServiceNow case is a direct instruction. Any custom or scripted API endpoint inside a SaaS platform must default to requires_authentication enabled and must require an explicit, reviewed exception to disable. Inventory every custom endpoint in every platform, audit the authentication posture of each, and remove or repair anything that allows unauthenticated access without a documented, signed-off reason. The same discipline applies to webhook receivers, public REST endpoints fronted by your own infrastructure, and any HTTP interface that touches platform data. The cost of doing this once and keeping it true is small. The cost of not doing it is the headline.
Most mid-market security teams understand all five disciplines. The reason they do not run continuously is capacity. Inventorying connected apps across four or five major platforms, reviewing scopes, hunting dormant tokens, monitoring API traffic, and auditing custom endpoints is steady-state work that competes with everything else on a lean security team's plate. It tends to get done once during an audit cycle and then drifts.
This is the practical case for a managed model. A managed [cybersecurity partner](/en/services/cybersecurity) runs the inventory and revocation cycle on a defined cadence, ingests platform audit logs into continuous monitoring, and treats anomalous integration behavior as a tier-one alert. A managed [API integration practice](/en/services/software-development/api-integration) handles the clean, least-privilege design and decommissioning of integrations so that dormant tokens do not accumulate in the first place. A [DevSecOps function](/en/services/software-development/devsecops) folds the same controls into the development pipeline so that custom endpoints inside SaaS platforms ship with authentication on by default and are reviewed before they reach production.
The reason this works economically for a mid-market budget is delivery model. Doing 24/7 integration-layer monitoring with in-house staff in Western Europe is expensive enough that most companies do not do it. Doing it nearshore from Morocco, in a Western-European time zone with a multilingual, technically skilled workforce, is affordable enough that most companies can. Our [Why Morocco](/en/why-morocco) overview explains why that cost and time-zone profile makes continuous, hands-on work like this viable rather than aspirational.
The Salesforce-via-Klue and ServiceNow incidents of June 2026 are not stories about flawed SaaS platforms. They are stories about an integration and identity layer that almost every mid-market company is running without continuous governance. The fix is not exotic technology; it is a small, disciplined set of practices, inventory, revocation, least-privilege, behavioral monitoring, endpoint hardening, applied continuously to a surface that most teams currently audit once a year, if that. Whether you build that practice in-house or contract it to a partner is a choice. Whether you need it is not. The same companion piece on production AI reliability is here: [Your AI Agent Passed the Demo, Not Production: The 2026 Reliability Playbook](/en/blog/ai-agent-reliability-evals-production-gap-2026).
If you want help inventorying your connected-app surface, decommissioning dormant integrations safely, or putting continuous integration-layer monitoring on contract, two ways to start:
As reported by The Hacker News, Dark Reading, ReliaQuest, Obsidian Security, and Salesforce Ben, attackers used a long-lived, dormant OAuth refresh token tied to a deprecated Klue-to-Salesforce integration to authenticate as the integration account and run mass queries against customer CRM records, exfiltrating competitive-intelligence and pipeline data. Salesforce disabled the Klue connected app on June 11, 2026 in response.
BleepingComputer reported that ServiceNow disclosed an unauthenticated-access flaw in a Scripted REST API endpoint whose requires_authentication parameter was set to false, allowing unauthenticated HTTP requests to read customer instance data. ServiceNow remediated hosted instances as part of its response.
No. In both cases the core platform was not exploited in the classical sense. The breach surface was the integration and identity layer: a stale OAuth token in the Salesforce case, a misconfigured custom API endpoint in the ServiceNow case. The platforms were doing what they were asked to do; the customer-controlled layer around them was the weak point.
Pull a live inventory of every connected app and active OAuth grant across your major SaaS platforms (Salesforce, Microsoft 365, Google Workspace, ServiceNow, and equivalents), then identify any grants tied to integrations that are no longer in use. Revoke them. That single exercise eliminates the most common version of the Salesforce-via-Klue scenario.
Through behavioral monitoring of API and app-to-app traffic. A known-good integration suddenly running mass queries it has never run before is the anomaly. This requires feeding platform audit and API logs into a SIEM or detection platform, baselining per-app behavior, and alerting on deviations, since the credential itself looks legitimate.
Our managed cybersecurity, API integration, and DevSecOps teams run the inventory, revocation, scope review, and continuous monitoring on a defined cadence, and review custom API endpoints inside SaaS platforms so authentication is on by default. Delivery is nearshore from Morocco, which makes 24/7 coverage economically realistic for mid-market budgets.
CALL IT DEV — Software, AI and dedicated tech teams — Casablanca | Madrid | Dubai — contact@callitdev.com — +212-537-373777