Cyber Kendra

Drupal Patches Highly Critical SQL Injection That Lets Anonymous Attackers Hijack PostgreSQL-Backed Sites

protalweb@gmail.com (Vivek Gurung) — Thu, 21 May 2026 00:29:13 +0530

Drupal has pushed emergency security updates for a highly critical SQL injection vulnerability in its core database abstraction layer — the kind of flaw that lets an unauthenticated attacker walk straight into your database without needing a username or password.

The vulnerability, tracked as CVE-2026-9082 and disclosed under advisory SA-CORE-2026-004, scores 20 out of 25 on Drupal's risk scale. That "Highly Critical" rating isn't an exaggeration: the scoring breakdown shows zero access complexity, no authentication required, and full confidentiality and integrity impact — meaning an attacker can read everything and modify anything.

What's broken and why

Drupal's database abstraction API is supposed to act as a safety net — a layer between PHP code and the database that automatically sanitizes queries to block injection attacks. But a flaw in this API allows specially crafted HTTP requests to slip past that sanitization entirely, enabling arbitrary SQL to execute directly against the database.

The vulnerability only affects sites running PostgreSQL databases, not MySQL or MariaDB backends. That's a narrowing factor, but PostgreSQL is common among enterprise Drupal deployments — government portals, university sites, and large media organizations frequently run it for performance and compliance reasons.

The consequences of successful exploitation range from data exfiltration (leaking user records, private content, credentials) to privilege escalation and, in some configurations, remote code execution — full server takeover.

Broader blast radius: Symfony and Twig

The patches do more than fix the SQL injection. The releases for all supported branches also bundle upstream security updates for Symfony and Twig, two PHP libraries that Drupal depends on heavily.

Drupal's advisory explicitly warns that depending on your site's configuration and installed modules, you may be independently vulnerable to those upstream issues — even if PostgreSQL isn't in the picture. All sites should update regardless.

The advisory specifically recommends reviewing which user roles have the ability to update Twig templates, for example through Views or contributed modules — a Twig template injection path could compound the risk significantly.

Who is affected and what to do

Every supported Drupal branch is in scope: Drupal 10.4 through 11.3. The Drupal Security Team went further and issued best-effort patches for end-of-life Drupal 8 and 9 installations, acknowledging the severity warrants the exception — though those patches come without guarantees and those sites remain exposed to prior unpatched vulnerabilities.

Patched versions are:

Drupal 11: 11.3.10, 11.2.12, 11.1.10
Drupal 10: 10.6.9, 10.5.10, 10.4.10

