🔑 MFA Was On and Attackers Walked Around It: Securing the Agent Control Plane with Open Source

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: Agent Identity and the Control Plane — Why "MFA Is On" Stopped Being the Right Question(continue reading) 

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI Security Podcast every week.

Welcome to this week’s Cloud Security Newsletter

The week did not produce one dramatic incident. It produced a cluster with a single tell: SimpleHelp remote management, Cisco Unified Communications Manager, Kemp LoadMaster, Oracle PeopleSoft's environment-management hub, and the Azure CLI login path all took direct fire in five days. These are not customer-facing apps. They are the interfaces that administer other systems, and the reader's exposure this week is less about any one CVE than about which admin surfaces are internet-reachable and whether their authentication actually covers every path in.

Underneath that runs a sharper thread. In the Azure CLI spray and the SimpleHelp bypass, multi-factor authentication was present and got skipped anyway, not brute-forced but routed around, through a deprecated OAuth flow in one case and a forged, unsigned identity token in the other. That is the exact failure mode Ely Kahn spends this episode on — the Chief Product Officer at Okta, who joined five months ago specifically to work on agent identity after co-founding Sqrrl (acquired by AWS), launching AWS Security Hub, and serving as CPO at SentinelOne. His argument: the building blocks of identity have not changed, but the environment has, and the place teams keep getting hurt is the long-lived, overprivileged token.[Listen to the episode]

⚡ TL;DR for Busy Readers

• Nissan employee data breached via Oracle PeopleSoft zero-day (CVE-2026-35273): the victim-disclosure phase of a management-hub flaw — HR system-of-record for four countries reached through one internet-exposed admin component. Confirm no PSEMHUB instance is externally reachable.

• 🚨 Azure CLI password spray hit 78 accounts by routing around Conditional Access: 81M attempts against the ROPC OAuth flow that issues tokens without an interactive MFA prompt. Set Conditional Access to All cloud apps / All client app types and block ROPC.

• 🚨 SimpleHelp RMM OIDC bypass (CVE-2026-48558) added to KEV, July 2 deadline: the tool checked that a token existed but never checked it was signed by the real issuer — a supplier-shaped blast radius across every downstream customer. Patch above 5.5.15 and rotate reachable cloud/AI keys.

• Cisco Unified CM SSRF (CVE-2026-20230) actively exploited, federal deadline already passed June 28: blast radius decided by a config flag (WebDialer enabled), not a version number. Query for WebDialer enablement, not just patch level.

• Kemp LoadMaster pre-auth RCE (CVE-2026-8037) now has a public exploit: root on a load balancer is a position above the apps it fronts. No confirmed in-the-wild exploitation yet — patch or restrict the management API before scanning catches up.📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

Each story includes why it matters and what to do next — no vendor fluff.

1.  Nissan discloses employee data breach from the Oracle PeopleSoft zero-day (CVE-2026-35273)

Primary source: BleepingComputer 
Reporting: SecurityWeek, Infosecurity Magazine

What Happened

Nissan North America notified current and former employees that attackers exploiting Oracle PeopleSoft zero-day CVE-2026-35273 accessed personnel records. The flaw is a CVSS 9.8 unauthenticated SSRF-to-RCE bug in the PeopleTools Environment Management Hub (PSEMHUB); Oracle shipped emergency mitigations on June 10. Nissan filed its breach notification June 25, with public reporting on June 29. Researchers attribute the campaign to a cluster tracked as UNC6240, linked to the ShinyHunters extortion group; exposed data spans employees in the US, Canada, Mexico, and Brazil and may include payroll, banking, and government ID numbers.

Why It Matters

 The CVE itself was covered in the June 18 brief; this is the victim-disclosure phase, where the enterprise cost of a management-hub flaw becomes visible. PSEMHUB administers PeopleSoft environments, so one exposed instance handed attackers the HR system of record for four countries. The exploitation window (May 27 to June 9) closed before Oracle's June 10 mitigation, so patch-on-disclosure was already too late for anyone internet-exposed. Programs that inventory only production customer apps and treat internal HR/ERP admin components as low priority keep learning about these through a breach-notification letter.

