The Email That Changes Everything

Imagine your AI assistant — the one that summarizes your inbox, reminds you of meetings, and knows your preferences — suddenly believing something that never happened. A single email can make that happen. No malware, no password theft, just a carefully crafted message that rewrites what the assistant thinks it knows about you.

Researchers have demonstrated a new attack vector they call MemGhost. It targets the memory systems embedded in modern large language model (LLM) agents. These systems let AI retain information across sessions, making them feel personal and useful. But that same convenience becomes a weapon when an attacker sends one email.

The attack plants a persistent false memory. The user sees a routine reply in their inbox. They never realize their assistant has been quietly reprogrammed.

How MemGhost Works: A Single Email Injects a Lie

The technique exploits how AI agents process and store information from email. Most assistants have permission to read your messages — it’s how they summarize threads, extract action items, or remind you of deadlines. MemGhost turns that feature into a flaw.

An attacker sends an email that appears normal. Inside, it contains hidden instructions or context designed to be ingested by the AI’s memory system. The agent reads it, extracts a fabricated “fact” — say, that the user changed their bank account number or has a new dietary restriction — and stores it as truth. From that point forward, every answer the assistant gives is subtly poisoned by that false datum.

The researchers behind MemGhost showed that the false memory persists across sessions. Even if the user deletes the original email, the stored memory remains. The AI doesn’t double-check. It trusts its memory, just as you trust yours.

Why Persistent Memory Makes AI Vulnerable

Memory is what separates a useful assistant from a forgetful chatbot. Products like OpenAI‘s ChatGPT with memory, Google Gemini’s recall features, and Microsoft Copilot’s context retention all rely on persistent storage. They remember your name, your projects, your preferences. That’s powerful. But it’s also a single point of failure.

In a traditional computer system, memory is protected by access controls. If someone wants to change a file, they need permission. In an AI agent, memory is written by inference. The agent reads text, decides what’s important, and saves it. There’s often no verification step. The system trusts the input because it trusts the user’s data stream.

MemGhost weaponizes that trust. The attacker doesn’t need to hack the AI. They just need to send an email the AI will read. For anyone using an AI assistant connected to their inbox — and millions do — the attack surface is wide open.

Real-World Scenarios: From Annoying to Dangerous

The consequences vary depending on the false memory injected. At the nuisance level, an attacker could make the assistant believe you hate a certain restaurant, causing it to never suggest that option again. Annoying, but not catastrophic.

Things escalate quickly. Imagine a false memory that your work project deadline was moved up by two weeks. The assistant starts sending you urgent reminders, stressing you out, causing you to reprioritize incorrectly. Or a memory that you authorized a payment to a specific vendor. The assistant might prompt you to finalize that transaction, thinking it’s following your instructions.

In enterprise settings, where AI agents manage calendars, draft emails, and handle customer data, a single planted memory could steer a business decision. An attacker could make the assistant believe a competitor’s proposal was approved, or that a key contact changed their email address — redirecting sensitive communications.

The attack is silent. The user reads an ordinary-looking reply and never learns their assistant was tampered with.

Can You Protect Against Memory Poisoning?

There’s no easy patch. The vulnerability is architectural: memory systems are designed to be helpful, not paranoid. But there are steps users and developers can take right now.

For users, the simplest defense is to review what your AI assistant remembers. Most platforms let you view and delete stored memories. Make it a habit to check, especially after reading emails from unknown senders. If you use an AI assistant connected to your inbox, ask yourself: do I really need that integration? Consider using a dedicated email client for sensitive accounts, separate from your AI tools.

For developers, the fix is harder. Memory systems need validation layers. Before storing a new fact, the AI should cross-reference it with existing data. If the new memory contradicts something already stored, flag it. Better yet, don’t let AI automatically write memories from email at all. Require explicit user confirmation for any memory that changes a critical fact — like financial details, contact information, or schedule changes.

The researchers suggest implementing a “memory quarantine” for incoming data. Treat email-derived memories as suspect until the user approves them. It adds friction, but it’s better than a poisoned assistant.