Sites using Drupal Steward (Drupal's WAF-based protection service) are already shielded from known attack vectors, but should still upgrade promptly in case additional exploitation paths surface.

Two days before release, the Drupal Security Team issued an advance public notice — rare, and a signal of how seriously they treated this. The team explicitly warned that "exploits might be developed within hours or days" of the advisory going public, urging administrators to reserve time the same day patches dropped.

If your Drupal site runs PostgreSQL and hasn't been updated yet, that window is closing fast. Update now.

PinTheft: New Linux Exploit Steals Kernel References to Root Shell

protalweb@gmail.com (Vivek Gurung) — Wed, 20 May 2026 23:38:04 +0530

A working proof-of-concept exploit for a new Linux kernel privilege escalation bug called PinTheft went public this week, adding another name to a growing list of kernel-level root escalations that have shaken the Linux security community throughout early 2026.

Discovered by Aaron Esau of the V12 security team, PinTheft allows a local attacker to gain root access by exploiting an RDS (Reliable Datagram Sockets) zerocopy double-free bug. A kernel patch is already available — V12 released their PoC only after confirming independent discovery by other teams and verifying the fix landed upstream.

What Makes This One Different

The bug itself lives in a corner of the kernel most people rarely think about: the RDS zerocopy send path, specifically in rds_message_zcopy_from_user(), which pins user memory pages into kernel space one at a time. If a later page triggers a fault, the error path drops the already-pinned pages — but later RDS message cleanup drops them a second time, because the scatterlist bookkeeping stays live even after the zcopy notifier is cleared. Each failed zerocopy send steals exactly one memory reference from the first page.

On its own, a reference count bug like this is difficult to turn into a useful primitive. PinTheft's real cleverness is what it does next.

To weaponize the reference count bug, the exploit leverages io_uring. The attacker registers an anonymous memory page as an io_uring fixed buffer, assigning it a FOLL_PIN bias of 1024 references — then systematically drains those references through 1024 deliberately failing RDS sends, until io_uring is left holding a pointer to a page it no longer legitimately owns.

From there, the exploit evicts the target SUID binary's first page from cache, reclaims that same physical page, and uses io_uring's now-dangling buffer pointer to overwrite the page cache of a privileged binary — /usr/bin/su, passwd, or pkexec are preferred targets — with a small custom ELF payload. Run the binary, get a root shell.

Who's Actually at Risk

Beyond having the RDS module loaded, PinTheft also requires io_uring to be enabled, a readable SUID-root binary to be present, and an x86_64 system. The required RDS module is only default on Arch Linux among common distributions tested — other major distributions do not load it out of the box.

That limits the immediate blast radius. But the conditions aren't exotic on systems where administrators have enabled RDS for workloads that use it, or on containers and CI runners where kernel modules may be more permissive.

A Pattern That Isn't Slowing Down

PinTheft follows a wave of other Linux local privilege escalation vulnerabilities disclosed over the past several weeks — DirtyDecrypt, DirtyCBC, Dirty Frag, Fragnesia, and CopyFail — all belonging to the same broad vulnerability class of page-cache overwrite exploits. Threat actors have already begun actively exploiting CopyFail in the wild. Each new PoC in this series raises the question of how many similar bugs remain undiscovered in the kernel's networking and asynchronous I/O subsystems.

What to Do Now

The straightforward mitigation is to remove RDS entirely if nothing on your system actually needs it:

rmmod rds_tcp rds
printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf

Apply your distribution's kernel update as soon as it incorporates the upstream patch. If you're running Arch Linux, that should be your first call this week. For everyone else: check whether CONFIG_RDS is enabled in your running kernel before assuming you're clear.

The V12 team also warns that the exploit temporarily corrupts the target SUID binary's page cache in memory. Before running on any test system, the PoC backs up the target binary and prints a restore command — but don't skip the reboot on anything that matters.

PostgreSQL Patches 11 Security Flaws, Including Code Execution and a Sneaky Password-Stealing Timing Attack

protalweb@gmail.com (Vivek Gurung) — Wed, 20 May 2026 23:11:11 +0530

The world's most popular open-source database just dropped its biggest security update of the year — and if you haven't patched yet, attackers may already be eyeing your stack.

The PostgreSQL Global Development Group shipped simultaneous security updates across every supported major version — 18.4, 17.10, 16.14, 15.18, and 14.23 — fixing 11 CVEs (Common Vulnerabilities and Exposures) and more than 60 additional bugs. Three of those CVEs carry a CVSS score of 8.8 out of 10, meaning they're rated "high severity" and exploitable by a low-privilege remote attacker with minimal friction.

The Flaws That Matter Most

The headline vulnerability is CVE-2026-6637, a stack buffer overflow buried inside PostgreSQL's refint contrib module — a built-in tool for enforcing referential integrity between tables. Any unprivileged database user can craft input to trigger the overflow and run arbitrary code as the operating system user running the database. That's a full server compromise from a regular user account.

Equally alarming is CVE-2026-6473: integer wraparound across multiple PostgreSQL server features lets an attacker force the server to allocate undersized memory blocks, then write beyond their boundaries — leading to segmentation faults and, in the worst case, memory corruption. Ten independent security researchers reported this one, which is a signal that it was being actively probed.

Then there's a subtler threat: CVE-2026-6478, a covert timing channel in how PostgreSQL compares MD5-hashed passwords during authentication. An attacker can measure the tiny time differences in password comparisons to reconstruct valid credentials — without ever getting a login error. The catch: this only affects databases that still use MD5 passwords, a legacy format inherited from upgrades from PostgreSQL 13 or earlier. The current default, scram-sha-256, is immune. If you're on an upgraded cluster, check your pg_authid table.

Logical Replication and Symlink Tricks

Two more vulnerabilities deserve attention for production deployments. CVE-2026-6638 allows SQL injection via the ALTER SUBSCRIPTION ... REFRESH PUBLICATION command, giving a subscriber table creator the ability to execute arbitrary SQL using the publication side's credentials — a serious risk for anyone running logical replication (a method of selectively streaming database changes between servers) across trust boundaries.

Meanwhile, CVE-2026-6475 exploits symlink following in pg_basebackup and pg_rewind, letting a superuser on the origin server overwrite sensitive OS-level files — such as .bashrc — on the backup target, potentially hijacking the operating system account during failover operations.

What You Should Do Right Now

The update process is straightforward: no database dump or schema migration is required. Stop PostgreSQL, replace the binaries, restart. That's it.

Linux (Debian/Ubuntu): sudo apt update && sudo apt install postgresql-17
RHEL/Fedora: sudo dnf update postgresql
macOS (Homebrew): brew upgrade postgresql@17

For managed cloud databases (AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL), minor version patches roll out during maintenance windows. Log into your console now and verify you're on the patched release — or trigger a manual upgrade if your provider supports it.

This update also serves as a final warning shot for teams running PostgreSQL 14: the version reaches end-of-life on November 12, 2026, after which it will receive no further security fixes. Version 14.23 is the last patch you'll see. If production workloads are still on 14, treat this upgrade cycle as the deadline to migrate to PostgreSQL 16 or 17.

PostgreSQL powers infrastructure at companies ranging from Apple and Instagram to the majority of cloud-native SaaS platforms. A database this deeply embedded in the internet's plumbing is exactly the kind of target that threat actors monitor closely. The 60+ bug fixes bundled alongside these CVEs make patching a double win — security and stability in a single restart.

GitHub's Own Codebase Was Breached — A Poisoned VS Code Extension Was All It Took

protalweb@gmail.com (Vivek Gurung) — Wed, 20 May 2026 22:29:15 +0530

The world's largest code-hosting platform just became the victim of its own ecosystem. On May 20, 2026, GitHub confirmed that a threat actor exfiltrated roughly 3,800 of its internal repositories — not through some sophisticated platform zero-day, but by slipping malware into a Visual Studio Code extension and waiting for a GitHub employee to install it.

The attack was claimed by TeamPCP, a cybercrime group that has spent 2026 methodically dismantling developer trust across the open-source supply chain. The group posted the stolen data on the Breached cybercrime forum with a $50,000 asking price, threatening to leak everything publicly if no single buyer steps forward.

GitHub's response moved fast. The company said it identified and contained the breach after the poisoned VS Code extension compromised an employee's endpoint. The affected device was isolated, the malicious extension version was pulled, and critical credentials were rotated overnight with the highest-impact secrets prioritized first.

GitHub's current assessment is that only internal repositories were exfiltrated, and the attacker's claims of roughly 3,800 repositories are directionally consistent with what the company's investigation has found so far.

There is, as of now, no evidence that customer repositories, enterprise accounts, or user data were touched — though the investigation remains active.

The mechanics of the attack are deceptively simple. A developer installs what looks like a legitimate VS Code extension — the kind millions of engineers add to their editors without a second thought. The extension is poisoned: it silently compromises the host machine and gives attackers access to whatever that user can reach. For a GitHub employee, that foothold touched thousands of internal repositories.

The TeamPCP group achieved a series of compromises by deploying Mini Shai-Hulud, their adapted version of a self-replicating worm first documented in 2025, which largely automates supply chain attacks by stealing CI/CD credentials and using them to publish infected versions of further packages.

The campaign has affected over 170 packages spanning both npm and PyPI, with more than 518 million cumulative downloads. Earlier in May alone, the group published trojanized versions of Microsoft's official Durable Task Python SDK to PyPI. The malware payload skips systems with a Russian locale — a consistent hallmark of Eastern European cybercrime operations.

Security researchers warn that even limited access to internal repositories could expose operational tooling, internal APIs, authentication workflows, or infrastructure configurations useful for future attacks.

Cybernews researchers noted that exposed source code increases the risk of finding fresh vulnerabilities, particularly in GitHub's integrations with tools like Copilot — even after credentials have been rotated. The breach also arrived shortly after the April 28 disclosure of CVE-2026-3854, a critical GitHub vulnerability that allowed authenticated users to execute arbitrary commands on GitHub servers.

GitHub says a fuller report will be published once the investigation concludes. In the meantime, security teams are urging developers to immediately rotate any API keys or secrets stored in private repositories, audit all IDE extensions and remove anything unverified, and treat their build pipelines as production-grade attack surfaces. When the platform that hosts the world's code gets hit through a developer's own toolchain, the lesson lands for everyone.

Google I/O 2026 — Here's Everything Google Announced

protalweb@gmail.com (Vivek Gurung) — Wed, 20 May 2026 00:28:57 +0530

Google doesn't do small announcements anymore. At I/O 2026 in Mountain View, the company dropped more new products in a single two-hour keynote than most companies release in a year — and a significant chunk of them are already live. The thread running through all of it: Gemini is no longer a chatbot. It's becoming the operating layer of everything Google makes.

Sundar Pichai opened with a scale check that few companies on earth could match. Two years ago, Google was processing 9.7 trillion tokens a month. Last year that climbed to roughly 480 trillion. Today the number is over 3.2 quadrillion per month — a 7x jump in a single year — with over 8.5 million developers now building with Google's models monthly. That trajectory is the context for everything announced on stage.

Gemini Spark: Your First Real AI Agent

Gemini Spark is described as "your personal agent" that takes actions on your behalf to help "navigate your digital life." Google calls it a big shift — transforming Gemini from an assistant that answers questions into an active partner that does real work under your direction. It integrates with Gmail, Docs, and other Google Workspace apps first, before expanding to third-party tools via MCP over the summer.

Spark runs on private Google Cloud servers in the background and keeps working even when you're not actively using your phone. The live demo showed it planning a block party — creating an RSVP tracker in Google Sheets, auto-updating Docs, and sending follow-up email reminders to people who hadn't responded.

You can work with Spark however is most convenient: in the Gemini app, or soon through email and chat. Later this summer, Spark will also operate directly within Chrome, acting as your agentic browser assistant. The beta rolls out to Google AI Ultra subscribers in the US next week.

Android Halo: The Status Bar That Knows What Your Agent Is Doing

Android Halo provides at-a-glance visibility into what your agent is working on at any given time, with subtle communication at the top of your phone screen — meaning you can see an agent's progress without having to stop what you're doing or switch apps.

The only visual cue shown so far is a glowing circle morphing into the Gemini sparkle in the upper-left corner of a Pixel phone's status bar. It's coming in Android 17, with more details expected later this year when new Pixel hardware arrives.

Search Gets Its Biggest Upgrade in Nearly 30 Years

By combining with Gemini Spark, questions you ask in Search can now be agentic — instead of returning a snapshot of information at that moment, Search can give you ongoing updates in the future. Searching is now an AI function, not just a text input.

Google is also combining AI Overviews and AI Mode into a more unified experience, letting users move seamlessly between traditional results, AI-generated answers, and follow-up conversations without losing context. The deeper you go into a conversation, the more relevant links and sources become. The updated experience is rolling out globally today.

Gemini 3.5 Flash and Omni: The Engine Room

Gemini 3.5 Flash is better across all benchmarks than the previous Gemini 3.1 Pro, has made significant progress in coding, and is four times faster than other frontier models in terms of output tokens per second.

Gemini Omni is a new series of models that combines Gemini's reasoning with creation — accepting image, audio, video, and text as input and generating video output grounded in real-world physics and knowledge. Omni Flash is live today for Google AI Plus, Pro, and Ultra subscribers, as well as YouTube Shorts and YouTube Create users at no extra cost.

Antigravity 2.0: Coding by Agent

Antigravity will now use Gemini 3.5 Flash and allow for faster development cycles. At I/O, Google announced a standalone desktop application dubbed Antigravity 2.0 and a new command-line interface for developers who prefer staying in the terminal, along with new Google Cloud standard privacy protections.

The platform now includes native voice support and integrations with Android, Firebase, and Google AI Studio, and is described as "unabashedly agent-first."

CodeMender: The AI That Patches Your Security Holes Automatically

This is the announcement that didn't get nearly enough attention in the keynote recaps. CodeMender is a new AI-powered agent developed by Google DeepMind that takes a comprehensive approach to code security that's both reactive — instantly patching new vulnerabilities — and proactive, rewriting existing code to eliminate entire classes of flaws. Over the six months Google spent building it, CodeMender already upstreamed 72 security fixes to open-source projects, including codebases as large as 4.5 million lines.

The tool was built using Google's learnings from BigSleep and OSS-Fuzz. It relies on Gemini for root cause analysis, after which it produces security patches that are peer-reviewed by specialized "critique agents" before reaching a human reviewer for final sign-off.

CodeMender is now available as a powerful AI security agent through Google's Agent Platform, letting any developer — not just Google's own teams — benefit from autonomous vulnerability detection and patching. Alongside CodeMender, Google also announced a dedicated AI Vulnerability Reward Program with bounties up to $30,000, and Secure AI Framework 2.0, an updated set of industry standards for securing autonomous AI agents.

Google Pics, Stitch, and Pomelli: The Creative Triple Threat

Google Pics is a new image creation tool inside Google Flow that lets you generate images on the fly with AI, all automatically watermarked with SynthID. Stitch lets people create and launch websites using AI, with simple voice inputs to make changes and guide layouts in real time.

Pomelli goes a step further — introducing AI agents that can help you design your brand book and launch a full website, adding new ways to build brand content and entire web presences from scratch. Together, the three tools represent Google's most direct move yet into the territory occupied by Canva, Squarespace, and similar creative platforms.

Universal Cart and the End of Tab-Switching While Shopping

Google has partnered with Amazon, Shopify, and Walmart on a new open standard called the Universal Commerce Protocol, designed to unify digital commerce so AI agents can browse inventories and handle entire purchases without hard-coded integrations for each merchant.

The Universal Cart follows you across Google services, notifying you when items go on sale or come back in stock. In one demo, it flagged that a chosen motherboard and processor were incompatible and recommended a replacement that actually worked — then added everything to the cart automatically. It arrives in the US this summer.

Gemini for Science, Project Genie, and the Long Game

Gemini for Science will bring together powerful AI tools to assist researchers and help scientists model complex concepts, framed as "a force multiplier for human ingenuity to usher in a new age of progress." Project Genie is being connected with nearly 20 years of Google Street View imagery, letting people create new virtual worlds anchored in real locations. These two announcements sit at the edge of the consumer keynote but point to where Google's deepest research bets are heading.

Daily Brief, Ask YouTube, and Docs Live

Daily Brief is a personalized digest that sifts through your Gmail, Calendar, and Tasks to prioritize your day and suggest next steps. It's rolling out today to Google AI Plus, Pro, and Ultra subscribers in the US. Ask YouTube expands more widely this summer, letting you use YouTube search as an AI chatbot that points you to exact timestamps in videos that answer your questions. Docs Live, coming this summer to AI Pro and Ultra subscribers, lets you verbally brain-dump whatever's on your mind — complete with "ums" and mid-sentence changes — and Gemini converts it into a finished, structured document.

The Bigger Bet

Google is looking to spend six times more on AI in 2026 than it did in 2022, with an estimated $190 billion in capital expenditures for the year alone.

That's not hedging. Everything shown at I/O 2026 — from Spark running quietly in the cloud, to CodeMender patching your repositories overnight, to Halo glowing in your status bar — is Google betting that the next platform isn't an operating system or a search box. It's an agent that already knows what you need before you type it.

Microsoft's durabletask Hit by TeamPCP — Your Cloud Keys Were the Target

protalweb@gmail.com (Vivek Gurung) — Tue, 19 May 2026 23:52:33 +0530

TeamPCP has quietly poisoned yet another trusted developer package — and this time the target was sitting inside Microsoft's own toolchain. Three consecutive releases of durabletask (v1.4.1, v1.4.2, and v1.4.3), the official Python client for Microsoft's Durable Task workflow framework, were compromised and loaded with credential-stealing malware — a direct follow-on to the group's hit on guardrails-ai just days earlier.

The Same Worm, A Sharper Payload

Security researchers at Wiz disclosed the compromise, noting that the malicious payload — dubbed rope.pyz — is an evolved version of transformers.pyz, the dropper previously deployed in the guardrails-ai attack on May 11.

The core mission hasn't changed: steal everything and move on. But the durabletask variant is notably more aggressive in where it injects, spreading its hooks across task.py, entities/__init__.py, extensions/__init__.py, and payload/__init__.py — giving it more entry paths than the earlier version. The C2 (command-and-control) server has also shifted from a raw IP address to check.gitservice.com, with a fallback to t.m-kosche.com, and SSL verification is now enabled — a sign the operation is maturing.

What Gets Stolen — And How It Spreads

The worm's credential sweep is comprehensive by design. Once executed on a Linux host, it goes after AWS IAM keys, Azure and GCP service account tokens, Kubernetes service account credentials, HashiCorp Vault tokens, filesystem passwords, and the contents of your shell history files (.bash_history, .zsh_history). If you store credentials in Bitwarden, 1Password, or pass/gopass, the payload attempts to brute-force unlock them using passwords it harvests along the way.

What makes this variant especially dangerous is its lateral movement. After infection, the worm actively scans for AWS SSM-reachable instances (Amazon's remote management service) and Kubernetes clusters, then propagates itself to up to five additional targets per compromised host. In a shared CI/CD environment or a cloud cluster, that ceiling can still translate to dozens of machines from a single install event.

"These packages are likely to be installed in local developer environments, CI jobs, release workflows, and internal build systems — where git tokens, cloud credentials, Kubernetes service account tokens, and deployment secrets live." — Wiz Threat Intelligence

⚡ Immediate Action Required— If your environment installed durabletask v1.4.1, v1.4.2, or v1.4.3, treat the host as fully compromised. Rotate all cloud credentials immediately and check for the infection marker at ~/.cache/.sysupdate-check.

Part of a Relentless 2026 Campaign

The durabletask compromise doesn't exist in isolation. TeamPCP — also tracked as PCPcat, ShellForce, and DeadCatx3 — has been running supply chain operations since at least September 2025, gaining notoriety following the React2Shell campaign that exploited cloud environments.

Through early 2026, the group cascaded through Trivy, Checkmarx KICS, LiteLLM, and Telnyx before pivoting to the Mini Shai-Hulud npm and PyPI wave that poisoned over 400 packages in a single night in mid-May. The guardrails-ai infection on May 11 served as the direct precursor to the durabletask attack — the group reusing and refining the same payload architecture each time.

What makes TeamPCP analytically notable is the architectural decision to chain multiple compromises sequentially — where each foothold yields the specific credentials needed to compromise the next target. This isn't spray-and-pray malware. Each package is chosen because it lives in a sensitive part of a development pipeline.

What Security Teams Must Do Now

Find the exposure: Search lockfiles and CI logs for durabletask versions 1.4.1, 1.4.2, or 1.4.3. Look for /tmp/managed.pyz or /tmp/rope-*.pyz on Linux hosts.
Check for execution: The infection marker lives at ~/.cache/.sysupdate-check (general) and ~/.cache/.sysupdate-check-k8s (Kubernetes). Its presence confirms the payload ran.
Rotate everything: AWS IAM credentials, Azure service principals, GCP service accounts, Kubernetes service accounts, Vault tokens, and any passwords that lived in Bitwarden, 1Password, or shell history. Treat all of these as already exfiltrated.
Audit SSM and Kubernetes: Check CloudTrail for SSM:SendCommand and SSM:DescribeInstanceInformation calls. Review Kubernetes audit logs for unexpected kubectl exec activity.
Block C2 infrastructure: At DNS or proxy level, block check.gitservice.com and t.m-kosche.com, and outbound connections to the exfil endpoints /v1/models, /audio.mp3, and /api/public/version.
Enforce lockfile hashes: Going forward, validate every PyPI package against known-good hashes. A compromised publishing token — not a vulnerability in your code — is all it takes for the next wave.

The clean versions of durabletask (v1.4.0 and below) are unaffected. Given TeamPCP's cadence in 2026, this will not be the last package to carry rope.pyz — the question is which trusted dependency gets hollowed out next.

Google's Aluminium OS Spotted on GDG Community Page Hours Before I/O 2026 Keynote

protalweb@gmail.com (Vivek Gurung) — Tue, 19 May 2026 22:17:46 +0530

A Google Developer Groups event page quietly confirmed what millions of Chromebook users have been waiting to hear — but the story is more complicated than a name leak.

Hours before Google's I/O 2026 keynote kicked off at the Shoreline Amphitheater, Cyber Kendra spotted a GDG Nuremberg recap event page that surfaced, listing "Googlebook & Aluminum OS" as a confirmed discussion topic — describing it plainly as "Google's new premium laptop category and the merged Android/ChromeOS platform underneath it."

For anyone tracking the slow-burning death of ChromeOS, that single line on a community calendar told the whole story before Sundar Pichai said a word on stage.

Image- CyberKendra

But here's the thing: this wasn't a leak in the traditional sense. Google had already pulled back the curtain on May 12, during a pre-I/O livestream called The Android Show: I/O Edition. The GDG page was simply a community mirror of what Google had already put on the table — and it's precisely that kind of casual community-level confirmation that tends to cut through the PR gloss.

What Aluminium OS Actually Is

Aluminium OS is the internal codename for a desktop-optimized Android-based operating system that replaces the Linux-based ChromeOS for consumers. The same Android core runs on both mobile and desktop, adapting to different screen sizes — and it supports both ARM and x86 processors, which would make it the first mainline x86-maintained Android build.

Google has since clarified that "Aluminium" is a development codename, not the final retail brand, and says the actual consumer name will be revealed later in 2026. The hardware carrying this OS has a name, though: Googlebook — Google's deliberate answer to the MacBook branding game.

The announcement was made by Senior Director for Laptops and Tablets Alex Kuscher, and at its center is a feature called Magic Pointer — an AI-powered cursor built with Google DeepMind that brings Gemini's context awareness directly to wherever your mouse is pointing. Shake your cursor over a spreadsheet chart, and Gemini offers analysis. Hover over a paragraph, and it surfaces rewrite or translation options. It is, in effect, Gemini embedded into the lowest level of how you interact with a screen.

Beyond the cursor, Cast My Apps lets users open Android phone apps directly on the laptop display mid-workflow, while Quick Access lets users browse and insert files from a phone via Google Drive — no cable or manual transfer required. Create Your Widget lets users prompt Gemini to build a custom desktop widget pulling from Gmail, Calendar, or the web.

Who Makes the Hardware — and Who Gets Left Behind

The first Googlebooks are being built by Acer, ASUS, Dell, HP, and Lenovo, with retail availability expected in Q3 2026. Every device will carry a distinctive "Glowbar" light strip as a hardware identifier for the platform. Pricing hasn't been announced, but the range is expected to span from sub-$300 education devices to premium models competing with MacBooks at $1,000+.

For existing Chromebook owners, the news is mixed. Chromebooks with Intel 12th Gen (Alder Lake) or MediaTek Kompanio 520 processors, at least 8GB of RAM, and 128GB of storage are the strongest candidates for future Aluminium OS upgrades. Older, lower-spec devices will likely remain on Chrome OS until their support window expires.

Critically, ChromeOS is not going away entirely — Google intends to keep it alive for enterprise and education users, where the managed, locked-down experience that IT departments depend on remains intact. Schools running Chromebook fleets won't need to panic.

Why This Matters Beyond the Laptop Market

Microsoft is embedding Copilot into Windows. Apple is integrating Apple Intelligence across its platforms. Google's answer — Gemini baked into the OS at the architecture level rather than retrofitted — gives it a structural advantage neither OpenAI nor Anthropic can replicate: every Googlebook user becomes a Gemini user by default, with no app to download and no subscription to manage.

The GDG Nuremberg event page, scheduled for May 21-22 as a community recap of I/O announcements, plans to dig into exactly this: what Aluminium OS means for Android developers building for large screens, and how the shift to a merged platform affects the existing app testing matrix. Those are developer-facing questions that the polished keynote stage tends to gloss over — and they are often where the real story lives.

Google I/O 2026 is still unfolding today. More details on Aluminium OS, pricing, and the device lineup are expected. But the developer community already knew the headline before the lights came up.

Microsoft Busts "Fox Tempest" — A Dark Web Service That Sold Fake Code Signatures to Ransomware Gangs

protalweb@gmail.com (Vivek Gurung) — Tue, 19 May 2026 21:57:43 +0530

Microsoft has dismantled a sophisticated criminal operation that essentially ran a paid signing service for malware, allowing ransomware groups to make their malicious software appear completely legitimate to Windows security tools.

The threat actor, tracked as Fox Tempest, operated a service called signspace[.]cloud that exploited Microsoft's own Artefact Signing infrastructure (formerly Azure Trusted Signing) to generate short-lived, 72-hour code-signing certificates. Those certificates let malware masquerade as trusted software — think AnyDesk, Microsoft Teams, PuTTY, or Webex — bypassing endpoint security controls that would otherwise flag unsigned executables.

In May 2026, Microsoft's Digital Crimes Unit (DCU), working with industry partners, pulled the plug on the operation and revoked over 1,000 fraudulent certificates Fox Tempest had generated across hundreds of Azure tenants.

How the Service Worked

Fox Tempest ran this like a proper SaaS business. Customers — other cybercriminals — paid between $5,000 and $9,500 per plan (with higher tiers getting queue priority) via a bilingual English-Russian Google Form. They'd upload malicious payloads to Fox Tempest-controlled environments and receive a properly signed binary back, ready to deploy.

The infrastructure evolved over time. By February 2026, the group had shifted to providing customers with pre-configured virtual machines hosted on Cloudzy, a US-based VPS provider, further streamlining operations and reducing their own exposure.

Microsoft believes Fox Tempest likely used stolen US and Canadian identities to pass the identity verification required for Artefact Signing certificates.

Fox Tempest attack chain | Image- Microsoft

Real-World Damage

The downstream impact was severe. Ransomware groups, including Vanilla Tempest, Storm-0501, and Storm-2561, all used Fox Tempest-signed malware in active attacks. One documented chain involved Vanilla Tempest distributing a trojanized Microsoft Teams installer through paid Google Ads — victims who downloaded it got the Oyster backdoor and, in several cases, Rhysida ransomware.

Microsoft links Fox Tempest to proceeds in the millions, with victim organisations spanning healthcare, education, government, and financial services across the US, France, India, and China.

What You Should Do

Microsoft recommends enabling cloud-delivered protection in Microsoft Defender, turning on Safe Links and Safe Attachments in Defender for Office 365, and activating attack surface reduction rules — specifically the advanced ransomware protection rule. Users should also be cautious when downloading software via search ads, even if the binary appears to be signed.

The takedown is significant, but the model Fox Tempest pioneered — malware-signing-as-a-service — is likely to be replicated. Security teams should treat code signatures as a trust signal, not a guarantee.

Discord Calls Are Now End-to-End Encrypted — Even Discord Can't Listen In

protalweb@gmail.com (Vivek Gurung) — Tue, 19 May 2026 08:34:19 +0530

For years, Discord held the same uncomfortable position as every other major communication platform: it could technically access your voice and video calls if asked.
Today, Discord has now completed the full rollout of end-to-end encryption (E2EE — where only the people in a call can decrypt it, not even the platform itself) across every voice and video call on the platform, no settings toggle required.

The change affects DMs, group DMs, server voice channels, and Go Live streams — essentially everything except Stage Channels, which are designed for large broadcast-style audiences where E2EE isn't architecturally suited.

What DAVE actually does under the hood

The system is built on a custom protocol called DAVE — Discord's Audio and Video End-to-End Encryption — developed with input from cybersecurity firm Trail of Bits, using WebRTC encoded transforms and Message Layer Security (MLS) to protect calls even from Discord's own servers. In plain terms: each audio and video frame gets encrypted using a per-sender symmetric key that only the people on the call can access. External parties, including Discord, are never privy to the media encryption keys.

What makes DAVE technically remarkable isn't just what it does — it's where it has to do it. DAVE has been providing E2EE for tens of millions of calls on Discord every single day, spanning users simultaneously on laptops, phones, PlayStations, Xboxes, and web browsers in the same call. Getting a single encryption protocol to work seamlessly across that device diversity, without audible lag or call quality regressions, is genuinely non-trivial.

At one point, extending DAVE to Firefox exposed a browser-level bug that Discord couldn't simply work around. Rather than ship a patch or quietly drop Firefox support, the team went upstream — collaborated directly with Mozilla, identified the root cause in Firefox's codebase, and helped get a fix merged. That's a level of commitment to "doing it right" that most platform teams don't bother with.

How to verify your call is actually encrypted

On the desktop app, a green lock icon labeled "End-to-end encrypted" now appears in the Voice/Video Details panel, along with a new Privacy tab containing a Voice Privacy Code. That code can be compared out-of-band with other participants — on a different platform or in person — to confirm no one is being impersonated on the call. Privacy codes update whenever participants join or leave. It's an optional but meaningful layer for high-stakes conversations.

Each Go Live stream also has its own Stream Privacy Code accessible via the right-click context menu, letting streamers verify the encrypted state of their broadcast independently from the voice channel.

This E2EE rollout landed in the middle of a period of significant trust turbulence for Discord. The platform simultaneously introduced "teen-by-default" settings globally, requiring age verification via face scan or government ID — a move that drew backlash, especially after a 2025 breach at Discord's third-party verification vendor exposed at least 70,000 government ID photos. Completing call encryption — where even Discord cannot listen in — is a direct response to exactly that kind of trust problem.

It's a notable split: Discord is simultaneously expanding what it can't access (your calls) while navigating controversy over what users are being asked to hand over (government IDs). Call encryption doesn't resolve that tension, but it does represent a structural, verifiable privacy guarantee that no policy document can replicate.

What's still not encrypted: text

Discord has confirmed it has no current plans to extend E2EE to text messages. The reason is engineering scope, not reluctance: text-based features like message search, moderation, bots, and content filtering are all built on the assumption that messages are readable server-side.

Re-architecting that for E2EE would require rebuilding significant platform infrastructure. For now, if a conversation needs full end-to-end security — text and audio — Signal remains the better choice.

What this means for users

If you're on a current version of the Discord app, your voice and video calls are now encrypted by default, with no action required on your part. Third-party applications and bots that connect to Discord voice must now implement DAVE support to continue functioning, which means some niche bots may have already broken or require updates from their developers. If a bot in your server abruptly dropped out of voice channels around March 2026, this is likely why.

The DAVE protocol is open-source, and the implementation has been publicly audited — which means the encryption claim isn't one you have to take on faith. That's rarer than it should be.

Storm-2949 Hackers Turned One Stolen Password Reset Into a Full Azure Cloud Takeover

protalweb@gmail.com (Vivek Gurung) — Tue, 19 May 2026 08:16:51 +0530

A single helpdesk phone call was all it took.

Microsoft's Threat Intelligence team has published a detailed breakdown of how a threat actor it tracks as Storm-2949 weaponized Microsoft's own Self-Service Password Reset (SSPR) feature — a routine IT tool — to trigger a sweeping breach across a victim organization's entire cloud environment, spanning Microsoft 365, Azure App Services, Key Vaults, SQL databases, and virtual machines.

The attack never used traditional malware. Instead, Storm-2949 impersonated IT support staff and called targeted employees, convincing them to approve what looked like routine multi-factor authentication (MFA) prompts.

Once victims clicked "Approve," the attacker hijacked the password reset flow, wiped the legitimate user's authentication methods, and enrolled their own device as the new trusted authenticator — effectively locking the real user out permanently.

Using those hijacked accounts — which held privileged Azure role-based access control (RBAC) permissions — the attackers quietly mapped the organization's tenant using automated Microsoft Graph API queries, then began draining OneDrive and SharePoint, targeting VPN configurations and remote access documentation.

Storm-2949 attack diagram | Microsoft

That was just phase one.

According to Microsoft's Threat Intelligence, on the Azure side, Storm-2949 pivoted to App Service publishing profiles to harvest deployment credentials, then raided an Azure Key Vault in under four minutes, pulling database connection strings, identity credentials, and application secrets. Those secrets unlocked the crown jewel: the organization's primary production web application, whose password they changed to maintain control.

From there, they manipulated SQL firewall rules to extract database contents, abused Azure Storage account keys to exfiltrate blob data over multiple days using a custom Python script, and deployed ScreenConnect — a legitimate remote management tool — on virtual machines after disabling Microsoft Defender's real-time protection. Post-compromise activity included harvesting .pfx certificate files and scanning network shares for password strings.

The entire operation exploited legitimate administrative features rather than vulnerabilities, making detection significantly harder.

Microsoft's guidance is direct: enforce phishing-resistant MFA (hardware keys or certificate-based authentication) for all privileged accounts, restrict SSPR to pre-registered methods only, audit Azure RBAC assignments regularly, and deploy Defender for Cloud across Key Vault, Storage, and App Service workloads.

Three attacker-controlled IP addresses have been published as indicators of compromise: 176.123.4[.]44, 91.208.197[.]87, and 185.241.208[.]243 (the ScreenConnect C2 server).

The broader warning is hard to miss — in cloud environments, identity is the perimeter.

How I Deep Clean My Windows Junk Files with Advanced SystemCare 19

protalweb@gmail.com (Vivek Gurung) — Mon, 18 May 2026 21:45:10 +0530

Over time, I noticed my Windows PC was becoming slower, especially after installing and testing many Windows apps. Even after uninstalling some apps, my storage space kept shrinking, and performance didn’t fully improve. That’s when I realized that Windows applications leave behind cache files, temporary files, logs, and other data that quietly accumulate over time.

To solve this problem, I started using Advanced SystemCare 19, a PC cleaner and Windows optimization tool that safely and automatically removes hidden junk files. After using it regularly, I found it much easier to clean up stored and hidden junk, free up storage space, and improve overall system responsiveness. In this tutorial, I’ll show you how I use Advanced SystemCare 19 to deep-clean Windows junk in just a few simple steps.

Why I Started Cleaning My Windows Junk Files

At first, I underestimated how much clutter Windows apps could create. Even though these apps are convenient, many continue generating unnecessary data in the background.

The most common junk files I found included temporary cache files, update leftovers, log files, outdated installation files, and uninstallation remnants. Over time, these files consumed a surprising amount of disk space and started affecting my PC’s startup speed and responsiveness.

After reading about the Junk File Clean feature in Advanced SystemCare 19, I decided to test it myself. The software claimed it could fully clean outdated data created by Windows programs, automatically improving system speed and freeing up storage space.

My Step-by-Step Experience Cleaning Windows Programs' Junk Files

Step 1. Installing and Opening Advanced SystemCare 19

First, I downloaded this Windows cleaner from the official website and installed it on my Windows PC. After launching the software, I immediately noticed the dashboard offered two main cleaning modes: AI Mode and Manual Mode.

For deep cleaning Windows app junk files for the first time, I chose manual mode because it gives me more control over what gets scanned and cleaned. However, for regular maintenance, I usually use AI Mode because it automates everything intelligently. However.

Step 2. Using Junk File Clean in Manual Mode

Inside Manual Mode, I found several optimization and cleanup modules. To focus on all Windows junk files, I enabled all the checkboxes, including the Privacy Sweep, for additional cleanup.

What impressed me most was that the professional Junk File Clean feature in version 19 could detect junk created by multiple Windows applications much more thoroughly than the default Windows cleanup tools.

Step 3. Running the Scan

Once the scan started, Advanced SystemCare analyzed my system for multiple types of clutter, including: temporary app cache, installation leftovers, invalid shortcuts, useless registry entries, privacy traces, and old Microsoft Store app data. The scanning process felt surprisingly fast, and I could see the amount of reclaimable disk space updating in real time.

Step 4. Removing the Detected Junk Files

After the scan finished, the software displayed a detailed cleanup report showing all detected junk files and leftover data. Before cleaning, I carefully reviewed the results, then clicked the Fix button. Advanced SystemCare safely removed cache files, temporary files, outdated Microsoft Store data, registry clutter, and privacy traces.

I appreciated that the software focused only on unnecessary files rather than deleting important system data. After the cleanup finished, I immediately noticed extra free storage space and smoother system performance.

Step 5. The Cleanup Results I Noticed

Once the process was completed, the confirmation screen summarized everything that had been cleaned. On my older system, the difference was noticeable almost immediately. Startup speed improved, and applications opened more smoothly.

The Summary screen also showed the total number of junk files removed, disk space reclaimed, problems fixed, and privacy and security improvements. For ongoing maintenance, I enabled AutoCare, which now performs cleanup automatically in the background.

Why Advanced SystemCare 19 Stood Out for Me

Although I originally turned to Advanced SystemCare 19 mainly to remove persistent Windows apps' junk files, I quickly realized that the software offers far more than a PC cleaner, particularly for performance and speed optimization.

The Startup Optimizer became an immediate asset, significantly reducing my boot times by disabling unnecessary startup programs that typically drag down system responsiveness. When I needed to push my hardware further during intensive gaming sessions or heavy multitasking, Turbo Boost proved invaluable by temporarily pausing non-essential background processes to channel raw power where it mattered most.

To cap it off, the Internet Booster delivered a highly noticeable upgrade to my daily workflow, accelerating web browsing and improving download speeds by optimizing my browser settings.

Beyond sheer speed, Advanced SystemCare 19 stood out for its robust, intuitive suite of privacy and security features. The Privacy Shield acted as a secure barrier, safeguarding my sensitive files and personal data from unauthorized third-party access, while the automated Anti-Spyware Protection continuously worked in the background to root out hidden spyware and adware threats.

My everyday online experience felt much cleaner and safer thanks to Browser Protection, which actively blocked intrusive ads, prevented frustrating homepage hijacking, and cleared away tracking traces.

Final Thoughts

Before using Advanced SystemCare 19, I didn’t realize how much hidden junk Windows programs were leaving behind on my system. Manually searching for cache folders and leftover files felt frustrating and incomplete.

After switching to Advanced SystemCare 19, cleaning junk files became much easier, faster, and safer. The software helped me recover storage space, improve system responsiveness, and reduce unnecessary clutter without requiring advanced technical skills. What I personally liked most was the combination of automatic cleanup, intelligent scanning, privacy protection, and performance optimization all in one place.

If your PC feels slower over time or your storage space keeps disappearing unexpectedly, Windows junk files could be a hidden cause. From my experience, regular deep cleaning with Advanced SystemCare 19 can make a noticeable difference in keeping Windows fast, clean, and responsive.

The Rise of Autonomous Cyber Attacks: Risks, Examples & Defense

protalweb@gmail.com (Vivek Gurung) — Sat, 25 Apr 2026 08:18:00 +0530

Last month, a mid-size financial services company ran a routine penetration test. The testers used an AI-assisted reconnaissance tool to map the network. Within 40 minutes, the tool had identified exposed services, correlated employee names with LinkedIn data, generated targeted phishing lures, and flagged three likely paths to domain admin.

The internal security team, working with traditional alert queues and weekly review cycles, would not have caught any of it in time.

That was a controlled test. The real attackers are running the same playbook, but they do not stop when the clock runs out.

Key Takeaways:

Autonomous attacks operate at machine speed with no human in the loop
AI enables adaptive exploitation that bypasses static defenses
Traditional SOC workflows were not built for millisecond threat cycles
Defending autonomously is no longer optional; it is the only practical response

What Are Autonomous Cyber Attacks?

Autonomous cyber attacks are AI-powered operations that independently plan, execute, and adapt intrusions without requiring a human operator to guide each step. Unlike traditional attacks, where a person types commands and reacts to output, these systems make decisions dynamically, shift tactics when they encounter resistance, and propagate across environments faster than most security tools can generate an alert.

Three characteristics define them:

Self-learning: The attack refines its approach based on what succeeds. If a port scan triggers a firewall rule, the system notes that and tries a different vector.
Decision-making capability: The system evaluates multiple exploitation paths and selects the most promising one without waiting for a human to weigh in.
End-to-end automation: Reconnaissance, initial access, lateral movement, and exfiltration can all be chained together with no human touchpoints.

This is not theoretical. The tooling exists today, and significant portions of it are openly available.

The Autonomous Cyber Attacks are rising in 2026 due to the easy accessibility of AI tools and Large language models. Today, a moderately skilled operator can assemble one from open-source components, AI APIs, and leaked offensive toolkits in an afternoon

Real-World Examples of Some Autonomous Cyber Attacks

Attribution in this space is difficult, and public disclosure is rare. But several documented cases give a clear picture of where things stand.

The GT-1002 Campaign: Security researchers tracking this campaign documented a threat actor using automated tooling to conduct reconnaissance, credential stuffing, and lateral movement across hundreds of enterprise targets. What stood out was the operational pace. Actions that would normally indicate a human operator working over days were compressed into hours. The infrastructure rotated automatically, and the attack pivoted when individual vectors were blocked, without any apparent manual intervention.

AI-Assisted Espionage: Anthropic's own research has documented adversarial attempts to use AI systems to assist in cyber operations. In documented cases, AI platforms were queried to assist with reconnaissance, writing attack scripts, and identifying security control gaps. The significance is not that AI was the attack itself, but that it dramatically accelerated the pre-attack research phase.

Hexstrike-AI Framework: Circulated within offensive security communities, this framework demonstrated an end-to-end automated attack chain: from public internet reconnaissance to internal network pivot, using AI to select and sequence attack techniques based on real-time feedback from the target environment. Regardless of who ultimately uses tooling like this, its existence demonstrates that fully automated, adaptive attack chains are technically feasible today.

How to Defend Against Autonomous Cyber Attacks

The reflexive answer is "use AI for defense too." That is partially right, but it obscures what actually needs to change operationally.

AI-Native Security Architecture

The core problem with traditional security stacks is that they were built around human review cycles. An alert is generated, queued, triaged, and escalated. That workflow made sense when attacks moved at human speed. It does not work when an attacker can complete initial access and lateral movement before the first alert is acknowledged.

Real-time detection means analyzing behavior at the point of occurrence, not after log aggregation. Network detection systems, endpoint telemetry, and identity activity monitoring need to feed into decision systems that can act within seconds, not minutes.

Automated response is the logical extension. Isolating a compromised endpoint, revoking a suspicious session token, and blocking an anomalous outbound connection: these actions cannot wait for a security analyst to approve them when the attacker is already moving laterally.

The pushback from operations teams is predictable. Automated response blocks legitimate users sometimes. That is a real cost. But the alternative is accepting that human review timelines are incompatible with the threat environment.

Zero Trust and Identity Security

Most security architectures still have a soft interior. Once an attacker has a valid credential and is inside the network perimeter, movement is surprisingly easy. Implicit trust based on network location is the foundational assumption that most attack chains depend on.

Continuous verification changes that calculus. Every access request, every API call, every privileged operation is evaluated against the current context: device health, user behavior patterns, time of day, geographic anomalies. A credential used from an unusual location at an unusual time does not automatically succeed.

Least privilege access removes the value of compromised credentials. If a developer's account can only access the specific resources their current work requires, a stolen credential is far less useful to an attacker. Operationalizing this requires more than a policy document; it requires an identity and access management solution for Zero Trust that enforces continuous verification, scopes permissions dynamically, and reduces or eliminates standing access across the environment.

Continuous Monitoring and Behavioral Analytics

AI-powered attacks do not behave like human attackers in terms of pattern and timing. They often move faster, access more resources in sequence, and operate at times that fall outside normal working hours. Behavioral analytics systems that baseline normal activity can flag these anomalies even when each individual action looks legitimate in isolation.

A single failed authentication is noise. Fifty sequential failed authentications across different accounts from the same IP range, at 3 AM, followed by one success, is a pattern. Systems that detect and respond to the pattern, rather than the individual event, are significantly harder to bypass.

Securing AI Systems

Security teams increasingly need to defend their own AI deployments. Large language models used in internal tooling can be targeted through prompt injection, where malicious input manipulates the model into performing unintended actions or disclosing sensitive information.

The OWASP Top 10 for LLM Applications provides a starting framework. Key concerns include prompt injection, training data poisoning, and over-reliance on AI outputs without human validation. Organizations deploying AI-assisted security tools need to treat those tools as part of the attack surface, not just part of the defense.

The Role of Identity and Access Management in Defense

Autonomous attacks are effective in large part because they exploit legitimate credentials and access paths. The attacker does not break in through the window; they walk through the front door with keys they found or stole.

Identity and Access Management (IAM) and Privileged Access Management (PAM) address this directly by:

MFA and Adaptive Authentication

Automated credential stuffing attacks test millions of username-password combinations against login portals. Standard MFA blocks the vast majority of these because the attacker has the password but not the second factor. Adaptive MFA goes further: it evaluates context at each login attempt, flagging anomalies in location, device fingerprint, or behavioral patterns and stepping up verification requirements accordingly.

Identity Lifecycle Management (Provisioning and Deprovisioning)

Orphaned accounts are one of the most consistently exploited entry points in enterprise environments. An employee leaves, their Active Directory account persists, and six months later, an autonomous scanner finds it during credential stuffing. Automated provisioning and deprovisioning closes this loop: access is removed when roles change or employment ends, not when someone remembers to file a ticket.

Role-Based Access Control

Role-based access control makes the users hold only the minimum permissions their work requires; a compromised credential gives the attacker a narrow foothold rather than broad infrastructure access. AI malware that hijacks a user session inherits that session's permissions. Keeping those permissions tightly scoped limits how far the attack can propagate.

Single Sign-On (SSO)

SSO centralizes authentication through a single control point, which means anomalous activity is easier to detect and correlate. A credential being used to authenticate against fifteen different applications in four minutes is obvious in a centralized SSO log. That same activity spread across fifteen separate authentication systems may never surface as a coherent signal

Just-in-Time Privileged Access

Standing administrative privileges are a permanent target. Just-in-time access management makes sure privileges are granted for a specific task, for a limited window, and revoked automatically when the window closes.

Session Monitoring and Recording

Even legitimate admin access can be abused, whether by a compromised account or a malicious insider. Privileged session management records privileged sessions to create an auditable trail of exactly which commands were run, which files were accessed, and which systems were touched. It also creates a detection surface: behavioral analytics applied to session recordings can flag automated command sequences that look nothing like human interaction.

Credential Vaulting and Rotation

Static credentials are a gift to autonomous attackers. A password that never changes, once exfiltrated, remains valid indefinitely. Credential vaulting stores secrets in an encrypted, access-controlled store rather than in config files or developer laptops. Automated rotation changes those passwords on a regular schedule, meaning stolen credentials have a limited validity window. AI bots built around credential reuse find that the credentials they collected last month no longer work.

Solutions like miniOrange's IAM and PAM platform consolidate these controls: credential vaulting, just-in-time access provisioning, privileged session monitoring, and machine identity management in a single operational framework. The practical value is not just in having the controls, but in having them integrated so that signals from one layer inform decisions in another.

Future Outlook: AI vs. AI Cybersecurity

The trajectory is clear. Offensive AI capabilities will continue to improve. Defensive AI capabilities will need to match that pace. The intermediate period, where attackers have sophisticated AI tooling and defenders are still running largely manual SOC operations, is the most dangerous window.

AI vs. AI warfare is already a meaningful framing. Autonomous attack systems probing for weaknesses, automated defense systems detecting and responding, and the outcome determined by which side has better models, better data, and faster feedback loops.

Predictive threat intelligence is an emerging defensive capability. Rather than detecting attacks that are already in progress, systems trained on attack patterns can identify the precursors: scanning activity, credential testing and staging infrastructure registration. Acting before the attack chain reaches exploitation is significantly more effective than responding during lateral movement.

Autonomous SOCs are a real near-term development. Not replacing human analysts, but automating the high-volume, time-sensitive work: alert triage, initial investigation, containment actions. Human analysts focus on judgment calls and strategic decisions while automated systems handle the operational tempo.

Regulatory frameworks are developing in parallel. NIST's AI Risk Management Framework provides structured guidance for managing AI-related risk, including the risks of AI-powered adversaries. Compliance frameworks are likely to evolve to explicitly address autonomous threat scenarios.

Are We Ready? A Final Assessment

Most organizations are not. That is not a criticism; it is an accurate description of where the industry stands.

Security programs built over the past decade were designed for a threat environment where attackers moved at human speed. The tooling, processes, and staffing models reflect that assumption. The threat environment has changed faster than most organizations have adapted.

But the gap is closeable. The starting point is honest assessment.

Organizational Readiness Checklist:

Can your SOC detect and respond to a threat within minutes, not hours?
Are privileged access permissions reviewed and right-sized quarterly?
Do you have behavioral analytics capable of detecting anomalous patterns, not just known signatures?
Are machine identities (service accounts, API keys) inventoried and monitored?
Is MFA enforced with session-level controls, not just at login?
Do you have automated response capabilities for common threat scenarios?
Are AI tools in your environment treated as part of the attack surface?

Maturity Levels:

Level	Characteristics
Reactive	Alert-based, human review and incident response after compromise
Preventive	MFA, patching, basic monitoring, policy enforcement
Detective	Behavioral analytics, threat hunting, anomaly detection
Adaptive	AI-assisted detection, automated response, continuous verification
Autonomous	AI-native defense, predictive intelligence, real-time autonomous response

Most enterprise organizations sit between Preventive and Detective. The threat environment requires at least Adaptive.

Immediate Next Steps:

Audit all privileged accounts and remove standing administrative access where not operationally necessary
Implement behavioral analytics on identity and privileged activity, not just network traffic
Introduce just-in-time access for high-risk systems, reducing the value of stolen credentials
Inventory and rotate machine identity credentials on a scheduled basis
Test your automated detection and response capabilities against a realistic autonomous attack simulation
Evaluate your AI systems for exposure to prompt injection and model manipulation

If the goal is to enforce controls like session monitoring, just-in-time access, behavioral analytics, and centralized privileged activity auditing without building each capability independently, platforms like miniOrange PAM can centralize these capabilities across hybrid and cloud environments without disrupting existing developer and operations workflows.

The attackers have already automated. The only viable response is to automate the defense.

Frequently Asked Questions:

Q. What are autonomous cyber attacks?

A. AI-driven attacks that independently plan, execute, and adapt cyber intrusions without human involvement. They use machine learning and automation to select targets, identify vulnerabilities, and move through environments faster than human defenders can respond.

Q. What is an AI cyber attack?

A. A cyber attack that uses artificial intelligence to automate decision-making, targeting, and execution. This includes AI-generated phishing content, automated exploitation, and self-adapting malware that evades detection.

Q. What are the top types of autonomous cyber attacks?

A. AI-powered phishing and deepfakes, self-adapting malware, autonomous botnets, and AI-based vulnerability discovery are the primary categories currently observed in enterprise environments.

Q. Why are autonomous attacks particularly dangerous?

A. They operate at machine speed, adapt in real time when defenses block initial approaches, and can run the same campaign against thousands of targets simultaneously. Traditional security workflows built around human review cycles are poorly matched to this tempo.

Q. How can organizations defend against AI cyber threats?

A. Through AI-native detection and automated response, Zero Trust security with continuous verification, behavioral analytics that detect anomalous patterns rather than known signatures, and identity governance that limits the value of compromised credentials.

Grafana Labs Refuses Ransom After GitHub CI Flaw Exposed Its Source Code

protalweb@gmail.com (Vivek Gurung) — Sun, 17 May 2026 19:41:35 +0530

Grafana Labs publicly confirmed this week that attackers stole a GitHub access token through a misconfigured CI/CD pipeline, downloaded private source code repositories, then attempted to extort the company — and walked away empty-handed.

The breach, announced via a six-tweet thread on X, traces back to a subtle but well-known class of GitHub Actions vulnerability called a "Pwn Request." A recently enabled GitHub Action workflow configured to trigger on pull_request_target events inadvertently granted external contributors — anyone who could open a pull request — access to production secrets during CI runs.

The attacker's method was methodical. By forking a Grafana repository, injecting malicious code via a curl command, and dumping environment variables to a file encrypted with a private key, the threat actor extracted privileged tokens, then deleted their fork to cover their tracks before leveraging the stolen credentials against four additional private repositories.

What stopped the attacker from going completely undetected? Their own curiosity. One of the thousands of canary tokens — invisible tripwires Grafana embeds across its code and infrastructure — was triggered, immediately alerting the global security team. Canary tokens are decoy credentials designed to fire an alert the moment they're used, exposing access that would otherwise go unnoticed.

Grafana's investigation found no evidence of code modifications, unauthorized access to production systems, or exposure of customer data. The company revoked all compromised tokens, disabled the vulnerable workflows, and ran a full credential audit using tools including Trufflehog and Gato-X.

That didn't stop the attacker from trying their luck. After downloading the private codebase, they escalated to extortion — demanding payment in exchange for not releasing the stolen code. Grafana refused. The company cited FBI guidance, noting that paying ransoms offers no data-recovery guarantee and only incentivizes more attacks.

Reports from Hackmanac and Ransomware.live attribute the attack to CoinbaseCartel, a data extortion crew that emerged in September 2025 and is assessed to be an offshoot of the ShinyHunters, Scattered Spider, and LAPSUS$ ecosystems. Unlike traditional ransomware groups, CoinbaseCartel focuses exclusively on data theft and extortion, and has already claimed over 170 victims across healthcare, technology, transportation, and manufacturing.

The incident lands as part of a troubling pattern. It follows Instructure's controversial decision to settle with ShinyHunters after the group threatened to leak terabytes of data from thousands of U.S. schools. Grafana's refusal to pay sets a different precedent — one that the FBI has long advocated for.

For developers and security teams, the Grafana incident is a practical reminder: audit any GitHub Actions workflow using pull_request_target triggers in public repositories, restrict CI secrets to least-privilege scopes, and deploy canary tokens across sensitive codebases.

The tripwire is what saved Grafana from a far longer dwell time — threat intelligence from Mandiant suggests the average gap between credential theft and active exploitation is 11 days. Grafana caught it before that clock ran out.

Google's AI Search Guide Is Out — Explained Without the Hype

protalweb@gmail.com (Vivek Gurung) — Sat, 16 May 2026 09:23:46 +0530

If you've been following the chatter around "Generative Engine Optimization" or "Answer Engine Optimization," you've probably seen a flood of advice about llms.txt files, content chunking, AI-friendly schema, and prompt-style writing. Most of it is noise. Google's own documentation — updated in 2025 — cuts through cleanly, and the core message is both simpler and more demanding than the SEO industry tends to admit.

This article breaks down what Google actually says, explains what it means in practice, and highlights the parts most publishers miss entirely.

First, Understand What's Actually Powering AI Overviews

Before diving into optimization tactics, it helps to understand the engine underneath. Google's AI Overviews and the newer AI Mode aren't magic boxes that independently read the entire web. They work through two primary techniques:

Retrieval-Augmented Generation (RAG): The AI doesn't generate answers from memory alone. It queries Google's core Search index — the same one used for blue-link results — fetches relevant pages, reads them, and generates a response grounded in that retrieved content. The clickable source links you see in AI Overviews are the pages that were actually retrieved.

Query fan-out: When someone searches for something complex, the AI doesn't just process the literal query. It generates multiple related sub-queries simultaneously. A search like "how to recover from a Google core update" might fan out into "signs your site was hit by a Google core update," "content quality signals Google uses," and "how long do core update recoveries take." Each fan-out query pulls its own results.

Why this matters: It means there's no separate "AI index" to get into. If your page ranks well in organic search and is crawlable with a snippet, it's already eligible for AI Overviews. You're not optimizing for a different system — you're optimizing for the same Search infrastructure you already know.

The Real Divide: Commodity vs. Non-Commodity Content

This is the single most important concept in Google's guidance, and it's the one most often glossed over.

Commodity content is information that could originate from anyone. "10 cybersecurity tips for small businesses." "What is phishing?" "How to create a strong password." These topics have been covered thousands of times, the information is widely known, and a generative AI model could produce them without consulting your site at all. If your content falls into this category, AI systems have no particular reason to cite you — they can simply generate the answer themselves.

Non-commodity content has something commodity content lacks: a reason to exist that's specific to you. A security researcher's first-hand analysis of a zero-day they discovered. A breakdown of an incident your team responded to. A documented test comparing five password managers using criteria you defined. A breach post-mortem with root cause analysis that only the affected organization could provide.

The difference isn't just about depth. It's about whether your content contains information that exists only because you produced it. First-hand experience, original research, proprietary data, expert analysis of primary sources — these are signals that your content adds something to the web rather than duplicating what's already there.

Consider the example Google itself provides: "7 Tips for First-Time Homebuyers" (commodity) vs. "Why We Waived the Inspection & Saved Money: A Look Inside the Sewer Line" (non-commodity). The second piece has a perspective that can't be replicated — the author was there, made a specific decision, and is reporting the outcome. AI can't fabricate that. It can only cite it.

For cybersecurity publishers specifically, a news article that simply rewrites a vendor advisory is a commodity. A piece that adds timeline analysis, compares the vulnerability to a prior incident, reaches out to affected parties for comment, or provides reproduction steps from independent testing — that's non-commodity.

What AEO and GEO Actually Mean (And Why Google Disagrees With the Industry)

The SEO industry has spawned two new acronyms to describe optimization for AI systems: AEO (Answer Engine Optimization) and GEO (Generative Engine Optimization). Consultants have built entire service lines around these terms.

Google's official position: these are just SEO. The same signals. The same systems.

This is more significant than it sounds. It means Google is explicitly pushing back on the idea that you need a separate strategy for AI search. The implication is that anyone selling you an "AEO audit" distinct from a standard SEO audit is selling you something Google doesn't recognize as real.

That said, there's a practical nuance worth noting: while the underlying signals are the same, the emphasis shifts when AI is synthesizing answers. Traditional SEO rewards pages that match query intent and have authority signals. AI Overviews also reward pages that are citable — meaning their content is structured clearly enough that the AI can extract a specific claim, quote an explanation, or attribute a data point. A page can rank well in organic search but never appear in an AI Overview if its content isn't written in a way that's easy to reference directly.

The distinction isn't about a different algorithm. It's about readability and extractability — which are good writing practices anyway.

The Myth-Busting Section: Things You're Wasting Time On

Google's documentation explicitly names several practices circulating in the industry as unnecessary or ineffective for Google Search. Here's the list with added context on why each one falls short:

llms.txt files

This format, borrowed from robots.txt conventions, was proposed as a way to give AI systems a structured summary of your site. Google says directly: " You don't need this. Google can crawl and index many file types, but no special file type gets you preferential treatment in AI systems. For non-Google AI crawlers (like those from Anthropic, OpenAI, or Perplexity), llms.txt may eventually matter — but for Google, it's currently irrelevant.

"Chunking" content

Some advice tells you to break pages into small, discrete answer blocks so AI can extract them more easily. Google explicitly says this isn't required. Their systems can understand which part of a longer page is relevant to a query. Write for your readers. If shorter pages make sense for your topic and audience, great. If a 3,000-word technical deep-dive serves your readers better, that's fine too.

Rewriting content in "AI-friendly" language

You don't need to adopt a Q&A format, use specific trigger phrases, or rephrase everything as direct answers. Google's AI understands synonyms and semantic intent. If your content genuinely answers a question, the system can figure that out without you gaming the phrasing.

Chasing inauthentic "mentions"

Some practitioners advise seeding forums, comment sections, and third-party blogs with brand mentions to influence AI responses. Google's spam systems catch this, and the generative AI features inherit the same quality filters. Unearned mentions don't help; they may hurt.

Overloading structured data

Structured data (schema.org markup) remains useful for rich results — it helps Google display reviews, FAQs, products, and events properly in traditional search. But there's no special schema that gets you into AI Overviews. Don't add schema, specifically hoping it unlocks AI features; it won't.

What Actually Moves the Needle

Strip away the myths, and you're left with a short, unglamorous list:

1. Be crawlable and indexable with a snippet enabled

Pages blocked by noindex, those behind login walls, or those with no-snippet directives can't appear in AI Overviews regardless of content quality. This is table stakes. Run a Search Console coverage audit first.

2. Produce genuinely first-hand or expert content

The AI is looking for pages that contain information it can't synthesize on its own. Reviews written after actual use. Analysis from someone with domain expertise. Data from your own research. If your content could be generated by an AI without consulting your site, it probably won't be cited by one either.

3. Write clearly, with a navigable structure

Headings that describe what a section covers. Paragraphs that contain one idea each. Sentences that say what they mean without filler. This isn't about writing "for AI" — it's about writing well. The extractability that makes AI Overviews cite your content is the same thing that makes human readers trust it.

4. Use high-quality images and video where relevant

AI Overviews can surface image and video results, not just text. If your topic benefits from visual illustration — a hardware teardown, a vulnerability diagram, a product comparison screenshot — include original visuals with accurate alt text and descriptive filenames.

5. Ensure good page experience

Core Web Vitals, mobile rendering, and low latency. These remain ranking signals, and they affect whether retrieved pages get surfaced prominently in AI responses.

If You Use AI to Help Write Content: What Google Actually Requires

This is where many publishers are nervous, and the guidance is worth reading carefully.

Google does not ban AI-assisted content. What it penalizes is scaled content abuse — producing large volumes of pages without adding value for users. The test isn't whether AI was involved in writing. The test is whether the output meets the same quality and usefulness standards Google would apply to any content.

In practice, this means:

Using AI to draft a structure, then filling it with first-hand knowledge, original analysis, and expert commentary: acceptable, and likely fine.
Using AI to generate 500 pages of product descriptions with no human review or added value violates the spam policy.
Using AI to speed up research or improve phrasing on content you've substantially developed yourself: acceptable.
Using AI to spin existing articles into slightly different versions at scale: spam policy violation.

The guidance also notes that transparency is a good practice. If your publication process involves AI tools in meaningful ways, explaining that to readers (in a site-level disclosure or per-article note) builds trust. For e-commerce specifically, AI-generated images must include IPTC DigitalSourceType metadata, marking them as algorithmically produced.

The Agentic Web Is Coming — Here's What to Watch

Beyond AI Overviews, Google's documentation introduces something worth tracking: agentic experiences. AI agents — systems that can book reservations, fill out forms, compare products, and complete tasks autonomously — are beginning to access websites the same way browsers do, by rendering pages, reading the DOM, and interpreting accessibility trees.

Google points to the Universal Commerce Protocol (UCP) as an emerging standard for how agents will interact with commerce sites. This isn't mainstream yet, but it signals where things are going: a web where the "user" visiting your site may be an AI agent acting on someone's behalf, not a human at all.

For publishers, this is mostly future-watch territory. For e-commerce operators, it's worth considering now: your checkout flows, product data structures, and schema markup will increasingly be navigated by agents rather than read by humans. Semantic HTML, clean DOM structure, and good accessibility practices aren't just for screen readers — they're also how agents parse your pages.

The Practical SEO Checklist for AI Search Readiness

For website owners who want a concrete action list:

Content audit:

Identify your top-traffic pages. Ask honestly: does this page contain information that exists because we produced it, or is it a restatement of commonly available facts?
Flag commodity pages for upgrading with first-hand data, original examples, or expert commentary.

Technical audit:

Check Search Console for indexing issues, noindex tags on content you want crawled, and coverage errors.
Verify snippets aren't blocked via X-Robots-Tag or meta robots directives.
Review Core Web Vitals, particularly LCP and CLS.

Content creation:

Build a process for producing non-commodity content: primary source analysis, original interviews, first-hand testing, proprietary data.
Stop creating "answer" pages that duplicate what's already on a dozen other sites.

AI tools policy:

Decide your publication's approach to AI-assisted writing and document it.
Ensure any AI-assisted content goes through substantive human review that adds real value before publication.

Ignore:

llms.txt, content chunking, AI-specific schema, inauthentic mention campaigns.

Final Thought: The Bar Just Got Higher

The honest takeaway from Google's guidance is that the bar for content that earns visibility in AI-powered search is meaningfully higher than the bar for traditional organic ranking. An article that ranks #3 for a moderately competitive query by satisfying on-page signals might never be cited in an AI Overview if it lacks a distinctive perspective.

That's not necessarily bad news. It's a forcing function. The content that survives this shift is the content that was always worth creating: original, authoritative, specific, and written with a real reader in mind. Publishers who've been producing commodity content at scale are the ones with the most to worry about.

For those doing genuine editorial work — original reporting, expert analysis, first-hand testing — the AI era may actually favor them over the SEO optimization shops that dominated the last decade.

Sources: Google Search Central — Optimizing your website for generative AI features on Google Search and Google Search's guidance on using generative AI content

Microsoft Exchange Zero-Day Exploited in the Wild — and Pwn2Own Researchers Just Made It Worse

protalweb@gmail.com (Vivek Gurung) — Sat, 16 May 2026 08:19:37 +0530

Microsoft Exchange Server is having a very bad week. While threat actors are already exploiting a critical cross-site scripting vulnerability in the wild, elite researchers at Pwn2Own Berlin 2026 independently demonstrated full SYSTEM-level remote code execution on the same platform — all within 48 hours of each other.

Microsoft confirmed on Thursday that a critical XSS vulnerability, tracked as CVE-2026-42897, is being actively exploited against on-premises Exchange Server deployments. The flaw affects Exchange Server 2016, 2019, and the Subscription Edition. Exchange Online users are not at risk.

The attack is deceptively simple: an attacker sends a specially crafted email to a target. If the victim opens it in Outlook Web Access (OWA) — the browser-based interface for accessing Exchange mailboxes — arbitrary JavaScript can execute silently in the browser context. No credentials needed, no complex setup. Just a well-timed phishing email.

The vulnerability appeared just two days after Microsoft's May 2026 Patch Tuesday, which addressed 138 separate flaws — a grim reminder that even the most patched environments can be blindsided by zero-days arriving between update cycles.

Microsoft has not identified the threat actor behind the active exploitation, nor shared details about targets, campaign scale, or whether any attacks were successful. CVE-2026-42897 has not yet been added to CISA's Known Exploited Vulnerabilities catalog, though given its "Exploitation Detected" status, that designation could come at any time.

Pwn2Own Adds Fuel to the Fire

As if the zero-day wasn't enough, on day two of Pwn2Own Berlin 2026, Orange Tsai of DEVCORE Research Team chained three bugs together to achieve remote code execution with SYSTEM privileges on Microsoft Exchange, earning $200,000 — the single largest payout of the competition so far. This is a separate, distinct attack chain from CVE-2026-42897, and per Pwn2Own rules, vendors receive a 90-day window to patch before details are made public.

It follows an equally impressive day-one performance, where Orange Tsai earned $175,000 by chaining four logic bugs to escape the Microsoft Edge sandbox — cementing DEVCORE's position atop the leaderboard.

What Should Exchange Admins Do Right Now?

Microsoft is still working on a permanent fix. In the interim, two mitigations are available:

The Exchange Emergency Mitigation Service (EEMS) automatically applies protection via a URL rewrite configuration and is enabled by default on supported on-premises Exchange deployments. Admins should verify it's active.

For air-gapped or disconnected environments, Microsoft advises downloading the Exchange On-premises Mitigation Tool (EOMT) and running it via an elevated Exchange Management Shell — either per server or across all servers at once using the CVE-2026-42897 identifier.

Be aware that applying the mitigation introduces some side effects: OWA calendar printing may stop working, and inline images might not render correctly in the reading pane. Microsoft recommends using the Outlook desktop client as a workaround in both cases.

A permanent patch is planned for Exchange SE RTM, Exchange 2016 CU23, and Exchange Server 2019 CU14 and CU15. However, Exchange 2016 and 2019 updates will only be distributed to customers enrolled in the Period 2 Extended Security Update program — Period 1 ESU customers are excluded, as that program ended in April 2026.

With Exchange at the center of corporate email infrastructure — and often internet-exposed — organizations running on-premises deployments cannot afford to wait on this one.

Linux Kernel Had a Six-Year Bug That Let Anyone Steal SSH Host Keys and Root Passwords

protalweb@gmail.com (Vivek Gurung) — Fri, 15 May 2026 21:08:45 +0530

A logic flaw sitting quietly in the Linux kernel since at least 2020 — possibly longer — just got a working exploit, a public proof-of-concept, and a same-day patch from Linus Torvalds.

The vulnerability, dubbed ssh-keysign-pwn, was disclosed by Qualys on May 14, 2026, and patched by Linus Torvald the same day. The damage it could have done — and in unpatched environments still can — is significant: any unprivileged local user can silently read a server's SSH host private keys or the entire /etc/shadow file containing hashed user passwords.

The bug lives in __ptrace_may_access(), the kernel's gatekeeper for deciding whether one process can inspect another. The function skips its "dumpable" check when task->mm == NULL — a state that occurs briefly during process exit, after memory is released (exit_mm()) but before file descriptors are closed (exit_files()). That tiny window is everything.

An attacker uses pidfd_getfd(2) — a legitimate Linux syscall introduced in kernel 5.6 — to steal open file descriptors from a dying privileged process during that gap, when the caller's UID matches the target's. No root required. No special permissions needed.

Two ready-to-run exploits ship with the public PoC: sshkeysign_pwn targets the ssh-keysign utility, which opens sensitive host key files before dropping root privileges. By racing the process exit, an unprivileged user can lift those file descriptors. chage_pwn attacks the chage utility to pull /etc/shadow, enabling offline cracking of password hashes. The exploit reliably hits within 100–2,000 process spawns.

Six Years of Missed Warnings

Google security researcher Jann Horn had already proposed a patch for the underlying FD-theft behavior back in October 2020 — but it never made it through. The ssh-keysign fd-leaving pattern itself dates to 2002. chage's vulnerable spw_open + setreuid shape is similarly ancient. The flaw was there. The patch proposal existed. Nobody pushed it across the finish line for five years.

Who Is Affected

All stable Linux kernels as of May 14, 2026, are affected — everything before commit 31e62c2ebbfd. Confirmed vulnerable distributions include Arch Linux, Debian, Ubuntu, CentOS, and Raspberry Pi OS. If you run any mainstream Linux server or desktop and haven't applied yesterday's kernel update, your SSH host keys and shadow file are readable by any local user on the box.

The fix is in the mainline kernel as of May 14. Until you patch, a temporary workaround is removing execute permissions from ssh-keysign and chage — though this doesn't fix the underlying issue and may break legitimate functionality.

Update your kernel immediately and reboot — this is the only real fix
Rotate all SSH host keys on any system that may have been exposed
Force a password reset for privileged accounts if /etc/shadow was accessible
Run uname -r to confirm your running kernel includes commit 31e62c2ebbfd

The patch adjusts the kernel's ptrace behavior to properly handle the mm == NULL case. Linus described the new logic as "slightly saner" — an understated note for a bug that spent six years one race condition away from becoming a full server compromise.

Google Quietly Cut New Account Storage to 5GB — Your Phone Number Is Now the Price of 15GB

protalweb@gmail.com (Vivek Gurung) — Fri, 15 May 2026 08:59:59 +0530

Google has changed the rules on free storage for new accounts — and most users won't notice until it's too late. New Google accounts now default to just 5GB of free storage. To unlock the full 15GB shared across Gmail, Drive, and Google Photos, users must link and verify a phone number during account setup.

The prompt users now encounter makes the trade-off explicit: provide your number and get 15GB, or skip it and stay capped at 5GB. Google's stated rationale, visible within the signup flow itself, is that the phone number ensures the 15GB allocation is granted "only once per person" — effectively an anti-abuse measure to stop bots and throwaway accounts from hoarding free storage indefinitely.

The Change Was Already Underway in March

This didn't happen overnight. Google quietly changed its language around the included storage in mid-March. Where it previously promised an unconditional 15GB, it now offers "up to" 15GB across its services. Using the Internet Archive's WayBack Machine, the change can be traced to around March 18, 2026, and remains live today.

Google Calls It a Regional Test

A Google spokesperson confirmed to How-To Geek that the company is "testing" a storage policy for new accounts when they're created in "select regions," although it didn't name those areas. Current reports suggest the 5GB cap is most prevalent in parts of Africa, including Kenya and Nigeria. Existing accounts are not affected — only users creating fresh accounts going forward.

Why Now? AI Costs and Account Abuse

AI and automation have made multi-account abuse considerably easier — you can theoretically build a seamless storage pool without much manual effort. Malware creators could exploit this to store code and stolen data at scale. Google also isn't immune to the soaring memory prices driven by AI demand it's partly responsible for creating through Gemini.

The concern is that you still have to share your phone number to get 15GB of space that millions take for granted. Google and others already provide two-factor authentication without phone numbers specifically for privacy reasons — a data breach exposing your linked number is a real risk. Small business owners running dedicated work accounts without wanting to tie a personal number will also feel the friction.

What You Should Do

If you're creating a new Google account, link a phone number during setup to claim the full 15GB. After setup, check your actual storage allocation in Google Account settings — if it reads 5GB rather than 15GB, the account was created without phone verification.

Some users report still receiving 15GB without linking a phone, especially on Android devices set up without a SIM card, so your experience may vary by region and device.

Google's Security Team Built a Zero-Click Root Exploit for the Pixel 10

protalweb@gmail.com (Vivek Gurung) — Fri, 15 May 2026 07:55:23 +0530

Google's elite Project Zero security team has done it again — this time turning the Pixel 10 into a case study for how hardware driver vulnerabilities can silently hand an attacker full root control of your phone, no taps required.

In a research post published May 13, Project Zero researcher Seth Jenkins detailed a complete zero-click exploit chain for the Pixel 10, building on the team's earlier, three-part Pixel 9 research series published in January 2026. That earlier work had demonstrated it was possible to go from a zero-click context to root on Android in just two exploits — and Jenkins wanted to see if the same was possible on Google's latest flagship.

The Entry Point: A Dolby Audio Bug, Repurposed

The first link in the chain is CVE-2025-54957, a vulnerability in the Dolby Unified Decoder (UDC) — a library for processing Dolby Digital audio formats that is integrated across Android, iOS, Windows, and media streaming devices.

The dangerous part: the Dolby UDC is part of the zero-click attack surface of most Android devices because incoming audio messages in Google Messages are transcribed before a user even opens them. A malicious audio file sent as a message triggers the exploit with no interaction from the target.

Adapting the Dolby exploit for Pixel 10 was straightforward, Jenkins noted, with the main hurdle being that the Pixel 10 uses RET PAC instead of -fstack-protector, a different stack protection mechanism that requires a workaround.

The Escalation: A Video Driver With No Boundaries

On the Pixel 9, the second exploit leveraged the BigWave AV1 decoder driver. That driver doesn't exist on Pixel 10. But Jenkins and collaborator Jann Horn found something worse. Working together, they spent just 2 hours auditing the VPU driver — used for video decoding on the Tensor G5 chip — and discovered an exceptional vulnerability.

The flaw in the driver's mmap handler is disarmingly simple: the driver makes a call to remap_pfn_range based purely on the size of the VMA (virtual memory area) and not at all bound to the size of the hardware register region, meaning a caller can map as much physical memory as they want into userland — including the entire kernel image. Making matters worse, the kernel is always at the same physical address on Pixel, so an attacker knows exactly where it is relative to the returned mmap address — no scanning required.

The result: achieving arbitrary read-write access to the kernel required just 5 lines of code, and the full exploit took less than a day to write.

One Bright Spot: Faster Patching

Jenkins reported the VPU bug on November 24, 2025, and it was patched 71 days later in the February Pixel security bulletin — notably the first time Android patched a driver bug Jenkins reported within 90 days. Compare that to the Pixel 9 Dolby chain, where the UDC vulnerability remained unpatched on Pixel for 82 days after public disclosure, and the BigWave driver bug took until January 6, 2026, to fix.

Progress — but Project Zero isn't satisfied. Jenkins noted that after flagging the BigWave driver issues, he had hoped the same development team would audit their other drivers. Five months later, a serious, extremely shallow vulnerability was immediately apparent in their VPU driver during a cursory review.

What Pixel 10 Users Should Do

The VPU vulnerability was patched in the February 2026 Pixel security update. If your device is running the February 2026 Security Patch Level (SPL) or later, you are protected. Check under Settings → About phone → Android security update. The Dolby exploit only affects devices on SPL December 2025 or earlier.

The deeper lesson here goes beyond any single bug fix: as Android packs in more AI-powered features that silently process incoming media, the zero-click attack surface keeps growing — and hardware driver security hasn't kept pace.

NGINX Rift: An 18-Year-Old Bug Lets Hackers Hijack One-Third of the Internet's Web Servers

protalweb@gmail.com (Vivek Gurung) — Wed, 13 May 2026 23:32:21 +0530

A memory corruption flaw in NGINX's source code, hidden since 2008, now has a working exploit. An unauthenticated attacker anywhere on the internet can send a single crafted HTTP request to crash NGINX worker processes — or, under the right conditions, achieve full remote code execution on the server.

Researchers at depthfirst, an autonomous vulnerability analysis platform, discovered the flaw — now tracked as CVE-2026-42945 — while scanning the NGINX codebase in April. Their automated system flagged it within six hours. It was introduced in 2008 and has been quietly sitting in every standard NGINX build for nearly two decades. F5, which maintains NGINX, confirmed the issue on April 24 and published a coordinated advisory today.

NGINX powers approximately one-third of all websites globally. If your configuration uses rewrite directives with unnamed regex captures ($1, $2) alongside a replacement string containing a question mark, followed by another rewrite, if, or set directive — you are exposed. No authentication is required to trigger it.

Four CVEs, One Critical Hit

Depthfirst's scan returned five findings total. Four were confirmed by NGINX. The critical one dominates:

CVE-2026-42945 - (9.2 Critical)
CVE-2026-42946 - (8.3 High)
CVE-2026-40701 - (6.3 Medium)
CVE-2026-42934 - (6.3 Medium)

CVE-2026-42946 is also noteworthy: a state mismatch in the SCGI and uWSGI modules results in a cross-buffer pointer subtraction that yields a ~1 TB key length, causing a crash in the worker. The remaining two are a use-after-free in the SSL module and an out-of-bounds read in the charset module.

What Breaks and Why

The vulnerability lives in src/http/ngx_http_script.c, inside ngx_http_rewrite_module — a module present in every standard NGINX build. NGINX's script engine processes rewrite directives in two passes: first, it calculates how much memory to allocate, then it writes the actual data. The flaw breaks the contract between those two passes.

When a rewrite replacement string contains a question mark, a function called ngx_http_script_start_args_code sets an internal flag (e->is_args = 1) on the main script engine and never clears it.

A later set directive computes the buffer length using a freshly zeroed sub-engine — so it measures the capture as raw bytes, with no escaping. But when the actual write happens, the main engine still has is_args = 1, so it re-escapes the data through ngx_escape_uri in NGX_ESCAPE_ARGS mode. Every +, %, or &amp; character in an attacker's URI expands from one byte to three. The buffer was sized for the smaller value. The write runs past the allocation.

"The bytes written past the allocation are derived from the attacker's URI, so the corruption is shaped by the attacker rather than random." — depthfirst advisory

The researchers developed a working proof-of-concept demonstrating unauthenticated RCE with ASLR disabled. They also detail a theoretical technique — progressively overwriting pointer bytes across repeated requests — that could be used to defeat ASLR. NGINX's multi-process architecture actually aids exploitation: if a worker crashes, the master spawns a new one with an identical heap layout, giving attackers unlimited retries at no cost.

Who Is Affected

The scope is wide. Affected products span most of the NGINX ecosystem:

Product	Vulnerable Range	Fixed In
NGINX Open Source	0.6.27 – 1.30.0	1.31.0 / 1.30.1
NGINX Plus	R32 – R36	R36 P4 / R32 P6
NGINX Instance Manager	2.16.0 – 2.21.1	Move to fixed branch
NGINX App Protect WAF	4.9.0–4.16.0, 5.1.0–5.8.0	Move to fixed branch
NGINX Gateway Fabric	1.3.0–1.6.2, 2.0.0–2.5.1	Move to fixed branch
NGINX Ingress Controller	3.5.0–5.4.1 (multiple)	Move to fixed branch

F5 BIG-IP, BIG-IQ, Distributed Cloud, and Silverline are not affected.

What You Should Do Right Now

Upgrade first. For NGINX Open Source, upgrade to 1.31.0 or 1.30.1 and restart to reload workers with the patched binary. NGINX Plus users should apply R36 P4 or R32 P6.

If you can't patch immediately, convert unnamed regex captures to named captures in every affected rewrite directive:

# Vulnerable — unnamed captures with ? in replacement rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last; # Mitigated — named captures bypass the vulnerable code path rewrite ^/users/(?[0-9]+)/profile/(?

.*)$ /profile.php?id=$user_id&tab=$section last;

Named captures ((?<name>...)) do not pass through the vulnerable escaping logic. This configuration change removes the attack surface without a binary upgrade.

The broader implication here is harder to ignore than the patch itself. A bug this old, in software this widely deployed, was found not by a human auditor poring over diffs, but by an automated system running for six hours. That says something uncomfortable about the gap between how long critical infrastructure has been accumulating risk and how fast the tools to find it are now moving.

Linux Kernel Strikes Again: "Fragnesia" Is the Third Root-Level Flaw in Two Weeks

protalweb@gmail.com (Vivek Gurung) — Wed, 13 May 2026 22:53:21 +0530

Linux administrators have barely had time to recover from Copy Fail and Dirty Frag — and now there's a third exploit joining the same dangerous family. Security researchers at V12 Security have disclosed Fragnesia, a new Linux kernel local privilege escalation (LPE) vulnerability that gives any unprivileged local user a reliable, deterministic path to root — without needing a single host-level privilege to pull it off.

The timing couldn't be worse. As we covered here on Cyber Kendra, Copy Fail (CVE-2026-31431) — a 732-byte Python script that roots virtually every major Linux distribution since 2017 — dropped on April 29. Just one week later, Dirty Frag (CVE-2026-43284 / CVE-2026-43500), discovered by Korean researcher Hyunwoo Kim, chained two separate kernel bugs to deliver the same devastating outcome. Now, Fragnesia arrives as an unintended consequence of one of the very patches meant to fix Dirty Frag — a bitter irony that underscores just how fragile this surface area of the kernel has become.

What Makes Fragnesia Different

Fragnesia was discovered by William Bowling and the V12 team using their agentic security tooling, V12. Like its predecessors, it targets the Linux kernel's XFRM ESP-in-TCP subsystem — the component responsible for handling IPsec (encrypted network traffic) over TCP connections. The core bug is a logic flaw in how the kernel handles shared page fragments during socket buffer (skb) coalescing: the skb "forgets" that a fragment is shared, hence the name.

The attack is methodical and requires no race condition whatsoever. Here's what happens under the hood:

The exploit first calls unshare() to carve out an isolated user and network namespace — a standard unprivileged operation — which grants it CAP_NET_ADMIN (network administration capability) within that bubble, without any real privileges on the host. It then installs a crafted ESP security association using a known AES-128-GCM key.

Next, it builds a 256-entry lookup table mapping every possible keystream byte to a specific cryptographic nonce value. With that table in hand, the exploit splices file pages directly from the target binary — /usr/bin/su — into a TCP socket buffer before enabling ESP-in-TCP mode.

When the socket transitions into espintcp ULP (Upper Layer Protocol) mode, the kernel attempts to decrypt the queued data in-place. The result: the AES-GCM keystream is XORed directly into the kernel's page cache copy of the file, flipping exactly the bytes the attacker wants.

The exploit repeats this for each byte that needs changing, effectively overwriting the first 192 bytes of su with a small ELF stub that calls setresuid(0,0,0) and executes /bin/sh. Running su then drops you into a root shell. The on-disk binary is never touched — the corruption lives entirely in memory.

Who Is Affected

All Linux kernel versions affected by Dirty Frag are also affected by Fragnesia — specifically, any kernel without the patch published to the netdev mailing list on May 13, 2026. The exploit has been confirmed working on Ubuntu 22.04/24.04-era kernels (tested on 6.8.0-111-generic). Ubuntu's default AppArmor restrictions on unprivileged user namespaces can raise the bar slightly, but the README is explicit: that restriction only requires one additional bypass step and is out of scope for the vulnerability itself.

Microsoft has previously noted active in-the-wild exploitation of related techniques, observing campaigns that gain SSH access and immediately escalate privileges via su — a pattern consistent with both Dirty Frag and now Fragnesia.

What You Should Do Right Now

The mitigation is the same as for Dirty Frag. If your systems don't depend on IPsec ESP or the RxRPC protocol, disabling the vulnerable modules is the fastest interim fix:

rmmod esp4 esp6 rxrpc
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/fragnesia.conf

If you believe a system has already been exploited, the modified /usr/bin/su lives only in the page cache. Clear it before anyone else runs su:

echo 1 | tee /proc/sys/vm/drop_caches

Or simply reboot. Apply kernel patches from your distribution vendor as they become available — the upstream patch for this specific bug landed on May 13, 2026.

Three critical Linux LPEs in two weeks is not a coincidence — it's a signal that this region of the kernel has been underexamined for a long time. Keep an eye on your patch feeds.

Fragnesia was discovered by William Bowling and the V12 team. Technical details and a proof-of-concept are available in the V12 Security GitHub repository.

Composer Bug Silently Dumped GitHub Tokens Into CI Logs — Patch Now

protalweb@gmail.com (Vivek Gurung) — Wed, 13 May 2026 22:23:33 +0530

Millions of PHP developers who rely on Composer for dependency management were silently exposed to a token-leaking vulnerability this week — one that required no misconfiguration, no attacker interaction, and no unusual setup to trigger. Just running a normal composer install inside a GitHub Actions workflow was enough.

The issue, tracked as GHSA-f9f8-rm49-7jv2 with a CVE identifier still pending, was publicly reported on May 12, 2026, by GitHub user kesselb — first as a regular issue, then escalated to a security advisory just hours later. Fixed builds shipped within hours of the security report, on the morning of May 13.

What Actually Happened

GitHub has been quietly rolling out a new format for the auto-generated GITHUB_TOKEN that every Actions workflow receives. The new structure — shaped like ghs_<numeric-id>_<base64url-JWT> — includes a hyphen (-) character that was absent from the old format.

Composer has validated GitHub tokens since 2021 against an allowed character set that never included -. When the new-format token hit that validation in BaseIO::loadConfiguration(), Composer threw an UnexpectedValueException — and critically, the exception message interpolated the full token value verbatim:

// The exception that leaked everything

"Your github oauth token for github.com contains invalid characters: ghs_12345_ABC-xyz..."

Symfony Console then wrote that message to stderr. In any CI environment, stderr is captured and persisted in job logs — logs that are visible to every repository collaborator, and sometimes stored by third-party log shippers, monitoring tools, or support systems.

"Users do not need to opt into any unusual configuration; the leak occurs on the default code path whenever an affected token format is in use."

Three factors conspired to make this worse than a typical error message leak. GitHub Actions' built-in secret masker works by exact substring matching — but when Symfony Console renders the exception, it may wrap text or inject ANSI escape sequences, breaking the masker's pattern detection. The token sailed through unredacted.

Who Was Exposed

Any workflow that configured a GITHUB_TOKEN or GitHub App installation token into Composer's authentication, then ran any Composer command, was affected if GitHub had already migrated that repository to the new token format. Crucially, popular Actions like shivammathur/setup-php do this automatically — no deliberate Composer auth setup required.

Packagist confirmed it is unaffected. Private Packagist also escaped exposure since GitHub had not yet issued the new token format for their GitHub App — and they've since applied the patch and audited their logs.

GitHub has rolled back the new token format rollout, buying the PHP ecosystem time to patch. The immediate urgency to disable GitHub Actions has passed, but the patch should still be applied before GitHub resumes the rollout.

The Fix

Composer 2.9.8 and 2.2.28 address both root causes. The exception message no longer includes the rejected token value — diagnostic output now identifies which credential failed without revealing its contents. Additionally, the validation character set now accepts -, matching GitHub's current structured token format. This second fix also protects against future credentials with similar character sets hitting the same error path.

What You Should Do Right Now

Update Composer immediately with composer.phar self-update. If you use shivammathur/setup-php and did not pin the Composer tool to a specific version, you're likely already protected. If you pinned it, update the pin explicitly.

Run composer.phar self-update immediately to upgrade to Composer 2.9.8 (mainline) or 2.2.28 (LTS). Legacy users should target 1.10.28, though upgrading to 2.x is strongly recommended.

Review recent GitHub Actions job logs for any runs that printed token-shaped strings. Delete log contents where leaked tokens may not yet have expired — particularly for self-hosted runners, where the window can stretch to 24 hours. For any GitHub App installation tokens found in logs, revoke them immediately via the GitHub Apps API regardless of apparent expiry.

This incident is a sharp reminder that secret masking in CI is a last-resort safety net, not a primary control — and that incremental format changes in one tool can quietly break security assumptions in another, with no warning until credentials are already written to persistent logs.

WhatsApp's New Incognito AI Chat Is Genuinely Private — But Read the Fine Print

protalweb@gmail.com (Vivek Gurung) — Wed, 13 May 2026 21:50:59 +0530

WhatsApp today launched Incognito Chat with Meta AI, a mode where conversations are processed in a secure environment that even Meta cannot access, with messages disappearing by default once you close the session.

It's a genuinely bold privacy claim from a company not historically associated with restraint when it comes to user data — and the technical architecture behind it is more sophisticated than the marketing suggests.

This isn't just a "delete after read" gimmick. Private Processing, the underlying system, is built on Trusted Execution Environments (TEEs) — hardware-isolated enclaves where even the server operator cannot inspect what's being computed. Concretely, Meta is running AMD EPYC processors with SEV-SNP (Secure Encrypted Virtualisation-Secure Nested Paging), which encrypts virtual machine memory so that even the hypervisor — the software layer that normally has god-mode access to VMs — is locked out.

Your request travels from your phone through a third-party Oblivious HTTP relay (currently Fastly), which strips your IP address before it ever reaches Meta's infrastructure. An Anonymous Credentials Service authenticates you as a legitimate WhatsApp user without revealing you identity. The result: Meta's own load balancers route your request without knowing it's yours.

Before your device sends a single byte of conversation data, it cryptographically verifies that the server it's talking to is actually running the attested code — a process logged to a third-party transparency log operated by Cloudflare. If the code has been tampered with, your phone refuses to connect.

How Private Processing Works — White Paper
How Private Processing works

Here's where it gets interesting — and where most coverage stops short. Meta's own technical white paper acknowledges two meaningful gaps.[PDF]

First, when AI inference requires multiple GPUs (which large language models routinely do), the NVLink interconnect between those GPUs is not encrypted on NVIDIA's Hopper platform. Meta acknowledges this is a potential interception avenue, mitigated mainly by NVLink's high bandwidth, making real-time sniffing difficult with currently available hardware. That's not a theoretical fix — it's a practical one.

Second, web search. When Meta AI needs real-time information, the search query leaves the TEE entirely and is sent to Meta infrastructure, which forwards it to external search providers. Queries are capped at 100 characters and limited to 5 per prompt, and Meta says searches are unlinked from user identity — but that still means data is leaving the privacy bubble. Users can disable web search, but it's on by default.

Prof. Alan Woodward, a cybersecurity expert at Surrey University, raised a concern that the disappearing, unretrievable nature of these chats creates an accountability vacuum — if an AI's response leads to harm, there's no chat history to investigate.

WhatsApp head Will Cathcart acknowledged that the feature is initially text-only and that Meta AI's safety filters will refuse harmful requests more aggressively in this mode than in standard chats. Yahoo!

Cathcart said the mode "will steer the user towards helpful information if it can and then refuse and eventually even just stop interacting with the user completely" for harmful queries — but the inability to audit that process after the fact is a real trade-off users should understand before assuming total safety. ABC News

What's Coming Next

Meta is also building Side Chat with Meta AI, which will let users privately ask Meta AI about an ongoing WhatsApp conversation — summarising threads or answering context-aware questions — without disrupting the main chat. That feature is arriving later this year and is also protected by Private Processing. Engadget

The rollout of Incognito Chat is gradual across WhatsApp and the Meta AI app over the coming months. For users who routinely ask AI about health symptoms, financial decisions, or personal situations, the hardware-level privacy guarantee is meaningful — just not unconditional.

Microsoft's AI Just Found 16 Windows Vulnerabilities Humans Missed — And It's Only Getting Started

protalweb@gmail.com (Vivek Gurung) — Wed, 13 May 2026 07:59:00 +0530

For decades, finding dangerous bugs buried deep inside Windows has been a job for elite human researchers armed with time and hard-won instinct. Today's May 2026 Patch Tuesday quietly marks the moment that changes — because 16 of the vulnerabilities Microsoft patched this month were found not by a human, but by an AI system that argues with itself.

Microsoft's CEO, Satya Nadella, noted that their new multi-model agentic security system brings together more than 100 specialized agents across frontier and custom models to find exploitable bugs, delivering top performance on the CyberGym benchmark. Microsoft used it ahead of Patch Tuesday to help find and fix 16 vulnerabilities.

Microsoft's Autonomous Code Security (ACS) team publicly revealed MDASH — its multi-model agentic scanning harness — alongside this month's security bulletin. The system orchestrates over 100 specialized AI agents across an ensemble of frontier and distilled models, each assigned a distinct role: auditor, debater, deduplicator, or prover.

The architecture is deliberately adversarial — one agent flags a suspicious code path, another argues against it, and a finding only advances if it survives that cross-examination. The whole point is to kill false positives before they waste an engineer's morning.

The results are hard to argue with. On the public CyberGym benchmark — 1,507 real-world vulnerabilities drawn from 188 open-source projects — MDASH scored 88.45%, leading the leaderboard by roughly five points over the next competitor.

Tested against five years of confirmed Microsoft Security Response Center (MSRC) cases in two of Windows' most scrutinized kernel components, it achieved 96% recall on clfs.sys and a clean 100% on tcpip.sys. On a private test driver seeded with 21 deliberately injected vulnerabilities, it found all 21 with zero false positives.

The Bugs That Prove the Point

Two of this month's Critical findings demonstrate exactly why a single AI model — or a single human — would likely have missed them.

CVE-2026-33827 is a use-after-free (UAF) in the Windows kernel TCP/IP stack, reachable by a remote, unauthenticated attacker via specially crafted IPv4 packets that carry the SSRR routing option.

The flaw isn't obvious because the vulnerable pointer release and its later reuse are separated by multiple validation checks and alternate control flow branches. No single function view connects the dots. MDASH caught it by cross-referencing analogous patterns elsewhere in the codebase, flagging the inconsistency — exactly what a senior human researcher would do after days of staring at the same code.

CVE-2026-33824 is worse from an exploitation standpoint. It lives in ikeext.dll, the Windows IKEv2 service that handles VPN keying for DirectAccess and Always-On VPN. A shallow memcpy during fragment reassembly leaves two owners holding the same heap pointer — and both eventually free it. That double-free spans six source files.

Two UDP packets, no race condition, no special timing required. Because IKEEXT runs as LocalSystem within svchost.exe, successful exploitation results in full system compromise before the attacker has authenticated to anything. Both bugs were patched in April and are now publicly disclosed.

These 16 CVEs don't exist in isolation. May's Patch Tuesday is a 120+ vulnerability release — fixing 120 flaws, 17 of which are rated Critical and 14 of which are remote code execution vulnerabilities. The network attack surface this month is particularly wide: high-value targets include Windows DNS Client (CVE-2026-41096), Netlogon (CVE-2026-41089), Windows Native Wi-Fi Miniport, and multiple Office and Word RCEs — components routinely exposed to untrusted network traffic and documents.

Critically, MDASH isn't just another scanner. Microsoft's architecture deliberately separates the system from any single model — when a better model ships, swapping it in is a configuration change, not a rebuild. That's the strategic bet: the pipeline outlasts the model.

The broader industry is feeling the same pressure — Anthropic's Mythos vulnerability discovery model recently surfaced 271 vulnerabilities in Firefox 150 prior to release, driving an unprecedented coalition of 12 companies, including Apple, Amazon, Cisco, and Microsoft, into a shared AI security research agreement called Project Glasswing.

NIST has already announced it can no longer enrich every CVE at the current volume. Oracle moved from quarterly to monthly patch cycles. The pipeline of AI-discovered bugs is now moving faster than the industry's traditional patching machinery was designed to handle.

What You Should Do Right Now

If you manage Windows systems, this month's priorities differ from usual. The MDASH-discovered flaws are concentrated in network-exposed kernel components — tcpip.sys, ikeext.dll, netlogon.dll, and dnsapi.dll — meaning internet-facing machines, VPN gateways, and domain controllers are the sharpest edge of risk. Patch those first. Microsoft Office RCEs exploitable via the preview pane are a close second priority for end-user environments.

There's also a harder deadline looming: the Secure Boot certificate expiration on June 26, 2026, gives organizations roughly 45 days to complete deployment before Windows devices enter a degraded security state. May's Patch Tuesday is the last comfortable window to handle that at scale.

The AI didn't just find these bugs. It proved to them — by constructing triggering inputs, validating exploitability, and handing engineers confirmed findings rather than a speculation queue. That's the real shift. The question for defenders going forward is less "can AI find bugs" and more "how fast can we patch what it finds"

Googlebook: Google’s Android laptop platform for Gemini PCs

protalweb@gmail.com (Vivek Gurung) — Tue, 12 May 2026 21:38:00 +0530

Update- Google Confirms Googlebook Adding Gemini Intelligence and Android apps

Fifteen years after Chromebook redefined affordable laptops, Google is quietly retiring the concept — and replacing it with something far more ambitious.

A leaked internal slide, first published by XDA before being pulled (a near-certain sign of a pre-announcement takedown), reveals Googlebook: a new laptop platform that puts Gemini AI at the centre of the operating system itself, not as an app or assistant, but as the interface layer.

The most technically striking feature isn't the hardware or the branding — it's Magic Pointer, developed in partnership with Google DeepMind. The AI-driven cursor doesn't just move where you click; it reads what's on your screen and proactively suggests actions. Spot a date in an email? Magic Pointer surfaces a calendar invite. Open two photos? It can composite them into a new image on the spot.

Googlebook · First Look

1 / 6

Create My Widget lets users generate live, data-connected dashboards through plain-language prompts, pulling from Gmail, Google Calendar, and other services. Meanwhile, Cast My Apps streams the apps installed on your Android phone to your laptop — no local installation required. The leaked slide shows a roster including Adobe Photoshop, CapCut, Spotify, Roblox, and Uber.

The hardware partners confirmed on the slide — Acer, ASUS, Dell, HP, and Lenovo — mirror the original Chromebook launch playbook. Devices are expected this fall, each featuring Glowbar, a Google-branded RGB light strip running along the chassis edge.

We can't tell whether these Googlebooks will run on the rumoured Aluminium OS. However, it seems possible, although official information and confirmations are still pending.

In the past, we learned that a new Android-powered PC operating system is running on the latest Android 16 platform. Google plans to merge its ChromeOS and Android for PC projects into a single branch, resulting in an Android for PC version called "Aluminium OS." This new OS will incorporate Google's advanced AI technologies from Gemini.

Google is expected to formally unveil Googlebook at today's Android Show: I/O Edition. Whatever gets confirmed, the Chromebook era has effectively ended — and the age of the intelligence-first laptop is beginning.

Google Confirms Googlebook Adding Gemini Intelligence and Android apps

protalweb@gmail.com (Vivek Gurung) — Tue, 12 May 2026 23:05:00 +0530

We called it. Now Google's made it official: the Chromebook era is over, and Googlebook is the intelligence-first laptop that replaces it — not with better specs, but with a fundamentally different idea of what a laptop should do.

When we first reported on the Googlebook leak today, it looked like a pre-I/O tease — internal slides, hardware renders, and a brand name too clean to be accidental. Today, Google's Senior Director for Laptops & Tablets, Alex Kuscher, confirmed everything on the official Google blog and added enough new details to change how you should think about the device entirely.

The headline-grabbing feature is Magic Pointer — but calling it a smarter cursor undersells what it actually is. Built in collaboration with the Google DeepMind team, Magic Pointer brings Gemini's contextual intelligence directly to the cursor itself.

The idea sounds small until you think about how little the cursor has changed since right-click was invented. Point at a date in an email, and it surfaces a calendar invite. Hover over two photos, and it can composite them into a new image right there. It's not an assistant you call; it's ambient intelligence woven into every mouse movement.

What Google didn't make explicit in the blog post — but what's worth spelling out — is the strategic architecture here. Google is merging the best of Android (Google Play apps, a modern OS built for intelligence) with ChromeOS (the world's most popular browser) into a single platform called Googlebook. This isn't a rebrand. It's a platform consolidation that's been years in the making, and it signals that ChromeOS as a standalone OS is effectively being retired into this new combined foundation.

Cast My Apps — the feature that streams your Android phone's apps directly to your Googlebook without any local installation — is more disruptive than it sounds. Apps like Adobe Photoshop, CapCut, and Uber running on your laptop from your phone's install means your laptop's app library is no longer determined by what's available for that OS. It's a direct shot at the "app gap" problem that dogged Chromebooks for years.

The Quick Access feature extends this phone-laptop continuity further, letting users view, search, and insert files directly from their Android phone through the Googlebook file browser — no transfers, cables, or cloud sync required. For anyone who's spent time AirDropping files between devices, this will feel like a long-overdue feature that Apple hasn't cracked between iPhone and Mac.

Create your Widget lets users generate live, personalized dashboards by simply describing what they want in plain language. Gemini connects to Gmail, Calendar, and the web to build it — so a family reunion planner, for example, could pull in flights, hotel bookings, restaurant reservations, and a countdown into one desktop widget. It's the kind of feature that sounds like a demo until you try it in a real workflow.

The hardware side is deliberately premium. Acer, ASUS, Dell, HP, and Lenovo are the confirmed launch partners, with devices arriving this fall. Every Googlebook will carry the Glowbar — a branded light strip along the chassis edge that Google describes as both functional and a design statement. Whether it serves a notification purpose (think iPhone's Dynamic Island, but physical) or is purely aesthetic hasn't been spelled out yet, which is perhaps the one gap the official announcement leaves open.

What's still unconfirmed is the underlying OS. Our earlier reporting pointed to Aluminium OS — Google's internal Android-for-PC branch built on Android 16 — as the likely engine under the hood. Google's blog references Android and Chrome OS convergence without naming the OS directly, which aligns with the company's approach of not burying the headline under an OS name nobody's heard of yet.

The bigger picture: Google just drew a line between the laptop market as it was (cloud-dependent, browser-first, budget-oriented) and what it wants laptops to become — devices where the intelligence layer, not the hardware spec sheet, is the primary selling point. That's a direct challenge to Microsoft's Copilot+ PC push, and the race to define the "AI PC" category just got a serious new entrant.

Googlebook devices launch this fall.