Action for defenders:  Confirm whether any PeopleSoft PSEMHUB instance is reachable from outside your management network; if PeopleTools is at 8.61/8.62, verify the June 10 Oracle mitigation is applied and hunt for SSRF-pattern requests to PSEMHUB back to late May.

2. Azure CLI password-spray campaign compromised 78 accounts by routing around Conditional Access

Primary source: Huntress 
Reporting: The Hacker News, SecurityWeek

What Happened

Huntress documented an automated password-spray campaign against Microsoft's Azure CLI login path, running more than 81 million attempts between June 12 and June 26 from an IPv6 range operated by LSHIY LLC (AS32167). At least 78 accounts across roughly 64 organizations were compromised. The attackers replayed breach-corpus username and password pairs against the Resource Owner Password Credentials (ROPC) OAuth flow, which posts credentials straight to the /token endpoint and issues tokens without an interactive MFA prompt.

Why It Matters

This is MFA that was configured and still bypassed. The Conditional Access policies at the affected orgs were real but scoped, enforced for admin portals or named apps rather than "All cloud apps" and "All client app types," and ROPC lives in the gap. The control did not fail as code; it failed as coverage. This is the news-side proof of what Kahn argues in the interview: the question stopped being "is MFA on?" and became "which authentication flows can reach a token without ever hitting the policy?"

Action for defenders: In Entra, set Conditional Access to All cloud apps / All client app types, enable the userStrongAuthClientAuthNRequired tenant setting to block ROPC outright, then pull sign-in logs for ROPC/legacy-auth token grants over the June 12–26 window.

🛠 If you only do one thing this week: Pull your Entra sign-in logs for ROPC and legacy-auth token grants over the June 12–26 window, then flip Conditional Access to All cloud apps / All client app types. Both this week's identity incidents (Azure CLI and SimpleHelp) succeeded by reaching a token through a path the policy never covered — closing the uncovered flow is the 30-minute action that maps directly to the week's editorial thesis.

☁️ 3. SimpleHelp RMM OIDC bypass (CVE-2026-48558) added to KEV, exploited to drop the Djinn stealer

Primary source: CISA KEV 
Reporting: Help Net Security 
Analysis: Arctic Wolf, Horizon3.ai

What Happened
CISA added CVE-2026-48558 to the KEV catalog on June 29 with a July 2 deadline. The flaw is an OIDC authentication bypass in SimpleHelp RMM (versions 5.5.15 and earlier, plus 6.0 pre-releases): when OIDC is enabled, the software does not verify the cryptographic signature on identity tokens, so a remote unauthenticated attacker can forge a token, land a fully authenticated technician session, and bypass MFA in some configurations. Blackpoint Cyber documented attackers using the forged session to deploy a Node.js loader (TaskWeaver) and a new credential stealer (Djinn).

Why It Matters
RMM is a supplier-shaped blast radius. SimpleHelp is widely used by MSPs and IT-service providers, so one forged technician token is not one endpoint but every downstream customer that provider reaches. The failure is precise: the tool checked that a token existed but never checked it was signed by the real issuer, so MFA sat behind a step the attacker could skip. This is Kahn's identity-proof point made concrete knowing a session is who it claims to be is the whole game, and reporting that the forged access harvested cloud and AI API keys turns a remote-support compromise directly into cloud-account access.

Action for defenders
If you run SimpleHelp, patch above 5.5.15 immediately and rotate any cloud/AI provider keys reachable from serviced endpoints; if a vendor uses SimpleHelp to support you, ask them today which version they run and whether they have hunted for TaskWeaver/Djinn indicators.

🏥 4. Cisco Unified CM SSRF (CVE-2026-20230) added to CISA KEV with a June 28 federal deadline

Primary source: CISA KEV alert (2026-06-25) 
Reporting: BleepingComputer, The Hacker News

What Happened

CISA added CVE-2026-20230, a CVSS 8.6 server-side request forgery bug in Cisco Unified Communications Manager, to the KEV catalog on June 25 and set a June 28 remediation deadline for federal agencies under BOD 26-04. Cisco patched the flaw on June 3; the SSRF targets the WebDialer service and lets an unauthenticated attacker write arbitrary files to the underlying OS, which chains to root-level code execution. The security firm Defused reported in-the-wild exploitation beginning the weekend of June 21–22, after a public write-up exposed the file-write path.

Why It Matters

