GCP News - 2026-09-29

Whether you are mapping global forest cover, detecting changes in the built environment, or monitoring agricultural yields, writing scripts in Google Earth Engine is a powerful way to develop these insights. This platform is part of Google Earth AI, our collection of geospatial models and datasets designed to help you transform planetary information into actionable intelligence, and we’ve launched a new feature, Ask, that makes accessing that planetary intelligence even easier. 

We know that translating complex geospatial logic into code takes time, and memorizing specific Google Earth Engine API functions, searching documentation, and debugging syntax or memory errors can interrupt your flow. Ask is designed to help you get to actionable insights faster, by integrating Gemini capabilities directly into the Google Earth Engine Code Editor.

Starting today, you can use your own Gemini API key to write, debug, understand, and optimize geospatial queries without ever leaving the Code Editor.

How it works: Context-aware assistance

You can ask a question directly in the Code Editor, and get a response based on context from your workspace, such as:

• The full text of your active script

• Your imported assets and geometries

• Your active session chat history

Because Gemini capabilities in Google Earth Engine automatically understand your work, you don’t have to add code or explain your datasets. It already knows these details, so it can provide more relevant, helpful answers. Additionally, you can automatically view the diff and merge it into your script. No more copy and pasting!

You can also personalize Ask to make responses more comprehensive and suited to your needs:

• Access the latest Gemini models: Choose the Gemini model that meets your needs — at launch, the available models are Gemini 3 Flash Preview, Gemini 3.1 Pro Preview, and Gemini 3.5 Flash.

• Docs search: Use AI to search the official documentation for up-to-date syntax and functions.

• Dataset search: Allow AI to search the Earth Engine Data Catalog to find and reference the exact datasets you need.

• Google Search: Grounds response in the latest public web results using Grounding with Google Search (mutually exclusive with docs search and dataset search).

Quick-start examples

Not sure where to start? Here are four ways you can use Ask in your workflows:

1. Generate code from natural language

Need to calculate NDVI (“Normalized Difference Vegetation Index”), perform a cloud mask, or build a chart, but can't remember the exact syntax? Just ask and Earth Engine can generate JavaScript code for you. You can review the code directly in the chat and click Insert to add it to your script, or Copy it to your clipboard. If your editor is not empty, inserting code displays a side-by-side diff view so you can review changes before accepting them.

Prompt example: "Write a script to load Sentinel-2 imagery for 2025 over Boulder, CO, apply a cloud mask, calculate NDVI, and add the median composite to the map."

2. Explain complex code

If you’re working with a script written by a colleague or adapting an example from the community, you can use Gemini capabilities to explain it. Simply ask, "Explain what this script does," and receive a step-by-step breakdown of the logic and Earth Engine functions being used.

3.  Perform one-click troubleshooting and debugging

Debugging is an inevitable part of coding. When your script throws an error in Google Earth Engine, the Console displays an error message. Now, those messages include a "Troubleshoot" button. Clicking it automatically populates the Ask panel with a prompt that contains the error message and a request for help to diagnose the issue and suggest a fix.

4. Optimize queries

If your script is, for example, running slowly, consuming resources inefficiently, throwing "computation timed out" or "too many concurrent aggregations" errors, ask for optimization tips. Gemini capabilities can suggest best practices like early filtering, reducing computation steps, or converting client-side loops into server-side operations.

Get started in two steps

Ask is available globally today. To get started, you just need a Gemini API key:

1. Get an API key: If you don’t already have a Gemini API key, head to Google AI Studio and create one (there are free options; if you choose a paid-tier API key, you will be billed for your usage). Learn more about Gemini API terms.

2. Add the API key to GEE: Open the Google Earth Engine Code Editor. On the right-hand panel, click the Ask panel. Click the key icon in the bottom left corner and enter your API key.

We want to hear from you! Please use the Code Editor Feedback button to share your feedback and help us improve the experience.

Every week, I talk with founders who are building at an unbelievable pace. Teams are moving from inception to product-market fit faster than ever, with foundation models wired deeply into their core product workflows.

Yet as startup architectures mature, a clear divide has emerged between teams struggling with margins and those scaling sustainably. The most effective engineering teams have abandoned the one-size-fits-all model strategy.

In the early days of LLMs the default architecture was simple: send every interaction to the largest model available. But as applications move into production, serving millions of people and running autonomous multi-agent workflows, relying on a single frontier model starts to strain in three places:

• Latency penalties: Relying entirely on cloud round trips makes it difficult to deliver the sub-second responsiveness that interactive mobile and desktop apps require.

• Infrastructure overhead: Self-hosting large open models with more than 70 billion parameters forces early-stage teams to act like infrastructure providers, pulling senior engineers on cluster provisioning and multi-GPU orchestration.

• Margin erosion: Sending high-frequency, structured tasks (like intent routing, JSON extraction, or status validation) to general-purpose frontier endpoints spends capital that could be funding product differentiation.

Great engineering teams pick the right tool for each job. Most production requests don’t require a frontier generalist, and routing every call to one can actually slow your product down. Instead, the winning pattern is a compound AI stack: pairing frontier models for complex synthesis with compact, open-weight models that you can tune, control, and run anywhere. 

It’s for these reasons that an open model like Gemma belongs in your model lineup. With more than one billion downloads across the developer community, Gemma 4 is our most capable open model family to date, using the same foundational research and technology behind the Gemini models.

Built under one roof

Gemma is built by Google DeepMind using the same foundational research and architecture advances behind the Gemini models. Because they share common DNA and developer tooling, your team can prototype in Google AI Studio and design hybrid architectures where Gemini and Gemma work together.

Released under a commercially permissive Apache 2.0 license, Gemma 4 is engineered for parameter and token efficiency. Rather than forcing a single model architecture onto every hardware target, Gemma 4 spans five sizes across four specialized architectures: compact E2B and E4B models with native audio and vision for mobile and edge devices; an encoder-free 12B Unified multimodal model; a 26B A4B Mixture-of-Experts (MoE) model that activates only 4B parameters per token for high-throughput serving; and a dense 31B model that fits on a single GPU for maximum reasoning quality and fine-tuning. Every model includes configurable thinking modes, native function calling, up to 256K context, and built-in Multi-Token Prediction (MTP) draft models for speculative decoding. 

Real proof: How startups are winning with Gemma

Founders are using Gemma to solve urgent problems around unit economics, output accuracy, and responsiveness.

• Flipping the architecture: Cue is a voice-activated desktop assistant that runs natively on a user's machine to automate everyday tasks. They integrated Gemma 4 E4B via Ollama on local hardware to handle real-time transcript formatting. While they originally planned for Gemma to be a weak offline fallback, benchmarking proved it was so fast and precise that they made it their default engine—driving a 44% latency drop (from 876 ms to 488 ms).

• True edge independence: Mobile development studio HubX built BetterSpeak, a voice-based interactive mobile English-learning tutor that simulates immersive, real-time voice conversations. To bypass cellular network lag and avoid charging users expensive subscription fees to cover cloud hosting, they packaged a 4-bit quantized Gemma 4 E2B model (~2.9 GB) natively on-device. The result is an offline, speech-to-speech mobile tutor that costs them $0 in server bills.

• Scientific discovery and air-gapped security: K-Dense has built Faraday, an AI-powered scientific collaborator optimized end-to-end across hardware, software, and sensor suites, powered by Gemma 4 together with K-Dense's Scientific Agent Skills. Faraday runs fully air-gapped, making it suitable for secure, proprietary scientific work in pharma and biotech. Deployed on an NVIDIA DGX Spark, Gemma 4 can also be fine-tuned locally on a user's own proprietary datasets.

• Unlocking infinite gameplay and retention: Gaming company Latitude integrated Gemma across their AI-native game products. By swapping in Gemma for AI Dungeon, they significantly improved player retention, while their new AI RPG platform Voyage leverages Gemma to deliver high intelligence at a cost that enables unlimited user gameplay with ultra-fast latency.

Four workloads where Gemma wins for startups

If you’re evaluating where Gemma fits into your stack today, start with these four jobs:

1. Edge and local execution (low latency, true privacy)

If you’re building mobile apps, developer desktop tools, robotics, or offline-first experiences, every cloud round-trip adds latency that people can feel. Gemma can run directly on laptops (including Apple silicon), smartphones, and local appliances. Your users get immediate feedback, and sensitive data never has to leave their device.

You can handle many local interactions on-device for zero incremental cost, and keep a bridge to frontier models in the cloud for the requests that need it. When a local workflow calls for large-scale multimodal reasoning, long-context data synthesis, or complex planning, your application can route that specific request to Gemini.

