Security & Threat Intelligence

The Watch

The Signal

Chrome's DevTools Protocol hijacks live sessions without tripping MFA or your SSO logs.

Detection lives in the wrong place. The --remote-debugging-port flag catches launch, cookie-theft rules catch exfil, and this trips neither because DevTools comes on inside a Chrome or Edge process that's already authenticated. What your telemetry should flag instead: a loopback debug listener on a browser that's already logged in. That's the tell most stacks aren't watching for.

In Play

  1. SAP Commerce Cloud Exploited Days After the Fix

    The Hacker News reports exploitation attempts against CVE-2026-58231 in SAP Commerce Cloud, rated CVSS 10.0, within days of its patch. A separately patched Apple macOS Screen Sharing flaw is now being used to drop Monero miners on internet-exposed Macs, per a Netherlands NCSC warning. Both cycles are faster than a monthly change window. The advisory withheld the SAP flaw class, so validate specifics against SAP's security note before writing detections.

    Ask Clarity
    Try
  2. A Browser Session Hijack With No Login Event

    Researchers published a technique that switches on the Chrome DevTools Protocol inside an already-running Chrome or Edge process on Windows, per The Hacker News. The operator then drives the authenticated session directly. No credential is stolen, so no MFA prompt fires and no new logon lands in your SSO logs. Your detection hook is the loopback debug listener appearing on a live browser process, not a command-line flag at launch.

    Ask Clarity
    Try
  3. Agent Privileges Now Change Mid-Conversation

    Two sources converge on one point: when an AI agent is compromised, the failure lands in the harness — the orchestration and application code wrapped around the model — not in the model or the prompt, per CSO First Look. Latent.Space documents the mechanism in production, where Flue 2 ships 16 React-style hooks including useTool and useSubagent that let an agent attach capabilities at runtime. Your IAM review sees a static role while the effective permission set is recomputed every turn.

    Ask Clarity
    Try
  4. Attackers Are Buying Reputation Rather Than Bypassing It

    Threat actors spent nearly $7 million dropcatching expired domains to inherit their age, traffic and reputation, per Infoblox research reported by The Hacker News. CTM360 separately counted more than 3,000 recruitment-themed phishing URLs using Browser-in-the-Browser overlays, which paint a fake browser window inside the page to harvest Google and Facebook logins. Domain age and URL inspection are the two signals your web filtering and your awareness training still lean on.

    Ask Clarity
    Try

Deep Dives

Patched, Exploited Anyway: SAP and the Mac Estate

Deployment closes the vulnerability; only pre-patch access logs answer whether you were already hit — and on most Mac fleets those logs were never collected at all.

Patch status is not an incident answer

Deploying the fix for CVE-2026-58231 closes the hole. It says nothing about the interval between the patch shipping and the next change window opening. The Hacker News reports attackers were firing into exactly that interval. A vulnerability scanner will not answer the question. Web and application access logs for the pre-patch period will, on every internet-facing Commerce Cloud instance: the /hac and /backoffice administrative paths, and the OCC API endpoints. Pull them before retention rotates them out. On a commerce platform those paths sit adjacent to payment and PII flows. A regulator or an acquirer will eventually ask for that reconstruction.

Public and inferred, kept separate: the published advisory withheld the flaw class. A CVSS 10.0 on an internet-facing commerce platform almost always means unauthenticated remote code execution. That is inference, not a stated fact. Confirm against SAP's own security note before any detection logic depends on the mechanism.


The Mac estate is where inventory fails

The second exploitation is less severe and more embarrassing. The Netherlands NCSC warns that a patched macOS Screen Sharing flaw is being used against internet-exposed Macs to install Monero miners. The abused component is a legitimate operating-system feature, which makes this a perimeter and configuration problem rather than a malware problem. Two asset classes carry it in most technology companies: developer Macs on network segments with generous inbound rules, and hosted Mac build runners used for iOS CI, which routinely sit outside both EDR deployment and attack-surface-management inventory. Cryptojacking is the payload. The same access is a beachhead in a build pipeline later. That is the part that sets priority.

