gbhackers - A chilling discovery by Koi Security has exposed a sophisticated browser hijacking campaign dubbed “RedDirection,” compromising over 1.7 million users through 11 Google-verified Chrome extensions.

This operation, which also spans Microsoft Edge with additional extensions totaling 2.3 million infections across platforms, exploited trusted signals like verification badges, featured placements, and high install counts to distribute malware under the guise of legitimate productivity and entertainment tools.

The RedDirection campaign stands out due to its deceptive strategy of remaining benign for years before introducing malicious code via silent updates, a tactic that evaded scrutiny from both Google and Microsoft’s extension marketplaces.

These updates, auto-installed without user intervention, transformed trusted tools into surveillance platforms capable of tracking every website visit, capturing URLs, and redirecting users to fraudulent pages via command-and-control (C2) infrastructure like admitclick.net and click.videocontrolls.com.

Google has issued an urgent security update for its Chrome browser, addressing a critical zero-day vulnerability that is being actively exploited by attackers.

The flaw, tracked as CVE-2025-6554, is a type confusion vulnerability in Chrome’s V8 JavaScript engine, which underpins the browser’s ability to process web content across Windows, macOS, and Linux platforms.

The vulnerability was discovered by Clément Lecigne of Google’s Threat Analysis Group (TAG) on June 25, 2025. According to Google, attackers have already developed and deployed exploits targeting this flaw in the wild, prompting the company to act quickly.

Learn about the new permission prompt for sites that connect to local networks.
Published: June 9, 2025

Chrome is adding a new permission prompt for sites that make connections to a user's local network as part of the draft Local Network Access specification. The aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks, and to reduce the ability of sites to use these requests to fingerprint the user's local network.

To understand how this change impacts the web ecosystem, the Chrome team is looking for feedback from developers who build web applications that rely on making connections to a user's local network or to software running locally on the user's machine. From Chrome 138, you can opt-in to these new restrictions by going to chrome://flags/#local-network-access-check and setting the flag to "Enabled (Blocking)".

Note: Chrome previously experimented with restricting access to local network devices with Private Network Access, which required CORS preflights where the target device opted in to being connected to, instead of gating all local network accesses behind a permission prompt. Local Network Access replaces that effort, after PNA was put on hold. Thank you to everyone who helped test PNA and provide feedback to us—it has been incredibly valuable and helped guide us to our new Local Network Access permission approach.
What is Local Network Access?
Local Network Access restricts the ability of websites to send requests to servers on a user's local network (including servers running locally on the user's machine), requiring the user grant the site permission before such requests can be made. The ability to request this permission is restricted to secure contexts.

A prompt with the text 'Look for and connect to any device on your local network.'
Example of Chrome's Local Network Access permission prompt.
Many other platforms, such as Android, iOS, and MacOS have a local network access permission. For example, you may have granted this permission to access the local network to the Google Home app when setting up new Google TV and Chromecast devices.

What kinds of requests are affected?
For the first milestone of Local Network Access, we consider a "local network request" to be any request from the public network to a local network or loopback destination.

A local network is any destination that resolves to the private address space defined in Section 3 of RFC1918 in IPv4 (e.g., 192.168.0.0/16), an IPv4-mapped IPv6 address where the mapped IPv4 address is itself private, or an IPv6 address outside the ::1/128, 2000::/3, and ff00::/8 subnets.

Loopback is any destination that resolves to the "loopback" space (127.0.0.0/8) defined in section 3.2.1.3 of RFC1122 of IPv4, the "link-local" space (169.254.0.0/16) defined in RFC3927 of IPv4, the "Unique Local Address" prefix (fcc00::/7) defined in Section 3 of RFC4193 of IPv6, or the "link-local" prefix (fe80::/10) defined in section 2.5.6 of RFC4291 of IPv6.

A public network is any other destination.