2. High-throughput triage and agent routing

In multi-agent architectures, agents spend a surprising amount of tokens on simple tasks like checking statuses, classifying intent, and routing tickets. With Gemma as your front-line gatekeeper, those high-volume background tasks run on a compact model and your team can save frontier reasoning for the requests where it creates product value.

3. Task-specific fine-tuning for real moats

Adapting a model to your proprietary data is one way to build a competitive moat. Because Gemma gives you full access to model weights and has a compact memory footprint, your team can run parameter-efficient fine-tuning (LoRA or QLoRA) on a single GPU in hours rather than days.

4. Turnkey vertical starting lines

DeepMind releases domain-specific variants of Gemma, so you don’t have to start from scratch. One example is MedGemma. MedGemma scores 87.7% on the MedQA benchmark, matching the clinical accuracy of frontier models at roughly one-tenth the inference cost. In a blind clinical study, board-certified radiologists judged that 81% of chest X-ray reports generated by the lightweight MedGemma 1.5 4B were accurate enough to result in equivalent patient management compared to reports written by human experts.

Beyond healthcare, biotech startups use C2S Scale to model virtual cellular responses and accelerate oncology research. Meanwhile, DataGemma cross-references more than 240 billion public data points to help reduce numerical hallucinations. If you’re operating in a specialized market, starting with a model that already speaks your industry's language can save you engineering time and compute budget.

Deploy wherever your business lives

Gemma is designed to fit into your existing engineering stack without lock-in:

• Apache 2.0 licensing: Gemma 4 ships under the Apache 2.0 license, giving startups the freedom to fine-tune, quantize, redistribute, and deploy commercial products on-premises or at the edge with full ownership of their custom weights.

• Day-zero open tooling: Run and fine-tune Gemma with the tools your engineers already use, including vLLM, Ollama, llama.cpp, LM Studio, MLX, Unsloth, Hugging Face, Kaggle, Keras, PyTorch, JAX, and LiteRT-LM.

• Serverless and managed cloud deployment: Prototype immediately in Google AI Studio, scale to zero on serverless GPUs with Cloud Run, or deploy dedicated endpoints from Model Garden on Gemini Enterprise Agent Platform when traffic surges and you don’t want to manage GPU clusters.

• Enterprise-ready safety: Gemma undergoes rigorous pre-release safety evaluations, data filtering, and red-teaming, and pairs with ShieldGemma 2 to help you meet enterprise compliance requirements.

Build with Gemma: What to do this week

Great technical architecture isn't about finding one model to do everything. It’s about assembling the right tool for each job so you can move faster, protect your runway, and ship a superior product.

Here’s my challenge to your engineering team this week:

1. Audit your model calls: Look at your logging dashboard and identify three high-volume, deterministic tasks (such as intent classification, JSON validation, or summarization) currently running on your most expensive models.

2. Benchmark Gemma: Run a quick test with a compact Gemma model locally or on a single endpoint. Measure the latency and calculate what happens to your gross margins when that workload runs with lower inference cost.

3. Redirect your runway: Take the capital and engineering hours you save on compute and invest them back into your core differentiators.

You can download the Gemma weights directly or deploy them through Model Garden. If you need compute credits and technical architecture reviews to get up and running, the Google for Startups team is ready to help you build - learn more.

Introduction

In late September 2026, Mandiant Consulting and Google Threat Intelligence Group (GTIG) identified active, in-the-wild exploitation of a zero-day vulnerability (CVE-2026-88772) affecting Citrix NetScaler ADC and NetScaler Gateway appliances. We have observed evidence that organizations in North America and Europe in the government, financial services, education, legal and professional services sectors were likely impacted by this exploitation campaign, which has been ongoing since at least early September. According to vendor disclosures, threat actors are also actively exploiting a second zero-day vulnerability (CVE-2026-88771). 

Exploitation of CVE-2026-88772 bypasses authentication and triggers an unhandled termination of the NetScaler Packet Processing Engine (NSPPE) to establish initial root-level access. Analysis of the actor’s post-exploitation toolkit reveals newly discovered custom PHP web shells, such as WHIPSHOT, capable of disguising Base64-encoded command-and-control (C&C) payloads within native HTTP headers. The toolkit also includes a novel companion Python tunneler, SLAPSHOT, capable of proxying traffic into internal networks for reconnaissance and credential theft. In at least one observed intrusion, the threat actor routed traffic through this proxy to manually conduct internal reconnaissance and credential theft.

Citrix issued guidance for customers on newly addressed vulnerabilities and recommended updates here. We encourage defenders to review the Citrix documentation and prioritize patching of these vulnerabilities. As part of this blog, Mandiant is also issuing containment and remediation guidance.

Campaign Overview

Initial Access

During the initial pre-authentication cryptographic handshake the NSPPE parses inbound DTLS record structures. While Google Threat Intelligence Group does not possess exploit code, analysis of frontline telemetry suggests that transmitting specially malformed or fragmented record headers induces heap memory boundary corruption within the packet engine, diverting control flow to execute arbitrary shellcode with root-level operating system privileges on the underlying FreeBSD platform.

Successful exploitation attempts generated two log artifacts:

0-PPE-0 : default SSLLOG SSL_HANDSHAKE_FAILURE 0 : SPCBId - ClientIP - ClientPort - VserverServiceIP - VserverServicePort 443 - ClientVersion DTLSv1.0 - CipherSuite "TLS1-AES-256-CBC-SHA" - Session New - Reason "Handshake failure-Internal Error"

Figure 1: SSL Handshake Failure recorded in Syslog

