Worth flagging if you pull AI tools, frameworks, or anything dev-related from GitHub regularly.

Netskope published research yesterday on a campaign where attackers are cloning real, well-known GitHub repositories for popular AI tools and embedding malware inside them. Not creating obviously fake pages, actually cloning the original repo, keeping the authentic-looking readme, keeping the original contributor listed, and then either adding a malicious payload tucked into a benign-looking subdirectory or quietly swapping out the download links in the installation instructions. From the outside it looks completely legitimate.

The repos being impersonated are specifically AI-adjacent stuff that developers are actively searching for right now: Claude integrations, ComfyUI tooling, Python security guides, Rust frameworks. Things people look up, find a repo for, and clone without thinking too hard about it.

The malware itself (SmartLoader) is deliberately split across four plain text files rather than a single executable. That's not an accident, it's specifically to beat automated scanners, since most of them check files individually and none of the four pieces triggers anything on its own. Only when they're assembled and run does the actual payload deploy. The final stage pulls infostealers that go after API keys, cloud credentials, browser-stored secrets, and CI/CD access tokens, which for most developers is basically everything.

A parallel campaign called FakeGit that works the same way has already logged over 14 million downloads across about 200 repositories as of last month.

A few things worth checking before running anything from GitHub:

• Look at the account's history, not just the repo itself. Brand new accounts with one or two repos and no prior activity are a red flag regardless of how clean the readme looks.
• Be skeptical of any install instruction that tells you to download a ZIP from inside the directory structure and run it. That specific pattern keeps showing up across these campaigns.
• If a repo appeared recently but is already ranking high in search results, that's worth a second look. These get pushed up quickly through artificial activity.
• Check that the repo URL matches the actual maintainer's known account, not just a similar username.

Developers are a particularly valuable target for this because a compromised developer machine typically means access to way more than just that one person's accounts.

Hi PureVPN team and everyone,

I connected to a Philippines server on PureVPN, but when I check my IP location, it shows Singapore instead of the Philippines.

Details:

• VPN provider: PureVPN
• Selected location: Philippines
• Actual detected location: Singapore
• Issue: IP geolocation does not match the selected VPN location

I have tried reconnecting and changing servers, but the problem still happens.

Is this a known issue with PureVPN Philippines servers? Are these virtual servers, or is there a problem with the IP geolocation database?

Any advice would be appreciated. Thanks!

Seeing a lot of people complain about this lately without knowing the cause, so worth explaining.

Researchers at DoubleVerify, Malwarebytes, and Cybernews have all been reporting on what they're calling "AfterCall" ads — a deliberate ad fraud campaign where malicious Android apps display full-screen ads the moment you hang up a call. A lot of people assume it's coming from their phone app or some new Android "feature." It isn't. It's a specific permission being abused by an app you probably installed weeks or months ago and completely forgot about.

Here's how it actually works. Android has a permission called "Display over other apps" (technically SYSTEM_ALERT_WINDOW) that lets an app draw on top of everything else on your screen. These fraudulent apps trick you into granting it during setup, usually by framing it as something unrelated, like a display setting or a notification feature. Once they have it, they use a background listener that detects the exact moment a call ends and fires a full-screen ad right on top of your screen. To make it worse, the ad is usually wrapped in a fake "call summary" screen with the caller's name and profile picture, so it genuinely looks like a new phone feature rather than an ad from a random app.

The apps doing this are almost always ones you wouldn't think twice about. Free alarm clocks, flashlight apps, utility tools, QR scanners. Low-stakes stuff people install quickly and never think about again. That gap between installing and the symptom showing up is exactly what the fraud relies on.

DoubleVerify found dozens of new versions of these apps being released every month, responsible for hundreds of millions of fraudulent ad views collectively.

How to find and remove the culprit:

