Gmail Address Variants Bypass String Comparison and Enable Multiple Registrations
A developer investigation revealed that one user had successfully registered four separate accounts using only legitimate Gmail address variants that all route to the same mailbox: Ivan.Petrov@gmail.com, ivanpetrov@gmail.com, ivan.petrov+shop@gmail.com, and IVAN.PETROV@gmail.com.
Colleagues noticed more user records than actual people in the database. The discrepancy traced back to a single line of code that compared email addresses as raw strings without normalization.
Gmail treats the local part of an address case-insensitively, discards everything after a plus sign, and ignores dots. These rules let one inbox generate an unlimited number of distinct strings that still receive mail at the same destination.
Why string comparison fails
Three common cases break naive equality checks:
- Case differences in the local part or domain
- Plus-addressing suffixes such as +shop or +promo
- Dots inserted anywhere in the local part of a Gmail address
Normalization must be applied selectively. Dots are ignored only for gmail.com and googlemail.com; applying the same rule to other providers would incorrectly merge unrelated mailboxes.
Homograph domain attacks
A separate but related threat appears when domains contain visually identical Cyrillic characters. The string еxample.ru (with Cyrillic е) encodes under IDNA to xn--xample-2of.ru, creating a look-alike address that passes superficial inspection yet points elsewhere.
Recommended implementation
Store two fields: the original address for sending mail and a normalized address for uniqueness enforcement. Perform lower-casing on the entire address, strip plus-suffixes only for Gmail, remove dots only for Gmail, and run every submitted domain through IDNA encoding to detect hidden non-ASCII labels. A simple confirmation email remains the most reliable validator of deliverability.
A diagnostic query can surface existing problems by grouping on the normalized domain and comparing raw versus deduplicated local parts.
Related articles
Dangling DNS Records Expose Companies to Subdomain Takeovers Years After Projects Shut Down
A marketing team requested reactivation of a three-year-old promotional landing page, only to discover that its domain now served an unrelated third-party website. The root cause was a forgotten CNAME record in the company's DNS zone that continued pointing to a project name on external hosting after the original service had been decommissioned. Because many hosting providers use wildcard DNS entries, standard availability checks and simple DNS resolution tests fail to detect that the target project no longer exists. Attackers who re-register the freed project name can then serve content under the company's legitimate subdomain, automatically obtaining valid TLS certificates and inheriting domain-wide cookies. The article details how such dangling records accumulate across infrastructure, marketing, and acquired company zones, and explains the concrete risks including cookie theft, bypass of Content-Security-Policy, and unauthorized domain ownership proofs. It concludes with a practical remediation workflow: export the full zone, assign owners to every record, validate external targets by application response rather than DNS resolution, and embed record removal into decommissioning procedures.
Google Patches Actively Exploited V8 Zero-Day in Chrome (CVE-2026-85046)
Google has released an urgent update for Chrome to address CVE-2026-85046, a high-severity zero-day vulnerability in the V8 JavaScript engine that is being actively exploited in the wild. The flaw is a type confusion issue within the Maglev compiler, specifically tied to optimizations around Array.prototype.sort, which can lead to arbitrary memory read and write primitives inside the JavaScript heap. Attackers can exploit the vulnerability by tricking victims into visiting a specially crafted HTML page, enabling remote code execution within the browser sandbox. The update brings Chrome to version 152.0.7977.82 or higher on Windows, macOS, and Linux, while also addressing a total of 12 vulnerabilities. The issue was reported by researcher Salvatore Gulizia, known as Serotav, who received a $1,000 reward. Other Chromium-based browsers such as Edge, Brave, Opera, and Vivaldi will require corresponding updates from their vendors.
Google Patches Actively Exploited V8 Zero-Day in Chrome (CVE-2026-85046)
Google has released an urgent update for Chrome to address CVE-2026-85046, a high-severity zero-day vulnerability in the V8 JavaScript and WebAssembly engine that is being actively exploited in the wild. The flaw is a type confusion issue tied to the Maglev compiler and optimizations around Array.prototype.sort, which can lead to arbitrary memory read and write primitives inside the JavaScript heap. Successful exploitation allows a remote attacker to execute arbitrary code within the browser sandbox after a victim visits a specially crafted HTML page, a technique commonly seen in malvertising and compromised-site campaigns. The fix is included in Chrome 152.0.7977.82 and later for Windows, macOS, and Linux, and the update also resolves a total of twelve vulnerabilities. The vulnerability was reported on 4 August 2026 by researcher Salvatore Gulizia, known as Serotav, who received a $1,000 reward. Other Chromium-based browsers such as Microsoft Edge, Brave, Opera, and Vivaldi will require corresponding updates from their respective vendors.
CISA Adds Seven Actively Exploited Vulnerabilities to KEV Catalog, Including SonicWall and LiteLLM Flaws Targeting AI Infrastructure
CISA has added seven vulnerabilities confirmed to be exploited in the wild to its Known Exploited Vulnerabilities catalog, with two carrying CVSS scores of 10.0. The list includes critical issues in SonicWall SMA 1000 devices, JFrog Artifactory, Kestra workflow engine, and LiteLLM AI gateway components. Attackers are now systematically targeting AI infrastructure to steal large language model API keys and configuration data from databases such as LiteLLM_ProxyModelTable. Qilin ransomware operators have already chained LiteLLM flaws for remote code execution and data theft. CISA has set a 48-hour remediation deadline for federal agencies, underscoring the urgency for all organizations running these components.