The Control Plane Was the Target This Week. Your AI SOC Might Miss Why.

This week's exploited flaws sat in the management and trust plane itself — a SIEM (Splunk), a malware sandbox (FortiSandbox), a hosting control panel (LiteSpeed/cPanel), an SD-WAN controller (Cisco), and the HR system of record (Oracle PeopleSoft) — while the supply chain moved into AI developer tooling. We feature insights from Aqsa Taylor of Exaforce on "vibe hunting" and why an AI SOC that lacks context can hurt as much as help.

Author

Ashish Rajan
June 18, 2026

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: The AI SOC is only as good as the data it reasons over (continue reading) 

This image was generated by AI. It's still experimental, so it might not be a perfect match!

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 pattern this week was uncomfortable: the systems an enterprise runs to see, operate, or protect everything else were the ones under attack. A pre-auth RCE chain landed in Splunk, the box your IR team would use to spot an intruder. FortiSandbox, the appliance that detonates files you don't trust, came under active exploitation. And Oracle PeopleSoft, the system of record for HR and payroll data, was exploited by ShinyHunters before any patch existed. When the exploited surface is the control plane, the blast radius isn't one host — it's the tooling you'd otherwise use to find and contain the others.

That makes this week's episode well-timed. Ashish Rajan sat down with Aqsa Taylor, Chief Security Evangelist at Exaforce (and formerly a product lead on Twistlock and Prisma Cloud), for a conversation about "vibe hunting" applying AI agents to threat hunting the way vibe coding applies them to development and what actually separates an AI SOC that earns trust from one that buries a real alert. Her throughline connects directly to the news: the AI is only as good as the data and context it reasons over. (Disclosure: Exaforce sponsored this episode.)[Listen to the episode]

⚡ TL;DR for Busy Readers

  • 🚨 Oracle's patch arrived after the compromise had already begun. Review logs back to late May, not just the disclosure date.

  • A critical Splunk flaw exposed a surprising reality: deployment topology may matter more than patch status when assessing exposure.

  • FortiSandbox exploitation turned a security control into the attack surface itself.

  • Cisco SD-WAN and LiteSpeed joined CISA's KEV list, continuing a trend of attackers targeting management and control systems.

  • AI developer tooling became the latest supply-chain target, with compromised packages and fake AI assistants hunting for API keys.

  • 🎯 The pattern matters more than the CVEs: attackers spent this week targeting the systems used to manage, detect, analyse, and govern everything else.

  • 🤖 From this week's podcast: Aqsa Taylor (Exaforce) explains why AI SOC platforms fail without context, why "vibe hunting" is gaining traction, and why the future of detection depends more on the data model than the model itself.

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

 1. Oracle PeopleSoft zero-day (CVE-2026-35273) exploited by ShinyHunters before disclosure

What Happened

Oracle issued an out-of-band alert for CVE-2026-35273 (CVSS 9.8), a server-side request forgery flaw in PeopleSoft PeopleTools 8.61 and 8.62 that is remotely exploitable without authentication and can lead to remote code execution. Mandiant and the Google Threat Intelligence Group attributed pre-disclosure exploitation to ShinyHunters (UNC6240), with activity running roughly May 27 to June 9 — before any patch existed. CISA added it to KEV on June 12 with a federal deadline of June 15. Stolen data was published on the ShinyHunters leak site.

Why It Matters

PeopleSoft is the system of record for HR and financial data at large institutions, so an unauthenticated SSRF-to-RCE converts directly into bulk exfiltration of the most regulated data an enterprise holds, plus a credential-harvesting foothold into federated identity systems. Exploitation predated the advisory by about two weeks, so log review back to late May matters more than racing the June 15 clock.

Action for defenders: Confirm PeopleTools is patched per Oracle's alert; pull web-tier and Integration Broker logs for SSRF patterns and anomalous outbound requests from late May onward, and treat any PeopleSoft-adjacent service-account credentials touched in that window as exposed.

🚨 2. Splunk Enterprise pre-auth RCE chain (CVE-2026-20253) is exposed by default on AWS

Primary source: Orca Security 
Reporting: CyberSecurityNews · The Cyber Express

What Happened

Researchers disclosed CVE-2026-20253 (CVSS 9.8), an unauthenticated RCE chain in Splunk Enterprise 10 and later that abuses a misconfigured PostgreSQL sidecar. The sidecar isn't always enabled on-prem but runs by default in Splunk Enterprise on AWS, so cloud deployments are exposed out of the box. Exploitation allows file creation/destruction on the host, code execution inside the Splunk environment, and SSRF pivoting to internal resources. Splunk has released a fix. 