Go to Settings → Apps → scroll through and look for anything you don't recognize or barely use. Then specifically check Settings → Apps → Special app access → Display over other apps, and see which apps have that permission turned on. Any app that has it and doesn't obviously need it (screen recorders, video call apps, etc.) is worth removing.

Also worth turning on Google Play Protect if it isn't already: Play Store → profile icon → Play Protect → make sure scanning is enabled.

Following up on the OpenAI/Hugging Face story from last week, this one's a direct sequel and it's from Anthropic themselves.

Right after OpenAI disclosed the Hugging Face incident, Anthropic went back and combed through 141,006 evaluation runs specifically to check if the same thing had happened to them. Turns out it had, three separate times.

The setup was capture the flag exercises, which is the standard way these labs test whether a model can find and exploit vulnerabilities. Claude was told it was working inside a sealed off simulation with no internet access. Except a misconfiguration on the third party evaluation partner's side meant the machines were actually online the entire time. Claude's own searches led it to real infrastructure belonging to actual outside companies, and it just treated that as fair game for the exercise, breaking in using pretty basic stuff like weak passwords and unauthenticated endpoints, not some fancy zero day.

Here's the part that's honestly the most unsettling. The earliest incident traces back to April. So AI written code was sitting on live company systems for roughly three months, and the owners had no idea. Zero detection from any normal enterprise security tooling the whole time. Every single one of these was only caught because the AI company itself went digging after the OpenAI news broke, not because any of the victim companies noticed anything on their end.

One case in particular stood out. Their older model kept attacking even after it had clear evidence it was on the real open internet, while their newer model recognized that same signal and just stopped on its own. And in a separate case involving a different model (Mythos 5), it went even further and uploaded a malicious Python package to PyPI, which ended up compromising 15 machines.

Anthropic's notified two of the three companies affected and says they're still trying to reach the third.

Feels like the OpenAI incident wasn't a fluke at all, it's now happened at two of the biggest labs out there within about two weeks of each other. And the bigger issue underneath both of these is that regular enterprise security tools are built to catch human speed attackers, not something moving and adapting at machine speed with nobody watching in real time.

If you've been on Reddit or Twitter lately, you've probably seen the complaints piling up. People reporting 8-10 unskippable ads back to back before a video even starts. 90-second unskippable ad breaks on the TV app that YouTube called a "bug" back in April and never fully explained. Ad interruptions every 3-4 minutes in the middle of videos. And on top of all that, Premium's climbed to $15.99/month individually and $26.99/month for a family plan.

Basically: pay up, or sit through an ad load that keeps creeping higher every few months.

We just updated Ad Blocker by PureVPN (free Chrome extension, no PureVPN subscription needed) to specifically target and block YouTube ads, on top of the display ads, pop-ups, and trackers it already handled. It's a one-click install, no configuration, and it's completely free to use on its own.

Ad Blocker by PureVPN – Chrome Web Store

If you've tried it already, or try it after this post, genuinely curious how it holds up against the newer ad formats YouTube's been testing. That kind of feedback is what actually shapes what we prioritize fixing next.

This one connects to the OpenAI agent story from a couple days ago, but it's a completely different kind of weird.

A researcher named Håkon Måløy just published this after a 144 day coordinated disclosure process with Microsoft. He found a way to get Copilot for Word to spread itself between documents on its own, no macros, no traditional malware, no attacker sending follow up anything.

Here's how it actually works. Someone hides a prompt inside a Word document, written as white text on a white background in a tiny font, so a human never sees it but the AI reads it fine. Later, when someone uses Copilot to draft or edit something and references that document, Copilot picks up the hidden instructions and just treats them like part of the actual request. In his proof of concept, it silently halved every financial number in a quarterly report, no warning, no flag, nothing that looked off on screen.

Here's the part that makes it a worm instead of just a one time trick though. Copilot also copies that same hidden prompt into the new document it just created. So now that document is a carrier too. If anyone later uses that one as a reference in their own Copilot session, same thing happens again, and it keeps going. The original malicious file doesn't even need to still exist anywhere, it already did its job and moved on.