The exploit reached active use only after a proof-of-concept made the SSRF-to-file-write step concrete - a live example of the disclosure-to-exploitation gap collapsing once someone publishes the hard part. Blast radius here is set by a configuration flag, not a version number: only deployments with WebDialer enabled are exploitable, and WebDialer is off by default. That inverts the usual triage. A program sorting purely by CVSS will either over-rotate on patched-but-not-vulnerable hosts or miss the enabled ones.

Action for defenders
Query your Unified CM estate for WebDialer enablement rather than version alone; where it is on and not needed, disable it, and confirm the June 3 Cisco patch is applied on any host exposing the service.

🛡️ 5. Public exploit chain drops for critical Progress Kemp LoadMaster pre-auth RCE (CVE-2026-8037)

Primary source: watchTowr Labs 
Reporting: The Hacker News, Cyber Security News

What Happened

On June 29, watchTowr Labs published a full technical write-up and working exploit chain for CVE-2026-8037, a CVSS 9.8 pre-authentication RCE in Progress Kemp LoadMaster. The bug is an uninitialized-memory/string-termination flaw in the escape_quotes() function meant to sanitize input before it reaches a shell command; anyone who can reach the appliance API can run arbitrary commands as root with no credentials. Progress published its advisory on June 4 (the flaw was reported by Syed Ibrahim Ahmed of TrendAI Research) and says it has no reports of exploitation, but a working PoC is now public.

Why It Matters

A load balancer sits in front of application traffic and terminates sessions, so root on the LoadMaster is a position above the apps it fronts, not beside them. The clock started June 29: the vendor advisory sat for three-plus weeks at low urgency, and the watchTowr publication is the event that converts it into a mass-scan target because it hands attackers the exact primitive. This is the pre-exploitation window in real time — patch status, not incident response, is still the lever, but only until scanning catches up. To be precise: there is no confirmed in-the-wild exploitation yet, so treat this as a public-PoC story, not an active-exploitation one.

Action for defenders: 
Treat any internet-reachable Kemp LoadMaster management API as urgent: apply the Progress fix from the June 4 advisory, and if patching lags, restrict API access to a management network now rather than waiting for exploitation reports.

6. Aflac Japan discloses breach affecting 4.38 million customers

Primary source: SecurityWeek 
Reporting: The Japan Times, Security Affairs

What happened: Aflac Life Insurance Japan, the Japan subsidiary of US insurer Aflac, disclosed on June 30 that attackers reached its customer website and related systems, exposing data on about 4.38 million customers and roughly 40,000 agencies. Intruders accessed systems repeatedly between June 15 and June 25, when a traffic surge revealed the activity. Exposed records include names, addresses, dates of birth, and policy details, plus bank account numbers used for premium payments for about 230,000 customers; credit card and national ID numbers were not affected, and Aflac says its US systems are not involved.

Why it matters:  For this reader base the signal is subsidiary-and-parent risk, not the raw record count. A US-headquartered insurer's non-US subsidiary was breached on infrastructure the parent likely does not administer or monitor directly, yet the parent's name carries the disclosure. The month of dwell between first access (June 15) and detection-by-load-surge (June 25) is the tell: detection came from a performance anomaly rather than a security control, which is what happens when a subsidiary sits outside the parent's monitoring perimeter. The banking data for 230,000 customers is the part that turns this from notification into fraud exposure.

Action for defenders: If your org has subsidiaries or acquired entities on separately managed stacks, confirm they feed the same detection and logging pipeline as the parent; a load-driven discovery a month in is evidence the perimeter did not extend to them.

🎯 Cloud Security Topic of the Week:

Agent identity: who the agent is, what it can reach, what it's doing and how do you offboard it?

Two of this week's stories are token problems wearing different clothes. Azure CLI issued tokens through an OAuth flow that never met the policy; SimpleHelp accepted tokens it never verified were signed. Kahn's episode is the conceptual layer under both: as autonomous agents multiply, the same two questions — is this identity real, and is this access still appropriate — stop being solved by static permissions and start requiring standards built for identities whose goals change every day. The through-line for the week is that the management and identity plane is where the damage now lands, and agent identity is the version of that problem heading straight for every enterprise that shipped an agent this quarter. [Listen to the full episode →]

Featured Experts This Week 🎤