Why It Matters

The SIEM holds credentials and network reach into nearly every system it monitors, so pre-auth RCE on Splunk is a detection-and-response decapitation — the attacker lands inside the tool your IR team would use to spot them. The default-on AWS exposure is the operative detail: "we didn't enable that service" is right on-prem and wrong in cloud, making deployment topology the thing to check first.

Action for defenders: Identify Splunk Enterprise 10+ instances on AWS, apply the fix, and until patched, restrict network reach to the PostgreSQL sidecar and keep the management interface on a hardened admin path

🛠 If you only do one thing this week: Take 30 minutes to map which of your security and detection tooling — SIEM, sandbox, log pipeline, AI gateway — is reachable from anything other than a hardened admin path, and on which platform. This week's Splunk and FortiSandbox flaws both turn on deployment topology, and the episode's core point is the same: the tool you'd use to catch the intruder is exactly what's being targeted.

☁️ 3. Fortinet FortiSandbox flaws under active exploitation

Primary source: CyberScoop 
Reporting: SecurityWeek · The Hacker News 
Analysis: CISA KEV

What Happened
Threat-intel firm Defused reported active exploitation of a pair of FortiSandbox flaws Fortinet disclosed earlier this year — 49 exploitation events from 11 IPs over six days, traced to nine countries. Reporting ties the activity to an OS-command-injection flaw (CVE-2026-39808) and a path-traversal flaw (CVE-2026-39813), the latter confirmed exploited June 15. Fortinet separately patched a WEB UI command-injection flaw, CVE-2026-25089 (CVSS 9.1); SOCRadar reported ~30,000 exposed Fortinet firewalls.

Why It Matters
FortiSandbox detonates files an organization doesn't trust, so code execution on the sandbox hands the attacker a privileged position inside the pipeline meant to contain malicious code — the containment tool becomes the execution environment. For hybrid estates feeding cloud-bound mail and file flows through FortiSandbox, a compromised appliance can poison verdicts and pass malware as clean into cloud workloads downstream.

Action for defenders
Inventory FortiSandbox appliances and confirm a fixed build, restrict WEB UI and management access to an admin segment, and hunt for the vendor/Defused indicators across the June window.

🏥 4. CISA's June 15 KEV additions: LiteSpeed cPanel root escalation and a second Cisco SD-WAN flaw

What Happened

CISA added two actively exploited flaws to KEV on June 15. CVE-2026-54420 (CVSS 8.5) is a symlink-handling flaw in the LiteSpeed cPanel plugin (before v2.4.8; LiteSpeed WHM Plugin before 5.3.2.0) that lets a user with FTP or web-shell access escalate to root on shared-hosting servers running CloudLinux or CageFS; the federal deadline was June 18. The second add, CVE-2026-20262 in Cisco Catalyst SD-WAN Manager, is an arbitrary-file-write / path-traversal flaw distinct from the command-injection flaw (CVE-2026-20245) covered in the June 10 brief.

Why It Matters

A symlink-to-root flaw on CloudLinux/CageFS breaks the per-tenant isolation shared hosting sells as its core control, so one tenant with a web shell reaches every other tenant on the box — a multi-tenant blast radius on the hosting tier many SaaS and agency workloads still run on. A second Cisco SD-WAN Manager flaw in two weeks means the controller is under sustained probing; reopen that item if you closed it after June 10.

Action for defenders
Upgrade the LiteSpeed WHM/cPanel plugin and review hosting-server logs for symlink-abuse indicators; for Cisco SD-WAN Manager, confirm both CVE-2026-20245 and CVE-2026-20262 remediations and restrict management-plane access to a hardened jump path.

🛡️ 5. Supply-chain attacks shift to AI developer tooling: Mastra npm namespace and fake JetBrains plugins

Primary source: The Hacker News 
Reporting: Help Net Security

What Happened

Two near-simultaneous supply-chain compromises aimed at AI development tooling. Roughly 144 npm packages under the Mastra namespace were compromised after a single account mass-published 140-plus malicious packages within a short window on June 17. Separately, a coordinated JetBrains Marketplace campaign published at least 15 malicious plugins posing as AI coding assistants that exfiltrate AI-provider API keys to attacker-controlled servers.

Why It Matters

The credential these campaigns steal is the AI-provider API key, now a billing-and-data primitive — a leaked key buys model access on the victim's account and the data flowing through it. Targeting the AI-coding-assistant supply chain means the malicious code lands inside the developer's agentic toolchain, which already has filesystem, repo, and often cloud-credential reach. It's the news-side mirror of what Aqsa Taylor describes below: attacks that ride GitHub and package registries and look like normal developer activity until you have repo-layer context.