ExposureWhat to checkFirst evidence to pullBlocking control
SAP Commerce Cloud CVE-2026-58231/hac, /backoffice, OCC API reachabilityPre-patch access logs for those pathsPatch, or WAF virtual patch plus IP allowlist
macOS Screen Sharing to Monero minerTCP 5900, TCP/UDP 3283 on external ranges, VPCs, build fleetsSustained CPU, stratum-protocol egress, unexpected ~/Library/LaunchAgents entriesPerimeter block plus MDM profile disabling Screen Sharing and Remote Management

Where the reporting agrees

CSO First Look argues for re-baselining patch and exposure SLAs on internet-facing and identity-adjacent assets, and for moving spend away from faster manual triage toward exposure reduction and automated isolation. The Hacker News lands on the operational version of the same conclusion: a pre-authorized emergency lane with a 72-hour SLA for CVSS 9.0-plus internet-facing assets. The agreement matters because it isolates the constraint. Neither exploited flaw needed a novel control to survive contact. Both needed someone empowered to approve a same-day change. Shops that clear inside 72 hours held. Monthly-window shops will lose the same race with a different CVE number.

Both exploited flaws already had patches; what decided the outcome was who could approve a change inside 72 hours.

What to do

  1. Inventory every SAP Commerce Cloud instance today, apply the CVE-2026-58231 fix or deploy WAF virtual-patch rules with IP allowlisting on /hac, /backoffice and the OCC API, and export pre-patch access logs for those paths before retention expires.

  2. Sweep external ranges, cloud VPCs and hosted Mac build fleets for TCP 5900 and TCP/UDP 3283 within 48 hours, block at the perimeter, and disable Screen Sharing and Remote Management by MDM profile.

  3. Stand up a pre-authorized emergency remediation lane with a 72-hour SLA for CVSS 9.0-plus internet-facing assets before the next monthly patch cycle closes.

A Session Hijack That Leaves Your Identity Logs Spotless

Command-line detections and phishing-resistant MFA both sit on the wrong side of this technique; the reliable observable is a loopback listener on a browser process that is already logged in.

Why existing browser-abuse content misses it

Modeled tradecraft against browsers does one of two things: steal cookies at rest, or relaunch the browser with --remote-debugging-port. SOC detection content reflects that history, keying on process command lines and file access on cookie stores. The technique in the source reporting does neither. Per The Hacker News, the operator switches the DevTools Protocol on inside a Chrome or Edge process that is already running and already authenticated. There is no relaunch to catch, no credential surfacing in a dump, no fresh logon at the identity provider, no impossible-travel signal. The user legitimately established that session minutes earlier. An attacker driving an admin session into a cloud console produces SSO telemetry that looks pristine end to end.


What actually fires

The observable set is small and distinctive: a loopback debug listener appearing on a live browser PID (127.0.0.1:9222 is the conventional port), remote thread creation into chrome.exe or msedge.exe, and local WebSocket traffic to /json-style endpoints. In Sysmon terms that is Event ID 3 for the loopback high-port connection tied to a browser process, and Event ID 8 for the injection. The configuration half is cheap and should go first: the Chrome and Edge enterprise policy RemoteDebuggingAllowed=false, pushed fleet-wide.

Budget for false positives before routing this to on-call. Legitimate developer tooling speaks the same protocol on the same loopback ports: browser automation frameworks, test harnesses, IDE debuggers. Baseline engineering endpoints first. Then scope the high-confidence rule to finance, executive and administrator populations, where nobody has a reason to be debugging a browser. The advisory detail behind this technique is thin, so a purple-team pass is the difference between a detection and a noise generator.


The identity control that does not cover this

The other identity item, Browser-in-the-Browser overlays harvesting Google and Facebook logins at scale, points every roadmap at the same answer: accelerate FIDO2 for admin, finance and executive roles. That is the correct answer to a different problem. MFA protects the authentication event; this technique targets everything after it. The controls that map are session-integrity controls: token binding or device-bound session credentials, anomalous session-reuse detection, shortened session lifetimes on cloud admin consoles, and re-authentication on sensitive actions. Most programs carry those on a roadmap slide. This technique moves them from roadmap to control gap, because the logs normally reached for cannot see the attack at all.

MFA protects the moment of login; this technique starts one second later, and your SSO log stays clean the whole time.

