Google Releases Chrome 153 Fixing 230 Vulnerabilities Including Zero-Day Exploit
Google has released Chrome 153 on September 8, 2026, addressing a total of 230 vulnerabilities, including a zero-day flaw already under active exploitation.
The update ships as version 153.0.8010.37 and 153.0.8010.36 for Windows and macOS, and 153.0.8010.36 for Linux. Five issues rated Critical were resolved, covering use-after-free vulnerabilities in WebGL (CVE-2026-87464 and CVE-2026-87488), an out-of-bounds write (CVE-2026-87438), a buffer overflow (CVE-2026-87527), and a use-after-free in the Cast component (CVE-2026-87628).
Additional high-severity fixes were applied across multiple components including ANGLE, PDFium, V8, DevTools, Web Authentication, and Payments. The medium-severity zero-day CVE-2026-87491 in the V8 engine involves an out-of-bounds write and was reported on August 6, 2026; exploitation has already been confirmed.
Full list of patched CVEs
Critical: CVE-2026-87438, CVE-2026-87464, CVE-2026-87488, CVE-2026-87527, CVE-2026-87628
High: CVE-2026-87440, CVE-2026-87444, CVE-2026-87447, CVE-2026-87460, CVE-2026-87467, CVE-2026-87474, CVE-2026-87480, CVE-2026-87492, CVE-2026-87498, CVE-2026-87499, CVE-2026-87500, CVE-2026-87512, CVE-2026-87514, CVE-2026-87517, CVE-2026-87520, CVE-2026-87524, CVE-2026-87525, CVE-2026-87536, CVE-2026-87542, CVE-2026-87552, CVE-2026-87554, CVE-2026-87558, CVE-2026-87564, CVE-2026-87569, CVE-2026-87572, CVE-2026-87578, CVE-2026-87581, CVE-2026-87585, CVE-2026-87587, CVE-2026-87596, CVE-2026-87604, CVE-2026-87607, CVE-2026-87612, CVE-2026-87621, CVE-2026-87633, CVE-2026-87639, CVE-2026-87646, CVE-2026-87647, CVE-2026-87650, CVE-2026-87651, CVE-2026-87654
Medium: CVE-2026-87431 through CVE-2026-87658 (115 CVEs total, including the exploited CVE-2026-87491)
Low: CVE-2026-87429, CVE-2026-87430, CVE-2026-87437 and 48 additional low-severity issues
Google plans to complete the staged rollout over the next several days to weeks.
Related articles
CISA Adds BeyondTrust Remote Support and Fortinet Flaws to KEV Catalog Following Zero-Day Exploitation by ARMORY CASTLE
The US Cybersecurity and Infrastructure Security Agency has added two vulnerabilities affecting Fortinet and BeyondTrust products to its Known Exploited Vulnerabilities catalog. CVE-2026-102764 is an authentication bypass flaw in BeyondTrust Remote Support that allows remote attackers to manipulate appliance files without credentials due to insufficient source validation. BeyondTrust released an advisory on October 15, 2026, rating the issue 9.3 on CVSS v4.0 as Critical. Mandiant attributes the zero-day exploitation to the suspected Chinese group ARMORY CASTLE, which deployed web shells for persistence and privilege escalation in late August. The second CVE, CVE-2025-61624, also appears on the KEV list but lacks further public technical details in the current advisory. Organizations are urged to apply patches immediately to prevent further compromise.
Use-After-Free in HTTP/2 Upload Leads to Potential RCE in curl: Detailed Analysis of CVE-2026-92392
In curl 8.23.0, developers fixed a high-severity Use-After-Free vulnerability tracked as CVE-2026-92392 that could allow remote code execution during HTTP/2 uploads. The flaw stems from a dangling pointer left on an easy handle after a server resets an HTTP/2 stream, which later gets dereferenced when the multi handle closes. An attacker controlling the server can influence memory contents to hijack a function pointer and execute arbitrary code, though successful exploitation requires precise conditions including upload size, memory layout, and knowledge of the target architecture. The issue was discovered by Luna Tong at Anthropic using their OSS Scanner and reported to the curl security team on September 15. The team accelerated the release cycle by two weeks to deliver the fix while maintaining standard procedures. curl maintainers continue reducing internal handle pointers in favor of identifiers and are adding more tests and static analysis to prevent similar memory-safety errors. The vulnerability highlights ongoing risks in C-based networking code handling multiplexed protocols like HTTP/2.
Automating Asset Scanning in MaxPatrol VM via API: Part 4 on Authentication
A detailed technical guide explains how to build asset scanning automation in MaxPatrol VM using its API, starting with authentication methods. The author covers three authorization options including local account login-password, domain account credentials, and reference tokens, providing working Python examples for local accounts. Code reads secrets from an .env file and obtains a Bearer token valid for 24 hours from the Core role instance. The post details required privileges in both the Management Console and MaxPatrol 10 for tasks such as vulnerability exports, dynamic asset group management, scan task creation, and report exporting. It credits Alexey Leonov for an early GitHub script that enabled practical API usage and lists additional resources including webinars, SDK, CLI, Jira integration, and a Postman collection. All subsequent API calls rely on the generated headers containing the Bearer token.
Securing Hadoop Clusters: Removing Passwords from XML Configs with Credential Provider API and JCEKS
Hadoop configurations frequently expose sensitive credentials such as database passwords and cloud access keys in plain text within files like hive-site.xml and core-site.xml. The Credential Provider API, introduced in Hadoop 2.6, allows applications to retrieve secrets from an external JCEKS keystore instead of embedding them directly in XML. This mechanism uses conf.getPassword() to fetch decrypted values from the keystore when hadoop.security.credential.provider.path is configured. JCEKS relies on the outdated PBEWithMD5AndTripleDES algorithm, which remains vulnerable to Sweet32 attacks in theory though practical risk for small keystore files is low. Master password protection for the keystore itself is the weakest link, with options including environment variables, protected password files, or HDFS Transparent Data Encryption. Arenadata has automated credential encryption management in its ADH platform through ADCM to handle keystore creation, permission setting, and rotation across cluster nodes.