Some platforms already offer memory management features. For example, you can check how to delete ChatGPT memory and start fresh. But that’s a reactive fix, not a preventive one.

The Bigger Picture: Trust in AI Needs a Rethink

MemGhost is not a hypothetical. It’s a working exploit demonstrated in a lab. The researchers published their findings to push the industry toward better memory security. The question is whether companies will listen before a real-world attack causes real damage.

We’re racing toward a future where AI agents handle more of our digital lives — reading our messages, managing our calendars, even making purchases on our behalf. That future is exciting. But it’s also fragile. Every new capability introduces a new way to be tricked.

The lesson from MemGhost is simple: if your AI remembers everything, make sure it remembers the right things. Because one email is all it takes to rewrite what your assistant thinks it knows about you. And you might never find out.

Google Rushes Out Chrome 150 to Close Seven Memory Safety Holes

Google has shipped a fresh security update for its Chrome browser, version 150, addressing a cluster of seven memory safety bugs. Among them are three critical-severity use-after-free vulnerabilities — the kind attackers love to weaponize.

The update lands as versions 150.0.7871.128/.129 for Windows and macOS, and 150.0.7871.128 for Linux. Users on all platforms should grab it now.

Critical Flaws Found in CameraCapture, GPU, and Network Components

Three of the most dangerous bugs are use-after-free issues in Chrome’s CameraCapture, GPU, and Network subsystems. All carry a critical severity rating. Google’s own security team discovered each of them.

Use-after-free flaws are a classic memory corruption pattern. They occur when a program continues to use a pointer after the associated memory has been freed. An attacker can exploit that dangling reference to execute arbitrary code, crash the browser, or steal data.

Google has been hammering away at this class of bug for years. The company has invested heavily in memory-safe languages like Rust and in compiler hardening to reduce the attack surface. Still, these vulnerabilities keep cropping up.

High-Severity Use-After-Free Bugs in Cast, Ozone, and Aura

Beyond the critical trio, the Chrome 150 update also fixes three high-severity use-after-free flaws. They live in the Cast, Ozone, and Aura components. Again, Google’s internal researchers found them.

Cast handles media streaming to Chromecast devices. Ozone is the abstraction layer for windowing systems on Linux and ChromeOS. Aura is the desktop window manager that draws the browser chrome itself. A bug in any of these could give an attacker a foothold.

V8 Engine Bug Found by OpenAI Codex Security

The seventh vulnerability is different. It’s an out-of-bounds read and write flaw in Chrome’s V8 JavaScript engine. And it wasn’t found by Google — it was discovered by OpenAI Codex Security, the AI-driven code analysis platform.

Out-of-bounds bugs let an attacker read or write memory beyond the allocated buffer. That’s a classic stepping stone to code execution. Google says it hasn’t yet determined the bug bounty payout for this finding.

OpenAI Codex Security is part of a growing trend: using large language models to audit source code for vulnerabilities. The results so far are mixed, but this discovery suggests the approach is starting to pay off.

No Signs of Active Exploitation — But Don’t Wait

Google’s advisory makes no mention of any of these bugs being exploited in the wild. That’s the good news. The bad news: memory safety bugs in Chrome have been a favorite target for attackers, including state-sponsored groups. Exploit code for similar flaws often appears within days of a patch.

The company has patched over 1,400 Chrome vulnerabilities since April, hundreds of them memory safety issues. Many were found by Google itself, likely through automated fuzzing and AI-assisted scanning. That volume underscores just how hard it is to write safe C++ code at Chrome’s scale.

For a deeper dive into recent browser security trends, check out our coverage of the critical vulnerabilities patched in Chrome 150 and Firefox 152.

How to Update Your Browser

Chrome updates roll out automatically in the background. But you can force the update to get the fix immediately:

• Click the three-dot menu in the top-right corner.
• Go to Help > About Google Chrome.
• Chrome will check for updates and install the latest version.
• Click Relaunch to complete the process.