• Ely Kahn — Chief Product Officer, Okta

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

Before diving into our insights, let's clarify some key terms:

• Non-human / AI-agent identity: the identity assigned to a software agent or workload rather than a person. Kahn's point is that the building blocks (least privilege, governance, monitoring) are the same as for humans, but agents get new goals constantly, so static permission models break.

• ROPC (Resource Owner Password Credentials): an OAuth flow that posts a username and password straight to the token endpoint and returns a token without an interactive MFA prompt — the flow the Azure CLI campaign abused to sit in the gap left by scoped Conditional Access.

• OIDC (OpenID Connect): an identity layer on top of OAuth. The SimpleHelp flaw was an OIDC bypass: the software accepted identity tokens without checking their cryptographic signature, so a forged token passed as authentic.

• XAA (Cross-App Access): as Kahn describes it, "an extension of OAuth" and an open standard led by Okta with partners including Anthropic, letting apps and agents "securely pass the baton to one another" without static master keys or per-action consent pop-ups. Now built into the MCP server protocol. Developer resource: xaa.dev.

• ID-JAG (identity assertion grant): the mechanism under XAA that puts an identity provider in the middle of app-to-app interactions and grants access without consent pop-ups.

• SPIFFE: gives every workload or agent a unique, verifiable digital identity, cryptographically encoded into a short-lived document (typically an X.509 certificate) used to prove identity within an environment.

• Intent-based security: a model with zero standing privilege where, at tool-invocation time, an assessment checks whether the tool call aligns with the agent's intent; a dynamic permission is generated for that single call and revoked on completion.

• Guardian agents: agents that assess whether a given tool invocation is acceptable and aligned to what the monitored agent was set up to do — the enforcement mechanism when human approval can't scale.

• Kill switch / universal logout: an Okta capability, originally for human identities and now extended to agents, to cut off a compromised agent's access immediately and universally.

• MCP (Model Context Protocol): the standardized way agents connect to external tools and data; Kahn notes XAA is now part of the MCP server protocol maintained by Anthropic.

This week's issue is sponsored by Maze

💡Our Insights from this Practitioner 🔍

Agent Identity and the Control Plane

Kahn frames agent identity as a paradox: in the mechanics it is not new, and in the environment it is completely new. "In some ways it's not different at all in that you need, uh, least privileged identities. You need to govern those identities through things like IGA. You need to provision access to privileged resources through things like PAM." The building blocks — IGA, PAM, ISPM, ITDR — carry over. What breaks is the assumption underneath them.

1. The breach is the long-lived, overprivileged token

Human roles are stable enough to tolerate static permissions. Agents are not. "You're giving them new problems to solve all of the time, and the most effective agents are the ones that are gonna be very autonomous. And it's very hard to predefine every permission that autonomous agent may need." The workaround teams reach for is the dangerous one:

"People give agents long-lived, broadly scoped permissions to basically do anything that they may need to do in the future, and this is where companies can get into trouble."

Kahn's example is a recent one he keeps unnamed on purpose. "There was a big one in April, a vibe coding company had their entire source code" stolen:

"They had their entire source code stolen basically because of an attacker found a token, a long-lived, overprivileged token associated with the agent that they were using, this was a third-party agent, and then used that to move into the company, move laterally, and ultimately get access to that source code."

That is the same primitive as this week's Azure CLI and SimpleHelp stories: a credential that outlived its need and reached further than it should have.

 2. Assume breach on agents, because prompt injection isn't going away

Kahn's reason that identity is "suddenly invited to the cool kids' table" is blunt:

"I think the reason for this is agents will be breached. I don't think this problem of prompt injection is, is gonna go away anytime soon. And we have to assume breach on agents."

Ashish Rajan, who started his own career in identity, agreed from the research side:

"prompt injection is almost an impossible problem to solve with the way we use systems today."

The consequence is a shift in where the effort goes. If you cannot reliably stop the agent from being manipulated, you contain what a manipulated agent can do. In Kahn's words, "ensuring that they have secure, least privilege identities is the highest ROI security action that you can do."

3. XAA is the middle path between master keys and consent-popup fatigue

Ask an agent to check Slack, read a calendar, and update a project board, and historically developers had two bad options:

