A vulnerability in Google Gemini’s Android integration allowed malicious content embedded in notifications from apps such as WhatsApp, Slack, Signal, and SMS to hijack the AI assistant without requiring any installed malware. An attacker could craft a poisoned notification that caused Gemini to open browser windows, impersonate contacts, initiate calls, or corrupt the assistant’s long-term memory. This is a prompt injection attack exploiting the trust Gemini places in notification content it processes.

Architect’s Take: Organisations deploying Android devices with Gemini enabled should review mobile device management (MDM) policies to restrict AI assistant access to sensitive notification streams, and treat AI assistants as untrusted data processors when designing data-handling workflows. Raise awareness with security teams about prompt injection as a realistic attack vector on enterprise mobile estates.

Original advisory: WhatsApp, Slack Notifications Could Hijack Google Gemini on Android

A prompt injection vulnerability in Google Gemini on Android allowed hostile content embedded in notifications from apps such as WhatsApp, Slack, Signal, and SMS to hijack the AI assistant without requiring any malicious app to be installed. An attacker could craft a poisoned message or notification that caused Gemini to perform unauthorised actions — including impersonating contacts, initiating calls, or corrupting its long-term memory. The attack required no user interaction beyond the assistant processing the notification, making it particularly dangerous for enterprise users relying on AI-assisted workflows.

Architect’s Take: Review your organisation’s mobile device management (MDM) policies to restrict or audit Gemini’s access to third-party app notifications, particularly on corporate Android devices. Until Google confirms a fully patched release, consider disabling Gemini’s notification-reading capabilities via app permissions and assess whether AI assistant integrations meet your acceptable risk threshold for enterprise use.

Original advisory: WhatsApp, Slack Notifications Could Hijack Google Gemini on Android

A critical remote code execution vulnerability (CVE-2026-23479) in Redis, introduced in version 7.2.0 over two years ago, has been patched following discovery by an autonomous AI-powered bug-hunting tool. The flaw is a use-after-free bug in Redis’s blocking-client handling code, allowing any authenticated user to execute arbitrary operating system commands on the host server. This is significant because Redis is widely deployed across cloud environments as a caching and data store layer, meaning exposure could lead to full host compromise.

Architect’s Take: Prioritise patching all Redis instances to the May 5 fixed release immediately, paying particular attention to managed Redis services (AWS ElastiCache, Azure Cache for Redis, GCP Memorystore) and self-hosted deployments — check with your vendors for patch availability. In the interim, enforce network segmentation and strict authentication controls to limit which services and users can reach Redis endpoints, reducing the authenticated-user attack surface.

Original advisory: Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (CVE-2026-23479)

Attackers are exploiting Google’s DoubleClick ad-serving domain as a redirect hop in malicious email campaigns, using its trusted reputation to bypass security filters before delivering the DesckVB remote access trojan. Because many email and web security tools whitelist or deprioritise scrutiny of well-known Google-owned domains, the technique significantly increases the likelihood of successful delivery. Once installed, a RAT gives attackers persistent remote control over the victim’s machine.

Architect’s Take: Review your email and web proxy security policies to ensure that redirects through trusted domains — including Google-owned properties like DoubleClick — are still subject to full URL chain inspection and sandbox detonation. Consider enforcing policies that follow and evaluate the final destination URL rather than trusting the initial domain at face value.

Original advisory: Google DoubleClick Abused in New Malspam Campaign to Deliver DesckVB RAT

Attackers are exploiting Google’s DoubleClick ad-serving domain as a redirect layer in malicious spam emails, using its trusted reputation to bypass security filtering tools before routing victims to attacker-controlled infrastructure that delivers the DesckVB remote access trojan. Because DoubleClick is a widely trusted Google domain, many email and web security products will not flag the initial link as suspicious. This technique is a growing trend of abusing legitimate cloud services to obscure the early stages of an attack chain.

Architect’s Take: Review your email and web proxy security controls to ensure they inspect the full redirect chain rather than trusting links solely based on the root domain — allowlisting DoubleClick or similar Google domains without inspecting downstream redirects creates a blind spot. Consider enforcing URL rewriting and sandboxed link-following in your email security gateway, and ensure endpoint detection controls are tuned to flag RAT behaviour post-delivery.

Original advisory: Google DoubleClick Abused in New Malspam Campaign to Deliver DesckVB RAT