Action for defenders: 
Inventory Mastra packages and AI-coding-assistant IDE plugins across engineering, rotate any AI-provider API keys reachable from dev machines or CI in the June 17 window, and add AI-provider keys to the secret-scanning and short-TTL policies you apply to cloud credentials.

🛡️ 6. Databricks acquires Panther Labs, consolidating the security-data layer for AI-era detection

Primary source: Tech Startups 
Reporting: Infosecurity Magazine

What happened: Databricks agreed to acquire Panther Labs, a cloud-native security-data and detection platform whose customers include Anthropic. Reporting frames it as Databricks' third cybersecurity acquisition and a move to compete with CrowdStrike and Cisco-owned Splunk as enterprises rebuild detection for AI-driven threats. Financial terms were not disclosed.

Why it matters: A data-platform vendor buying a SIEM-class detection layer points at where security operations is consolidating — onto the same lakehouse that already holds the enterprise's analytics data. For architects it reframes a procurement question (which SIEM) into a data-gravity question: if detection moves to where the data already lives, tool-selection independence narrows toward whoever owns the lakehouse. It rhymes with the episode's argument that the AI SOC is defined by its data model, not its label.

Action for defenders: If Panther or Databricks is in your stack, map current detection-content and data-residency dependencies now, so a post-acquisition consolidation doesn't quietly relocate where your security telemetry lives or who governs access to it.

🎯 Cloud Security Topic of the Week:

The AI SOC is only as good as the data it reasons over.

This week's news kept hitting the tools security teams rely on — the SIEM, the sandbox, the package registry developers trust — and that is exactly the surface Aqsa Taylor's argument is about. The pitch for "AI SOC" is everywhere; by her count there are more than 54 startups in the category, plus every legacy SIEM and SOAR rebadging into it. Her test for separating signal from marketing isn't the model but the data: what config, identity, code, and posture context does the platform fold in before it tells you what's a false positive? As she put it, "AI can help, but it can also hurt without the right context." The same week attackers compromised npm and JetBrains plugins that look like ordinary developer activity, that's not abstract — it's the difference between a tool that catches the anomaly and one that waves it through. [Listen to the full episode →]

Definitions and Core Concepts 📚

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

  • Vibe hunting — "If you're using AI for code development, it's vibe coding. If you're using AI for threat hunting in SOC, vibe hunting." The analyst's skill stays; AI makes the hunt faster and higher-confidence.

  • AI SOC — A contested umbrella label. SIEM and SOAR vendors now market themselves as AI SOC too, so the category name tells you little; the data the AI reasons over tells you everything.

  • The four pillars — Detection, investigation, triage, response. Triage is the commoditized layer; the differentiated value is level-two investigation and, carefully, response.

  • Semantic / real-time knowledge graph — A "living graph" fusing events with configuration, identity, code, and posture context, retaining business-context exceptions over time.

  • Peer-group baselining — Judging a user's behavior against their team's baseline, not only their own.

  • MFA fatigue / "spray and pray" — Flooding a user with auth attempts so they approve one MFA prompt; response is session/token revocation and blast-radius containment.

  • ITDR / ISPM — Identity threat detection and response / identity security posture management.

  • CNAPP — Cloud-native application protection platform, where code-repo and posture context typically live before it reaches the SOC.

This week's issue is sponsored by Varonis

AI Security Requires More Than Visibility. It Requires Control. 

Security leaders are under pressure to enable AI innovation while managing a rapidly expanding attack surface across cloud, identity, and data layers. AI agents and copilots can introduce new access paths, automated high-impact actions, and accelerate threat timelines. 

Varonis Atlas helps organizations secure AI end-to-end - from understanding usage and enforcing guardrails to detecting suspicious activity and reducing risk dynamically. watch the recording to learn how Varonis Atlas can help security teams operationalize AI security at scale. 

💡Our Insights from this Practitioner 🔍

1. "Vibe hunting" came from the SOC floor, not the marketing team

Aqsa is explicit that the term originated with her company's own MDR team during a live hunt, then stuck because it mirrored vibe coding. The substance underneath is automation agents that update detection logic continuously as indicators publish, instead of an analyst manually chasing blogs and Substacks.

"If you're using AI for code development, it's vibe coding. If you're using AI for threat hunting in SOC, vibe hunting." — Aqsa Taylor

Point agents at trusted IOC sources so detection logic updates as indicators land, while checking the environment's exposure window from configuration and posture data — not only from inbound events.