Note: In the future, we plan to extend these protections to cover all cross-origins requests going to destinations on the local network. This would include requests from a local server (for example, https://router.local) to other servers on the local network, or from a local server to localhost.
Because the local network access permission is restricted to secure contexts, and it can be difficult to migrate local network devices to HTTPS, the permission-gated local network requests will now be exempted from mixed content checks if Chrome knows that the requests will be going to the local network before resolving the destination. Chrome knows a request is going to the local network if:

The request hostname is a private IP literal (e.g., 192.168.0.1).
The request hostname is a .local domain.
The fetch() call is annotated with the option targetAddressSpace: "local".

// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");

// Example 2: .local domain is exempt from mixed content.
fetch("http://router.local/ping");

// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");

// Example 4: Adding the targetAddressSpace option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
targetAddressSpace: "local",
});
What's changing in Chrome
Chrome 138
Our initial version of Local Network Access is ready for opt-in testing in Chrome 138. Users can enable the new permission prompt by setting chrome://flags#local-network-access-check to "Enabled (Blocking)". This supports triggering the Local Network Access permission prompt for requests initiated using the JavaScript fetch() API, subresource loading, and subframe navigation.

A demo site is available at https://local-network-access-testing.glitch.me/ for triggering different forms of local network requests.

Known issues and limitations
The new permission prompt is currently only implemented on Desktop Chrome. We are actively working on porting it to Android Chrome. (Tracked in crbug.com/400455013.)
WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834), and WebRTC (crbug.com/421223919) connections to the local network are not yet gated on the LNA permission.
Local network requests from Service Workers currently require that the service worker's origin has previously been granted the Local Network Access permission.
If your application makes local network requests from a service worker, you will currently need to separately trigger a local network request from your application in order to trigger the permission prompt. (We are working on a way for workers to trigger the permission prompt if there is an active document available—see crbug.com/404887282.)
Chrome 139 and beyond
Our intent is to ship Local Network Access as soon as possible. Recognizing that some sites may need additional time to be updated with Local Network Access annotations, we will add an Origin Trial to let sites temporarily opt-out of the secure contexts requirement before we ship Local Network Access by default. This should provide a clearer migration path for developers, especially if you rely on accessing local network resources over HTTP (as these requests would be blocked as mixed content if requested from an HTTPS page in browsers that don't yet support the Local Network Access mixed content exemption).

We will also be adding a Chrome enterprise policy for controlling which sites can and cannot make local network requests (pre-granting or pre-denying the permission to those sites). This will allow managed Chrome installations, such as those in corporate settings, to avoid showing the warning for known intended use cases, or to further lock down and prevent sites from being able to request the permission at all.

We plan to continue integrating the Local Network Access permission with different features that can send requests to the local network. For example, we plan to ship Local Network Access for WebSockets, WebTransport, and WebRTC connections soon.

We will share more information as we get closer to being able to fully launch Local Network Access in Chrome.

Google on Monday released a fresh Chrome 137 update to address three vulnerabilities, including a high-severity bug exploited in the wild.

Tracked as CVE-2025-5419, the zero-day is described as an out-of-bounds read and write issue in the V8 JavaScript engine.

“Google is aware that an exploit for CVE-2025-5419 exists in the wild,” the internet giant’s advisory reads. No further details on the security defect or the exploit have been provided.

However, the company credited Clement Lecigne and Benoît Sevens of Google Threat Analysis Group (TAG) for reporting the issue.

TAG researchers previously reported multiple vulnerabilities exploited by commercial surveillance software vendors, including such bugs in Chrome. Flaws in Google’s browser are often exploited by spyware vendors and CVE-2025-5419 could be no different.

According to a NIST advisory, the exploited zero-day “allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page”. It should be noted that the exploitation of out-of-bounds defects often leads to arbitrary code execution.

The latest browser update also addresses CVE-2025-5068, a medium-severity use-after-free in Blink that earned the reporting researcher a $1,000 bug bounty. No reward will be handed out for the zero-day.

The latest Chrome iteration is now rolling out as version 137.0.7151.68/.69 for Windows and macOS, and as version 137.0.7151.68 for Linux.

Note: Google Chrome communicated its removal of default trust of Chunghwa Telecom and Netlock in the public forum on May 30, 2025.

The Chrome Root Program Policy states that Certification Authority (CA) certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion. It also describes many of the factors we consider significant when CA Owners disclose and respond to incidents. When things don’t go right, we expect CA Owners to commit to meaningful and demonstrable change resulting in evidenced continuous improvement.

Chrome's confidence in the reliability of Chunghwa Telecom and Netlock as CA Owners included in the Chrome Root Store has diminished due to patterns of concerning behavior observed over the past year. These patterns represent a loss of integrity and fall short of expectations, eroding trust in these CA Owners as publicly-trusted certificate issuers trusted by default in Chrome. To safeguard Chrome’s users, and preserve the integrity of the Chrome Root Store, we are taking the following action.

Upcoming change in Chrome 139 and higher:

Transport Layer Security (TLS) server authentication certificates validating to the following root CA certificates whose earliest Signed Certificate Timestamp (SCT) is dated after July 31, 2025 11:59:59 PM UTC, will no longer be trusted by default.
OU=ePKI Root Certification Authority,O=Chunghwa Telecom Co., Ltd.,C=TW
CN=HiPKI Root CA - G1,O=Chunghwa Telecom Co., Ltd.,C=TW
CN=NetLock Arany (Class Gold) Főtanúsítvány,OU=Tanúsítványkiadók (Certification Services),O=NetLock Kft.,L=Budapest,C=HU
TLS server authentication certificates validating to the above set of roots whose earliest SCT is on or before July 31, 2025 11:59:59 PM UTC, will be unaffected by this change.
This approach attempts to minimize disruption to existing subscribers using a previously announced Chrome feature to remove default trust based on the SCTs in certificates.

An unknown actor has been continuously creating malicious Chrome Browser extensions since approximately February, 2024. The actor creates websites that masquerade as legitimate services, productivity tools, ad and media creation or analysis assistants, VPN services, Crypto, banking and more to direct users to install corresponding malicious extensions on Google’s Chrome Web Store (CWS). The extensions typically have a dual functionality, in which they generally appear to function as intended, but also connect to malicious servers to send user data, receive commands, and execute arbitrary code.

Even weirder: Why would Google give so many the "Featured" stamp for trustworthiness?

Google is hosting dozens of extensions in its Chrome Web Store that perform suspicious actions on the more than 4 million devices that have installed them and that their developers have taken pains to carefully conceal.

After the release of the Secure Annex ‘Monitor’ feature, I wanted to help evaluate a list of extensions an organization I was working with had configured for monitoring. Notifications when new changes occur is great, but in security, baselines are everything!

To cut down a list of 132 extensions in use, I identified a couple extensions that stuck out because they were ‘unlisted’ in the Chrome Web Store. Unlisted extensions are not indexed by search engines and do not show up when searching the Chrome Web Store. The only way to access the extension is by knowing the URL.

In this blog post, learn about the supply chain attack targeting Chrome browser extensions and the associated targeted phishing campaign.

This blog post looks into how 62 malicious extensions circumvent Google’s restrictions of remote code execution in extensions. One group of extensions is associated with the company Phoenix Invicta, another with Technosense Media. The largest group around Sweet VPN hasn’t been attributed yet.

The data-loss startup says it was targeted as part of a "wider campaign to target Chrome extension developers."

Familiar ransomware develops an appetite for passwords to third-party sites

Google will roll out a Safe Browsing update later this month that will provide real-time malware and phishing protection to all Chrome users, without compromising their browsing privacy.

The company launched Safe Browsing in 2005 to defend users against web phishing attacks and has since upgraded it to block malicious domains that push malware, unwanted software, and various social engineering schemes.

Learn about the fake Google Chrome update malware, a common form of website malware that tricks users into downloading a remote access trojan disguised as a browser update. Understand how it works, its impact on websites, and how to protect your site from such threats. Stay updated on the latest malware trends with Sucuri.

Eight malicious extensions still remain in Chrome Web Store. These use some interesting tricks to keep running arbitrary code despite restrictions of Manifest V3.

Google has released an emergency Chrome security update to address the first zero-day vulnerability exploited in attacks since the start of the year.

Cyble Research & Intelligence Labs analyzes the recent surge in users being infected by Browser Hijackers using Chrome plugins.

The “Dormant Colors” is yet another vast campaign of malicious extensions with millions of active installations worldwide, this time with a color-related theme and full of deception all through the chain. It starts with the trickery malvertising campaign, continues with a crafty novel way to side-load the real malicious code without anyone noticing (until now!), and finally with stealing not only your searches and browsing data, but also affiliation to 10,000 targeted sites — a capability that is easily leveraged for targeted spear phishing, account takeover and credential extraction — all using this powerful network of millions of infected computers worldwide!

Some of the largest websites in the world have exposure to sending Google and Microsoft sensitive user PII, including username, email, and passwords

A few months ago, we blogged about malicious extensions redirecting users to phishing sites and inserting affiliate IDs into cookies of eCommerce sites. Since that time, we have investigated several other malicious extensions and discovered 5 extensions with a total install base of over 1,400,000
"...the extensions also track the user’s browsing activity."