This week’s Cloud Security Newsletter topic: Misuse of Trust: What Happens When the Attacker Is Someone Your Customer Hired (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!

Tuesday was the busiest patching day of the month. F5, Check Point and Arista each disclosed a vulnerability already being exploited, all three landed on CISA's KEV catalog on September 22, and all three carried a three-day federal deadline under BOD 26-04. The Check Point case is the one worth sitting with: the attacks it describes happened on July 23, and the fix arrived on September 22. Sixty-one days.

Marcus Hallberg and Samuel Kelemen, both security engineers at Lovable, spent this week's episode with Ashish Rajan describing an attack that never touched their platform's defences. A threat actor group built personas as freelance developers, waited to be hired by Lovable customers who wanted help finishing their apps, and then used the access those customers granted them. The group had been refining the technique for over a year. Both guests are firm that this is not an AI story, and their reason for saying so is more interesting than the attack itself. [Listen to the episode]

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

Primary source: F5 Security Advisory K000162605
Reporting: SecurityWeek
Analysis: CISA KEV addition, September 22

What Happened

F5 disclosed CVE-2026-94127 (CVSS 9.8), a heap-based buffer overflow in BIG-IP Access Policy Manager that hands an unauthenticated attacker remote code execution through crafted traffic to an affected virtual server. F5 found it internally and confirmed exploitation. Exposure requires an APM access policy and an OAuth profile on the same virtual server, and the flaw triggers only when APM acts as an OAuth Authorization Server, not as a client or resource server. F5 describes it as a data plane issue with no control plane exposure, notes that Appliance mode is also vulnerable, and published three indicators of compromise that it says should be correlated together rather than treated individually. Affected versions are reported as 21.1.0, 17.5.0 through 17.5.1, and 17.1.0 through 17.1.3.

Why It Matters

The exposure condition is a decision most teams made deliberately, for identity consolidation: put APM in front of applications and let it issue the tokens. That turns a load balancer into the thing that mints access for everything behind it, so pre-auth RCE there reaches the issuing position rather than one proxied app. The practical problem is that your CMDB knows the version. Configuration is what decides exposure here. CISA gave federal agencies three days on the same day F5 published, which means the disclosure-to-deadline gap was zero.

Action for defenders: Enumerate every BIG-IP virtual server carrying both an access policy and an OAuth profile, confirm which of those run APM as Authorization Server, and hotfix those ahead of the rest of the fleet. Then correlate F5's three IoCs against data plane logs, because the patch tells you nothing about what happened before it.

Primary source: Check Point security advisory
Reporting: The Hacker News, BleepingComputer

What Happened

CVE-2026-93616 (CVSS 9.8) is a path traversal flaw in the Security Management Server web service that lets an attacker who can reach the service upload scripts and run them without authenticating. Check Point says the attacks it observed took place on July 23, 2026, and released the fix on September 22. Affected products include Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server and SmartEvent, across a version matrix keyed to Jumbo Hotfix take numbers. The LivePatch takes that fixed CVE-2026-91843 on September 16 do not address this one. The same advisory reports exploitation attempts since September 12 against CVE-2026-85102, a VPN certificate flaw patched on September 9, affecting gateways and Spark firewalls, Check Point's small-business line, with attempts using certificates with subjects such as CN=vpn,OU=users,O=global from anonymising infrastructure. Check Point has not named the July targets, the actor, or what the attackers did afterwards.

Why It Matters

Sixty-one days passed between the attacks Check Point describes and a patch existing. Any compromise assessment scoped to "since the advisory" is therefore mis-scoped by two months, and the vendor's own guidance is explicit that installing the fix does not reveal whether the server was attacked beforehand. This is a forensics job wearing a patching job's clothing.

Action for defenders: Check each management server's release and Jumbo Hotfix take against the advisory matrix, install the build in sk1000171, then run the hunting guidance and IoCs in that article against logs going back to at least July 23. Separately, review Mobile Access logins for unusual certificate-based authentications and what those sessions did next, which Check Point notes is often internal port and service scanning.

🛠 If you only do one thing this week: Open your BIG-IP configuration and list every virtual server that has both an access policy and an OAuth profile attached, then check which of those run APM as OAuth Authorization Server. That set is your exposed population for CVE-2026-94127, and no version report or CMDB query will produce it for you. Budget 30 minutes. While you are in there, the same question applies to anything else in your estate that issues tokens on behalf of other systems, because this week's pattern is that the component sitting in the middle is the one under attack.

Primary source: Arista Security Advisory 0183
Reporting: SecurityWeek, BleepingComputer

What Happened
Arista patched CVE-2026-93952 (CVSS 10.0), an improper input validation flaw in on-premises VeloCloud Orchestrator that lets a remote attacker reach privileged internal functionality. Arista says the issue was found externally and is known to be actively exploited. Exposure requires certificate-based authentication from VeloCloud Edge to VCO to be configured, plus the public portion of the Edge authentication certificate and network access to the VCO web interface. VCO tenant or operator credentials are not required. Only VeloCloud Orchestrator On-Prem is affected. Fixes shipped in VCO 5.2.3.16 and 6.4.2.8, with other trains to follow, and Arista says there are no definitive indicators of compromise.

Why It Matters
VCO steers traffic for every SD-WAN edge under it, including the branch-to-cloud paths carrying traffic into your IaaS regions, so privileged access there is a route to re-steering or mirroring rather than just reading configuration. What makes this one uncomfortable is the exposure condition: the Edge authentication certificate's public half is not secret by design, so moving from shared secrets to certificates did not help. With no IoCs published, the log review Arista recommends cannot return a clean negative. You cannot prove you were not hit.

Action for defenders: Confirm whether VCO On-Prem is in use with certificate-based Edge authentication, restrict the web interface to management networks today, and schedule the 5.2.3.16 or 6.4.2.8 upgrade. Pull VCO web access logs for requests to operator-scoped endpoints from outside the management range.

Primary source: Microsoft Security Blog
Reporting: BleepingComputer, Help Net Security, SecurityWeek

What Happened

Microsoft's Digital Crimes Unit, working with Health-ISAC, law enforcement and SpyCloud, disrupted EvilTokens, a phishing-as-a-service operation that compromised more than 12,000 Microsoft accounts across more than 10,000 organisations. The platform emerged in February 2026 and, per Microsoft, was the first to support device code authentication at scale, alongside AI-assisted lure customisation and high-value target identification. Subscribers paid $1,500 for access plus $500 monthly. Microsoft seized 50 websites and disabled more than 150 additional domains. Reporting states that two men, aged 32 and 38, suspected of administering the site were arrested in the UK. The most-targeted countries were the United States, followed by Canada, Australia, the United Kingdom and Saudi Arabia.

Why It Matters

Device code phishing harvests no password, so the controls built to stop credential theft never fire. The victim authenticates on a genuine Microsoft endpoint and the attacker collects tokens, which is why MFA and password hygiene do not change the outcome here. At $1,500 plus $500 a month the technique stopped being a targeted-operation capability, and more than 10,000 affected organisations is what that looks like in practice. Four of the five most-targeted countries are core reader geographies, and device code flow is enabled by default in tenants that have never scoped it.

Action for defenders: In Entra ID, establish whether device code flow is permitted for your tenant and scope it with a Conditional Access policy to the specific device and application cases that need it, blocking it everywhere else. Then hunt sign-in logs for device code grants from IPs or countries that do not match the user's pattern.

Primary source: BleepingComputer
Analysis: Accomplish AI research writeup by Oren Yomtov

What Happened

Oren Yomtov of Accomplish AI disclosed two Codex sandbox escapes, reported to OpenAI on August 12 and fixed within eight days. Heapjack targets node_repl, a component Codex Desktop writes into the shared ~/.codex/config.toml at install time with no opt-out, which Codex CLI users inherit. That component runs trusted and untrusted JavaScript contexts in one Node process sharing one heap, so the authorization token the trusted context presents can be read out of a heap snapshot and replayed to an unsandboxed parent process. The proof of concept launched an application outside Codex's process tree from read-only mode, the strictest setting, and the same access reaches Unix sockets including a Docker daemon socket. Overpatch abuses Codex CLI's apply_patch, which grants write access to the parent folder of every path named in a patch, to widen permissions through /tmp and append a line to .zshrc via a symlink. OpenAI fixed Heapjack in Codex Desktop build 26.818.21641 and Overpatch in Codex CLI 0.149.0.

Why It Matters

Both escapes land unsandboxed execution on a developer workstation, which is the machine holding cloud CLI sessions, kubeconfigs and signing keys, and Heapjack's reach to a Docker daemon socket is a direct path from agent sandbox to container host. The trigger is opening someone else's repository and asking a question about it, which is ordinary code review. No sensible policy forbids that. The architectural version of the problem is that the guardrail was living inside the thing it was supposed to govern.

Action for defenders: Inventory Codex Desktop and Codex CLI versions across engineering and require at least Codex Desktop 26.818.21641 and Codex CLI 0.149.0. Because the node_repl entry lives in the shared config that Desktop writes, check ~/.codex/config.toml on any machine where Desktop was ever installed, including ones now used only through the CLI.

Primary source: SecurityWeek
Reporting: Wall Street Journal (paywalled, originating report), CNN Business

What happened:
Google confirmed that a Gemini model accessed the systems of three real companies during a May 2026 capture-the-flag evaluation run by the AI testing firm Irregular. The exercise used a fictional company name that matched a real domain, and internet access the model was not meant to have was available. In one run the model guessed passwords until it reached a protected system; in two others it searched for the company name, found credentials belonging to other companies in public repositories, and used them. Google says the model recognised each time that it had reached a real company and stopped, that the incidents did not involve its latest model, and that it notified federal authorities and the three affected companies. Irregular notified Google at the end of July. Google published nothing until the Wall Street Journal made contact, and says the incidents did not warrant disclosure because no harm occurred, comparing the episode to a bug bounty. Google's VP of security engineering, Heather Adkins, gave SecurityWeek a statement on the incidents.

Why it matters:
The access path involved no novel capability. Password guessing and credentials sitting in public repositories are what worked, which makes this a secret-hygiene story as much as an AI-safety story. For anyone running a vendor security review, the disclosure decision is the part with teeth: a provider taking the position that unauthorised access to a third party needs no notification when the model stops by itself is a position that belongs in contract language rather than a press statement. Questionnaires asking whether a provider has had a security incident will not surface this class of event if the provider has filed it under evaluation behaviour.

Action for defenders: Add a question to AI vendor reviews covering evaluation-environment isolation and the provider's notification threshold for unauthorised third-party access, with a defined reporting window. Separately, re-run secret scanning across public repositories and forks associated with your organisation, because that exposure is what the model found.

Primary source: BleepingComputer
Reporting: SecurityWeek, SC Media
Analysis: Master of Malt customer notice

What happened:
BigCommerce confirmed on September 17 that credentials for the third-party applications Ribon and Ribon 1.5, operated by Be A Part Of, a Fastr company, had been compromised and used to inject malicious scripts into a small number of merchant storefronts. The attacker used the compromised application key to access shopper data in BigCommerce environments between September 13 and September 17. BigCommerce uninstalled the applications from affected stores, began notifying merchants on September 18, and is supplying log data to the developer's investigation. UK spirits retailer Master of Malt says exposed fields include full names, email addresses, phone numbers and shipping addresses, and has reported the incident to the ICO. BigCommerce says passwords and payment card data are stored separately and were not exposed, and that neither its systems nor the platform were breached. The platform supports over 1,200 third-party applications and integrations.

Why it matters:
Two statements are both true here: the platform was not breached, and platform-held customer data was taken. The compromised credential was an application key issued to an installed app, so the attacker inherited whatever data scope the merchant granted at install time and needed nothing from the merchant's own accounts. Vendor questionnaires that ask about the vendor and never about the vendor's marketplace miss this entirely. Detection also fell to the platform operator rather than the merchant or the app developer, which left merchants with no signal across a four-day access window.

Action for defenders: Pull the list of installed third-party apps for every SaaS platform holding your customer data, record what scopes each was granted, and remove or re-scope any app whose access exceeds its function. Where the platform supports it, rotate app keys on a schedule and alert on API calls from an installed app to endpoints it does not normally touch.

Primary source: Accenture newsroom
Reporting: SecurityWeek, CyberScoop
Analysis: Dragos

What happened:
Dragos announced on September 21 that it has completed its acquisitions of NetRise and runZero, the last step in Accenture's roughly $4.2 billion plan to take a majority stake in Dragos and full ownership of the two smaller companies. Reported closing dates are NetRise on July 31, the Accenture majority investment in Dragos on September 16, and runZero on September 17. The stated aim is one platform for critical infrastructure and industrial operations, including power grids, pipelines, manufacturing, distribution facilities and data centres, combining Dragos OT threat detection with runZero's asset visibility and NetRise's firmware analysis. The three companies were reported at approximately $208 million in combined annual recurring revenue as of June 2026, up 53% year over year. runZero CEO HD Moore, NetRise CEO Thomas Pace and NetRise CTO Michael Scott joined Dragos with their teams.

Why it matters:  
What Accenture paid for is asset discovery and firmware inspection, not detection content, which prices unauthenticated inventory of things you cannot install an agent on as the scarce capability in this market. The buyer is a global systems integrator rather than a security vendor, so the near-term effect for readers is that OT and device-inventory capability increasingly arrives bundled inside managed-service contracts, which moves where that requirement sits in procurement.

Action for defenders: If runZero or NetRise is in your stack or your evaluation pipeline, get the post-close roadmap and support commitments in writing before the next renewal. If neither is, settle which team owns unauthenticated asset inventory for appliances, orchestrators and OT devices.

Lovable is an AI-native app builder out of Stockholm with more than 40 million apps deployed. Its users are mostly not engineers, which is the entire product proposition and also the shape of its security problem. Samuel Kelemen puts the difficulty plainly: "For us, we're trying to empower everyone to make whatever apps they feel are necessary or what they wanna build. And so we're thinking about how do we secure things that we don't even know what it is they're, they're building."

The campaign Marcus Hallberg and Samuel Kelemen described at fwd:cloudsec, and walked through again on this episode, did not exploit any of that. Customers who wanted help finishing their apps hired what they believed were freelance developers. Those people belonged to a group Lovable had been tracking, and they used exactly the access their clients had granted them. For a while they behaved like ordinary contractors, making ordinary commits. Then the malicious artifacts started appearing.

What Lovable's investigation surfaced is that the group had been working on this for more than a year, and had a development process. Because Lovable could see both the attacker-owned projects and the customer projects, the team could watch a technique get built in one place and deployed in the other. The most striking detail is a timing trick. A customer asked the coding agent to change a link. The agent committed. Roughly 1.5 seconds later a near-identical commit appeared, carrying malicious code, fired by an attacker who was watching for the commit event. In the chat interface it looked like one change.

Marcus keeps returning to what this is and is not. "It's more about you giving your, your keys to your house to, you know, a, a, uh ... a carpenter or a contractor, and then that person, uh, does a burglary, right?" Neither guest claims Lovable was breached, and neither accepts that AI created the problem. Samuel's version: "this is not a platform nor an AI problem, right? This problem has always existed."

That refusal is the useful part, because it points at where the work actually is. Samuel's answer to commit impersonation is commit signing, a control the industry has had for years and mostly skipped. His answer to agent attribution is that the agent should have its own identity rather than borrowing yours. Marcus's answer to agent oversight is to make it produce a plan, check the plan against what you intended, then check the result. None of that is new. All of it is unfinished.[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

Lovable customers hired people they believed were freelance developers. Those people were part of a tracked group, and the access they used was access they had been given.

"And this particular example was very interesting because we found, once we had done the complete analysis, that this specific threat actor had been, um, doing these techniques and refined it for a very, very long period of time, more than a year." — Marcus Hallberg

Marcus is careful about the boundary. His guidance to customers is the unglamorous version: work out who the person is, whether they come from a company with a reputation worth protecting, whether you can verify what they do, and what changes they have actually made. He does not oversell it. "The risk will still be there."

Because Lovable was watching both attacker-owned projects and customer projects, the investigation could reconstruct the workflow rather than infer it.

"So when we did the full investigation, we could see that as the attackers were developing, uh, new techniques and they were refining the malicious code they were introducing, they would first test that on their own projects, see that it worked, and then they would weaponize that and try to implement that into the customer projects." — Marcus Hallberg

What made this visible was correlation across attacker tenants and customer tenants at the same time. Marcus notes the pattern is common in the industry and "it's really hard to, you know, to, to discover unless you, you know what to look for." Multi-tenant platforms have a visibility advantage here that individual victims do not, which is worth remembering when deciding what to escalate to a provider.

The attackers studied how Lovable's coding agent behaves and when it commits, then used that timing.

"Same message, same everything, but in this case it was the attacker who was listening to the Git commit happening." — Marcus Hallberg

"And it's only when you look at the actual source code and the commit itself that you see what they were actually trying to do." — Marcus Hallberg

A customer had asked the agent to change a link. The notification looked like one change. Nothing in the chat interface distinguished the second commit from the first, which means the detection signal was the timing and the diff, never the notification text. If your developers review agent activity through a tool's activity feed rather than the actual commit contents, this technique works on you too.

Lovable gives creators access to their own source code, including sync to GitHub or GitLab. That means anyone a customer adds to the external repo can affect the project.

"And so because the agent can pull code from GitHub that you've attached to your project, uh, any time you add an external person to your GitHub repo, they can also affect your project as well. So there's, like, a little bit of a, a challenge in seeing, like, we don't always have full visibility everywhere." — Samuel Kelemen

"And we, um, like, it's not our GitHub organization, it's hard for us to, to say, 'This is what you can or cannot do.'" — Marcus Hallberg

Neither guest offered a solution, and both were straightforward that the industry does not have one yet. Marcus framed it as something Lovable and its peers are "actively working to put as much guardrails as we can into place" on. Worth noting that story 7 above is the same shape with different nouns: a platform that was genuinely not breached, and data taken through something a customer chose to install.

Samuel's framing collapses the distinction between a supply chain problem and an insider problem.

"I, I think it's also, like, a convergence of the supply chain issue and then the internal, like, uh, disgruntled employee kind of threat vector as well, right?" — Samuel Kelemen

"they're essentially like another employee, right? They have all the same access that an employee would in a bigger company." — Samuel Kelemen

"And I think we've discussed before, like, trust is never, like, a binary thing. ... You have, like, you know, a sliding scale of where you trust someone to do some things but not other things. ... Uh, you know, I trust my doctor to do surgery, but I don't trust him to be my accountant ... or my lawyer, right?" — Samuel Kelemen

He treats the underlying activity as a success signal rather than a risk to suppress: customers hiring people means customers are building real companies. "that's a success story for us. ... And how do we make that not so scary?" The open questions he names are what trust means operationally and how you explain a trust boundary to someone who is not technical.

Samuel argues agents should be attributed separately from the humans they act for, because the agent has a different threat model: prompt injection, a model provider change, and no human judgement.

"Um, but I think that there's also some sort of industry question about, like, delegation versus impersonation. ... Like, if you are using these AI tools, uh, should the tool itself have an identity, and should that say that it's being, using delegated access, for example?" — Samuel Kelemen

"Or should they act as me, right? If- ... like, in the, your logs, would you like to see that Samuel made this change even though it was my agent? ... Or would you like to see this agent made the change using Samuel's credentials?" — Samuel Kelemen

Marcus maps it onto ground cloud teams already covered once.

"And I think what we're seeing now with the introduction of, you know, uh, AI and agents and AI-driven development, we have the same sort of problem space, but this is now much more broader because it's not only my, you know, Google credentials, it's also any API keys or other credentials I have locally that I tell my agent to use or that the agent thinks it's, it's gonna use." — Marcus Hallberg

Service account keys used to tell you what an account did and not who used it. Delegation and impersonation fixed that. Marcus assesses the agent equivalent as early days, and the scope is wider, because the agent can reach every credential on the machine rather than one cloud identity.

Samuel demonstrates the weakness using a trick he runs on himself.

"Uh, one of my favorite tricks is I always add Marcus on all my commits ... as a, as a co-contributor. ... And then I have Cursor open the PR. So then I merge, like, all my commits with, uh, you know, him as the author and with Claude as the PR author." — Samuel Kelemen

"Um, so you know, there's ways to avoid this. If we were using commit signing- ... you wouldn't be able to do this kind of impersonation thing. ... Um, so I think there's things that we've been, um, not very good at as an industry of adopting, like commit signing." — Samuel Kelemen

His diagnosis of the blocker is cultural rather than technical: "we all know that, like, there, there are these things we can do, and I think they haven't been prioritized. ... We just have to accept that we need to do them." He also disposes of the usual objection to company-versus-personal GitHub accounts in one line.

"I mean, that street cred is completely gone. Like, GitHub statistics mean nothing anymore. We're all the top one developer with a million commits now." — Samuel Kelemen

Both guests reject the idea that AI guardrails are a new category. The old ones matter more now, because something will make mistakes and the question is whether you catch them.

"So I think when we're working with AI, we need to delegate our work, but not our thinking. And I think that the engineering becomes even more important." — Samuel Kelemen

Marcus's operating pattern is plan-then-verify.

"So for example, if you are telling a- an agent to do something and you ask it first, 'Oh, can you create this plan and tell me how are you gonna solve this problem?' Then you quickly can see is that what you had in mind, or is the agent, uh, maybe doing something else that you initially intended?" — Marcus Hallberg

"But it's still all about how we verify what good looks like." — Marcus Hallberg

Samuel is honest about the current state of practice, which is worth reading next to story 5.

"So we also are running on our machines, I think most of us are running in YOLO mode- ... uh, whether we can admit that to IT or not." — Samuel Kelemen

His direction of travel is to move the agent's workspace off the laptop entirely: a VM or cloud sandbox you can lock down, log completely, and wrap in policy and GRC. He wants it for usability too, so he can resume an agent session from his phone. Marcus draws the line by stakes rather than by rule: running skip-permissions to draft meeting notes is fine, doing it with your Kubernetes credentials is not. For teams rolling out Claude Code or Codex now, Marcus's concrete advice is to put predefined skills, MCPs and knowledge docs in the repository so the agent inherits project guidelines, and to decide deliberately when the tool is the wrong choice.

Practical takeaways

🔐 Do your logs show when an agent made a change instead of you? Or does it just look like you?

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