After the update, your browser should report version 150.0.7871.128 or later. If you’re an IT admin managing Chrome across an organization, deploy the update via Group Policy or your MDM tool as soon as possible.

Memory safety bugs aren’t going away. But with each update, Google chips away at the problem. The Chrome 150 patch is the latest reminder: update early, update often.

For more on how memory safety vulnerabilities are being exploited in the real world, read our report on WP2Shell WordPress vulnerabilities exploited in the wild.

The Slip That Unraveled a Phishing Empire

It started with a simple oversight. A Python web server, left listening on a public port with directory listing enabled. The command python3 -m http.server 8080 was still sitting in the readable .bash_history.

That one mistake gave French security firm Lexfo a window into a live Microsoft 365 phishing operation. And from that single lapse, they didn’t just lift the operator’s entire toolkit. They pivoted through it to uncover two more.

How a .bash_history File Blew the Cover

Attackers running Evilginx — a popular reverse-proxy phishing framework — usually cover their tracks. They hide servers behind VPNs, rotate domains, and scrub logs. But this operator got sloppy.

The exposed server was running on port 8080, completely open. Directory listing was on. That meant anyone could browse the file system. Lexfo found the .bash_history file, which contained not just the server command but also paths to phishing kits, configuration files, and session data.

From there, they extracted the full toolkit: custom templates mimicking Microsoft 365 login pages, redirect scripts, and harvested credential logs. The operator had been running campaigns targeting enterprise users across multiple industries.

The First Phishing Ring: Live and Active

The first operation was still active when Lexfo found it. It used Evilginx to intercept login credentials and session cookies from Microsoft 365 users. Victims landed on a near-perfect replica of the Microsoft login page. Once they entered their details, the attacker grabbed everything — username, password, and the session token — then redirected them to the real Microsoft site.

This gave the attacker persistent access. Even if the victim changed their password later, the session cookie remained valid until it expired. That’s the core danger of Evilginx: it bypasses multi-factor authentication by stealing the session itself.

Pivoting to Two More Operations

Lexfo didn’t stop at the first server. Using credentials and infrastructure details found in the exposed files, they traced connections to two more Evilginx phishing operations. These were separate rings, likely run by different operators, but they shared some infrastructure — possibly a common hosting provider or a resold server.

The second ring targeted Microsoft 365 users in the financial sector. The third went after healthcare organizations. Both used similar Evilginx templates, suggesting either a shared source code repository or a commercial relationship between the attackers.

Lexfo declined to name the hosting provider publicly but said they reported all findings to relevant authorities and Microsoft’s security team.

Why Evilginx Is So Dangerous for Microsoft 365

Evilginx is not your average phishing kit. It’s a reverse proxy that sits between the victim and the real login page. The victim interacts with the real Microsoft 365 interface — they see the real branding, the real URL (with a slight twist), and even real MFA prompts. The attacker just copies everything in transit.

This makes it incredibly hard to detect. Traditional security training tells users to check the URL. But Evilginx uses domains that look legitimate, like login-microsoft.com or microsoft-365.secure-login.net. Even savvy users can fall for it.

Microsoft 365 is the prime target because it’s the backbone of corporate communication and data. One compromised account can lead to email theft, data exfiltration, and lateral movement inside a company network.

Lessons from the Misconfiguration

This case is a reminder that attackers are only as strong as their operational security. A single open port, a forgotten history file, and the whole house of cards falls.

For defenders, it’s a lesson in proactive monitoring. Lexfo found the server by scanning for exposed services. That’s something any security team can do — regularly check for unintended public exposure, especially on non-standard ports.

For organizations using Microsoft 365, the takeaway is clear: session-based attacks bypass MFA. You need additional layers — like conditional access policies, device compliance checks, and user behavior analytics — to catch anomalies even after login.

The three rings are likely still active, just on different servers now. But the exposure of their tools and methods gives defenders a rare advantage: they know exactly what to look for.

Lexfo has published a detailed technical report with indicators of compromise. Security teams should grab it and check their logs. The attackers made one mistake. It’s up to the good guys to make sure it counts.