2. AI without context can hurt, not just help

The sharpest take is a warning, not a pitch. An AI layer that just wraps event severity can bury a real alert among false positives, because it lacks the context to judge what matters.

"AI can help, but it can also hurt without the right context." — Aqsa Taylor

Her example is the HackerBot Claw campaign: not a code vulnerability but malicious pull requests, where a payload manipulated Claude's auto-merge instructions and altered a README. PR-change requests aren't something traditional scanners alert on — the same repo-layer blind spot this week's Mastra and JetBrains compromises exploited.

3. Fix the data model before you trust the agents

Trust in AI agents depends on the underlying data model, not the model's raw intelligence. A more powerful frontier model doesn't remove the need for context.

"even before we move into AI, I think the data model on which the AI runs is so important to be able to then trust the AI agents" — Aqsa Taylor

She contrasts a static prompt-with-Claude approach — which works only on the data you feed it — against a "proactive model" where the data is a living graph that surfaces exposure on its own.

4. The hardest detections look exactly like normal activity

The detection problem worth solving is the legitimate-looking behavior. Aqsa's example is a North Korean "fake employee" with valid access who exfiltrates by copying a sensitive file and sharing the copy.

"They could copy the contents and then share the copied file with external, and you would not see that as a shared event because you're seeing the main file." — Aqsa Taylor

Catching that requires SaaS-layer visibility across Google Workspace, GitHub, Okta, and Slack, plus peer-group baselining: comparing a new hire's behavior to their team's, not just their own short history.

5. "AI SOC" is a crowded label — interrogate the data, not the badge

When Ashish notes buyers face 50-plus vendors, Aqsa's answer is to stop selecting on the label.

"there's over 54 in the startup world ... in AI SOC. And then I'm not even counting all the traditional platforms who have pivoted to AI SOC messaging more recently." — Aqsa Taylor

The buying question to ask instead: what factors — config, identity, code, location — does the platform weigh when it reduces false positives, and is it proactive enough to run its own detections rather than waiting on upstream providers?

6. AI doesn't change the threats; it changes the volume and the timeline

Across the four pillars, most platforms only do triage — enriching upstream events. The real value is reaching the judgment of an experienced level-two analyst.

"where defenders really need help with AI and where AI can give a lot more is level two threat investigation." — Aqsa Taylor

She expects 2026 to be when teams move past level-one and level-two triage into investigation and, carefully, response — but only after the first three pillars build trust. Response agents are real (she cites customer testimonials recorded during an RSA panel), but they earn autonomy.

7. Response works when one platform owns the whole kill chain

The response pillar becomes viable when the foundation pillars feed it — so the platform runs detection, identity mapping, blast-radius, and containment without hopping between ITDR, threat-hunting, and SOAR tools.

"we saw a credential stuffing attempt where there were like 390 authentication attempts across 14 accounts." — Aqsa Taylor

In that MFA-fatigue case, tying the detection to identity risk (who clicked phishing before), impact radius (which sensitive files the account can reach), and recent sharing activity — then revoking sessions — collapses a multi-tool workflow into one chain.

8. Don't build it yourself — equip your defenders instead

Both host and guest land on the same build-versus-buy conclusion. Ashish frames the trap from a CISO's chair:

"I am actually employing people to build a product in my own company. Is that what I'm going towards?" — Ashish Rajan

Aqsa agrees: DIY with Claude can help with smaller scripts, but it doesn't remove the context, accuracy, and confidence-scoring burden — "it's almost like you're changing the effort, but you're still putting effort." Her recommended starting point: begin with level-one triage on top of your existing SIEM using a dedicated platform, and "start from data" by asking what the platform weighs before you trust its verdicts.

"You need to make sure that you're equipping your defenders, your team, with the same advantage that the attackers have." — Aqsa Taylor

Practical Takeaways for Cloud Security Leaders

  • Map which security tooling (SIEM, sandbox, AI gateway) is reachable outside a hardened admin path, and on which platform — this week's flaws turn on topology.

  • Rotate AI-provider API keys reachable from dev machines and CI, and scan for them like cloud credentials.

  • When evaluating an AI SOC, ask what data (config, identity, code, location) it weighs — not whether it says "AI."

  • Start with level-one triage on your existing SIEM; treat the full four-pillar model as the destination, not the first project.

AppSec & DevSecOps Guidance

Podcast Episode

Question for you? (Reply to this email)

🤔  When did a "normal-looking" action — a copied file, a pull request — turn out to be the incident? What gave it away?

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!

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