qat0: Process <PID> NSPPE-<##> exit with orphan rings 5:500
pitboss[<##>]: pitboss <DATETIME> NOT restarting NSPPE-<##> (<PID>)

Figure 2: NSPPE Process Termination (/var/log/messages) recorded by the FreeBSD kernel and the appliance watchdog daemon (pitboss)

Establish Foothold and Persistence

Following successful exploitation, the initial web shell payload self-installs by modifying target httpd.conf files, configuring the system to treat specified non-script file types as executable PHP scripts, setting the stage for the deployment of additional custom malware including WHIPSHOT (a PHP web shell) and SLAPSHOT (a Python proxy/tunneler). 

Web Server Persistence Method A: Package Handler Masquerading (.deb)

In one case, the initial installer modified /etc/httpd.conf to have the web server handle .deb files as though they were PHP scripts.

php_flag engine on
  <FilesMatch "\.deb$">
    Header set Cache-Control "no-cache"
  </FilesMatch>
AddHandler application/x-httpd-php .deb

Figure 3: Persistence via package handler masquerading

This configuration change allowed the actor to stage web shells with deceptive file type extensions in /netscaler/gui/vpn/scripts/linux.

Web Server Persistence Method B: Icon Aliasing and Signature File Handler (.sig)

In other intrusions, the threat actor implemented a stealthier configuration hook that disguised web shell execution as image requests:

php_flag engine on#
AliasMatch ^/vpn/media/(.+).ico$ /var/netscaler/gui/vpn/scripts/linux/$1.sig
AddHandler application/x-httpd-php .sig

Figure 4: Persistence via icon aliasing and signature file handler

This configuration directive performs three actions:

1. Enables the mod_php engine.

2. Registers .sig files as executable PHP scripts.

3. Maps any incoming HTTP request ending in .ico under /vpn/media/ directly to a corresponding .sig file with the same base name inside /var/netscaler/gui/vpn/scripts/linux/.

For example, clients accessing /vpn/media/e6ee7c85.ico would be served by the dropped PHP web shell e6ee7c85.sig. In at least one case, web server access logs showed GET requests returning HTTP 404 responses, but exhibiting elevated processing durations and multi-kilobyte response sizes. In subsequent days, the actor attempted access to non-existent .sig files, which generated missing-file errors in httperror-vpn logs implying the files were not there. This may be an indication of attackers managing similar web shells in multiple compromised environments.

Root Privilege Persistence

Although the initial exploitation of CVE-2026-88772 executes with root privileges, subsequent requests processed by the web server (httpd) run under an unprivileged web service context. To establish persistent root-level execution for its web shells, the threat actor leveraged its lightweight installer web shells to assert the setuid (Set User ID) bit on the /bin/sh executable:

chmod u+s /bin/sh

Figure 5: Command to set the User ID

By altering the permissions of /bin/sh, the threat actor was able to ensure that subsequent web requests processed by the web server would execute with the elevated permissions. To apply the /etc/httpd.conf modifications alongside the SUID shell change, the installer initiated a full NetScaler appliance reboot (/netscaler/nsshutdown -R). 

In other variations of the web shell, the threat actor issued a command to restart the web service directly and assign root setuid (Set User ID) permissions to the /bin/sh executable.

system('/bin/httpd -k restart -f /etc/httpd.conf && chmod u+s /bin/sh');

Figure 6: Command to restart the webservice

Malware Analysis

The threat actor has deployed multiple PHP web shells and a tunneler malware to proxy traffic into the victim organization’s network facilitating internal reconnaissance, lateral movement and credential harvesting.

Installer and Standalone web shells

Mandiant recovered several lightweight PHP web shells staged in files with .deb and .sig extensions that provide direct command execution and automated appliance persistence. Across directly observed intrusions, the web shell filenames varied between victims. We observed multiple examples of lightweight web shells using variations of “nginstaller,” often followed by a number, as the filename. 

• One example, when executed via command-line interface (CLI), it modifies /etc/httpd.conf, enables setuid root permissions on /bin/sh (chmod u+s /bin/sh), scrubs references to /vpn/scripts/linux from /etc/crontab, and initiates an appliance reboot via /netscaler/nsshutdown -R. Over HTTP, it extracts Base64-encoded commands from the HTTP_NSC_LDAP header, executes them via shell_exec(), and returns Base64-encoded output.

• Another observed web shell variant that returns a spoofed HTTP 404 Not Found response code. It restarts the Apache daemon (/bin/httpd -k restart -f /etc/httpd.conf) to apply configuration changes and executes incoming payloads using eval(). For evasion, it uses a regular expression (#^.*/vpn/scripts/linux.*\n#m) to systematically scrub its installation path from system `/etc/crontab`. The web shell executes incoming Base64-encoded payloads received via HTTP from the HTTP_NSC_LDAP header directly as PHP using `eval()`.

• e6ee7c85.sig: A web shell variant that also enforces HTTP 404 Not Found responses, but extracts Base64-encoded payloads from the HTTP_NSC_CLIENTTYPE request header, likewise executing via eval().

WHIPSHOT

WHIPSHOT is a PHP web shell disguised as a Debian package and placed in /netscaler/ns_gui/vpn/scripts/linux/. It functions as an HTTP transport bridge for the SLAPSHOT proxy daemon.

Key capabilities and behaviors include:

• HTTP Chunked Transport: It inspects incoming HTTP request headers for sequential parameter blocks (HTTP_X_UX_0 through HTTP_X_UX_95 or HTTP_X_UX). It concatenates these header values, Base64-decodes the resulting stream, and forwards the data over loopback to the SLAPSHOT proxy.

• Process Management & Launcher: Before establishing a connection, WHIPSHOT checks for the presence of /tmp/.uxdport and /tmp/.uxdlock. If the proxy is not active, WHIPSHOT extracts an embedded Base64 payload containing SLAPSHOT and spawns it in the background using:

nohup <python> -c 'import base64;exec(base64.b64decode("<payload>"))' /tmp/.uxdport /tmp/.uxdlock > /dev/null 2>&1 </dev/null &

Figure 7: Command to execute SLAPSHOT in the background

• Loopback IPC: Once SLAPSHOT is active, WHIPSHOT reads the dynamic TCP port recorded in /tmp/.uxdport, establishes a socket connection to 127.0.0.1:<port>, and relays the client request.

• Evasion: WHIPSHOT suppresses standard error reporting (error_reporting(0)) and sets an HTTP 404 Not Found response header while returning the tunneled TCP response within the HTTP body.

SLAPSHOT

SLAPSHOT is a TCP tunneling tool written in Python. It acts as an internal network bridge, accepting commands from WHIPSHOT and forwarding arbitrary TCP streams to internal hosts.

Key capabilities and behaviors include:

• Dynamic Port Binding & Locking: When launched, SLAPSHOT binds to an ephemeral port on 127.0.0.1, writes the active port number to a specified file such as /tmp/.uxdport, and uses fcntl.flock to secure an exclusive file lock on a lock file such as /tmp/.uxdlock via  ensuring only a single instance runs concurrently.

• Custom Wire Protocol: Communication with the proxy uses a custom binary protocol where each message consists of a 4-byte big-endian length prefix followed by a JSON payload. Supported command actions include:

• open: Establishes an outbound TCP socket to a target host and port.

• push: Writes data to an open session.

• pull: Polls and reads data from an open session socket.

• exch: Sends and receives C&C data to and from an open session socket.

• close: Terminates a specified network session.

• ping: Performs a basic health-check verification.

• Idle Timeout: The daemon monitors connection activity and automatically closes the individual session sockets after 15 minutes of inactivity. If no active sessions or commands are received within 10 minutes (configurable via the UXD_IDLE_EXIT variable), SLAPSHOT removes its port and lock files, and terminates its process to minimize memory footprint and detection risk.

Implications

This campaign underscores the continued targeting of edge devices to gain initial access to victim networks, a trend that GTIG has tracked across a range of threat actors. Notably, these vulnerabilities made up about half of the enterprise-related zero-days in 2025. These appliances—including Application Delivery Controllers, VPN gateways, and firewalls—remain  attractive targets because they are exposed to the internet, sit outside the reach of endpoint detection and response (EDR) tools, and often store or process credentials that can be used to move deeper into the network. We expect threat actors to continue to exploit vulnerabilities in edge devices, given the proven effectiveness of this tactic. 

Hunting, Containment, and Remediation Guidance

Organizations should begin by analyzing existing logs and configuration files to detect potential signs of compromise.

Hunting Strategies 

Citrix NetScaler ADC Appliances

1. Verify Web Server Configuration: Inspect /etc/httpd.conf on all NetScaler ADC appliances for unauthorized MIME types, script handler directives, or web path aliasing. Any instance of AddHandler or AddType registering non-PHP file extensions (such as .deb, .sig, .html, .rpm, or .tgz) to run as PHP scripts, or any AliasMatch diverting public web paths (/vpn/media/, /vpn/theme/, /vpn/images/) to appliance script directories, indicates compromise.

grep -En -i "application/x-httpd-php|php_flag|AliasMatch" /etc/httpd.conf

Figure 8: Web path aliasing

2. Audit Appliance Staging and Client Plug-in Directories: Audit the contents of native client plug-in paths (/var/netscaler/gui/vpn/scripts/linux/, /var/netscaler/gui/vpns/scripts/vista/, /var/netscaler/gui/vpns/scripts/mac/) and web asset paths (/netscaler/ns_gui/vpn/media/, /var/vpn/theme/). Legitimate client deliverables in these directories are compiled binaries or archives; any file identified as ASCII text or containing PHP script markers is anomalous. In default installations, these directories contain legitimate compiled client binaries and static web assets. Inspect them for plain-text scripts masquerading under non-script extensions or files containing PHP code:

file /var/netscaler/gui/vpn/scripts/linux/* /var/netscaler/gui/vpns/scripts/vista/* /var/netscaler/gui/vpns/scripts/mac/* /netscaler/ns_gui/vpn/media/* 2>/dev/null | grep -E "ASCII text|PHP script"
grep -rlE "<\?php|eval\(|base64_decode\(|shell_exec\(" /var/netscaler/gui/ /netscaler/ns_gui/ /var/vpn/ /netscaler/portal/ 2>/dev/null

Figure 9: Inspect client plugin paths for scripts masquerading as non-script extensions or files containing PHP code

3. Review Web Server Access & Error Logs: Review /var/log/httperror* for syntax, parse, or execution errors referencing disguised or non-standard file extensions (which persist even if access logs were scrubbed). Audit /var/log/httpaccess.log for requests targeting static media, icons, or script paths returning simulated HTTP 404 status codes or unexpectedly large response payloads. Search access logs for sudden chronological gaps or truncated lines around /vpn/scripts/ or /vpn/media/, which may indicate execution of the actor's regex-based log wiper.

grep -E -i "\.(deb|sig|rpm|tgz|sh|so|dat|ico|png|html)" /var/log/httperror*

Figure 10: Search for non-standard file extensions and execution errors

grep -E "/vpn/media/|/vpn/scripts/|/vpn/theme/" /var/log/httpaccess.log* | awk '$9 ~ /200|404/ && $10 > 5000'

Figure 11: Search for unexpectedly large response payloads

4. Check for Ephemeral IPC Artifacts: Inspect the /tmp/ directory on appliances for lock files and port pointer files created by SLAPSHOT. The presence of /tmp/.uxdport or /tmp/.uxdlock indicates active or recent execution of the SLAPSHOT proxy daemon. Responders should record the port contained in .uxdport and inspect the listening process via sockstat -4 -l:

ls -la /tmp/.uxdport* /tmp/.uxdlock

Figure 12: Search for files created by SLAPSHOT

5. Verify Shell and Binary Permissions: Inspect /bin/sh to confirm unauthorized SUID permissions have not been established. If permissions indicate -rwsr-xr-x with root ownership, the binary has been modified for persistent setuid privilege escalation.

ls -l /bin/sh

Figure 13: Check for unauthorized SUID permissions

6. Examine Process Execution & Shell History: Inspect active system processes for anomalous Python interpreters executing background commands referencing /tmp/.uxdport or running under nohup. Review /var/log/sh.log for administrative commands executed outside change windows, including forced restarts (/netscaler/nsshutdown -R) and manual Apache restarts (httpd -k restart).

ps aux | grep -E "python.*(\.uxd|uxdport|uxdlock|base64)"

Figure 14: Inspect system process for anomalous Python interpreters

Note: Citrix has published guidance on using its indicator of compromise (IOC) Scanner to identify potential indicators of compromise on an organization’s NetScaler infrastructure. For additional details, refer to the following Citrix documentation:

• https://docs.netscaler.com/en-us/netscaler-console-service/instance-advisory/security-advisory-dashboard.html

• https://docs.netscaler.com/en-us/netscaler-console-service/instance-advisory/ioc.html

Note: Organizations should apply hunting techniques holistically across their broader infrastructure to identify potential lateral movement originating from the NetScaler infrastructure. These techniques should be applied across the environment, including, but not limited to, other Privileged Access Management (PAM) platforms.

Containment and Remediation Strategies 

Organizations that have not yet applied the latest security updates should immediately assess their exposure and risk. Broad internet isolation or strict IP allow-listing on NetScaler Gateways can create significant disruption for organizations supporting remote workforces through Citrix Virtual Apps and Desktops (formerly XenApp and XenDesktop). For this reason, Mandiant recommends a targeted, phased approach that prioritizes patching while applying appropriate containment and compensating controls based on the organization’s risk profile.

Immediate Mitigation

Organizations should evaluate the following options based on their risk tolerance, evidence of compromise, and operational requirements.

Option 1 — Apply the Latest Citrix Build (Mandiant Recommended)

Implement the latest Citrix build that addresses the in-scope vulnerabilities. Organizations should upgrade to the following fixed releases (or later) depending on their current deployment track:

• NetScaler 14.1 Track: Upgrade to version 14.1-73.37 and later releases.

• NetScaler 13.1 Track: Upgrade to version 13.1-64.23 and later releases of 13.1.

Note: Specific patched builds are also available for 14.1-FIPS and 13.1-FIPS/NDcPP deployments

Organizations that cannot locate specific builds in the Citrix customer downloads portal should  open a Severity 1 support case with Citrix to confirm and obtain the latest build containing the required fixes.

Option 2 — Isolate Compromised or Suspected Appliances

For confirmed or suspected compromise, isolate affected NetScaler appliances from the network. This option can introduce significant business disruption, particularly when the appliance provides remote access or other critical services.

If the hunting strategies described above identify indicators of compromise, Mandiant recommends implementing the following containment actions:

• Isolate the node. Immediately remove the confirmed or suspected appliance from the network.

• Halt HA synchronization. For NetScalers deployed in High Availability (HA) pairs, assess both nodes independently. Disable configuration synchronization until both nodes have been validated to prevent a compromised node from replicating malicious changes, such as modified httpd.conf files, to the standby node.

• Restrict egress. Block observed threat actor infrastructure and restrict outbound internet connectivity from the appliance. In particular, prevent arbitrary outbound TCP/UDP traffic and block outbound SMTP over TCP/25 unless explicitly required.

•  Review hypervisor network isolation. If the NetScaler runs as a VPX appliance in a virtualized environment, review vSphere vSwitch and Port Group configurations. Confirm that the NetScaler VPX is appropriately segmented and does not share a Layer 2 network with hypervisor management interfaces, such as ESXi vmk0 or vCenter, or other highly sensitive infrastructure tiers. Refer to the Mandiant hardening guidance for vSphere for additional recommendations.

Option 3 — Apply Targeted Compensating Controls

If immediate patching is not possible, organizations should implement targeted controls to reduce the exposed attack surface until the affected appliances can be updated. The DTLS and UDP/443 controls below are specific to CVE-2026-88772 and should not be relied on to mitigate CVE-2026-88771. Installing a fixed NetScaler build remains required to address both vulnerabilities.

Part A — Network Restrictions

• Disable DTLS where operationally feasible. If patching is delayed, disable DTLS on internet-facing NetScaler Gateway virtual servers where it is not required. In this campaign, the exploit payload is delivered over UDP/443 using Datagram Transport Layer Security (DTLS).

• Restrict inbound UDP/443 upstream. Block inbound UDP/443 to affected appliances unless DTLS is explicitly required. This control should be implemented on an upstream perimeter firewall or edge router. Relying exclusively on local NetScaler ACLs allows traffic to reach the vulnerable packet-processing engine (nsppe) before it is dropped.

• Implement upstream IP allow-listing where feasible. Organizations using NetScaler strictly for load balancing, or operating Access Gateways that serve a predictable set of external source IP addresses, should consider upstream network ACLs that drop unauthorized traffic before it reaches the appliance.

For public-facing VPNs supporting large remote workforces, this approach may not be practical because dynamic residential IP addresses can create significant administrative and operational overhead. 

• Preserve virtual appliance state for forensic analysis. For NetScalers deployed as virtual appliances, including NetScaler VPX on VMware vSphere or other hypervisors, take a full VM snapshot with memory state included before rebooting whenever operationally possible.

Part B — Credential Rotation and Session Termination

Organizations should operate under the assumption that credentials stored on a compromised appliance may have been exposed. Credential rotation and session termination should be coordinated across the appliance and connected systems.

• Revoke active sessions. Invalidate existing administrative, Gateway, and VPN sessions to remove potentially compromised session tokens. For organizations using the appliance as a gateway for Citrix Virtual Apps and Desktops, this should include terminating active ICA/HDX sessions where appropriate. Refer to Citrix CTX584227 for additional guidance.

• Rotate appliance secrets. Rotate NetScaler administrator credentials, local appliance accounts, Secure Shell (SSH) keys, TLS certificates, and associated private keys.

• Rotate integration credentials. Rotate LDAP bind and service accounts, RADIUS shared secrets, TACACS credentials, SNMP community strings, and NITRO/application programming interface (API) credentials.

• Audit downstream Citrix infrastructure. Review systems that the NetScaler communicates with directly, particularly Citrix StoreFront servers, Citrix Delivery Controllers (DDCs), and internal Citrix Virtual Apps and Desktops hosts. Review Windows Event Logs for anomalous interactive logons, unexpected remote desktop protocol (RDP) activity, signs of credential dumping, and other evidence of lateral movement.

Organizations should also consider revoking and rotating TLS certificates and associated private keys stored on compromised appliances.

Note: Organizations should rotate credentials after the appliance has been successfully patched.

Part C — Control Plane Restrictions

Organizations should apply additional restrictions to the NetScaler control and management planes.

• Restrict internet-facing services to required ports and protocols only.

• Implement default-deny outbound firewall rules for NetScaler appliances.

• Permit outbound connectivity only to explicitly approved destinations and services, including DNS, NTP, required OCSP/CRL services, approved backend applications, and approved management and security infrastructure.

• Explicitly block outbound SMTP over TCP/25 unless there is a documented business requirement.

• Prevent NSIP and management interfaces from being exposed to the internet.

• Restrict SSH, HTTPS management, and NITRO/API access to dedicated administrative networks, approved jump hosts, and explicitly approved source IP ranges.

Part D — Logging and Detection Engineering

Detection is a critical component of the response strategy. Mandiant recommends approaching detection across two areas: ensuring the necessary telemetry is available and implementing detections that correlate network, appliance, file system, and identity activity.

Logging and Visibility

Several of the detections below depend on logs that NetScaler does not forward by default. Before implementing detection logic, confirm that the SIEM receives the following telemetry:

• NetScaler audit logs (ns.log) through a syslog action, including SSL-related events.

• The appliance’s FreeBSD system log (/var/log/messages), which records NSPPE termination/crashes and pitboss messages and is not included in standard ns.log forwarding.

• Web server logs (/var/log/httpaccess.log and /var/log/httperror*), NetScaler Web Logging, or AppFlow telemetry. Because TLS terminates on the appliance, upstream network devices generally cannot inspect HTTP request paths or headers.

• Firewall or network flow logs for traffic originating from NetScaler NSIP and SNIP addresses.

• Secret Server or other privileged access management (PAM) audit logs.

Detection Engineering

Protocol and Traffic Analysis

• Alert on exploit-pattern DTLS failures. Look for SSL_HANDSHAKE_FAILURE events where ClientVersion is DTLSv1.0 and the reason is Handshake failure-Internal Error. Successful exploitation observed during this activity produced this event. Review individual occurrences and prioritize clusters originating from the same appliance.

• Correlate DTLS failures with engine termination/crashes. A matching DTLS handshake failure followed within minutes by an NSPPE termination/crash on the same appliance is a strong exploitation signal and should be investigated with high priority.

• Review unexpected inbound UDP/443. Focus on appliances where DTLS is disabled or not expected. Baseline the sources that normally establish DTLS connections with each Gateway. Because exploitation can require very little traffic, volume-based anomaly detection alone may not identify the activity.

Appliance Process and Memory Stability

• Monitor for NSPPE termination/crashes. Generate high-severity alerts for kernel messages indicating that an NSPPE process exited or was terminated by a signal. Also monitor for the creation of new NSPPE core files under /var/core/.

• Alert when pitboss does not restart NSPPE. Monitor for pitboss messages containing pitboss NOT restarting NSPPE. Alert on these messages and NSPPE kernel termination/crash events independently rather than requiring both conditions to occur.

• Correlate with availability events. Treat unexpected HA failovers or appliance restarts on internet-facing Gateways within the same time window as supporting evidence of potential exploitation.

File System and Configuration Integrity

• Monitor critical VPN script paths. Detect the creation, modification, or staging of .sig files, including files such as nsgclient.sig, within VPN-related directories such as:

• /var/netscaler/gui/vpn/scripts/linux/

• /netscaler/ns_gui/vpn/scripts/linux/

• /var/netscaler/gui/vpns/scripts/vista/

• /var/netscaler/gui/vpns/scripts/mac/

• /netscaler/ns_gui/vpn/media/

• /var/vpn/theme/

• Detect unauthorized web server configuration changes. Monitor /etc/httpd.conf, /nsconfig/httpd.conf, and /flash/nsconfig/httpd.conf for unauthorized modifications. In particular, alert on:

• The addition or modification of AddHandler application/x-httpd-php .[ext] directives.

• php_flag engine on configurations or other changes that enable PHP execution. Threat actor activity has included PHP-based web shells using extensions other than .php, and the specific extension may vary by environment. Alias, AliasMatch, or RewriteRule directives that map web asset paths such as /vpn/media/, /vpn/theme/, or /vpn/images/ to script directories or executable files.

• Check runtime state on a recurring basis. Monitor for:

• The SUID bit being set on /bin/sh

• The presence of /tmp/.uxdport or /tmp/.uxdlock

• Python processes launched through nohup or containing Base64-encoded payloads

• Unexpected changes to persistent configuration or startup files under /nsconfig/

Egress and Interaction Monitoring

• Detect suspicious web shell interaction with static or client-script paths. Focus on behavior rather than the requested path alone, since legitimate clients routinely access /vpn/media/ resources. Potential indicators include:

• 404 responses to /vpn/media/*.ico or /vpn/scripts/ paths that return multi-KB response bodies or exhibit unusually long processing times.

• “File does not exist” entries in HTTP error logs involving .sig or other non-standard files under /vpn/scripts/. These events may remain visible even when access logs have been modified or cleared.

• Gaps, malformed entries, or truncated lines in httpaccess.log around requests to /vpn/scripts/ or /vpn/media/.

• Identify anomalous appliance egress. Monitor outbound connections originating directly from NetScaler appliances and alert when destinations fall outside the organization’s approved egress allow-list. Prioritize activity involving credential vaults and PAM systems, connections to domain controllers over unexpected ports, connections to a large number of internal systems within a short period, and outbound SMTP over TCP/25.

Indicators of Compromise (IOCs)

Network & Transport Indicators

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

File Indicators

Detections

YARA Rules

rule G_APT_Backdoorwebshell_WHIPSHOT_1
{
    meta:
        description = "Detects WHIPSHOT PHP webshell tunneling frontend deployed on Citrix NetScaler ADC appliances"
        author = "GTIG"
        family = "WHIPSHOT"
strings:
    // Chunked transport headers
    $sh1 = "HTTP_X_UX" ascii
    $sh2 = "HTTP_X_UX_" ascii

    // IPC lock and port pointers to local proxy daemon
    $si1 = "/.uxdport" ascii
    $si2 = "/.uxdlock" ascii
    $si3 = "/tmp/.uxdport /tmp/.uxdlock" ascii

    // Socket forwarding logic
    $sf1 = "fsockopen" ascii
    $sf2 = "127.0.0.1" ascii
condition:
    filesize < 50KB and (
        ($sh1 or $sh2) and ($si1 or $si2 or $si3) and ($sf1 or $sf2)
    )

}

rule G_APT_Tunneler_SLAPSHOT_1
{
    meta:
        description = "Detects SLAPSHOT Python proxy daemon and tunneling tool deployed alongside WHIPSHOT on compromised NetScaler appliances"
        author = "GTIG"
        family = "SLAPSHOT"

   strings:
        // Lock and port files
        $ss1 = "/tmp/.uxdport" ascii fullword
        $ss2 = "/tmp/.uxdlock" ascii fullword
        $ss3 = "UXD_IDLE_EXIT" ascii fullword
        $ss4 = "127.0.0.1" ascii

        // Wire protocol command verbs
        $sc1 = "\"open\"" ascii fullword
        $sc2 = "\"conn\"" ascii fullword
        $sc3 = "\"push\"" ascii fullword
        $sc4 = "\"pull\"" ascii fullword
        $sc5 = "\"exch\"" ascii fullword
        $sc6 = "\"close\"" ascii fullword
        $sc7 = "\"ping\"" ascii fullword

        // Protocol parameter names
        $sp1 = "\"sid\"" ascii fullword
        $sp2 = "\"host\"" ascii fullword
        $sp3 = "\"port\"" ascii fullword
        $sp4 = "\"data\"" ascii fullword
    condition:
        filesize < 30KB and (
            ($ss1 and $ss2 and $ss3) or
            ($ss4 and ($ss1 or $ss2) and 3 of ($sc*) and 2 of ($sp*)) or
            ($ss3 and 3 of ($sc*) and 2 of ($sp*))
        )
}

rule G_Hunting_Config_NetScaler_PHP_1
{
    meta:
        description = "Detects unauthorized Apache configuration directives registering non-standard extensions as PHP scripts, or aliasing web paths to appliance script directories on Citrix NetScaler ADC"
        author = "GTIG"

    strings:
        // NetScaler appliance configuration context markers
        $ns1 = "/netscaler" ascii nocase
        $ns2 = "/var/netscaler" ascii nocase
        $ns3 = "/vpn/" ascii nocase
        $ns4 = "ns_gui" ascii nocase
        $ns5 = "<VirtualHost *:81>" ascii nocase
        $ns6 = "Listen 81" ascii nocase

        // Generic type or handler registration mapping non-standard file extensions to PHP
        $t1 = /Add(Handler|Type)\s+['"]?application\/x-httpd-php['"]?\s+\.([^p\s\r\n][a-zA-Z0-9_-]*|p[^h\s\r\n][a-zA-Z0-9_-]*|ph[^p\s\r\n][a-zA-Z0-9_-]*|php[^s\s\r\n][a-zA-Z0-9_-]*|phps[a-zA-Z0-9_-]+)/ ascii nocase

        // Diversion of web asset paths (media, theme, help, logon, images) to script staging directories
        $a1 = "AliasMatch" ascii nocase
        $a2 = /\^?\/vpn(s)?\/(media|theme|themes|images|help|logon|support)\// ascii nocase
        $a3 = /\/var\/netscaler\/gui\/vpn(s)?\/scripts\// ascii nocase
        $a4 = /\/vpn(s)?\/scripts\// ascii nocase

        // PHP execution flags
        $p1 = "php_flag engine on" ascii nocase

        // Exclusions for web pages, markup, and source code
        $not_html1 = "<html" ascii nocase
        $not_html2 = "<!DOCTYPE" ascii nocase
        $not_html3 = "<?xml" ascii nocase
        $not_code1 = "package " ascii
        $not_code2 = "#include " ascii
    condition:
        filesize < 100KB and not (
            $not_html1 or $not_html2 or $not_html3 or $not_code1 or $not_code2
        ) and (1 of ($ns*)) and (
            // Any directive registering a non-PHP extension as PHP
            $t1 or
            // Any AliasMatch diverting web paths to script directories
            ($a1 and ($a2 or $a3 or $a4)) or
            // Generic combination of php_flag engine on with script directory aliasing
            ($p1 and $a1 and ($a3 or $a4))
        )
}

rule G_Hunting_Backdoorwebshell_NetScaler_C2Headers_1
{
    meta:
        description = "Detects standalone PHP webshells deployed on NetScaler appliances extracting commands from custom or native SetEnvIf HTTP headers"
        author = "GTIG"

   strings:
        // NetScaler C2 header patterns (both HTTP_NSC_* and raw NSC_*, covering all native SetEnvIf variables)
        $h1 = /(HTTP_)?NSC_[a-zA-Z0-9_]+/ ascii
        $h2 = /(HTTP_)?NSC_(USER|NONCE|LDAP|CLIENTTYPE|FT_HIDE)/ ascii nocase

        // Specific named NetScaler SetEnvIf headers
        $hs1 = "HTTP_NSC_LDAP" ascii fullword nocase
        $hs2 = "HTTP_NSC_CLIENTTYPE" ascii fullword nocase
        $hs3 = "HTTP_NSC_USER" ascii fullword nocase
        $hs4 = "HTTP_NSC_NONCE" ascii fullword nocase
        $hs5 = "HTTP_NSC_FT_HIDE" ascii fullword nocase
        $hs6 = "NSC_USER" ascii fullword nocase
        $hs7 = "NSC_NONCE" ascii fullword nocase
        $hs8 = "NSC_LDAP" ascii fullword nocase
        $hs9 = "NSC_CLIENTTYPE" ascii fullword nocase
        $hs10 = "NSC_FT_HIDE" ascii fullword nocase

        // Dynamic execution sinks
        $e1 = "eval(base64_decode(" ascii
        $e2 = "shell_exec(base64_decode(" ascii
        $e3 = "system(base64_decode(" ascii
        $e4 = "passthru(base64_decode(" ascii
        $e5 = "eval(" ascii
        $e6 = "base64_decode(" ascii
        $e7 = "shell_exec(" ascii
        $e8 = "passthru(" ascii
        $e9 = "system(" ascii
        $e10 = "exec(" ascii
        $e11 = "popen(" ascii
        $e12 = "proc_open(" ascii
        $e13 = "assert(" ascii

        // Concealment and response markers
        $c1 = "http_response_code(404)" ascii
        $c2 = "REQUEST_METHOD" ascii
        $c3 = "<FATO>" ascii
        $c4 = "</FATO>" ascii
    condition:
        filesize < 50KB and (
            // Any NSC header accessed alongside dynamic execution
            ((1 of ($h*) or 1 of ($hs*)) and ($e1 or $e2 or $e3 or $e4 or ($e6 and ($e5 or $e7 or $e8 or $e9 or $e10 or $e11 or $e12 or $e13)))) or
            // Any NSC header paired with concealment markers
            ((1 of ($h*) or 1 of ($hs*)) and ($c3 or $c4 or ($c1 and $c2))) or
            // Standalone FATO marker webshell
            (($c3 and $c4) and ($e1 or $e2 or ($e5 and $e6) or ($e6 and $e7)))
        )
}

rule G_Hunting_Script_NetScaler_Persistence_1
{
    meta:
        description = "Detects appliance staging, installer, and anti-forensic maintenance scripts deployed during NetScaler compromise"
        author = "GTIG"
strings:
    // Appliance restart / shutdown commands
    $cmd1 = "/netscaler/nsshutdown" ascii
    $cmd2 = "nsshutdown -R" ascii

    // SUID root backdoor creation
    $cmd3 = "chmod u+s /bin/sh" ascii

    // Web server reload / restart
    $cmd4 = "/bin/httpd -k restart" ascii
    $cmd5 = "httpd -k restart -f /etc/httpd.conf" ascii

    // Forensic access log scrubbing regex pattern (across any staging path)
    $scrub1 = /#\^\.\*\/vpn(s)?\/(scripts|media|theme|themes|help|logon)/ ascii

    // Apache configuration modification strings
    $cfg1 = "AddHandler application/x-httpd-php" ascii
    $cfg2 = "AddType application/x-httpd-php" ascii
    $cfg3 = "php_flag engine on" ascii
    $cfg4 = "AliasMatch" ascii
    $cfg5 = "SetEnvIf" ascii
condition:
    filesize < 50KB and (
        // Log scrubber + privilege escalation or web server restart
        ($scrub1 and ($cmd3 or $cmd4 or $cmd5)) or
        // SUID root backdoor creation + appliance command or config modification
        ($cmd3 and ($cmd1 or $cmd2 or $cmd4 or $cmd5 or $cfg1 or $cfg2 or $cfg3 or $cfg4 or $cfg5)) or
        // Configuration tampering + appliance command
        (($cfg1 or $cfg2 or $cfg4) and ($cmd1 or $cmd2 or $cmd4 or $cmd5)) or
        // Generic 2 of the specific appliance maintenance commands
        (2 of ($cmd*))
    )

}

Google Security Operations 

Google Security Operations is continuously developing and updating rules within the Mandiant Intel Emerging Threats rule pack to ensure robust protection for customers. New rules are under active testing for threat activity detailed in this post, detection coverage will be added and deployed across Google SecOps.

Acknowledgements

This analysis would not have been possible without the assistance of Bella Valdescruz, Bhavesh Dhake, Chris Linklater, Christopher Romano, Geoff Carstairs, Greg Blaum, Josh Thackston, Kimberly Goody, Lianis Oliva, Matthew Quick, Michael Edie, Omar ElAhdan, Peter Ukhanov, Sagun Chetry, Stuart Carrera, Tyler McLellan.

※この投稿は米国時間 2026 年 9 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud のセッション管理では、組織のセキュリティ ポリシーのニーズに基づいてセッション管理を設定できる柔軟なオプションを提供しています。その一環として、セキュリティ ポスチャーの向上と、認証情報の窃取やアカウント乗っ取り（ATO）リスクの軽減を目的に、Google Cloud をご利用のお客様向けに、デフォルトのセッション時間を 16 時間に設定してロールアウトしました。

このセキュリティ標準は、セッション時間を独自に設定していなかったすべてのお客様への適用を完了しましたが、今日のクラウド環境ではさらに高い精度が求められています。このグローバル ロールアウトの完了に伴い、Google Cloud のセッション管理も、広範な管理設定から、コンテキストアウェア アクセス（CAA）の緊密に統合されたきめ細かい機能へと進化しました。

このアップデートにより、管理者はより柔軟に、より優れた自動化を実現し、より自然なセキュリティ ワークフローを構築できるようになりました。

セッション管理の新機能

1. 自動化ファースト: Terraform、gcloud、API のサポート最新のインフラストラクチャはコードとして管理されます。DevSecOps ワークフローをサポートするため、セッション管理ポリシーの設定は、UI からの手動設定に限定されなくなりました。一般提供が開始されたことにより、以下を使用してプログラムでセッション ポリシーを定義、デプロイ、管理できるようになりました。

• Terraform: セッション管理をインフラストラクチャ マニフェストに直接統合します。

• gcloud CLI: コマンドラインからポリシーを管理します。

• REST API: 複雑なマルチテナント環境全体でポリシーの適用を自動化します。

2. Google グループによるきめ細かいターゲティング最も要望の多かったアップグレードの一つは、ポリシーを正確にターゲティングする機能でした。以前は、セッション継続時間は組織部門（OU）に関連付けられていました。一般提供が開始されたセッション管理ポリシーでは、Google グループを使用できるようになりました。

この変更により、組織階層内のユーザーの場所に関係なく、特定のユーザー クラスタに異なるセッション ポリシーを適用できます。たとえば、権限昇格されたユーザー（課金管理者やプロジェクト オーナーなど）には 2 時間のセッションを適用し、一般の開発者には標準の 16 時間のセッションを維持できます。

3. アプリケーションの精密な制御セッション管理ポリシーでは、Google Cloud API スコープを必要とするすべてのアプリケーションに影響する包括的なポリシーではなく、特定のアプリケーションに対して個別にセッション管理を設定できます。これらのアプリケーションには、以下が含まれます。

• Google Cloud コンソール

• gcloud コマンドライン ツール

• 特定の OAuth アプリケーション

一般提供が開始されたこのアップデートにより、「全か無か（オール・オア・ナッシング）」といった極端なシナリオを防ぐことができます。たとえば、Cloud SDK に厳格なポリシーを適用した結果、OAuth を利用している正当なビジネス インテリジェンスやダッシュボードとの連携まで意図せず遮断されてしまう、といった事態を回避できます。

4. Google Cloud ネイティブのエクスペリエンスこれまで、Google Cloud のセッション継続時間の設定は、Google Workspace 管理コンソールでしか行えませんでした。

Google Cloud のお客様は、お申し込みいただくことで Google Cloud コンソールを使用できるようになり、Access Context Manager（ACM）の他のアクセスレベルやセキュリティ バインディングと合わせて、セッション ポリシーを管理することも可能になります。プレビュー版として提供されるこのアップデートにより、Google Cloud コンソールでのポリシー管理を好む管理者は、すべての CAA ポリシーをより柔軟に、そして統一された操作感で設定できるようになります。

ご利用方法

セッション制御を静的な組織のデフォルト設定から、動的なコンテキストアウェア ポリシーへと進化させることで、セキュリティ チームは開発スピードを損なうことなく、最もリスクの高い場面において、認証情報の窃取に対する再認証の制限を厳格化できます。

Terraform、REST API、gCloud を使用してセッション管理を構成する方法については、セッション管理に関するドキュメントをご覧ください。

- プロダクト マネージャー、Senzeni Mpofu

- ソフトウェア エンジニア、Cris Scruggs

※この投稿は米国時間 2026 年 9 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

ビルドツールの運用から、データ分析パイプラインや共同リサーチまで、データドリブンなタスクの実行は、あらゆるエンタープライズ エージェントにとって不可欠な作業です。

にもかかわらず、多くのプラットフォーム チームは、エージェントのストレージ要件にカスタムの回避策を継ぎ合わせて対応しているのが現状です。たとえば、エージェント サンドボックスと一元化されたストレージの間で状態をやり取りしたり、ローカル ディスクやセルフホスト型ファイル システムを手動で管理したりしています。このようなアプローチは、エージェント フリートが拡大するにつれ、コールド スタート時のレイテンシ、運用の複雑化、未割り当てアイドル状態のストレージの費用といった課題とのバランスを取るのが難しくなります。

エージェント サンドボックスは、数千、数百万のセッションを同時進行する規模までスケーリングする可能性があります。ストレージはそれに合わせて上記の課題を克服し、ワークスペースの徹底した隔離、セッションの即時再開、柔軟な従量課金制、流動的なマルチエージェント コラボレーションを必要とする動的なワークロードのニーズを満たすように進化する必要があります。

こうした新たな需要に応えるため、Google は AI ストレージ ポートフォリオを拡大し、Filestore エージェント ボリュームの提供を開始しました。これは、高パフォーマンスの柔軟なファイル ストレージで Google Cloud でのエージェント ワークロードのスケーリングを可能にするために設計されたフルマネージドの新機能です。

AI エージェント ワークスペース専用のストレージ

自律型エージェントが安全にタスクを実行するためには、隔離されたランタイム環境が必要です。たとえば、動的コードの実行、サードパーティ パッケージのインストール、各種ツールの運用を、ホスト インフラストラクチャやテナントデータを危険にさらすことなく実行する必要があります。GKE 上の Agent Substrate と GKE Agent Sandbox は、高密度のエージェント フリートを実行するために必要な専用コンピューティング環境を提供しますが、サンドボックスには専用の永続ワークスペースも必要です。

Google Cloud Filestore に含まれる Filestore エージェント ボリュームは、AI エージェント フリートのスケーリングと弾力性を考慮して特別に設計された動的プロビジョニング アーキテクチャにより、エージェント コンピューティングを補完する専用のエージェント ストレージを提供します。Agent Substrate との連携で大規模なエージェント フリートもサポートできるように設計されており、GKE サンドボックスに隔離された永続的なファイル ストレージへの即時アクセスを可能にします。Filestore を活用するようにエージェント環境を構成すると、GKE のストレージ管理がバックグラウンドで行われます。GKE が新しいエージェント タスク用にサンドボックスを起動するたびに、Filestore は隔離された専用ファイル ワークスペースをミリ秒単位でその環境に自動的に割り当て、アタッチします。プラットフォーム チームは、個々のエージェントの実行用にストレージ ボリュームを手動で作成、アタッチ、破棄する必要はありません。エージェント フリートのスケールアップとスケールダウンに応じて、システムがボリュームのライフサイクル全体を自動的に処理します。これにより、効率的なエンドツーエンドのインフラストラクチャ ソリューションが実現し、費用対効果の高いエージェント管理が以下の機能性をもたらします。

• 緻密な隔離と企業のガードレール: エージェント プラットフォームは、信頼できない自律型コードを実行する際に、セキュリティとデータ漏洩のリスクに直面します。Filestore エージェント ボリュームは、ワークスペースごとに厳格な境界制御と細分化されたアクセス権限を適用します。これにより、エージェントは指定されたディレクトリ内でのみ動作し、動的なツールチェーンがテナント間で厳密に分離されます。

• 1 秒未満でのセッション再開: 従来のストレージ プロビジョニング手法では、インタラクティブなエージェント セッションがコールド スタート時のレイテンシの影響で停止することがありました。Filestore エージェント ボリュームではミリ秒単位でアタッチとデタッチが行われるため、オーケストレーターがアイドル状態のサンドボックスを積極的に停止してコンピューティング費用を節約し、新しいタスクやユーザー入力を受け取ると直ちに再開します。

• スマート ライフサイクル エコノミーと従量課金制: 数千もの短時間または断続的なエージェント タスクに固定サイズの高パフォーマンス ストレージを事前割り当てすると、ストレージが大量に無駄になる可能性があります。Filestore エージェント ボリュームを使用すると、プラットフォームは消費されたストレージ容量に対してのみ課金され、自動ライフサイクル階層化のメリットを享受できます。つまり、エージェントがコードの読み取り / 変更やデータセットの分析を行っていないときは、アイドル状態のワークスペースを自動的に低コストのストレージに移行でき、費用の無駄を省いて高パフォーマンスを実現できます。

• マルチエージェント コラボレーション: マルチエージェント スウォームの使用は、データ受け渡しのパイプラインが脆弱になりがちで、ファイル競合のリスクにもつながります。Filestore エージェント ボリュームは、ネイティブの Read-Write-Many（RWX）サポートと POSIX ファイルロックを備えており、オーケストレーターが複数のエージェントに単一の共有ワークスペースをアタッチできます。共同作業を行うエージェントは、ファイルレベルの整合性と書き込み競合プロテクトにより、プロジェクト ファイルを安全に共同編集、テスト、レビューできます。

次世代エージェント ワークロードをサポート

Filestore エージェント ボリュームは、柔軟で高パフォーマンスの分離されたファイル階層化により、以下を含む本番環境の幅広いエージェント ワークロードとユースケースをサポートします。

• ソフトウェア エンジニアリングとコーディングのサンドボックス: エージェント コーディング プラットフォームで、数千件もの隔離されたワークスペースをスピンアップできます。エージェントは、ストレージ固有のカスタマイズを必要とせず、標準の POSIX ファイル セマンティクスを活用して、ライブラリのインストール、複数ファイルのパッチ作成、ビルドツールの運用、そして単体テストを安全に行うことができます。

• マルチエージェント スウォームのコラボレーション: リード オーケストレーターがリサーチ、コード生成、検証担当の専任サブエージェントにタスクを委任するような複雑なワークフローで、統合ファイルツリーを直接共有できます。RWX サポートにより、エージェントは書き込みの競合を発生させることなく、プロジェクト ファイルを同時に共同編集およびレビューできます。

• インタラクティブな長期ワークフロー: ユーザーが関与するアプリケーション（ユーザー承認を不定期に複数回必要とするエージェントや、数時間にわたるデータ分析パイプラインを実行するエージェントなど）の場合、プラットフォームはアイドル状態のエージェント サンドボックスを一時停止してコンピューティングの無駄を最小限に抑え、実行の再開にはオンデマンドで瞬時に対応します。

今すぐ利用開始

Agent-as-a-Service プラットフォームの構築から、コーディング支援のスケーリングやエンタープライズ エージェント フリートのデプロイまで、いかなるタスクにおいても、ストレージ ティアはイノベーションを妨げるのではなく、加速させるものでなければなりません。

Filestore エージェント ボリュームは、Google Cloud のすべてのお客様が非本番環境ワークロードで今すぐご利用いただけます。本番環境ワークロードの一般提供サポートは、許可リストを通じてのご提供となります。この新サービスは、GKE 上の Agent Substrate および GKE Agent Sandbox と直ちに統合できる点を特長としており、応答性が高く、スケーラブルで、費用対効果の高いエージェント プラットフォームをすぐに構築することができます。

Filestore エージェント ボリュームへのアクセスをご希望の場合は、こちらのフォームをご提出ください。詳細については、Filestore のドキュメントと GKE のドキュメントをご覧ください。

- グループ プロダクト マネージャー、Micah Waldman

- エンジニアリング マネージャー、Maya Gal

Every week, I talk with founders who are building at an unbelievable pace. Teams are moving from inception to product-market fit faster than ever, with foundation models wired deeply into their core product workflows.

Yet as startup architectures mature, a clear divide has emerged between teams struggling with margins and those scaling sustainably. The most effective engineering teams have abandoned the one-size-fits-all model strategy.

In the early days of LLMs the default architecture was simple: send every interaction to the largest model available. But as applications move into production, serving millions of people and running autonomous multi-agent workflows, relying on a single frontier model starts to strain in three places:

• Latency penalties: Relying entirely on cloud round trips makes it difficult to deliver the sub-second responsiveness that interactive mobile and desktop apps require.

• Infrastructure overhead: Self-hosting large open models with more than 70 billion parameters forces early-stage teams to act like infrastructure providers, pulling senior engineers on cluster provisioning and multi-GPU orchestration.

• Margin erosion: Sending high-frequency, structured tasks (like intent routing, JSON extraction, or status validation) to general-purpose frontier endpoints spends capital that could be funding product differentiation.

Great engineering teams pick the right tool for each job. Most production requests don’t require a frontier generalist, and routing every call to one can actually slow your product down. Instead, the winning pattern is a compound AI stack: pairing frontier models for complex synthesis with compact, open-weight models that you can tune, control, and run anywhere. 

It’s for these reasons that an open model like Gemma belongs in your model lineup. With more than one billion downloads across the developer community, Gemma 4 is our most capable open model family to date, using the same foundational research and technology behind the Gemini models.

Built under one roof

Gemma is built by Google DeepMind using the same foundational research and architecture advances behind the Gemini models. Because they share common DNA and developer tooling, your team can prototype in Google AI Studio and design hybrid architectures where Gemini and Gemma work together.

Released under a commercially permissive Apache 2.0 license, Gemma 4 is engineered for parameter and token efficiency. Rather than forcing a single model architecture onto every hardware target, Gemma 4 spans five sizes across four specialized architectures: compact E2B and E4B models with native audio and vision for mobile and edge devices; an encoder-free 12B Unified multimodal model; a 26B A4B Mixture-of-Experts (MoE) model that activates only 4B parameters per token for high-throughput serving; and a dense 31B model that fits on a single GPU for maximum reasoning quality and fine-tuning. Every model includes configurable thinking modes, native function calling, up to 256K context, and built-in Multi-Token Prediction (MTP) draft models for speculative decoding. 

Real proof: How startups are winning with Gemma

Founders are using Gemma to solve urgent problems around unit economics, output accuracy, and responsiveness.

• Flipping the architecture: Cue is a voice-activated desktop assistant that runs natively on a user's machine to automate everyday tasks. They integrated Gemma 4 E4B via Ollama on local hardware to handle real-time transcript formatting. While they originally planned for Gemma to be a weak offline fallback, benchmarking proved it was so fast and precise that they made it their default engine—driving a 44% latency drop (from 876 ms to 488 ms).

• True edge independence: Mobile development studio HubX built BetterSpeak, a voice-based interactive mobile English-learning tutor that simulates immersive, real-time voice conversations. To bypass cellular network lag and avoid charging users expensive subscription fees to cover cloud hosting, they packaged a 4-bit quantized Gemma 4 E2B model (~2.9 GB) natively on-device. The result is an offline, speech-to-speech mobile tutor that costs them $0 in server bills.

• Scientific discovery and air-gapped security: K-Dense has built Faraday, an AI-powered scientific collaborator optimized end-to-end across hardware, software, and sensor suites, powered by Gemma 4 together with K-Dense's Scientific Agent Skills. Faraday runs fully air-gapped, making it suitable for secure, proprietary scientific work in pharma and biotech. Deployed on an NVIDIA DGX Spark, Gemma 4 can also be fine-tuned locally on a user's own proprietary datasets.

• Unlocking infinite gameplay and retention: Gaming company Latitude integrated Gemma across their AI-native game products. By swapping in Gemma for AI Dungeon, they significantly improved player retention, while their new AI RPG platform Voyage leverages Gemma to deliver high intelligence at a cost that enables unlimited user gameplay with ultra-fast latency.

Four workloads where Gemma wins for startups

If you’re evaluating where Gemma fits into your stack today, start with these four jobs:

1. Edge and local execution (low latency, true privacy)

If you’re building mobile apps, developer desktop tools, robotics, or offline-first experiences, every cloud round-trip adds latency that people can feel. Gemma can run directly on laptops (including Apple silicon), smartphones, and local appliances. Your users get immediate feedback, and sensitive data never has to leave their device.

You can handle many local interactions on-device for zero incremental cost, and keep a bridge to frontier models in the cloud for the requests that need it. When a local workflow calls for large-scale multimodal reasoning, long-context data synthesis, or complex planning, your application can route that specific request to Gemini.

2. High-throughput triage and agent routing

In multi-agent architectures, agents spend a surprising amount of tokens on simple tasks like checking statuses, classifying intent, and routing tickets. With Gemma as your front-line gatekeeper, those high-volume background tasks run on a compact model and your team can save frontier reasoning for the requests where it creates product value.

3. Task-specific fine-tuning for real moats

Adapting a model to your proprietary data is one way to build a competitive moat. Because Gemma gives you full access to model weights and has a compact memory footprint, your team can run parameter-efficient fine-tuning (LoRA or QLoRA) on a single GPU in hours rather than days.

4. Turnkey vertical starting lines

DeepMind releases domain-specific variants of Gemma, so you don’t have to start from scratch. One example is MedGemma. MedGemma scores 87.7% on the MedQA benchmark, matching the clinical accuracy of frontier models at roughly one-tenth the inference cost. In a blind clinical study, board-certified radiologists judged that 81% of chest X-ray reports generated by the lightweight MedGemma 1.5 4B were accurate enough to result in equivalent patient management compared to reports written by human experts.

Beyond healthcare, biotech startups use C2S Scale to model virtual cellular responses and accelerate oncology research. Meanwhile, DataGemma cross-references more than 240 billion public data points to help reduce numerical hallucinations. If you’re operating in a specialized market, starting with a model that already speaks your industry's language can save you engineering time and compute budget.

Deploy wherever your business lives

Gemma is designed to fit into your existing engineering stack without lock-in:

• Apache 2.0 licensing: Gemma 4 ships under the Apache 2.0 license, giving startups the freedom to fine-tune, quantize, redistribute, and deploy commercial products on-premises or at the edge with full ownership of their custom weights.

• Day-zero open tooling: Run and fine-tune Gemma with the tools your engineers already use, including vLLM, Ollama, llama.cpp, LM Studio, MLX, Unsloth, Hugging Face, Kaggle, Keras, PyTorch, JAX, and LiteRT-LM.

• Serverless and managed cloud deployment: Prototype immediately in Google AI Studio, scale to zero on serverless GPUs with Cloud Run, or deploy dedicated endpoints from Model Garden on Gemini Enterprise Agent Platform when traffic surges and you don’t want to manage GPU clusters.

• Enterprise-ready safety: Gemma undergoes rigorous pre-release safety evaluations, data filtering, and red-teaming, and pairs with ShieldGemma 2 to help you meet enterprise compliance requirements.

Build with Gemma: What to do this week

Great technical architecture isn't about finding one model to do everything. It’s about assembling the right tool for each job so you can move faster, protect your runway, and ship a superior product.

Here’s my challenge to your engineering team this week:

1. Audit your model calls: Look at your logging dashboard and identify three high-volume, deterministic tasks (such as intent classification, JSON validation, or summarization) currently running on your most expensive models.

2. Benchmark Gemma: Run a quick test with a compact Gemma model locally or on a single endpoint. Measure the latency and calculate what happens to your gross margins when that workload runs with lower inference cost.

3. Redirect your runway: Take the capital and engineering hours you save on compute and invest them back into your core differentiators.

You can download the Gemma weights directly or deploy them through Model Garden. If you need compute credits and technical architecture reviews to get up and running, the Google for Startups team is ready to help you build - learn more.