This week’s Cloud Security Newsletter topic: Containment Over Policy: Paved Paths for Agents and Vibe Coders, and Egress as the Choke Point (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 gap between a fix and working exploitation is now measured in hours, and AI shows up on the attacker's side in several of this week's stories. OpenSSH's password bypass drew exploitation attempts almost as soon as the patch shipped. A researcher who says AI helped him published more than 30 zero-days against a remote management platform. Anthropic reports that an unreleased model wrote a remote root exploit for a Linux kernel bug. Qubole's customers lost AWS data through a trusted vendor role, with no software flaw involved.

This week we feature Nick Reva, director of security engineering at DoorDash, in conversation with Ashish on the AI Security Podcast. He describes how DoorDash handles the professional engineer running coding agents and the vibe coder who has never opened a terminal, and why he judges every control by one question: if an incident starts, how fast can you shut it down? [Listen to the episode]

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

Primary source: BleepingComputer
Reporting: SecurityWeek, Help Net Security
Analysis: eSecurityPlanet (KEV listing relay)

What Happened
CVE-2026-123158, nicknamed "SSHole" by researcher Ozgun Kultekin, lets a remote attacker log in to accounts whose password hash is set to "" by sending an oversized password. On musl-based Linux without PAM, the hashing function returns "" on error and OpenSSH treats that as a match. It affects OpenSSH before 10.6p2, including Alpine's default openssh-server build. The fix shipped on November 5 and exploitation attempts followed within days. CISA added the flaw to KEV on November 9 with a November 12 federal deadline.

Why It Matters
The exposed systems are container base images and cloud images. Help Net Security, citing SOCRadar, lists Alpine tiny-cloud AWS and Azure images 3.18.11 through 3.24.3, where the default alpine user has passwordless doas, so a login leads to root. BleepingComputer reports post-exploitation that went straight to cloud metadata queries and edits to authorized_keys. Installing the patched package does not restart a running sshd, so a patched image can keep serving the vulnerable process, and any program that counts "package installed" as "patched" will report green while exposed.

Action for defenders: Inventory Alpine, Buildroot, OpenWrt and Yocto-based images and containers running sshd, upgrade to OpenSSH 10.6p2, restart sshd, and set PasswordAuthentication no where passwords are not required. Search auth logs from November 5 for password logins by accounts that have no password set.

Action for defenders: Inventory Alpine, Buildroot, OpenWrt and Yocto-based images and containers running sshd, upgrade to OpenSSH 10.6p2, restart sshd, and set PasswordAuthentication no where passwords are not required. Search auth logs from November 5 for password logins by accounts that have no password set.

Primary source: BleepingComputer

Reporting: SecurityWeek

What happened: Researcher Sean Bales posted more than 30 alleged zero-days in N-able's N-central remote monitoring and management (RMM) platform on LinkedIn and published a GitHub repository called Able2Shell with proof-of-concept exploits. He said the discovery was AI-assisted, and that he did not notify N-able first because earlier reports on a different N-able product went unpatched. The most severe item is an unauthenticated XXE-to-RCE chain that runs commands as the nable user and can create a rogue administrator. N-able took hosted N-central environments offline on November 9 across the Americas, Europe and Asia-Pacific and told on-premises customers to shut their servers down "until further notice." N-able says it has not observed exploitation and is building a hotfix. [VERIFY: BleepingComputer has not independently confirmed all 30+ flaws, and the hotfix had no return date at publication.]

Why it matters: An RMM platform holds administrative reach into every tenant it manages, so a public exploit chain before a hotfix turns one vendor's hosting problem into every customer's incident window. The usual vendor-first sequence did not happen: proof-of-concept code was public before a fix existed, and the finder credits AI assistance for the volume. If one researcher can produce 30 findings that way, management planes will see longer queues of reports than vendors staff for. (That last point is an editorial inference.)

Action for defenders: If you run N-central on-premises, follow N-able's instruction to take it offline and watch uptime.n-able.com for hotfix status. If an MSP manages your estate, ask which RMM it uses and what it will do about local agent credentials and delegated admin access while the platform is down.

🛠 If you only do one thing this week: open the Entra enterprise applications list and write the named owner next to every app that holds a directory role or a client secret. Start with the ConnectWise and SkyKick apps: disable them (do not delete, which drops consent), remove any role you did not grant, and review secrets added since October 13. It takes 30 to 60 minutes and answers the first question Ramesh Ramani's DNS program had to answer: who owns this?

Primary source: The Hacker News (cites a Wiz technical analysis)

What happened: Between October 14 and October 26, an attacker used credentials for the AWS account that Qubole's platform uses to reach customer accounts, and assumed IAM roles in multiple customer accounts. Sentra spotted the activity and alerted Wiz. Most assumed roles were unused but still trusted Qubole's account. In examined accounts the attacker read Lambda environment variables, Secrets Manager secrets and SSM Parameter Store values, tested harvested credentials (AWS keys, Entra ID client secrets, Okta client credentials) with TruffleHog, and copied S3 data, sometimes a whole bucket in one session. How the attacker obtained Qubole's credentials has not been disclosed, and Qubole's owner Idera had not issued a statement. [VERIFY: the brief did not read Wiz's analysis directly. Victim count, attribution and whether the activity has stopped are not stated.]

Why it matters: The External ID in the AssumeRole call is not a secret and anyone with access to the role can read it, so it cannot stop a stolen vendor identity. The researchers say a source-IP condition alone would have blocked every observed role assumption. Unused vendor roles that still trust the vendor's account are standing access that nobody watches, and the stolen data included Entra and Okta secrets, which carried the blast radius out of AWS.

Action for defenders: List every IAM role whose trust policy names a third-party account, delete the unused ones, and add aws:SourceIp or aws:SourceVpce conditions to the rest. Then search CloudTrail from October 1 for AssumeRole calls from the vendor's account with non-AWS source IPs, and rotate the secrets those roles could read.

🛠 If you only do one thing this week: find every Alpine, Buildroot, OpenWrt and Yocto-based image that runs sshd, move it to OpenSSH 10.6p2 and restart the service, then time how long it takes to cut one of those workloads' outbound traffic. Both fit in under an hour, and the second gives you the containment number Nick Reva says decides whether an incident ends.

Primary source: Cybersecurity Dive (reporting Microsoft Threat Intelligence)

What happened: Microsoft tracks a Cambodia-based, financially motivated cluster, Storm 3358, that began attacks in October 2026 against banking and other firms in Southeast Asia and globally. It uses Artex, described as "an AI-enabled pen-testing tool that allows hackers to automate attacks," alongside conventional tools. Entry came through server-side request forgery and anonymous file-upload flaws, followed by remote-access Trojans (vshell and AdaptixC2) pulled down with curl and netcat. The reporting ties Artex to other activity: CERT-In reported a campaign against Indian fintechs and lenders, and CrowdStrike linked a cluster it calls Vapor Panda to a global espionage campaign of about 200 organizations. [VERIFY: Microsoft's report was not read directly, and the Storm 3358 victim count is not given.]

Why it matters: One automation framework turning up in both criminal and espionage operations makes the tool the stable thing to detect. The entry points named, SSRF and unauthenticated upload, are application-layer flaws on internet-facing workloads, and an SSRF on a cloud-hosted service is a metadata-credential question (an editorial inference that the article does not state).

Action for defenders: Review internet-facing apps for SSRF and unrestricted upload, enforce IMDSv2 and equivalent metadata protections, and hunt for vshell and AdaptixC2 artifacts. Pull Microsoft's report for the full indicator set before building detections.

Carried forward from the October 21 edition. The flaws were disclosed October 20 and patched October 21, after that edition's research pass.

Primary source: The Record

Reporting: The Hacker News

What happened: CVE-2026-109618 and CVE-2026-109619, two CVSS 9.2 unauthenticated RCE flaws in core PHP, were fixed on October 21 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA added both to KEV on October 26 with an October 29 federal deadline, a week after saying it had seen no exploitation. A researcher's honeypots recorded working shells on October 24, and GreyNoise reported at least six successful exploitations. The Record reports that Dream tied a suspected Chinese campaign to a chain of PHP2Shell and CVE-2026-46300 that compromised 24 firewalls, that Dream later named the vendor as Palo Alto Networks, and that Unit 42 verified the findings and shipped a fixed PAN-OS management web server. The Hacker News cites Censys at more than 32.51 million PHP services running an affected version. PHP 8.1 and older are end of life with no fix, and the PHP team says no complete mitigation exists, with risk highest on mod_php. [VERIFY: sources conflict on Dream's chain (24 firewalls with 22 webshell-only per The Record; 25 servers per The Next Web, which also reports Unit 42 withdrew its assessment of a separate attack and that Sophos saw mostly scanning). Honeypot evidence matches CVE-2026-109618 only; both are on KEV.]

Why it matters: A PHP flaw ended up on a firewall's management plane, so the PHP you need to find lives inside vendor appliances as well as your own servers.

Action for defenders: Find PHP in images, vendor appliances and managed runtimes, redeploy on the fixed versions, and plan a migration for anything on PHP 8.1 or older. The same family includes Node2Shell (Node.js Brotli decoder, CVE-2026-111497), added to KEV on October 27 with a November 10 federal deadline today. Check Node 22.23.4, 24.22.1 and 26.12.1 in the same pass. [VERIFY: Node2Shell dates and fixed versions come from a BleepingComputer article and a Tier 3 relay.]

Note: reported 2026-11-03 (Red Hat kernel patch 2026-11-01, Ubuntu fix in the proposed pocket 2026-11-02). Outside the strict 5-day window by two days but included as the single out-of-window exception: a critical flaw in the Linux kernel is an automatic candidate under the core-software rule, and the AI-written exploit is the clearest sign of how short exploit-development time has become.

Primary source: The Hacker News

Reporting: Akamai Security Research, BleepingComputer

What happened: A race condition in how the kernel frees IPv4 options on an incoming TCP connection gives an unauthenticated remote attacker a use-after-free through SYN packets carrying Record Route or Timestamp options. The bug dates to Linux 4.4, the upstream fix landed in October, and the kernel CVE team scored it 9.8. Red Hat raised its own rating from 5.9 to 9.8 and shipped RHEL 8, 9 and 10 kernels on November 1. Ubuntu 22.04, 24.04 and 26.04 fixes were in the opt-in proposed pocket as of November 2, and Ubuntu 20.04, 18.04 and 16.04 had no fix. Anthropic said on October 27 that an unreleased internal Claude model wrote a remote root exploit that works against a server with an MPTCP listener. Akamai and The Hacker News report no known exploitation in the wild and no public working exploit. [VERIFY: the exploit claim is Anthropic's own and has not been independently reproduced. Ubuntu status was current as of November 2. Exploit-timing figures differ between sources (48 minutes to a kernel address leak and five minutes to a root shell per The Hacker News; about 53 minutes per BleepingComputer).]

Why it matters: The demonstrated exploit needs an MPTCP listener, and Go 1.24 and later enable MPTCP by default on Linux listening sockets, so services written in Go may be exposed without anyone having turned it on. Disabling MPTCP does not remove the bug. Red Hat's nftables rule that drops IPv4 TCP packets with IP options does not cover container-to-container traffic on the same host, which leaves the east-west path open on the mitigation most clusters would reach for first. The disclosed exploit-development time, minutes to hours of model runtime per the reports, is a number to put in front of anyone still planning on a 30-day patch cycle.

Action for defenders: Run sysctl net.mptcp.enabled and ss -M -l -n -p -e across Linux fleets and node pools to find MPTCP listeners, then move to patched kernels (RHEL errata from November 1; Debian, Oracle, SUSE and Amazon Linux have shipped fixes). For Ubuntu nodes, track the proposed kernels and schedule reboots.

Primary source: SecurityWeek

Reporting: The Hacker News

What happened: SAP's November 10 patch day fixes four CVSS 10.0 flaws, all exploitable without authentication: CVE-2026-76964 (NetWeaver AS ABAP Internet Communication Manager, memory corruption), CVE-2026-89126 (SAP Web Dispatcher, memory corruption), CVE-2026-89103 (SAP Gateway, access control, named "ProxyGate" by Onapsis) and CVE-2026-120017 (NetWeaver SAML2 service provider, missing authentication). The vendor says the first two allow remote code execution. The SAML2 flaw lets an attacker log in as any user on some SAML single sign-on systems, privileged users included. Onapsis, which coined the ICM2SHELL name, says it gave SAP a working unauthenticated RCE exploit for ICM2SHELL. Neither source reports exploitation in the wild. [VERIFY: discoverers are not named for most CVEs, and exploitation status should be rechecked at publication.]

Why it matters: ICM and Web Dispatcher are the network-facing listeners for SAP systems, so memory corruption there puts unauthenticated bytes straight onto the code path. An ICM2SHELL exploit exists in a researcher's hands before most customers have applied the notes, the position PHP2Shell was in on October 20. The SAML2 flaw is an identity problem: where SAP trusts SAML assertions from a cloud identity provider, a missing-authentication bug on the SAP side bypasses whatever MFA and conditional access sit in front of that provider.

Action for defenders: Identify which ICM and Web Dispatcher instances are reachable from the internet or from partner networks, and apply SAP Notes 3778530, 3778556, 3798345 and 3849308. The bulletin lists affected releases and, per the reporting, omits fixed patch levels, so read each note for the correction.

Reva starts from a change in what security controls act on. A misconfigured bucket or an over-permissive SSH policy has a known consequence you can profile ahead of time. An agent with broad authorization finds paths that nobody modelled, and the people directing it may never have used a terminal. His response has three parts. Give each group a paved path that fixes the secure choices for them. Judge every control by whether it changes a technical outcome. Assume some control will fail, and build the ability to cut a laptop, a cloud workload and network egress within minutes.

DoorDash's examples are specific: a PR agent that posts security feedback as the PR is submitted, a managed deployment platform where vibe coders have no administrative access, a 20-minute training called Vibe Check that gates access to Claude and GitHub, and a guard called safety belts that refuses agent pushes to repositories the company does not own.[Listen to the full episode →]

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

This week's issue is sponsored by AI Security Lab

Containment Over Policy: Paved Paths for Agents and Vibe Coders, and Egress as the Choke Point

Reva's first difference between cloud security and AI security is how predictable the failure is. He gives three deterministic examples: a misconfigured S3 bucket exposed to the internet, an SSH policy that is too permissive, and an account with too many permissions that causes a large blast radius when compromised. Each has a profilable surface, and you can apply a control to it.

Reva: "The big difference with, with agentic security and AI security is a lot of this context is probabilistic."

Agents change that because of how they are authorized. Reva: "Agents are being given broad-scoped authorization grants to go do things, and because they're overzealous and they wanna be helpful and the mo- and the models powering the agents are highly trained and, and very capable, they're finding paths to do things that they shouldn't be doing, right?"

Try this week: pick one agent in your environment, write down every authorization grant it holds, and list what it could reach that nobody designed it to reach.

The second difference is who is now at the keyboard. Ashish described them in the cold open: "All these people are usually non-technical, like absolutely non-technical. Like, it's like Bob from accounting and Susie from legal." Reva says these users have never seen a terminal, do not know what SSH is, and do not know what a configuration file or an IDE is, and the agents act on their behalf without anyone knowing the difference between good and bad.

Reva: "So the, the, the agent is overzealous. The vibe coder is unfamiliar and unaware because they're not computer science people. It's like a double whammy of, of a forest fire that's impossible to contain on- once it starts burning, right?"

His answer is empathy plus a paved path. Security has to solve the principles for these users, because they will not know to.

Try this week: list who in your company can now deploy an application without going through engineering, including product managers, finance and legal.

The third difference is first-principles reasoning: ask what you are trying to affect the security of. Reva has seen companies hold a lot of paper policy and believe it does something because it says it should. He keeps governance in the picture and says it counts only when it changes the attack surface.

Reva: "Governance is great. Committees are great. Process and policy is great. But if you're not actually affecting the attack surface, if you're not actually affecting what can go wrong, we're not solving it."

Try this week: take your AI usage policy and mark each sentence that has a technical control behind it. The unmarked sentences are your gap.

For the professional engineer, Reva lists a stack of controls. Observability goes on the laptop, with visibility into which MCP servers an agent connects to, what authorization they hold, and whether the agent impersonates the engineer or uses a separate identity. Reva: "We need to place some kind of observe-observe-observability control on that device in order to then, uh, understand what they're actually doing on that device from, from an a- from an agent perspective."

Rules files in the IDE require every PR to pass security checks. Dependencies come only from a trusted source such as Artifactory, so engineers are not pulling tampered libraries. An agent that DoorDash built reviews each PR as it is submitted and posts correctness and security feedback. For customer-facing agentic work, a shared decorator class does authorization checks on agents and sub-agents, so each team does not invent its own. Agents also audit code bases for vulnerability patterns the company knows it has, cut the PRs, assign them to teams, and have other agents review them before a human confirms each is mergeable and deployable.

Reva: "But up until, like, the last, last, last step, a, a lot of this can be done with ag- agents now. This was never possible. This wasn't even possible, like, 10 months ago." The step that stays human is dialing up traffic in a canary release.

Ashish noted that the barrier for people who are not engineers has dropped too: "AI makes it possible for anyone to be an engineer. It just said whether you have the will to be or not."

Try this week: check which MCP servers and authorization grants your engineers' coding agents hold today.

Reva says the old rhythm cannot survive the volume. Reva: "And so before it used to be, here's the design document, a human looks at it, here's, here's a set of PRs, a human may review them if they're really consequential to the business. We can't do that anymore because the velocity and speed is so high."

His answer covers three stages. AI-assisted threat modeling runs on design documents and agent plans before code exists. An agent reviews each PR. At runtime, eBPF observes what an agentic deployment is doing, such as a strange egress call to an IP in a country where the company does not do business.

To trust an AI reviewer that might hallucinate, Reva has the team sample its decisions, has a human label each sample thumbs up or thumbs down, and uses that set as ground truth to coach it. Hardened rules files for Claude and Cursor can then be pushed to every engineer by MDM as secure defaults, which he compares to hardening laptops with MDM 20 years ago. Reva: "Like at the end of the day, the only way you're gonna prevent something bad is if, if you apply a hardening control."

A more traditional company does not have to do all of it. Reva suggests picking one slice, such as AI-assisted threat modeling on the design docs you already write.

Try this week: choose one surface, design documents or PRs, run an AI reviewer on it, and have a human thumbs-up or thumbs-down a sample of its decisions.

Reva treats platforms such as Vercel and Lovable the way a security team treats AWS, GCP and Azure. Reva: "you should apply the same exact principle to your Lovable, to your Vercel, to your FUBAR vibe coder deployment platform." Security sets the defaults and holds the knobs.

DoorDash claimed every domain the company owns, so the only way to deploy an app to a company domain on the approved platform is an enterprise-managed account with a company Okta identity. Vibe coders get no administrative access, secrets are managed one secure way, and users get a small menu of options. DoorDash also removed access from existing users. Reva: "But we did it for a reason, 'cause the security team needs to control the outcome." The users he took access from included power users, and some were upset.

Training has a ceiling. DoorDash's Vibe Check is a 20-minute course that Reva says he mostly wrote himself, and access requests for Claude and GitHub through ConductorOne are blocked until a person finishes it. He does not expect it to carry the load. Reva: "But, but really, I don't believe that you can like truly train non-technical people to like really deeply understand this infrastructure." Incidents get turned into proactive controls instead. One example came from watching agents push code to GitHub organizations the company does not own, which led to safety belts. Reva: "In order to constrain that, we built a mechanism called safety belts." The check looks at the GitHub push flow and refuses a non-enterprise remote. He says DoorDash will "probably" open source it and rewrite it in Golang.

Compare Qubole's roles from the news section: both cases come down to who and what is allowed to act inside an account, and who decided that.

Try this week: list the vibe-coding and app-builder platforms in use, who holds admin on each, and whether sign-up needs a company identity.

Reva's incident-response position is that prevention controls will sometimes fail, so speed of containment is the final measure. Reva: "But if an incident happens, and it will happen, I promise you, if you can't shut it down quickly, you haven't won." He ties this to regulation without naming a regime: some requirements he works under call for a 48 to 72 hour turnaround, and an organization that cannot affect the incident that fast cannot report on it.

He wants three surfaces under control. Reva: "So we have to be able to choke point at each of those, uh, in s- so segments: laptop, cloud infrastructure workload, and network egress." The laptop is the old one, and he points out that SpaceX used FireEye to contain laptops 12 years ago. The cloud workload (a Kubernetes pod, an EC2 or GCE instance) is the newer one. Egress carries his strongest argument. An agent or attacker with a foothold needs its next command from a model hosted outside your infrastructure, since a context window runs out and the next instruction has to come from a new one.

Reva: "If they can't reach that infrastructure on egress, they're not gonna get a command and control." He says the companies he works for are "getting close" to being able to do this at all three layers, and calls it "somewhat sophisticated."

For comparison, the SSHole reporting this week describes post-exploitation that went straight to cloud metadata queries. An egress and metadata policy that is already in place is the control that sits in that path.

Try this week: time how long it takes to cut one compromised workload's outbound traffic, from alert to block, and write the number down.

For AI for security, Reva says every incident has log collection and analysis, summarization for leadership, and repair-item tickets assigned to teams. Reva: "Every single incident has, has elements of those three things." DoorDash applies AI to all three, so the humans handle the parts that need judgment, such as talking to legal or, in some cases, attorneys general.

For a team without DoorDash's engineering depth, he gives three starting points on each side. For security for AI: profile activity on every laptop and device with a vendor (DoorDash chose a vendor), threat model any customer-facing agent experience including how it authorizes to data, and apply runtime containment to bad egress and compromised workloads. For AI for security: use AI on design documents and repos, put an agentic reviewer on PRs, and apply AI to incident analysis, reporting and tickets.

Reva: "AI for security, okay. All the analytical kind of work of threat modeling, you can use AI to, for that today."

Try this week: pick one of the three constants (log analysis, summarization, ticketing) from your last incident and trial an AI assistant on it with a human reviewing the output.

Practical takeaways

🛑 If an agent in your environment went rogue today, how fast could you cut its egress, and who holds that switch?

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