Topic starter
11/08/2026 3:23 pm
TL;DR: UNC6040 and UNC6395 are abusing OAuth phishing, overprivileged integrations, and harvested secrets to move from SaaS compromise into data theft and lateral access across connected environments, according to Bishop Fox. The pattern shows that SaaS governance now depends on least privilege, IP restrictions, and visibility into where tokens and credentials actually live.
Editorial analysis by NHI Mgmt Group, based on content published by Bishop Fox: “State of the SaaS Security Union”.
Key questions
Q: What breaks when organisations leave standing privilege in SaaS integrations?
A: Standing privilege turns a stolen or abused token into a long-lived access path.
Q: Why do stolen SaaS tokens create such a large breach impact?
A: Stolen tokens often bypass the strongest login controls because they represent already-approved sessions or delegated access.
Q: What are the signs that a SaaS-to-SaaS integration has been compromised?
A: Look for unusual query volume, bulk data exports, unexpected changes to integration behavior, and access from unfamiliar infrastructure.
Practitioner guidance
- Inventory all SaaS integrations as non-human identities Build a register of every OAuth app, service account, and API credential across your SaaS estate, including who owns it, what it can access, and when it was last reviewed.
- Reduce integration scope to the minimum required objects Remove broad object-level access, shared integration profiles, and inherited admin-style permissions from SaaS connectors that do not need them.
- Restrict SaaS and integration access by IP and known hosts Apply IP restrictions to user and integration access wherever the platform allows it, and reject vendors or connectors that cannot support fixed egress ranges for their automation.
Bottom line: The article shows that SaaS compromise now often travels through integrations, OAuth grants, and stolen secrets rather than only through direct account takeover.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/08/2026 3:33 pm
Integration abuse is now an identity problem, not just a SaaS problem. The article shows attackers using OAuth grants, tokens, and service credentials as reusable access rather than as one-off session artefacts. That changes governance expectations because each integration must be treated as a non-human identity with scope, ownership, and revocation requirements. For practitioners, the right control lens is lifecycle and privilege, not only application hardening.
A few things that frame the scale:
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
A question worth separating out:
Q: Who is accountable for securing SaaS integrations that create blind spots across an organisation?
A: Accountability sits with the organisation that approves, connects, and monitors the SaaS environment, not with the connectivity alone. Security, identity, and application owners should define minimum control expectations for every integration, including access scope, logging, review, and revocation. Where vendors publish inconsistent data, internal governance must compensate with standards, evidence collection, and ongoing oversight.
👉 Read our full editorial: SaaS integration abuse is exposing secrets across connected apps