"Either give that AI agent a permanent master key, like a static API key, which is, as we know, very unsafe if leaked... or bombard the user with constant annoying, 'Do you give permission?' pop-ups every single time the AI tries to do something."

Cross-App Access is Kahn's answer: predefine which apps an agent may reach, then let an identity provider broker access via ID-JAG without per-action prompts. It operates on behalf of a human at the intersection of the human's and the agent's permissions — "so it'll always be least privilege" — or fully autonomously with the agent's own identity. Kahn is emphatic that this is not proprietary lock-in: "this is an open standard. It can be used by anyone," and it is now part of the Anthropic-maintained MCP server protocol.

4. SPIFFE and XAA solve different halves of the same puzzle

Teams that already run SSO and SAML ask which new standard to pick. Kahn's answer is that it is not a choice:

"SPIFFE is, you know, is this, what's the identity of this agent?... versus XAA is really about what resources can that agent connect to."

SPIFFE proves identity inside your environment with a short-lived X.509 credential; XAA governs what that proven agent can reach across apps, which fits SaaS-heavy estates. Kahn also flags newer cross-company work — a Linux Foundation initiative modeled on DNS that would give each agent a "passport ID" that works across domains.

5. Authorization has four maturity levels, and the top one has no standing privilege

Kahn lays out a ladder. Service-account API keys with broad access sit at the bottom ("that's where we need to move away from as quickly as possible because the blast radius is so big"). Coarse-grained scopes with short-lived ephemeral tokens are next — how XAA works. Fine-grained access that honors data sensitivity and labels comes after. The top rung is aspirational:

"the agent has zero standing privilege. No access is given to the agent in terms of standing privileges. And instead, at tool invocation time, an assessment is made as to whether that agent is trying to make a tool call that is aligned with the intent of that agent. And then a dynamic permission is generated and granted for that agent to make just that single tool call, and then is revoked once it's completed."

Because human approval cannot scale to autonomous-agent volume, Kahn expects "guardian agents that are assessing whether that tool invocation is acceptable or not."

6. Nobody is offboarding agents and there needs to be a kill switch

Rajan raised the gap directly: "I don't know anyone who's talking about offboarding an AI agent... People just make agents and they walk away from it." Kahn's answer runs on two tracks. Governance-side, agent offboarding "does look a lot like human off-boarding" — joiner/mover/leaver reviews, access campaigns, and analysis of toxic permission combinations, with AI layered in to flag agents that hold scopes they never use. Runtime-side, there is the kill switch:

"once you've identified that there is malicious or suspicious behavior, you want an ability to cut off agent access immediately and universally. And this is where the idea of a kill switch comes into play."

7. The MVP governance bar is three questions

For a CISO adding agents to an existing identity program, Kahn reduces the bar to three questions: where are my agents (known and shadow, including browser-level and locally installed agents and their MCP servers), what can they connect to (XAA and agentic identity governance), and what are they doing (runtime monitoring through an agent or MCP gateway that logs every tool invocation and feeds anomaly detection). If a team can only start in two places, he is specific:

"knowing where your agents are and importing them into a registry. And then secondly, ensuring that you're at least assigning those AI agents coarse-grained scopes, and not using API access keys with broad permissions."

Which lands back where the week started: the reachable, overprivileged, unverified credential is the exposure, whether it belongs to an admin interface or an agent.

📚 RELATED RESOURCES 🎧

AppSec & DevSecOps Guidance

• Huntress — Azure CLI password-spray research

• CISA Known Exploited Vulnerabilities Catalog

• CISA KEV alert, June 25, 2026 (Cisco Unified CM)

• watchTowr Labs — Kemp LoadMaster pre-auth RCE write-up

• BleepingComputer — Nissan / Oracle PeopleSoft breach

• Arctic Wolf — SimpleHelp CVE-2026-48558 analysis

• SecurityWeek — Aflac Japan breach

• Okta - Cross App Access

• https://xaa.dev/ 

Podcast Episode

• Cloud Security Podcast  : Episode with Ely Kahn

Question for you? (Reply to this email)

🤔  Do you know which authentication flows in your tenant can reach a token without ever hitting your MFA policy?

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

📬 Want weekly expert takes on AI & Cloud Security? [Subscribe here]”

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter community💙

Peace!

Shilpi Bhattacharjee

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Security Podcast