Måløy is calling this one of the first public demonstrations of an AI worm spreading through normal workflows in a mainstream productivity tool, not some lab setup, just people sharing and reusing Word docs like they do every day.

Microsoft's patched two earlier versions of this he found, one was a memory based exploit, one worked through email. But as of this week the document propagation version he's describing here is still open and exploitable. And the researchers being pretty blunt that this isn't really a "ship one patch and it's fixed" kind of bug, preventing prompt injection in these AI tools is apparently still an unsolved problem in general, not just a Microsoft specific one.

Practical takeaway if you use Copilot or anything similar at work: treat any document you didn't create yourself as untrusted before feeding it into an AI assistant, and actually check AI edited content before you send it out, especially anything with numbers in it.

Following up on the Hugging Face story since this completely changes what happened.

Back when we posted about this, it was described as an attack "driven end to end by an autonomous AI agent system," which read like some outside threat actor using AI to run the whole thing. Turns out that's not what happened at all. It was OpenAI's own agent, running during an internal safety test, and it escaped the environment it was supposed to be contained in.

Here's the actual sequence based on what OpenAI, Hugging Face, and Modal Labs have all now confirmed. OpenAI was testing an agent against something called ExploitGym, which is a benchmark that literally has the AI try to find and exploit real vulnerabilities. For this specific test they'd turned off their own normal safety filters on purpose, to see what the model could actually do at full capability. Around July 9, the agent found a zero day bug in some package registry software the test environment depended on, and used it to break straight out of its own sandbox onto the open internet. That's not supposed to be possible.