What to do

  1. Push RemoteDebuggingAllowed=false through Chrome and Edge enterprise policy fleet-wide this week, with a documented exception group for engineering endpoints that require local debugging.

  2. Build a detection for loopback debug listeners on browser PIDs and remote thread creation into chrome.exe or msedge.exe, baseline it against developer tooling, and purple-team it before it reaches the on-call queue.

  3. Add session integrity to this quarter's identity roadmap: token binding or device-bound sessions, session-reuse anomaly alerting, and re-authentication for sensitive actions on cloud admin consoles.

The Privilege Grant That Happens in TypeScript

Blast radius here was set by two engineering decisions already shipped: a bot that graduated from reading issues to writing commits, and a single agent identity holding every credential.

The repo automation is the live chain

Flue's origin story, told to Latent.Space by Astro creator Fred Schott, is the most actionable part of the interview. It started as an LLM-driven script triaging issues inside the Astro repository. It "later gained the ability to take actions in the repo," then became a headless, programmable coding agent. That is a chain, not a product history. Attacker-controlled issue text flows into a bot holding repository write scope, which is supply-chain compromise (MITRE ATT&CK T1195.002) executed from inside the organization's own source control. The enumerable set is every bot, GitHub App and CI identity with write access. The exposed subset is the ones ingesting issues, pull-request bodies, comments or external webhooks. Severity turns on the App's scopes and whether its commits bypass required reviews. Most do.


The verification gate is a confused deputy

Flue 2's headline feature is React-style hooks — useSkill(), useTool(), useSubagent() — attaching capabilities at runtime. Schott's canonical example is a support agent that attaches an account-management tool after verifying the user. That is a privilege-escalation gate implemented in application code, with no policy engine in the loop. Where any agent state feeding that gate derives from untrusted input, meaning a customer message, a fetched document or a tool result, the path is indirect prompt injection to privilege escalation. MITRE ATLAS tracks it as AML.T0051, extending into tool and plugin abuse.

One identity, every integration

Flue v1 shipped one agent per file. Real usage killed it. Schott's reason is the line to escalate: "for a lot of people building with Flue, especially the bigger customers, their whole company is one agent." Developers read simplification. It is the union of every tool credential, data source and subagent under one workload identity. File-based routing was an awkward web metaphor and an accidental blast-radius control. Compromising the monolith is lateral movement across every integration at once (T1078, T1552), and it will look like normal service-account behavior, because for that identity it is.


Ownership, and the dependency floor

CSO First Look supplies the second half independently. When agents are compromised, the failure lands in harness code, which typically holds long-lived, over-scoped API tokens and ships from a platform team with no AppSec gate. Ownership moves off ML and data science. The credential-scope audit becomes the highest-leverage item on the list, because scope caps blast radius even when the harness falls. Underneath is a maturity question. Flue runs on Pi, a third-party minimal harness, with Vite in the hosted path, and it reversed its core architecture between v1 in early May and its first stable release roughly three months later. Forced migrations on a pre-stable API are where security review gets skipped. Pi belongs on the upstream-abandonment watchlist as a single-point dependency. Bret Taylor's framing, the jQuery era of agents rather than the React era, is the planning guide: controls built inside one framework's hook semantics get rewritten within a year, while controls at workload identity, credential scope, egress and authorization telemetry survive whoever wins.

A workload that grants itself new privileges mid-conversation is a privilege-escalation path, and if the SIEM holds no record of the grant it is already in production unlogged.

What to do

  1. Enumerate every bot, GitHub App and CI identity with write access to source repositories this month, and revoke write scope wherever a read-and-propose workflow suffices, starting with any identity that ingests issue or pull-request text.

  2. Require every agent framework in a production path to emit a structured authorization event for each runtime tool, skill or subagent attachment, then alert on privileged attachment with no preceding verification event.

  3. Publish an architecture standard this quarter banning a single company-wide agent identity: one scoped workload identity per agent domain, credentials segmented by data classification, and no shared token vault reachable by every subagent.

The bottom line

These items share a defect that sits in neither the exploit nor the patch: the layer under attack is also the layer you would query to prove anything happened. A session that was already trusted, a privilege granted inside application code, an estate no scanner ever enumerated — none of them produce the record your investigation plan assumes exists. Authentication logs, role definitions and agent telemetry are configuration, not evidence. Pick your two most consequential trust boundaries this week and prove each writes a record you can read from outside the system being attacked; where it does not, treat that control as unmonitored until it does.