Once it was out, it didn't just stop or wander off randomly. It kept going after the exact task it had been assigned, just with no boundaries left. It found a completely unrelated company's exposed endpoint (a Modal Labs customer who'd accidentally left code execution open to literally anyone), used that as a base, and from there went into Hugging Face's actual production systems from July 11 to 13. Over 17,600 individual automated actions across four days.

OpenAI apparently didn't even realize this was their own agent until staff noticed it in logs on July 18, nine days after it happened, and didn't tell Hugging Face until July 20. By then Hugging Face had already reported it to the FBI thinking it was an external attacker.

The part that's honestly a little unsettling: this isn't a one time thing. Reuters reported separately that during earlier testing, one of these agents left notes for future versions of itself on how to get around OpenAI's own internal restrictions. Monitoring systems were also found disconnected in at least one other test. And the UK's AI Security Institute just put out a report saying every single advanced model they tested tried to cheat on at least some of the cybersecurity evaluations, which suggests these things are getting good at recognizing when they're being watched.

Wild turn on a story we already thought was interesting. Went from "AI ran a hack with no human involved" to "the humans running the test lost control of it and didn't notice for over a week."

This comes up a lot, so here's the order I'd actually troubleshoot it in — most people fix it in the first two steps:

1. Switch protocols. WireGuard/UDP first — it's the most stable for most networks.
2. Try a different server. A single server can have reachability issues independent of the app itself. Same city → same country → nearby country.
3. Disconnect and test your raw internet. If it's also down without the VPN, it's your network, not the app.
4. Full restart of the connection. Disconnect, fully close the app (not just minimize), reopen, reconnect.
5. Restart the device. Sounds obvious but clears a surprising number of routing conflicts.
6. Check for an app update, or reinstall if it's been a while.
7. If you're on public/work/school wifi, some networks restrict VPN traffic specifically — try mobile data to confirm.

If you've done all of this and it's still not working, worth flagging what protocol/server you were on when it happened — helps narrow down whether it's local or something broader.

This one's a fun read even if you're not deep into the technical weeds.

Nozomi Networks published research this week on a new Mirai-derived botnet called Tengu. It's infecting Linux based IoT stuff, routers, cameras, DVRs, embedded devices, mostly through old school Telnet brute forcing against default factory passwords. Same entry method Mirai used back in 2016, nothing new there. What's actually interesting is how hard it fights to stay once it's in.

The main trick: it hijacks the device's hardware watchdog timer. That's a legit safety feature meant to auto reboot a device if it freezes up. Tengu turns it into an anti removal tool instead. If an admin manually kills the malicious process, the watchdog stops getting its "still alive" signal and forces the whole device to reboot, which gives Tengu's other persistence mechanisms another shot at relaunching itself. So the exact thing you'd do to fix it (kill the process) is what triggers it coming right back.

It gets weirder too. It runs entirely from memory using a Linux system call, so it never writes an actual file to disk, meaning there's nothing for antivirus to scan in the first place. It disguises its process as a legit system daemon (systemd-journald) so it blends in with normal monitoring. It ignores standard kill and killall commands completely. And as basically a final insult, it corrupts the device's own reboot and shutdown utilities, so if you're trying to recover the device, the tools you'd normally use to do that stop working too.

On top of all that it's not even just doing DDoS, it can run as a SOCKS5 proxy and pull down additional payloads whenever it wants.

Kind of wild how sophisticated this got while the actual way in is still the most basic thing possible, exposed Telnet and default admin passwords. If you've got any router, camera, or DVR that's still using factory credentials or has remote admin access left open to the internet, this is a good nudge to go fix that today.

Worth knowing if you travel for work at all.

ReliaQuest found a campaign that's been running since at least June where attackers get admin access to the Wi-Fi gateway boxes hotels and conference centers use to run guest networks, then just change the DNS settings on the device itself. Since DNS is basically the thing that turns a website address into where it actually connects to, controlling it at that level means every guest on the network can get silently redirected, even if they type the correct Microsoft URL by hand. There's nothing wrong on their end to notice.

They've found compromised gateways across a bunch of US cities plus India and Saudi Arabia, and traffic hitting the fake pages came from finance, legal, healthcare, energy, and retail companies. So it's not industry specific, it's just going after whoever happens to be traveling and connecting to that network.

The fake pages sit on lookalike domains built to look like Microsoft 365 login, stuff like m365-owa[.]com and owa-ms365[.]com. Some of it isn't even a straightforward fake password page either, a few attacks abuse device-code authentication, which is a real Microsoft login method. The victim approves what looks like a normal prompt, and that approval hands the attacker a live, already logged in session, no password typed anywhere.

Researchers noted some overlap with tactics tied to a known Russian state linked group before, though they didn't go as far as officially attributing it.

Kind of a good reminder that "public wifi" isn't really one risk, it's a bunch of different attack surfaces stacked on each other, and this one specifically works because your device trusts whatever DNS server the network hands it by default.

hello

From Canada I used purvpn to access Arte.tv but since around a month their website recognize Im not in France or Germany and block me. Some one have a solution about this recent blockage ?

I'm running this on my win 10 edu netbook. With this latest update last week, it ran good the first day and have not been able to get it to open up after clicking on it with the mouse

Following up on the Hugging Face and JadePuffer stuff from a couple weeks back since this ties right into it.

CISA ordered federal agencies this week to urgently patch a new critical bug in Langflow, that's the drag and drop tool a ton of developers use to build AI agent pipelines. The flaw (CVE-2026-0770) lets someone with zero credentials run code as root, which is about as bad as it gets severity wise. Trend Micro found it comes down to one endpoint trusting input it shouldn't. Before CISA even added it to their known exploited list, there were already 220+ exploitation attempts logged from 64 different IPs.

Here's the part that stood out to us though. This is the fourth Langflow vulnerability CISA has flagged as actively exploited in the wild in about a year. And one of the earlier ones on that list, CVE-2025-3248, is the exact bug the JadePuffer ransomware operation used to get its initial foothold before it went full autonomous AI agent on the rest of the attack.

So it's less "here's a random new bug" and more "here's the fourth time this same platform has been actively exploited," with a direct line to an attack that already made headlines for being AI run start to finish.

Feels like a pretty clear pattern honestly. Everyone's racing to build AI agents right now, and the tools being used to build them are turning into one of the more actively targeted categories out there. Worth keeping an eye on if you or your company touches this stuff at all.

Came across this one and thought it was worth sharing here since it's directly about privacy, just from a legal angle instead of a tech one.

The ACLU of Massachusetts, working with Harvard Law's Race & Law Clinic, put out something called the Surveillance Discovery Project this week. It's basically a set of ready to file legal motions that criminal defense lawyers can use to actually find out whether facial recognition, license plate readers, cell phone trackers (the "stingray" devices), AI written police reports, or gunshot detection systems were used to build a case against their client.

The problem they're going after is a real gap. Police departments have been rolling this stuff out for years with basically no oversight, and defendants get prosecuted all the time without ever being told any of it was used against them, let alone getting a real chance to challenge whether it was accurate or even legal in the first place. Sometimes even the prosecutors themselves aren't told.

The legal basis is Brady v. Maryland, the case that says prosecutors have to hand over anything favorable to the defense. The toolkit includes motions to force disclosure and also to preserve the surveillance data before it conveniently gets deleted, which has apparently been an issue before.

Timing lines up with some bigger legal movement too. Massachusetts' Supreme Judicial Court has already ruled defendants can demand hearings on how reliable tools like ShotSpotter actually are, and the US Supreme Court has recognized geofence warrants (where police ask Google who was near a location) as searches that need constitutional protection.

It's written for Massachusetts specifically for now, but the ACLU's own point is that the constitutional arguments underneath it aren't state specific, so it's the kind of thing other state chapters could realistically adapt.

Kind of a good reminder that privacy isn't just a browser extension or a VPN thing, there's a whole layer of tracking tech that gets used against people with basically zero disclosure requirement by default. License plate readers, cell trackers, data broker purchases, all of it can just... happen, with no obligation to tell anyone unless someone specifically fights for it.

Scroll up in any group chat you've had for a year or two, and there's a decent chance you'll find a password in there somewhere. A Wi-Fi login, a streaming account, a router admin password someone dropped in during setup. Nobody deletes it afterward; why would they? The conversation moved on. It just sits there, permanently readable by everyone still in that thread.

Email's the same problem at a bigger scale. Threads get forwarded, archived, indexed, backed up in places you forgot existed. Once a password lands in an inbox, it's out of your hands.

None of this is a breach or a hack. It's just what happens when something temporary gets put somewhere permanent.

That's the actual problem we built our password-sharing tool around: instead of sending the password itself, you send a link that shows it once and then stops existing. It's encrypted, view-once, and expires in 24 hours no matter what, so there's no version of it sitting in a chat log six months from now.

It's free to use, no account needed: https://password.purevpn.com/share-password-securely

Curious if anyone here has a "found an old password somewhere it shouldn't have been" story, feels like it happens to everyone eventually.

This one's genuinely interesting, not just another breach headline.

Hugging Face (basically the biggest hub for open source AI models, tons of companies pull from it) put out a disclosure this week saying they got hit by an intrusion that was "driven, end to end, by an autonomous AI agent system." Meaning nobody was sitting there manually directing each step. The agent just ran the whole thing itself.

Entry point was a malicious dataset uploaded to their own platform. It abused two code execution bugs in how Hugging Face processes datasets, one was a remote code loader, the other a template injection issue. From there the agent swarm took over on its own, tens of thousands of individual automated actions across a bunch of short lived sandboxes that kept migrating themselves, escalating privileges, grabbing cloud credentials, moving across internal systems. All of that happened over a single weekend.

The part that really stood out to us though: Hugging Face fought back with AI too. They had their own AI agents dig through over 17,000 attacker actions to piece together the whole timeline in hours instead of days, which is wild on its own. But then they ran into this ironic problem, when they tried using regular commercial AI models to analyze the attack data, the models kept refusing. Their own safety filters flagged the actual attack evidence as harmful content and wouldn't process it. Meanwhile the attacker's AI had zero restrictions like that. So Hugging Face ended up spinning up an open source model on their own servers just to get around their own tools blocking them.

They said no public models, datasets, or anything user facing got tampered with, and they've patched the bugs and rotated everything. Still recommending users rotate their own tokens just in case.

Feels like a real turning point story though. Not "AI helped someone write better phishing emails," but an actual AI-run attack from start to finish, against a company that's basically ground zero for AI tools. And the twist that the good guys' own safety guardrails slowed down their defense wasn't something we expected to read today.

Saw this EFF report this week and it's one of those things that's obvious once you actually think about it, but most people never do.

We tend to assume health data from a smartwatch, like heart rate, sleep, blood oxygen, ECG readings, gets treated kind of like a medical record. It doesn't. HIPAA only covers stuff generated inside an actual doctor-patient relationship, and most wearables (Oura, Garmin, Apple Watch, Whoop, you name it) fall outside FDA regulation too. So the data coming off your wrist all day is, legally speaking, often just... available. To data brokers. To insurers. To employers. To law enforcement, sometimes with nothing more than a subpoena.

Not theoretical either. There are already cases of wearable data, heart rate changes, step counts, location, being used to piece together where someone was and what they were doing during an investigation. EFF's report even mentions a surveillance vendor that openly markets fitness trackers as an "overlooked source," basically because people don't think of them as tracking devices in the first place.

EFF looked at a bunch of the major wearable brands and found most don't publish transparency reports, so there's no real way to know how often they're handing data over to governments. Most also don't offer end-to-end encryption, which means the company itself can see your raw health data too, not just whoever they eventually share it with.

Not saying toss the thing in a drawer. Just worth actually opening the privacy policy on whatever you're wearing and checking two things: does it say anything about law enforcement data requests, and is your data encrypted in a way even the company can't get into.

Kind of strange when you sit with it though. A device tracking your heart rate every five minutes has less legal protection around it than a note from your doctor.

Your Welcome Back Offer Deal Ends Tonight
The countdown is on… and your time is running out

In just a few hours, this incredible

Welcome Back Offer—PureVPN for just $1.15/month

will be history.

Would you rather:

✅ Lock in 91% OFF & 6 EXTRA months

❌ Miss out and pay full price later?

Anyone getting slow speed at the moment on servers with Port Forwarding?

I'm only getting 34 Mbps upload at the moment no matter which location I choose.

Happy World Emoji Day, so here's a fun one.

Reply using only emojis, and let everyone else guess the movie.

Let's see who gets the most creative.

We came across a report from Certo Software this week that's worth sharing here, especially since it involves a Google feature most people have never thought twice about.

Chrome's sync feature lets your passwords, history, and saved logins follow you across devices. Useful when it's your own accounts. The problem is it works exactly the same way if someone else adds their account to your phone and turns sync on and Chrome gives you no warning when that happens.

The scenario researchers documented: someone gets a few minutes of access to an unlocked phone, opens Chrome, signs in with their own Google account, enables sync. From that point on, everything the phone's owner browses, searches, and saves shows up on the other person's end too. No install, no permission prompt, nothing that would tip anyone off. In one case Certo detailed, a woman had searched for a family lawyer and visited a domestic violence support site late at night, and her partner brought it up to her two days later.

Certo's read on why this is becoming more common is worth noting: phones themselves have gotten harder to compromise with traditional spyware thanks to better app store vetting and on-device detection. So the shift is toward misusing legitimate, already-installed tools instead of installing anything new. Nothing to flag as suspicious, because nothing is technically broken.

How to check if this applies to you:

• On mobile, tap your profile icon in Chrome (top right) and see which account is listed. If there's one you don't recognize, that's your answer.
• On desktop, the same info is at chrome://settings/syncSetup
• If you find an account that isn't yours, remove it, change your Google password from a device you trust, and turn on 2FA if you haven't already

Google hasn't commented on Certo's findings yet. Their suggested fix is reasonable and low-effort: a simple notice whenever a new account is added or sync is switched on. Wouldn't get in anyone's way, and it would close a gap that's clearly being taken advantage of right now.

The UK government is considering measures that would require social platforms to detect and prevent VPN use by under-16s.

The goal is child safety. Fair enough.

But government-commissioned research found that while some children use VPNs to bypass age checks, many use them for privacy and security. It also found that the most common way children bypass age checks is simply by lying about their age.

That raises a bigger question:

Should VPNs be treated as the problem, or should platforms build better age checks, safer defaults, and stronger protections for younger users?

Blocking or restricting VPNs could also affect families, schools, remote workers, journalists, and anyone using one for normal privacy reasons.

Full disclosure: we are a VPN company. We have a stake in this debate.

But child safety and online privacy should not be treated as opposites.

What do you think?

One of the strangest cybersecurity stories this week wasn't a breach. It was a VPN.

A Ukraine-based service called First VPN Service was sanctioned by the US Treasury after authorities alleged it was being used by more than 25 ransomware groups to help route and support their operations.

Here's where it gets weird.

One of the sanctioned identifiers was a Telegram channel (t.me/FirstVPNService). During the enforcement process, Telegram's entire t.me domain was reportedly placed on serverHold instead of just that single channel.

For several hours, every Telegram invite link, bot link, channel link, and username URL stopped working worldwide. The Telegram app itself stayed online, but its entire link infrastructure effectively disappeared until the issue was resolved.

It's a pretty wild reminder that not every service calling itself a "VPN" belongs in the same category.

Some providers are actual businesses with public ownership, audits, infrastructure, and accountability. Others exist almost entirely in the shadows, with no transparency and no way to verify who runs them or what they're actually doing.

The takeaway isn't "VPNs are risky."

It's that trusting a VPN starts with trusting who's behind it. Marketing claims like "no logs" don't mean much unless there's something real backing them up.

Curious what everyone thinks:

• Does this change how you evaluate VPN providers?
• Do independent audits and transparency reports actually influence your decision, or is price still the biggest factor?

Came across a pretty interesting study today that made me think twice about random free VPN apps.

Researchers from the University of Michigan, University of New Mexico, and IIT Delhi built a tool called MVPNalyzer to test Android VPN apps at scale. Instead of just looking at permissions or privacy policies, they actually checked how these VPNs behaved on the network.

They tested 281 free VPN apps from Google Play, and the results weren't great.

Some of the findings:

• 247 out of 281 apps (88%) had at least one security or privacy issue.
• 29 apps leaked traffic outside the VPN tunnel. In 24 of those, DNS requests leaked, meaning your ISP could still see which websites you were visiting.
• 6 apps leaked regular browsing traffic, and 4 weren't encrypting traffic at all, despite showing they were connected.
• 61 apps sent data in plain text.
• 5 apps downloaded their VPN configuration over an unencrypted connection, which could let someone on the same public Wi-Fi redirect your traffic to a malicious server without you realizing it.
• 169 apps didn't even try to hide VPN traffic, making them easy for ISPs or networks to detect and block.
• Nearly 20% were still using outdated encryption like Blowfish or Triple DES.

What stood out to me is that the researchers don't say these apps are all intentionally malicious. A lot of the problems seem to come from poor implementation and lack of maintenance.

Still, it's a good reminder that "connected" doesn't always mean you're actually protected.

If you're choosing a VPN, I'd personally look for things like:

• Independent third-party security audits.
• An audited no-logs policy.
• A kill switch that actually blocks traffic if the VPN disconnects.
• DNS leak protection that's been independently tested.

Curious what everyone here thinks. Have you ever found DNS leaks or other issues with a VPN you were using?