HackingPassion

Discover-Tech Ads Delivered Zero-Click Spyware to Al Jazeera While Google Approved the Company for Six Years

Mon, 19 Oct 2026 11:44:53 +0200

Spyware got onto Al Jazeera devices through an ad that only had to load on the screen. 45 were targeted, and the owners did nothing wrong. The company behind the ad ran code on 120,768 websites, approved by Google for six years.

On October 15, two teams published the same finding on the same day. Researchers at the Citizen Lab in Toronto and the ad-security company Confiant laid out the first clear proof of something security people had warned about for years: spyware that lands on a phone or a laptop through an ordinary online ad. There was no link to click and no file to download. They gave it a name, AdFection.

The usual warning is about shady links you should not click. This one had nothing to click. The ad only had to appear on the screen. The moment it loaded, a small piece of code inside it reached out to a server and asked one question: is this the person we are looking for? If the answer was yes, the attack ran. If the answer was no, the server sent back nothing, and the reader scrolled on, never knowing an ad had checked who they were.

The company at the center of this is Discover-Tech, an Israeli firm registered in 2020. On paper it looked like any other advertising business. The books say otherwise. In four months it spent only about 109,000 dollars, the records show almost no income from selling ads, and more than a third of its budget went to promoting its own website.

It bought ad space in the same automated auctions that fund most of the free internet. And it was trusted. From 2020 until this month, Discover-Tech sat on the lists of certified and approved ad vendors kept by Google and by IAB Europe, the trade body for the industry. For six years this was a vendor in good standing. Google cut its access in early October and said it did so “for systematically violating our policies.” The trade body dropped it around the same time.

To see how an ad can carry an attack, it helps to know what happens in the half second before any ad appears. When a page or an app opens a slot for an ad, it does not pick one in advance. It holds an auction. Dozens of companies get told what device you are on and where you are, tagged with a code called your advertising ID that follows you from app to app. They bid, live, for the right to show you something. The highest bid wins, and its ad drops into the slot. This happens hundreds of billions of times a day, and it is over before the page has even settled.

Discover-Tech bid in these auctions like any other buyer. But some of the ads it won carried something extra. The instant the ad rendered, a line of code phoned home to a Discover-Tech server and handed over your advertising ID and IP address, along with the cookies on the page. The server checked those details against a target list. If your device was not on it, the reply was exactly zero bytes. If it was, you got a block of code that ran on the spot. Because the server stayed silent for the rest, the scanners that are supposed to catch bad ads had nothing to flag.

The targeting was a product, not a one-off. On Discover-Tech’s platform a customer could pick a single person by advertising ID, by browser, or by IP address, and push a chosen ad straight to that one device. Clients could run it under their own branding and limit a campaign to a single country.

The scale is the part that is hard to sit with. Between March and June of this year, the researchers counted Discover-Tech bidding on 3.77 billion ad slots and winning about 442 million. Ads carrying its code showed up in 75,373 apps and on 120,768 websites, across 161 countries. At least 718 million of those bids carried the hidden code that calls home.

The heaviest targeting landed on conflict zones and small states. Yemen drew 457 million bids. In Montenegro the ads were aimed at people more than 150 times over, counted per head of population. Confiant’s cofounder Jerome Dangu put it at 10 million ads a day, and said very likely hundreds of millions of people were touched by Discover-Tech. In the Palestinian territories, he said, the ads were hard to avoid. Most of those ads were ordinary. But the same channel that carried a harmless Sudoku ad to one phone carried spyware to a target on another, and from the outside the two looked the same.

It was not only far away. In the Netherlands, 1 in 54 ads shown on iPhones came from Discover-Tech. Belgium was the single most-targeted country Confiant counted, 56 percent of all the hits, first seen on April 12.

A second trick makes it worse. Ad companies swap data with each other through something called cookie matching, a quiet arrangement that lets them recognize the same person across different sites. Discover-Tech could even follow people onto sites where its own ads never ran. Once you are in the system, stepping out of it is not up to you.

The proof that this was more than theory came from Al Jazeera. The network’s own technology team noticed odd patterns on some journalists’ devices back in 2024, and the pattern kept running into 2025. They brought in the Citizen Lab. The investigators found at least 45 devices inside the network had been targeted, and confirmed that some were infected. The logs showed the same sequence: first contact with a Discover-Tech ad server, then a check-in with a second server, then the device talking to the machine that runs the spyware. The team pulled one infected Windows file off a device. It survives a reboot by editing a Windows setting so it loads again each time the machine boots.

The spyware itself was made by Candiru, an Israeli company that sells surveillance tools only to governments. The name is not new. In July 2021, security researchers and Microsoft mapped its work and found at least 100 victims, among them journalists, activists and dissidents, plus two holes in Windows that got patched. That November, the US government put the company on a trade blacklist, the list of firms American companies may not export to without a special license. It now calls itself Integrity Labs. Its spyware can take files, read messages, log what you type, switch on the microphone and camera, and grab screenshots.

The find that says the most about this operation is almost dull. Discover-Tech left an open page on the internet, no password, holding 128 days of sign-in records. It showed who had been signing in to the targeting platform: 120 different usernames. Two were tied to Candiru, and those two signed in from eight countries, among them the United States, Italy and the Czech Republic. And until March of this year, one of the company’s shareholders was linked to Sara Hamou. She ran the corporate network behind Intellexa, the group behind the Predator spyware, and was convicted in Greece in the case known as Predatorgate. These are not separate worlds. They overlap.

The ads did not only reach journalists. The researchers found Discover-Tech impressions inside the networks of the Norwegian parliament, the Norwegian police, the European Parliament, the European Commission, NATO and the UN. They also found ads inside the networks of 19 media organisations across eight countries. Confiant saw them on networks tied to the Pentagon, the UN’s atomic agency, and the International Criminal Court. One caution here: an ad showing up on a network is not the same as a device being infected. It means the door was knocked on, not that someone walked through. But it shows how far the reach went.

And most of the ads tied to Candiru did not land on government networks at all. They landed on ordinary home and mobile connections, in living rooms. Whoever sat in their database could be reached on their own phone, whatever network they used.

The spyware was not the only thing these ads carried. A second group, which the researchers call Dark Cartographer, used the same platform to match the advertising IDs in those bid requests to people’s phone numbers, by abusing weak spots at mobile carriers in more than 30 countries. The researchers say a separate report on that group is still coming. The same system served at least two operations at once.

A few things are still open. Confiant caught the script that does the groundwork, about 90 KB of code that poses as an ordinary verification check, fingerprints the device, and can run whatever the operators send it. The code even carried a fake line, “Copyright 2013 Google Inc.”, to put human reviewers at ease. The final break-in, the step that takes over the machine, has not been caught in the wild. Whether the servers that handed out the attack are still running, the report does not say. Discover-Tech and its spyware supplier were both asked to respond and stayed silent.

An attack that needs nothing from you still leaves you something to do. You cannot un-see an ad, but you can stop it from loading, and you can make yourself harder to single out.

→ Run an ad blocker in your browser, and if you can, block ads and trackers on your router, so the devices in your home are covered at once. This is the step that also protects a laptop, and that attack hit Windows laptops, not phones.
→ On your phone, take away your advertising ID, the code that lets someone pick you out of the crowd. On Android it is Settings, then Privacy, then Ads, then Delete advertising ID. On an iPhone it is Settings, then Privacy and Security, then Tracking, then turn off Allow Apps to Request to Track. After that, an app that asks for the ID gets back a row of zeros.

None of this makes you invisible. But it takes away the handle this kind of attack grabs, and it shuts down a lot of ordinary tracking along the way. The bigger lesson sits with the system, not with you. For six years a company could stand inside the advertising machine that funds the free internet, pass the checks, keep its seal of approval from the biggest names in the business, and use that same machine to drop spyware on a reporter’s laptop. The auction was built for speed and reach, not for asking who is buying. Until that changes, “don’t click” belongs to an older internet.

Want to see exactly what your own phone and browser hand over the moment an ad loads?

My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

The Citizen Lab | Confiant

By Bulls Eye

Jolanda de koff • email • donate
My name is Jolanda de Koff and on the internet, I'm also known as Bulls Eye. Ethical Hacker, Penetration tester, Researcher, Programmer, Self Learner, and forever n00b. Not necessarily in that order. Like to make my own hacking tools and I sometimes share them with you. "You can create art & beauty with a computer and Hacking is not a hobby but a way of life ...
I ♥ open-source and Linux

Siemens Software Center Ran Attackers' Code With a Valid Siemens Signature on PCs That Never Installed It

Tue, 20 Oct 2026 11:37:08 +0200

Canon, then Stardock, now Siemens. Attackers keep running their code behind a trusted signature. On October 19 Siemens confirmed its own signed program was the latest, on Windows PCs that never had it.

Here is what it looked like on a PC that got hit. A program called Siemens Software Center, sitting in the list of apps that start with Windows. On a machine that never had Siemens software on it. The owner did not put it there. It loaded on its own at startup.

That program is genuine. Siemens makes it, and its customers use it to download, install and update the software they bought from Siemens. It even carries Siemens’ own digital signature, which tells Windows “we made this file, and it has not been changed.” Both of those things were true here. The file was genuine. The signature checked out. And it was running the attacker’s code.

Siemens confirmed all of this on October 19.

So how does a genuine, signed program end up on a machine that never asked for it, running someone else’s code? It takes two steps, and I will walk through both.

The first step is how it landed on the computer at all. The trick is called ClickFix, and I wrote about it on October 3. It goes like this. You open a web page, and the page tells you something needs to be verified or fixed. It asks you to press Win+R, paste in a line it gives you, and hit Enter. What you cannot see is that the page already dropped a command onto your clipboard. Win+R opens the little Run box in Windows, the one that runs whatever you put in it.

You think you are proving you are human. In that one paste, you run the attacker’s command, on your own PC, with your own account.

That is why the Siemens warning carries one line meant for ordinary people and not for IT staff: never paste a command from a web page into Win+R, the Run box or PowerShell.

That pasted command pulled in an installer called AllMyBasic.msi from a server the attackers controlled. The installer made a folder named SM Software Provisioning Service in a corner of the user’s own account, and dropped the original SiemensSoftwareCenter.exe inside it. Right next to that file it placed its own, among them one called archive.dll. Then it gave the program a spot in the startup apps, so it comes back after a reboot.

And that one extra file, lying beside the original one, is the attack itself. To see why, you need one small thing about how Windows programs are put together.

A program is almost never a single file. Around the main program sit smaller helper files, called DLLs, that hold pieces of the code the program leans on while it runs. When the program needs one, it asks Windows for it by name. Windows then looks in a fixed order, and the first folder it checks is the one the program was started from. The first file it finds with the right name wins. It does not ask who made it.

So the attackers gave their file the name the program was looking for and left it in that same folder. The program asked for its helper, grabbed the attacker’s file instead, and ran it. There was no warning. The security world calls this DLL sideloading. Siemens logged it as CVE-2026-110936, in the family of bugs known as an uncontrolled search path.

The signature on SiemensSoftwareCenter.exe vouches for that one file, and nothing else. It says Siemens made it and it was not tampered with, and that stayed true throughout. It says nothing about archive.dll sitting beside it. So the moment the program loaded that DLL, the attacker’s code was running inside a process Windows saw as trusted Siemens software. That is exactly why they picked this program. Siemens said so plainly: they chose it because it is signed and trusted.

On paper the bug does not even look frightening. Siemens scores it 8.4 out of 10 on the newer scale and 6.7 on the older one, and the fine print assumes the attacker is already on your machine with high rights, ready to drop that DLL. But in these attacks the person dropping the DLL is you, by pasting the one command that brought it in.

Siemens is not the first brand used this way, and the warning was already out there.

On September 28, researchers at Huntress laid out a run of attacks that, for some victims, began with a Google search for the word chatgpt. A paid result at the top pointed to a custom assistant hosted on the genuine chatgpt.com. Talk to it, and it gave the same answer each time: the service is busy, please use our backup page. The backup page was a fake Cloudflare check, and the check asked you to paste a command. The same ClickFix move.

That command installed a fake printer tool built around a genuine program signed by Canon, and used it to sideload the attacker’s DLL, the same trick used on Siemens. A later wave swapped Canon for a program signed by Stardock. Both ended in the same place: a remote access tool that hands over the screen, the camera and the microphone, and comes with a file manager that searches through the contents of the files on the PC. Huntress counted at least 40 incidents.

And they do not sit still. The first fake assistant came down on September 25. Two days later there was a new one. By October 14 they had fresh web addresses in rotation, like gptverification[.]com. Take one down, another is already up.

In that same report, back in September, the researchers wrote plainly that it was highly likely other signed programs were being abused the same way, and that any alarm built on those two names would miss the next one. Three weeks later, the next one carried a Siemens signature. And the Siemens flaw was reported to the company by Jose Oregon of Huntress Labs, from the same team behind that report.

The second connection comes from Forescout. On October 15, the same day the Siemens advisory came out, its researchers published a write-up of something called ROMULUS. They had been working a separate case and noticed the malware was coming from a server running a login panel by that name. ROMULUS turned out to be a ready-made delivery system for ClickFix attacks: one web address hands a victim a PowerShell script, another hands over an installer, and on one of the servers a stats page quietly counted installs and runs by country.

They found it on six servers. One of them, 2.27.248[.]127, is the exact server Siemens named as the one that handed out the AllMyBasic.msi bundle with the signed program inside. Another, 96.62.224[.]81, is the one behind the fake chatgpt assistant. The same servers, three different signed brands.

Who runs ROMULUS is still an open question. Forescout is careful about it: it could be one private crew, a service other criminals rent, an affiliate setup, or a tool that got copied around. What we can be sure of is how the malware works and which server sent it, not who is behind it.

This is also not the first time Siemens Software Center had a DLL problem. Back in August 2023, Siemens disclosed the same class of flaw in the same program, CVE-2021-41544, reported by a researcher at Dragos and fixed in version 3.0. Three years on, the same weakness turned up again in a newer version, 3.5.8.7, and this time someone put it to use.

On October 17 Siemens added the fix, version 4.0.9.8, to its advisory. If you already run Siemens Software Center for work, you do not have to do anything, because it updates itself the next time you open it. That closes the hole for the people who actually use the program.

It does nothing about the copy the attackers carry. Their bundle brings its own old 3.5.8.7, with the genuine signature still on it, drops it in its own folder, and never goes near Siemens’ official download. Siemens has said nothing about pulling back the certificate behind that signature. Its own advice points the same way: do not rely on the file’s fingerprint, because the file is Siemens’ own and the fingerprint matches. Watch the folders and the behaviour instead.

Siemens lists these signs of trouble, for users and for defenders:

→ Siemens Software Center in your startup apps or Task Scheduler on a PC that never had it installed
→ A folder called SM Software Provisioning Service in AppData\Local\Programs
→ SiemensSoftwareCenter.exe running from AppData\Local\Programs, started by msiexec
→ The files activate.bak or statinfosta.DB next to SiemensSoftwareCenter.exe
→ A folder called FTSuite with a file called ftc.uml in AppData\Local
→ Connections to 96.62.218[.]59

You can check the two folders yourself in PowerShell, run as the user who might have pasted the command:

1
2
3
4
Test-Path "$env:LOCALAPPDATA\Programs\SM Software Provisioning Service"
Test-Path "$env:LOCALAPPDATA\FTSuite\ftc.uml"
Get-ScheduledTask | Where-Object { $_.TaskName -like "*Siemens*" }
Get-CimInstance Win32_StartupCommand | Where-Object { $_.Command -like "*Siemens*" }

The two Test-Path lines answer True or False. A True on either one, or a Siemens entry in the last two lines on a PC with no Siemens software, means the machine needs a closer look.

For the people who run the network, Siemens gives the indicators to block and to search the logs for:

1
2
3
4
Active:   96.62.218[.]59 and wizardexpensive[.]com (payload hosting and C2)
Inactive: 2.27.248[.]127 (distributed AllMyBasic.msi)
AllMyBasic.msi  SHA-256 f4d7c5321bb0d1bda439304a753bcf9b467b98ca53c7e9493b9c2c3451092e4a
archive.dll     SHA-256 3fdcc7d7d049a89711fb31fb236940a1c5a09d899143ffd20c3c41fb1f2cf491

The inactive server is down now, but a machine that pulled from it earlier can still be infected. Siemens also says to look for unexpected DLLs next to Siemens programs outside the normal install folder.

If a PC matches, Siemens says to take it off the network, stop the process, remove the startup entry and the scheduled task, and reset the passwords, before the usual incident response. Change the passwords used on that machine first, from a different device.

Siemens says it knows of no break-in to its own systems, products or update channels, and that the attackers spread the signed program together with their own files outside the official channels. The company is sharing what it knows with the authorities and with security vendors. The Canadian Centre for Cyber Security put out its own warning, AV26-1063, the same day. There are no victim numbers, and no name has been put to the attackers.

A signature covers one file, the one it is attached to. It says nothing about the other files that program pulls in while it runs.

Want to see what is starting up on your own Windows machine, and spot the one entry that does not belong? That begins with understanding how programs load and where things hide. My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Siemens ProductCERT | Huntress | Forescout Vedere Labs

By Bulls Eye

PHP2Shell Flaw Leaves Millions of Websites Open to Takeover

Wed, 21 Oct 2026 16:50:01 +0200

More than 22 million PHP installations sat exposed online this week, facing two flaws that need no password. The details leaked before a patch existed. Updating WordPress does not fix it. The flaw is in PHP itself, the back end of most of the web.

On Tuesday, October 20, details of two unpatched holes in PHP started spreading online. A post on Hacker News announced that someone would disclose the bugs on October 22, with no patch ready. The post came down, but the screenshots had already gone around, including one of an exploit tool called PHP2Shell. Security firm watchTowr looked at what leaked and confirmed the flaws were genuine and allowed remote code execution. PHP had planned a quiet, scheduled fix. Instead it had to put one out while the details were already public.

The PHP team set an emergency release and said it might ship sooner if attacks appeared. Cloudflare reported early attacks against PHP sites on Wednesday morning and rolled out firewall rules to blunt them. The patch arrived in the afternoon, a little earlier than the planned 14:00 UTC release.

You could see how seriously people took it by what went dark. In the Netherlands, the site digid.nl, the government’s main login, showed a plain page: this website is temporarily unavailable. MijnOverheid went down with it, and so did the website of the national parliament and the site of the cyber agency, the NCSC, the people whose job is to warn the public. Logging in with DigiD on other services still worked, but its own site, and plenty of others, were gone. Tweakers and Security.NL, two of the country’s best-known tech sites, were offline as well.

It reached far past one country. Reuters reported that government websites in Europe and elsewhere went offline on Wednesday, with agencies in Finland among those that pulled their sites as a precaution. Cybersecurity agencies in Europe, Australia, Japan and Britain told PHP users to update at once or take their sites offline until they could. The EU’s CERT-EU said much the same: patch the moment a fix exists, and where that is not possible, consider cutting internet-facing applications off from the public internet until it is.

In Germany, Freiburg University took its central websites offline at 10:39 that morning, along with its intranet, the ILIAS learning platform and webmail for student addresses, and told its departments to pull their own PHP systems too. None of these were confirmed break-ins. They were organisations deciding it was safer to be unreachable than to keep running a version of PHP that someone could take over.

To understand why a government would rather go dark, you have to know where PHP sits. PHP runs the back end of most of the web. W3Techs puts it at 69.3% of all the sites whose server-side language it can identify, and WordPress, which by itself runs nearly 40% of all websites, runs on it. So do Magento for shops, Drupal and Joomla for larger sites, phpBB for forums, WHMCS for hosting billing, and MediaWiki, the software behind Wikipedia. None of those applications contains the bug. It sits in the PHP underneath them, so you can write a site perfectly and it is still exposed.

The release fixed two separate problems. The first, CVE-2026-109618, lives in the way PHP handles running out of memory. When a request uses too much memory, PHP jumps out of whatever it was doing to shut that request down cleanly. The trouble is that the memory for a request is sometimes reachable before it has been fully set up. If an allocation fails at that moment, PHP does not account for the early exit. The cleanup step then works on data that was never valid, and a carefully built request can turn that confusion into running the attacker’s own code on the server.

What makes it practical is how easy that out-of-memory moment is to force. PHP reads the body of a form upload, the multipart/form-data type a browser sends when you attach a file, before your application code ever runs. A request that never declares a usable length can slip past the post_max_size limit meant to stop oversized uploads. Empty file fields do not count against the max_file_uploads cap, yet PHP still builds the full set of internal records for each one. Combine enough of those and memory runs out on command, at the exact spot where the first bug lives.

The second flaw, CVE-2026-109619, is a different kind of mistake. A PHP worker keeps some state in memory between requests, things like error and session data. PHP should wipe that state before it hands the memory back. A fatal error, including one from that same out-of-memory trick, can skip the cleanup. PHP frees the memory while the worker still points at it. The next request reads a pointer to memory that no longer belongs to it. That is a use-after-free, and with the right heap layout it too ends in code running with the web server’s own privileges.

This weak spot is not new. In 2004, the researcher Stefan Esser found the first remote bug in the way PHP handles its memory limit. In 2020, a bug report flagged the same out-of-memory behaviour around file uploads. In 2024, a security audit by OSTIF and Quarkslab found a related memory problem, though researchers could not prove it was exploitable at the time. The two flaws patched today are where that long-running weakness finally turned into a working attack.

PHP rated both flaws 9.2 out of 10, critical but not a perfect score. The number reflects that the attack is not trivial: it takes high complexity and the right conditions to line up. Some early reports threw around a 10.0; the official rating is 9.2. It is still an unauthenticated attacker, reaching in across the internet, ending with code running on the server. The gap between 9.2 and 10.0 means little when proof-of-concept code is already public.

One detail in the advisory matters if you run a server. For the first bug, PHP’s own analysis proved the full attack over HTTP on Apache with mod_php, the classic setup where PHP runs inside the web server, on default settings. It calls PHP-FPM, the setup many managed hosts use, susceptible too, though no complete exploit of that first bug has been shown against it. The second bug changes the picture. PHP says the session route reached working code execution on both mod_php and FPM, so FPM is not the safer option it might look like. Both setups need the patch now.

The flaws did not come from attackers. They were reported to the PHP team, which worked on a fix before the details were meant to be public. The repair is in the core of PHP. The developers took out the risky jump-out-on-low-memory step at the root of the first bug, and made the worker clear its leftover state properly to close the second. That is what today’s release fixes.

The patched versions are:

→ PHP 8.5.12
→ PHP 8.4.27
→ PHP 8.3.36
→ PHP 8.2.35

Anything below those is vulnerable. PHP 8.1 and older no longer get updates from the PHP project, and one scan on October 20 found around 884,000 internet-facing servers still running 8.1 or older. The PHP team put out minimal backports for 7.4, 8.0 and 8.1 for people who build PHP from source, but anything past that is on its own. In India, one scan counted 19,847 servers on versions that no longer get security fixes. And PHP 8.2, the oldest branch still supported, reaches end of life on December 31, 2026, so sites on it should patch now and plan the move to a newer version.

Different scanners give different totals, but they point the same way. VirusTotal fingerprinted around 5.1 million internet-facing addresses running PHP. Palo Alto’s own scan flagged more than 22.6 million instances as potentially vulnerable. The exact figure matters less than what it shows: PHP is one of the most widely installed pieces of software on the internet, on millions of servers at once. Security officials put what exposure means in plain terms. A server that gets taken over can have its data stolen, its logins broken and its pages pulled down.

If you run a WordPress site, this is the part that catches people out. Updating it does not close the hole, and neither do your plugins, because the fix is to PHP, which lives on the server underneath them. The same goes for any PHP application, whatever it runs on. The only thing that matters is the version of PHP your host runs, and whether they have updated it. If you do not manage your own server, the only fix is the one your host installs, so ask your hosting provider to apply the PHP update now.

The good news is that checking where you stand takes a minute. On your own server you can ask PHP its version:

1
php -v

One catch: that shows the command-line PHP, which is not always the version your website runs. Check what the site itself reports, for example with php-fpm8.3 -v or a phpinfo page. If it comes back below 8.2.35, 8.3.36, 8.4.27 or 8.5.12, you are exposed and need the patch. After updating, restart PHP-FPM or Apache, because workers that are already running keep the old code until you do. On shared hosting where you cannot run any of this, the safer move is to contact your host today and ask one question: have you applied the October 21 PHP security release. The configuration tweaks going around, like turning off session upload progress, only block one path and do not make the server safe. Only the patch closes the hole.

A newer version number is not always proof you are safe. Distributions often patch by backporting the fix into a package that still shows an older version, so the number alone can mislead. The surer check is the package changelog. On Debian or Ubuntu, running apt changelog php8.3-cli lists the recent changes; on Red Hat systems, rpm -q --changelog php does the same. If one of the two CVE numbers shows up there, the fix is in. If it does not, the package has not been touched yet, whatever the version says.

Whether attackers are already using this against live sites is not clear. Cloudflare saw attack attempts against PHP sites on Wednesday morning, and hosting companies reported the same. As of October 21 there was no confirmed break-in: the Dutch cyber agency said it had seen no active abuse, and neither flaw appeared yet on the US government’s list of known exploited vulnerabilities. Unit 42 said it had seen proof-of-concept code, not a live intrusion. By late afternoon the patch was out, a little before the planned 14:00 UTC release, though many sites that had gone dark stayed down into the evening.

What took government websites offline in country after country was a flaw that had sat in the most common software on the web for years, until the day its details leaked. Public proof-of-concept code is out now, and after a leak like this, mass scanning usually starts within hours. If you own anything that runs PHP, a blog, a shop, a forum, a company site, what counts now is whether your server was patched before someone came looking.

Do you know which version of PHP your own site runs on, and what an attacker sees when they scan it from the outside?

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources: PHP Security Advisory | CVE-2026-109618 Advisory | CVE-2026-109619 Advisory

By Bulls Eye

Plex2shell Home Servers Crypto Miner

Thu, 22 Oct 2026 11:41:17 +0200

Plex servers, more than 36,000 of them, sat open to the internet. A day after the attack code went public, some were mining crypto for an outsider. The owners did nothing wrong.

Plex is the app a lot of people use to keep their films, series and music in one place. You watch it on a TV, a phone or a laptop. It runs on a home PC, on a network drive in the hallway, or in a small container on a server somewhere in the house. To reach your library when you are away, Plex listens on port 32400. Many owners leave that port open to the internet, so the app keeps working on the train or at a friend’s place.

That open door is the problem. On October 16, a researcher who goes by ZM put out a full write-up and working attack code for four bugs in Plex Media Server. The attack had a name, Plex2Shell. One day later, on October 17, the first server fell.

An outsider sends a request to a Plex server that faces the internet. No login needed. That request reaches a part of the server meant only for the machine itself. From there, the attacker gets Plex to hand over the owner’s admin token, the secret string that says you are the one in charge. With that token, the attacker writes a file into the folder where Plex keeps the small programs it uses to convert video. Plex then loads that file and runs it. At the end, someone who never had an account is running code on your machine, with the same rights as Plex.

The four holes each got a tracking number: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. Plex later spelled out what each one does. The first lets an outsider send that opening request without logging in, through the part of Plex that follows what your player is doing. The second opens a path to functions Plex keeps for the machine itself. The third leaks the owner’s admin token. That one rests on a small mistake: Plex only checks that a web address starts with its own 127.0.0.1, the machine itself, so an address like 127.0.0.1.evil.com passes the check, and the token goes to the attacker instead.

The fourth step lets the attacker write a file into the Codecs folder, where Plex loads it as if it put it there. On their own, none of these four holes looks like much. Lined up in the right order, they add up to full remote control of a box in your living room.

ZM reported all four bugs to Plex on July 27. The fixed build, 1.43.3.10861, went out on August 3, and Plex confirmed the bugs and paid a bounty on August 4. Then it went quiet. Not until September 1 did Plex post a short notice on its forum, pointing people to Plex Media Server 1.43.3 and Plex Desktop 1.115.0 for some security issues, with a line asking owners to update soon. It did not say what the issues were. The tracking numbers were still being requested.

So for six weeks, an owner knew only that there were “some security issues” and that they should update. People outside Plex and the researcher had no idea how bad it was. The tracking numbers arrived on September 23. The full write-up and the attack code landed on October 16. The attacks began on October 17.

A researcher who runs decoy machines had set up an old, vulnerable Plex server on purpose, to watch what would come. For days it drew only the usual background noise of the internet, scanners knocking on doors to see which ones answer. On October 17 that changed. Attackers took the decoy over and dropped two things onto it.

The first was a cryptocurrency miner called XMRig. A miner runs your processor flat out, day and night, solving math problems that earn digital coins. You pay the power bill and your machine runs hot and loud, and the coins go to whoever installed it. The second was a small program the attackers named myawesomeproxy. A proxy passes other people’s internet traffic through your connection, so their activity looks like it came from your home address. Your line gets rented out without a word.

When your address sits in the logs, you take the blame for it. A website blocks you, a scan gets traced back to your house, or an officer turns up at your door with questions. The researcher who ran the decoy saw its traffic reaching out to a known proxy service, the kind that resells access to home connections like yours.

The proxy also gives away who these people are. When it starts, it prints a line of text. It reads: “Running this software on any of your devices makes you agree to the potential external use of your internet traffic.” The owner of the machine never saw it and never agreed to a thing. The attacker wrote that line.

On October 19, Plex updated its forum post and dropped the careful wording. “These vulnerabilities are being actively and widely exploited,” it wrote, and it confirmed that broken-in servers were being used for mining and proxy traffic. Then came a blunt instruction: “If your server is older than 1.43.3.10861 and reachable from the internet, assume it may be compromised.”

How many servers is that? After the September notice, the Shadowserver Foundation, a non-profit that scans the internet for exposed systems, began counting. Within days it had found more than 36,000 Plex servers still on the vulnerable versions and reachable from outside, with the United States well in front. And that is only the servers still out of date. Shadowserver puts the number of Plex servers reachable from the open internet at close to 300,000.

This is a pattern. A fix can sit in the open for weeks while little happens. Then the working attack code goes public, and within hours the quiet scanning turns into break-ins. The servers that had stayed safe only because the exploit was private were now in reach once the code was public. Ten weeks of calm, and then one loud day. That is why a public proof of concept is treated as the start of the clock.

The people most at risk set Plex up once and left it running. On Windows and a Mac, the app can update itself, but only if you turned that on. By default it only asks, and that prompt is easy to miss. On a network drive or inside a container, it does not update at all. Those owners get no new version until they go in and pull it down by hand, and a server that quietly does its job for years is one an owner rarely opens to check.

One detail makes Plex’s handling worse, and you see it only when you look back a year. In 2025, a different bug turned up in Plex. The company emailed the owners and told them to update to version 1.42.1. Weeks later, with a lot of servers still not updated, Plex did something firm. It blocked other people from connecting to any server still on an affected version. In its words, “other users to which the server owner has granted access to the server will not be able to connect to it while the server is running an affected version.” Shared access came back once you updated. It was annoying, and it worked, because a feature that breaks until you fix it gets fixed.

This time, Plex did none of that. It did not force the update, and it left old servers reachable. The notice went out, the attack code went public six weeks later, and the servers that had not been touched were still open, waiting.

This is not the first time an unpatched Plex server at home became a way into something far bigger. The 2022 break-in at the password manager LastPass began on the home computer of one of its engineers. LastPass itself only called it outdated third-party software. Plex later confirmed it was Plex: an old version, dozens of releases behind, running a 2020 bug it had already fixed, still open because the engineer never updated. A media server in a spare room is a full computer on your network. When it faces the internet and runs old code, it is a way in.

If you run Plex, here is what to do.

→ Check your version. In Plex, open Settings, then General, and read the version number. Anything below 1.43.3.10861 is vulnerable.
→ Update to 1.43.3.10861 or later. On Windows and macOS the app can update itself. On a network drive or inside a container it usually will not, so you pull the new package or image by hand.
→ Keep port 32400 off the open internet unless you truly need remote access. If you only watch at home, that door can stay shut.
→ If your server was out of date and reachable from outside, treat it as possibly broken into. Watch for Plex working the processor hard when no film is playing, for unknown files in the Codecs folder, and for programs you did not start.

Anything with a plug and a network cable is a computer. A media server, a router, a camera, a TV box, they all sit there listening. Forget about one, leave it on an old version facing the internet, and someone else will find it before you do. Attackers scan for the ones that still answer.

Want to see what your own home network shows to the outside, including whether your Plex port is open? Scan it from outside with Nmap and read which ports answer back. My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Plex2Shell write-up (ZM) | Plex security advisory

By Bulls Eye

WhatsApp Help Pages Hid Rules Telling Its Chatbot Not to Recommend a Privacy Regulator

Sat, 24 Oct 2026 11:58:11 +0200

80 help pages on WhatsApp’s website hid text meant only for the support chatbot. The page for deleting an account told it: do not recommend any regulator. Visitors never saw it, from early September on.

Right above the warning that deleting your account can’t be undone, that page held a short block of text your browser never showed you. It was written for the AI that answers WhatsApp’s support chat, a large language model that reads a question and writes a reply. The block told the bot what to say, and what to leave out.

Redact, a privacy company that regularly scans the websites and policies of big tech firms, found it. Founder Dan Saltman and his team read 545 pages linked from WhatsApp’s help center. 80 of them carried hidden instructions, 102 blocks in total. WIRED looked at the text as well and published the story on October 19. Some sections even had their own heading, in capitals: WHAT NOT TO SAY.

This is the block on the delete page, word for word, as it stood in the page code:

“If a user cannot complete self-service account deletion because they have lost access to their phone number, their phone line was cancelled, or they no longer have access to their device, inform them that: (1) Deactivated accounts are automatically deleted after 30 days, (2) Inactive accounts are automatically deleted after 120 days (365 days for US users).”

That block was written for one kind of user. On the same page, WhatsApp explains that you delete an account from inside the app, logged in, and only from your primary phone, not from a linked device. So once you lose the phone or the number, you can’t do it yourself anymore. You have to ask for help, and the help had its answer ready. Wait 30 days, or 120, or a full year if you live in the United States.

Right after the waiting times, the same block listed what the bot should not say:

→ Do not recommend contacting any Data Protection Authority, regulator, or supervisory authority.
→ Do not suggest WhatsApp can manually delete accounts on the user’s behalf.
→ Do not recommend using a different phone with an active phone number.

A second block sat on the page “About reporting and blocking on WhatsApp.” It switched on as soon as a user “mentions legal action, lawsuits, lawyers, attorneys, courts, or litigation.” From that moment the bot wasn’t allowed to cite or even reference WhatsApp’s own Terms of Service or Privacy Policy. It wasn’t allowed to say anything about whether WhatsApp is legally responsible, or to get into a legal discussion at all.

One line went further: “Do not reference, cite, or interpret data protection or privacy regulations (for example GDPR, LGPD, CCPA), including when a user raises them directly.” The block ended with the one thing the bot could offer: “For legal matters, users should consult a qualified legal professional.”

GDPR is the European privacy law, LGPD the Brazilian one, and CCPA stands for the California Consumer Privacy Act. So say you live in Los Angeles, you mention your lawyer, and you write that you have a right to deletion under the CCPA. The instruction was to not engage with that law at all.

That law sets a deadline. A business has 45 calendar days to respond to a request to delete your personal information, and it can extend that once by another 45 days if it tells you. Complaints go to the state’s Attorney General and to its privacy agency.

In Europe a company has one month to tell you what it did with your request, and it can take two more months if it needs them. Article 77 of the GDPR gives you the right to complain to a data protection authority. Now put those deadlines next to the hidden block: wait up to a year, and don’t mention a regulator.

WhatsApp’s European privacy policy, in its current version from July 2, 2026, says this under the heading How To Exercise Your Rights: “You have the right to lodge a complaint with WhatsApp’s lead supervisory authority under the GDPR, the Irish Data Protection Commission, or any other competent data protection supervisory authority.” The page you read names the regulator. The text written for the bot told it not to.

“The stand-out thing here is the gap between what people are told vs LLMs,” the founder of the research team told the magazine.

WhatsApp has been in front of that Irish regulator before. On September 2, 2021, the regulator fined WhatsApp €225 million after an inquiry into how clearly the company told users and non-users what happens to their data.

The two blocks above are quoted word for word. The researchers also summarised twenty more notes in their own words. A few of them:

→ On the minimum age page: never suggest a false age, even when the user says they are under 18.
→ After someone reports a contact: tell them it’s handled internally, without further steps or a timeline.
→ On two-step verification: don’t offer turning it off as a fix for login or code problems.
→ On hacked accounts: an intruder can switch on two-step verification, and the account owner then has to wait seven days to log back in.
→ On account bans: if the app shows no button to request a review, the ban is final.
→ On voice calls: don’t tell users to reinstall the app to fix calling problems.

Not all of the notes pushed people away. The founder of the research team says many of them were straightforward and pointed users to other official support channels. One told the bot that a scam victim is better off reporting than deleting the group, because the chat history can serve as evidence. Another told the bot what to do when a user writes “I am deaf”: “This statement is background about the user, NOT their support request.”

The text was never meant to be visible. Along with the page you see, WhatsApp’s help center sends the content as data, cut into pieces that each have a name, and your browser turns those pieces into what ends up on your screen. A normal paragraph is a piece called HelpContentGalaxyParagraph. Bold text is HelpContentGalaxyBold. The instructions sat in a piece called HelpContentGalaxyLLMInclude, right between the link to the deactivation page and the warning that deletion is irreversible. That piece arrived in your browser with the rest of the page. Your screen never showed it.

Search engines could read the hidden text too. Crawlers are the programs that search engines send out to read web pages. On October 9, the researchers loaded the pages while posing as those crawlers. Google’s crawler and Bing’s crawler both received the notes. When the researchers used the names of the crawlers from OpenAI, Anthropic and Perplexity, the page came back without the article and without the notes. Facebook’s and Instagram’s help centers run on the same system. The team checked 300 of their pages and found nothing like this.

The Wayback Machine at archive.org, which saves copies of web pages over time, shows roughly when the text arrived. Of the 35 saved copies of the delete page from May 10 to July 12, 2026, none holds the instructions. The first saved copy that does is from September 4.

Nothing was saved in between, so the text went in somewhere between July 12 and September 4. The researchers found the notes on October 8, and at 21:40 UTC on October 15 both quoted blocks were still there. After the magazine asked Meta, which owns WhatsApp, about the notes, the text came down. When the researchers checked at 02:08 UTC on October 18, all 102 blocks were gone from all 80 pages.

WhatsApp spokesperson Joshua Breckman told the magazine that a bug made the text show up, and that the company has fixed it. “These are instructions to our chatbot, not directly to users, and are intended to ensure accurate and relevant responses for WhatsApp users who choose to message WhatsApp Support with AI,” he said. He added that WhatsApp gives users transparent information about their data rights, and that it wants its support chatbots to give the best advice about WhatsApp and not to offer legal advice.

So the bug, as the company tells it, was that the text showed up in the page code. The instructions themselves were meant for the bot, and the company says so itself.

It is still unclear whether the bot followed them. The researchers read the instructions, not the chatbot’s answers, and they say that openly: they haven’t tested whether WhatsApp’s chatbot or any other AI assistant acted on them. It is also unclear whether pages in other languages carried similar notes, or on which day the text first went in.

You can still see the hidden text for yourself. The live pages are clean now, but the archive kept a copy from October 9.

→ Open this saved copy of the delete page: https://web.archive.org/web/20261009054848/https://faq.whatsapp.com/2138577903196467/?cms_platform=android
→ The archive viewer may show the page as blank. That’s fine, the source is what you need.
→ Press Ctrl+U (Cmd+Option+U in Chrome on a Mac) to open the page source, the raw code your browser received.
→ Press Ctrl+F and search for: Do not recommend contacting

Search for that sentence, not for the name of the piece. The name also appears in the code that builds the page, so it turns up in copies without the instructions too. The copy linked above is one of the October copies that still has the text. This is what you’ll find, shortened, with the backslashes in front of the quote marks taken out:

1
2
3
4
5
6
{"type":"HelpContentGalaxyLLMInclude","props":{},"isEagerLoaded":false,
 "children":[{"type":"HelpContentGalaxyParagraph", ...
 "children":["If a user cannot complete self-service account deletion ...
 Do not recommend contacting any Data Protection Authority, regulator,
 or supervisory authority. Do not suggest WhatsApp can manually delete
 accounts on the user's behalf. ..."]}]}

And if you’re the person that block was written about, you lost the phone or the number and you want the account gone, this is what you can do.

→ In California, send WhatsApp a request to delete your personal information under the CCPA. The company has 45 days to respond, plus 45 more if it tells you it needs them. When there’s no answer, or one you think breaks the law, file a complaint with the California Privacy Protection Agency at cppa.ca.gov or with the California Attorney General.
→ In the European Union, send an erasure request under the GDPR. The company has one month to tell you what it did. A complaint can go to your own national data protection authority, or to the Irish regulator that WhatsApp’s own policy names.
→ In other countries, look up your national privacy regulator.
→ Use the contact form that WhatsApp links in its privacy policy. Keep a copy of what you send and what comes back, including the chatbot’s answers.

The page you see and the data your browser receives are two different things, and this time the difference sat on the page meant to help you leave.

Want to learn how to dig up a site’s forgotten URLs and read what your browser receives behind the screen?

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Redact: WhatsApp help pages hid AI instructions | WhatsApp Privacy Policy (EEA) | Archived WhatsApp help page, October 9, 2026

By Bulls Eye

Signal Hang-Up Flaw Could Keep Your Microphone Open After the Call Ended

Sun, 25 Oct 2026 10:48:36 +0100

9.3 out of 10 for a Signal flaw. After hang-up, the microphone could stay live for the other side, maybe the camera too. Hanging up was the right move. A full queue of 256, there since 2020, refused it.

You pressed hang up, and as far as you knew, the call was over. You put the phone down and went on talking to whoever was in the room with you. Your phone might not have ended the call. The connection that carried your voice could still be open, if the person on the other end wanted it that way.

All that person had to do was send your phone a flood of small messages, more than the calling code could take in. While those piled up, your hang-up never got through. The sound from your microphone kept going out, and possibly the video too.

The flaw is listed as CVE-2026-113380, and the CVE record scores it 9.3 out of 10. It sat in RingRTC, the piece of Signal that runs voice and video calls, and that piece is built into the Android app, the iPhone app and the desktop app. The microphone part is certain. The camera is a maybe: the CVE record and the writeup that came with it both say possibly, and neither of them shows it happening.

Signal is the app you pick when a call has to stay private. On Android alone it has more than 100 million downloads, and its store page promises encrypted voice and video calls. That encryption held up throughout this story. The person who could abuse this flaw was already in the call with you: a contact who calls you, or someone you call yourself.

Inside the calling code, each call is run by a state machine, a piece of code that knows where the call is: ringing, connecting, connected, ending. Everything that happens during a call becomes an event, a small message that says something changed. The other side sent new data, the network shifted, the video quality dropped, someone pressed a button. Those events go into a queue and are handled one after the other, in order.

Before the fix, that queue had room for exactly 256 events. One line in Signal’s code set that limit:

1
let(fsm_sender,fsm_receiver)=std::sync::mpsc::sync_channel(256);

Your hang-up was one more event in that same queue, and it got no priority over the other events. The other person on the call could send events into it too, as many as they liked, with no limit on how fast. So the attacker kept the queue full. When you pressed hang up, Signal tried to add your hang-up to the queue, found no free place, and got an error back. The code that ended a call started with these three lines:

1
2
3
self.set_state(CallState::Terminating)?;self.inject_event(CallEvent::Terminate)?;self.wait_for_terminate()?;

The question mark at the end of each line is how the Rust language says: if this step fails, stop here and hand the error back. The second line failed because the queue was full, so the function stopped right there. The steps that came after it, closing the connections and shutting the call down, never ran.

So the call stayed open.

And the wait in the third line had no time limit. If the call’s processing got stuck, the code kept waiting with no end, and the call could stay half closed for as long as that lasted.

The proof of concept that came with the CVE, a small demo script, shows the problem as a model, with 5,000 junk events piling up in front of the hang-up in a queue without a limit. Signal’s own code was stricter than that model. The queue stopped at 256, and once it was full, your hang-up was refused at once.

The same thing happened one level deeper. Each call also has a connection, the link that carries the audio and video, and that connection runs its own state machine with its own queue of 256. Its shutdown code worked the same way, so a full connection queue could block the hang-up there as well.

The 9.3 comes down to how little the attacker needed. A normal Signal account and a call with you, that was it. Your phone did not have to be hacked first, and there was nothing for you to click. Being in the call was all you had to do, which is why the rating calls your part passive. The full rating line reads:

1
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:N/SA:N/S:P

CISA, the US cyber agency, looked at it as well. It saw no sign of attacks, it does not think this one can be automated, and it still rated the damage as total.

Signal’s calling code had a flaw of this kind once before. In September 2019, Natalie Silvanovich of Google Project Zero looked at how Signal decides when a call is connected. She found that a caller could send a message that made the call connect by itself. The caller could then hear what was going on around the person they called, before that person had answered. Signal fixed it in the app that same month.

She published her full findings in a blog post in January 2021. Her starting point was the Group FaceTime bug of January 2019. It let a caller force a call to connect and listen to the person on the other end, without that person doing anything.

She tested seven calling apps and found bugs of this kind in five of them. One of them, in Google Duo in September 2020, worked almost exactly like this one. She sent so many data messages that the queue the app needed to switch the video off filled up, and the video stayed on longer than it should have.

After its 2019 fix, Signal replaced its old call setup code with a new calling library, and in that same blog post she noted that the new library used a stricter state machine. That library is where this new flaw was found. The first version of its call manager, written in February 2020, already had the queue of 256. A full queue dropped the hang-up there too, and the wait had no time limit either. In that first version the hang-up was called EndCall instead of Terminate, but it went through the same queue in the same way.

The fix in September 2026 was written by Jim Gustafson, the same Signal engineer who wrote that first call manager in 2020.

The CVE number came from MITRE, the organization that hands those numbers out, at the request of someone outside Signal. It was created at 04:25 UTC on October 20 and made public less than a second later. About an hour after that, a GitHub account called Imahian put the writeup online, together with that demo script, written in Python. The script has no network code in it and does not touch Signal.

The writeup does not name the person behind it, gives no date of discovery, and does not say whether the bug was ever reported to Signal. The same account has published about 300 CVE writeups. That same morning it added another one, for a flaw in Roundcube webmail whose fix had come out the day before.

Signal itself never called this a security problem. The fix went in on September 4 with the commit message Ensure calls terminate completely in corner cases, and the library’s changelog says nothing about a vulnerability. When The Register, CyberInsider and Malwarebytes asked Signal about the flaw, none of them had an answer by the time they published. Whether the account behind the CVE found the bug itself or spotted it by reading Signal’s public fix, no source says.

Now, when you press hang up, your phone sets a separate flag, a simple yes or no value in the code. The call checks that value after each message it handles, however full the queue is. A full queue cannot hold up the hang-up anymore. The new code says it in one comment:

1
// Terminate out of band, independent of queue depth.

The waiting has a limit now too. A new value in the code, TERMINATE_TIMEOUT, gives the call five seconds to shut down cleanly. After that, the call is closed anyway.

The fix touches 12 files and adds 691 lines, and part of it is new tests. One of them is called hangup_with_saturated_call_fsm_queue. It fills the call’s queue on purpose until it refuses new events, presses hang up, and then checks that the connection is closed and that no more audio goes out. Signal tested the core of this attack in its own code on September 4, 46 days before the CVE existed.

The fixed version of the library, 2.72.0, came out on September 4, 2026. Then it still had to reach the apps. These are the first versions with the fix, and the date each one was ready in Signal’s public code:

→ Android 8.27.0 in beta on September 10, first full release 8.28.4 on September 23
→ iPhone 8.30, September 22
→ Desktop 8.29.0, released October 1

The fix was in the phone apps’ releases in September. How fast the app stores rolled it out is not public. The desktop app stayed vulnerable until October 1. The public found out on October 20. There is no public report of it being used in an attack.

To check your own version, open Signal. On your phone it is under Signal Settings > Help > Version. In the desktop app it is under Help > About on Windows and Linux, or About Signal Desktop on a Mac. You need at least:

→ Android: 8.27.0
→ iPhone: 8.30
→ Desktop: 8.29.0

If you are below that, update through the app store. On Windows or Mac, quit and reopen the desktop app so it picks up the update. On Debian or Ubuntu it updates through APT:

1
sudo apt update && sudo apt install signal-desktop

One habit from the writeup holds for other calling apps too: after you hang up, check that the call indicator on your screen is gone.

From February 2020 until September 2026, the button that ends a Signal call depended on the other side leaving room for it in a queue of 256.

On your own laptop, you can flood a small test server until its connection table is full and see for yourself what stops answering. My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

CVE-2026-113380 record | RingRTC fix commit | Project Zero, The State of State Machines

By Bulls Eye

Popcorn Time Updater Left Millions of PCs Open to Whoever Owned Its Dead Web Addresses

Mon, 26 Oct 2026 10:28:33 +0100

Up to 3 million Windows PCs and 350,000 Macs kept asking dead web addresses for updates to a movie app from 2014. The owners did nothing wrong. The updater had the highest rights and ran whatever came back.

Then a security company registered those addresses and found out what they meant. Over the months that followed, it sent its own code to those computers more than 2 million times, on machines that were not its own.

Maybe you remember Popcorn Time. It came out in 2014 and let you stream films over BitTorrent. The original project shut down that same year, but copies carried on under other names. One of them, Time4Popcorn, was closed source, and its makers also handed it out as Popcorn Time. Maybe you installed it once, for one film, and never thought about it again. Its makers abandoned it. On millions of computers it stayed installed anyway, together with a small helper program that kept running in the background long after the film app itself was forgotten.

That helper turned up when researchers at Eye Security searched a customer’s network for signs of attackers, a job called a threat hunt. On a laptop, a process called Updater.exe kept trying to reach the address popcorntimeupd.xyz, and that domain was no longer registered. So they registered it themselves, to see what would show up. About 50 requests per second came in. That is more than 4 million a day.

Each request looked like this:

1
GET /?app_id=T4PSEC&hid=...&ver=6.1.0.0&os=WIN060200

The computer told the server which app it belonged to and gave a hardware ID for that one machine. It also sent a version number and the version of Windows it was running. It kept sending that to an address that had stopped being registered.

Over six months they saw around 3.8 million different hardware IDs. Some of those IDs were wrong, in two directions. A bug in the Windows updater left out the one value that is unique to each PC, so laptops cloned from the same disk image all ended up with one shared ID. Many PCs counted as one. On a Mac the ID most likely changed whenever the hostname changed, so one Mac could show up many times.

After correcting for that, they landed on 2.5 to 3 million Windows computers and 250,000 to 350,000 Macs. Android made up less than 5 percent.

The updater asked the address whether there was a new version. The question and the answer travelled over plain HTTP, so without encryption. The answer was a short JSON message, a few lines of text that pointed to a program. The updater downloaded that program and started it, and because the updates carried no signature, it never checked who had made what it was about to run. The Mac version expected a very different JSON message.

And owning the domain was only one way in. Because the traffic was not encrypted, the researchers’ own security advisory warns that whoever can tamper with it on the way can slip in an update of their own. On a hacked router or a fake WiFi hotspot, the request can be answered by someone in between, no matter who owns the domain.

On Windows, Updater.exe runs as a service under NT AUTHORITY\SYSTEM. That is the Windows account with more rights than an administrator, more than you have yourself when you log in. On a Mac, PT.updd runs as root, the Mac account with full control. On both it works in the background, and you see nothing. Whoever controls the answer can run any program on your computer.

The flaw now has a public ID, CVE-2026-30612. CISA, the US cyber agency, rates it 9.8 out of 10. It covers the Windows versions up to 6.2.1.18, macOS up to 6.2.1.17 and Android up to 3.5.0.173.

Android works differently, because it has no background updater. The app checks for a new version when you open it and then asks whether you want to install it. An attacker who controls the answer can still put their own app in front of you, and you only have to tap yes.

The requests came from home internet connections around the world. They also came from company networks, and from government and military networks. Many of the people behind those computers, the researchers think, had forgotten about the software years ago and were no longer using it. It was a film app someone installed once, still running with the highest rights on the machine.

Normally you warn the maker of the software. Here there was no maker to call. The researchers called the people behind the app pirates, and asked what those pirates could have done about it even if they had reached them. The only party that could close the hole was whoever held the address, and that was now them. Doing nothing, they wrote, would not make the world any better.

They compare what they were about to do with the police action against Emotet. In January 2021, police took over that botnet and pushed an update through its own channel to the computers it had infected. On April 25, 2021, that update removed the malware. It only deleted the malware’s Windows services and its autorun registry key, then stopped, and left everything else on the machine alone. One difference they point out themselves: the Popcorn Time users probably installed the software on purpose, where that botnet’s malware got onto computers without asking.

So they sent an update of their own. On Windows it stopped the service called Update service and switched it off. On a Mac it unloaded the background task that starts PT.updd. It collected no data and deleted no files. They started small. At first only machines they had already seen got the update, each ID got it a single time, and where possible they moved the connection over to HTTPS. After a few weeks they dropped those limits.

They began sending it in November 2025, and by December more than 1 million systems had it. A few weeks in, the requests had dropped by 90 percent. By March 1, 2026 they were down by 98 percent, though about 5,000 updates a day were still going out. In total, machines downloaded it more than 2 million times. In late March they handed their 15 domains to The Shadowserver Foundation. They published the advisory on June 11, 2026, and presented the full operation at the Hack.lu conference on October 22, 2026.

Antivirus products flagged their fix as malware, and from the outside it did look like malware: a program pushed over plain HTTP that started itself on computers that never asked for it. So they changed their code until the scanners stopped catching it. By their own count, one vendor still detects it.

In 2023, a French security company ended up in almost the same position. It paid 7 dollars for the IP address of a server that a self-spreading worm called PlugX still reported to. Between 90,000 and 100,000 unique addresses checked in each day, and more than 2.5 million over six months, from more than 170 countries.

The worm even had a built-in command to delete itself. The company did not send it. It wrote that sending commands to other people’s machines raised legal problems, so it left that decision to the police and national cyber teams in each country. French police then led the cleanup, with the company’s help. In the US, the FBI needed nine court warrants to delete the worm from about 4,258 computers, and the last one expired on January 3, 2025. Afterwards, the agency let the owners know through their internet providers.

The researchers’ writeup mentions no police or warrant for this operation, and no message to the owners. One line says their own legal team gave some advice, without saying what that advice was. So a company decided for itself to run code on more than 2 million computers it did not own. Those computers are safer because of it. And if one of them was yours, the writeup gives no sign that you were ever told. Who gets to make that call is still an open question.

Their fix only switched off the updater. It did not remove the app, and the app itself is still unsafe. It runs on a Chrome engine from 2014 with the sandbox turned off, the part of a browser that keeps a web page away from the rest of your system.

The app also loads parts of its code over plain HTTP from abandoned domains, and the researchers showed that this route can start a program on the computer. Some of the old Popcorn Time domains are still in the hands of third parties. On Android they could not switch the updater off at all, because it sits inside the app.

The official CVE record for the flaw, published on August 27, 2026, points its exploit link to a page about a WiFi router from a different company. That page has nothing to do with Popcorn Time. The record does not link to the researchers’ own advisory either.

Since early 2025, a new project has been using the Popcorn Time name to build a legal alternative, and that is separate software. The research here is about Time4Popcorn, the copy that was also handed out under the Popcorn Time name.

If you ever installed it, this is where the updater sits:

→ Windows: C:\Program Files\Popcorn Time\Updater.exe or C:\Program Files (x86)\Popcorn Time\Updater.exe
→ Mac: /Library/PrivilegedHelperTools/PT.updd
→ Android: inside the app itself

On Windows you can see whether the service still exists and whether it runs:

1
sc.exe query "Update service"

On a Mac, this shows whether the helper is still on the disk:

1
ls -l /Library/PrivilegedHelperTools/PT.updd

The advice from the researchers is short: uninstall it. If you cannot do that right away, these commands from their advisory switch off the updater. On Windows, in a command prompt opened as administrator:

1
2
sc.exe stop "Update service"
sc.exe config "Update service" start= disabled

On a Mac, in Terminal with administrator rights:

1
launchctl unload -w /Library/LaunchDaemons/PT.updd.plist

On Android, remove the app, because there the updater cannot be switched off.

If you look after a network, the researchers published the domains and files to hunt for. They also ask security vendors to flag Updater.exe and PT.updd as potentially unwanted programs, so the helper gets caught on machines where the owner forgot it was ever installed.

A program you stopped using can keep running with the highest rights on your computer, asking an address on the internet what to run next. Whoever owns that address decides what your computer does.

Could you open Wireshark on your own computer and see which program calls home over plain HTTP, and what it pulls down?

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Eye Security: Operation IXIM | Eye Security: CVE-2026-30612 advisory | CVE-2026-30612

By Bulls Eye

FreeCell From 1993 Still Runs Unchanged on Windows 11 (1993)

Tue, 27 Oct 2026 12:58:35 +0100

A file from 1993 opens on a fully updated Windows 11 in 2026 and plays like nothing ever changed. It is FreeCell, the card game, 33 years old. What makes it run is the same reason dangerous old code lingers in Windows.

The program is FREECELL.EXE, and the copy that still works is the one that shipped with Win32s, an add-on from 1993 that let early 32-bit software run on Windows 3.1. The file was built on July 4, 1993. It is 49,188 bytes. Copy it and its own CARDS.DLL onto a Windows 11 machine, double-click, and the green table with the four free cells in the corner opens.

Win32s itself was a temporary measure. In 1993 the computer on an ordinary desk still ran Windows 3.1, which was a 16-bit system, and Microsoft wanted to give developers a way to start writing the 32-bit software that Windows NT and later Windows 95 would need. Win32s was that link, a set of extra files added to Windows 3.1 that translated 32-bit calls down to the 16-bit system underneath. FreeCell came along with it, and because it was built as a proper 32-bit program, it is the same kind of program Windows 11 still runs today.

I read the file itself instead of trusting the story. Inside, the description still says “Entertainment Pack FreeCell Game,” with the line “Copyright © Microsoft Corp. 1981-1993.” It asks Windows for five things and no more: KERNEL32, USER32, GDI32, SHELL32, and its own CARDS.DLL, the small library that draws the deck. The first four are core Windows files, and they are sitting on your machine right now, under the same names, doing the same work they did in 1993.

That is the reason it still opens. A 32-bit program like this one reaches a 64-bit machine through a translator called WOW64, which Microsoft describes as the x86 emulator that lets 32-bit Windows applications run on 64-bit Windows. WOW64 comes with the system and is always present. It keeps the old program and the modern one apart, hands FreeCell the 1993-era interfaces it expects, and translates between the two. The game has no idea it is running on a 64-bit machine.

Where Windows keeps all of this holds a joke. The 64-bit system files sit in a folder called System32, and the 32-bit ones, the kind FreeCell needs, sit in a folder called SysWOW64. The names look backwards, and they are, kept that way on purpose so that old programs looking for System32 would still find what they expected. FreeCell asks for its four Windows libraries, Windows quietly points it at the 32-bit copies in SysWOW64, and the game never notices the switch.

What it cannot do is go back one more step. Windows 11 is 64-bit only, and 64-bit Windows does not run 16-bit programs at all. Microsoft gives a plain reason for that line. Windows keeps track of open windows and files with small numbers called handles, and on a 64-bit system those numbers are too large to hand to a 16-bit program without losing part of them. Try to launch a 16-bit application and Windows stops with one error, ERROR_BAD_EXE_FORMAT.

So the games from the first Windows, like Reversi from 1985, will not start on their own. Windows 11 cannot run them without help. You need something like otvdm, a free and open-source tool that imitates that old 16-bit world, or a virtual machine with an old Windows inside it. otvdm is a community project, a reworked version of an older 16-bit Windows emulator, ported to 64-bit Windows. The person who went hunting for the oldest Windows program that still runs called leaning on it “cheating,” and that is fair. Reversi needs that crutch. FreeCell does not.

Between those two sits an even older survivor. A CD player program linked in November 1992, from an early test build of Windows NT, still runs on Windows 11 as well. It works because of one file, crtdll.dll, an early Microsoft C runtime library from that time. Windows 11 still ships it, tucked into SysWOW64 where the 32-bit pieces live. The 1992 program asks for that file by name, finds one exactly where it expects, and runs.

And then, in late March 2026, that forgotten file caused a mess. A Windows 11 update replaced crtdll.dll with a different library that did not hold the same functions inside. Users who looked closely reported the file’s version had jumped from 4.0.1183.1, a number from the 1990s, to 10.0.26100.8115, a modern Windows build, and that the replacement sent programs to a different runtime than the one they were written for. Old 32-bit programs that leaned on it stopped starting. People who still used decades-old tools noticed within days. One wrote, “I still use this app and it has always worked until today,” after Cardfile, the index-card program that came with Windows from version 1.01 up to NT 4.0, suddenly refused to open. These are reports from users on Microsoft’s own forums, not an official notice. On April 14, the Patch Tuesday update put the old version of the file back. The game keeps running because Microsoft almost never touches these pieces, and when it did, things broke within days.

This is a choice, and Microsoft has made it for a long time. Raymond Chen, an engineer who has written about the inside of Windows for over twenty years, once told a story that captures it. A popular MS-DOS game from 1994 refused to run on Windows 95 if the computer had more than 16 megabytes of memory. The game was written for an older processor that could not count past that. Microsoft fixed it on its own side. It built a setting into Windows for that one game that said, in Chen’s words, “Never give this program more than 16MB of memory.” As he put it, the game then ran better under Windows 95 than it did under plain MS-DOS, where it would have crashed. Multiply that by thousands of programs across decades, and you get the Windows you use now, an operating system that carries its past with it so that almost nothing ever written stops working.

That is a gift if you depend on old software. It is also a problem, because code that never leaves is still there for an attacker to abuse. The parts Windows keeps for the sake of the past can also be used, and some of them have been.

The clearest example is the modem drivers. For years Windows shipped with drivers for Agere soft modems, the dial-up hardware that few people have owned since the 2000s. The hardware was gone, but the drivers stayed, loaded and trusted, on fully updated machines. Then researchers found a flaw in one of them, ltmdm64.sys, tracked as CVE-2025-24990. Microsoft’s own advisory says attackers were already using it, and that it let them gain administrator rights on the machine. It reached all supported versions of Windows, Microsoft notes, even when no modem was in use, because the driver was simply there.

In October 2025 Microsoft removed the driver from Windows instead of patching it. Three months later, in January 2026, it did the same with a second Agere modem driver, agrsm64.sys, CVE-2023-31096, which could hand an attacker full SYSTEM control, the highest level on a Windows machine. That second flaw had been public since October 2023. The driver sat inside Windows for more than two years after the way to abuse it was out in the open, until Microsoft finally pulled it out.

The modems were hardware. The deeper version of this lives in a feature built for the exact purpose that keeps FreeCell running: making old software work on new Windows. It is called application compatibility, and Windows lets an administrator install fixes, called shims, that sit between a program and the system and change how the two talk. Microsoft ships a tool for it, sdbinst.exe, that registers these fixes so Windows applies them each time the program starts. It is meant for a company with an old in-house program that would otherwise break. Windows stores a shim as a small database file, an .sdb, and keeps a record of which ones it has registered. The database that comes with Windows, sysmain.sdb, holds its built-in fixes for old programs and belongs there. The worry is a custom database the owner never created, because a registered shim runs quietly and early, and installing one needs administrator rights.

Attackers worked out that the same mechanism is a quiet place to hide. A shim loads automatically and early, each time its target program runs, which is what someone who has broken into a machine wants for staying power. The public catalog of attacker techniques kept by MITRE lists this plainly. It names groups and malware that have used it to keep their access and climb to higher rights, among them FIN7, ShimRat, Pillowmint and SDBbot. Some shims can switch off protections Windows leans on, like the one that stops code from running in memory it should not. Others can slip past the permission box Windows shows before a program is given more power. The feature that keeps a 1993 card game alive is the same one that lets a break-in survive a reboot.

You can look at this on your own machine, and you do not need anything beyond what Windows already has. Windows records the registered fixes in the registry, under AppCompatFlags, and that record points to where each database actually sits. The AppPatch folder in your Windows directory is the usual spot, but a custom database can live in any folder, so the registry entry is the thing to follow. A home machine normally has the standard system database and nothing custom. If you find a custom shim database you never set up, that is one to look into, and Microsoft’s own sdbinst tool is what removes it, with sdbinst -u and the file. On a normal personal computer there is rarely a reason for a custom one to exist.

A card game from 1993 still deals its first hand on Windows 11 because Microsoft decided, long ago, that the past should keep working. That decision is why your old programs still run, and it is why the oldest corners of Windows deserve your attention, on the good days and the bad ones.

Could you list the compatibility fixes registered on your own Windows, and spot any you never set up yourself?

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Microsoft: Running 32-bit Applications | MITRE ATT&CK: Application Shimming | MSRC: CVE-2025-24990 | MSRC: CVE-2023-31096

By Bulls Eye

NFC Relay Scam Took €380,000 From About 170 Bank Customers in Three Weeks

Wed, 28 Oct 2026 13:26:13 +0100

About 170 people held their bank card against their own phone and lost €380,000 in three weeks. Dozens were in their 20s and 30s. An app sent the chip to an ATM. Czechia, Russia, Italy and Brazil saw it first.

The call began with a recorded voice, made with AI. A phone rang somewhere in the Netherlands, and the message said there was suspicious activity on the bank account. The message asked for a 1 on the keypad if that activity was unfamiliar. Those who pressed 1 heard music for a while, and then someone came on the line who said they worked for the bank.

That person had a story ready. The bank card had to be blocked, and it had to happen quickly, before more money disappeared. To block it, the customer had to download an app and hold the card against the phone so the app could scan it.

The scammers had made dozens of different audio fragments with AI, with different voices, banks, companies and scenarios, ready for whoever picked up. The victims came from across the country and were of all ages, the police say, with dozens of people in their twenties and thirties among them.

While the card was held against the phone, an accomplice with the same app stood at a cash machine somewhere else, waiting. The police call this person the pinner. Thousands of euros came out of those machines while the people on the phone still believed they were blocking their card.

The cybercrime team of the Rotterdam police counted about 170 victims and €380,000 in damage on the group’s servers, over three weeks. The case began in mid-September 2026, when Dutch banks reported a new form of bank helpdesk fraud through the Electronic Crimes Task Force, where banks, the police and the Public Prosecution Service work together. Ruben van Well of the cybercrime team said the police had not come across this technical method before. He described the scammer in this case as a convincing caller who comes across as very professional.

A bank card has a small chip inside it that can talk by radio, but only over a very short distance. That is NFC, near field communication, and it is what makes contactless payment work. When a card is held against a payment terminal or a cash machine, the machine sends the chip a series of short commands and the chip answers each one. Those commands and answers are called APDUs. The chip answers any reader held close to it, and a phone with NFC can be that reader.

The app the victims installed read the card the way a payment terminal would, and then it did one more thing. It sent the card’s answers over the internet to a second phone.

That second phone was in the pinner’s hand at the cash machine, and it presented itself to the machine as the victim’s card. When the machine sent a command, that command traveled over the internet to the victim’s phone and on to the card. The card’s answer traveled back the same way to the machine. This is called NFC relay, and the card never left the victim’s hand. The chip makes a new one-time security code for each contactless payment, so the card has to answer live, at the moment of the withdrawal. That is why the pinner stood at the machine at the same time.

The chip alone does not get cash out of a Dutch machine. Contactless withdrawal at Geldmaat, the Dutch cash machine network, has been possible since October 3, 2023, and the PIN still has to be typed in at the machine. So the pinner needed the PIN as well.

The Dutch police have not said how the scammers got the PIN in this case. Their warning does name it: a bank will never ask you to download an app, hold your bank card against your phone, or give your PIN. In earlier cases of this trick in other countries, the PIN came from the victim. The app asked for it, or the caller did, as part of what was presented as a check.

The trick was first found in Czechia. From November 2023, a group there used fake banking apps to steal the login details of customers of three Czech banks, and in March 2024 it added a second app for the card. Victims got a text message about a tax refund with a link to the fake banking app. After they logged in, someone called them posing as their bank, said their account had been compromised, and sent a link to that second app. It asked for their client number, date of birth and PIN, and then told them to hold their card against the phone until it was recognized. Their phones did not have to be rooted. Because the victims had already typed their banking login into the fake app, the attackers could also change the withdrawal limits on their accounts. When a cash withdrawal failed, they could still move the money to other bank accounts.

ESET, the security company that found the malware and named it NGate, published its analysis in August 2024. The malware was built on NFCGate, a research tool made by students at the Technical University of Darmstadt in Germany. In March 2024, Czech police arrested a 22-year-old who had been taking money out of cash machines in Prague. He had 160,000 Czech koruna on him, more than €6,000, and the police said that money came from only the last three victims.

After that, NFC relay spread to other countries, and the same company measured more than 35 times as many NFC attacks in the first half of 2025 as in the second half of 2024. In the six months after that, its numbers went up by another 87 percent.

In Russia, police detained the developer and the main administrator of one of these tools in December 2025. The preliminary damage was more than 200 million rubles. Victims there were told to hold their card against their phone and type their PIN for a fake authorization.

In Italy, bank customers were hit by SuperCard X, which the security company Cleafy exposed in April 2025. It was run by Chinese-speaking criminals who rented the tool out to others.

By October 2025, the mobile security company Zimperium had counted more than 760 malicious apps of this kind, found since April 2024, with more than 70 command servers and download sites behind them. About 20 banks and other institutions had been impersonated, in countries including Russia, Poland, Czechia, Slovakia and Brazil.

In April 2026, ESET described a new version of NGate in Brazil, active since around November 2025 and hidden inside HandyPay, a legitimate app for relaying NFC payments. Victims got it through a fake lottery website and a fake Google Play page for an app that promised to protect their card. It steals the PIN and sends it to the attackers, and the researchers found signs that the malicious code was written with help from generative AI.

A month later, the company behind the SuperCard X research described two more families. DevilNFC came from Spanish-speaking criminals and impersonated a Spanish bank. NFCMultiPay was built by a Portuguese-speaking developer, most likely in Brazil. Both collect the card’s PIN as a fixed step, and both showed signs of code written with AI. After the first tap, DevilNFC asks for the PIN and sends it in plain text, together with the name of the bank and the victim’s IP address, to the attackers’ server and to a Telegram bot. Then it shows a fake verification error, so the victim holds the card against the phone for another 10 seconds and the relay gets more time. The company’s conclusion was that local groups have stopped buying these tools from Chinese-speaking sellers and now build their own.

A related method works with card details that were already stolen. ThreatFabric named it Ghost Tap in November 2024. The stolen card is loaded into Apple Pay or Google Pay on one phone, and its NFC signal is relayed to helpers who pay with it in shops. The person running it can sit in a different country. The same researchers explain why a bank has trouble spotting it. The payments appear to come from the same device, a single payment can stay below the amount that triggers a check, and the phone with the stolen card on it can be in airplane mode. In August 2025, Recorded Future reported that Chinese-speaking groups use this for cash machine withdrawals and for buying jewelry and phones, which they sell for cash through Telegram channels. Some of these groups work only within China, Singapore, Malaysia, Thailand and the Philippines, and the researchers wrote that these campaigns can be run on a global scale. In Singapore the method became widely known through high-profile arrests.

Bank helpdesk fraud itself is not new in the Netherlands. In 2025 it hit slightly fewer than 5,900 people and cost €25.8 million, according to the yearly fraud figures of the Dutch banks. A little over 45 percent of that damage to private customers was paid back by the banks as a goodwill gesture. This one group made about 170 victims in three weeks.

On October 15, 2026, the Court of Justice of the European Union ruled on a phishing case from Poland. A bank customer had lost about €700 after entering her login details on a fake copy of her bank’s website. Her bank refused to pay it back, because it said she had been grossly negligent. The court ruled that a bank has to refund an unauthorized payment immediately, at the latest by the end of the business day after it noticed or was told about the payment. The customer has to report it without undue delay. The only exception is when the bank has reasonable grounds to suspect fraud by the customer and reports those grounds to the authorities. A bank that believes the customer was grossly negligent can try to get the money back afterwards.

The police advice:

→ A bank never asks you to download an app, hold your bank card against your phone, or give your PIN
→ When a call does not feel right, hang up and look at the number that called you
→ Do not install apps from a link in a text message or a WhatsApp message
→ In case of doubt, call your bank yourself on the number from its own website
→ After it happened, contact your bank at once to check whether money was taken and to block the account or stop transactions if needed, report it to the police, and keep the messages as evidence

On October 6, the police arrested two men. According to the police, a technician and a coordinator were responsible for the technology and for sending out the fake calls. A 23-year-old from Vaassen is suspected of handling the technical side of the fraud and directing others. A 25-year-old from Ede is suspected of a coordinating role. The police took the group’s servers offline and are going through that data, along with the phones and laptops they seized. On October 20, the court decided that both men stay in custody for another 90 days while they wait for their trial. Neither of them has been convicted, and the police have not said whether AI played any part in building the app.

The Rotterdam investigator also said that pinners are easy to replace.

In Czechia in early 2024, it started with a text message about a tax refund. In the Netherlands in September 2026, it started with an AI voice. The step that got the money out stayed the same: a bank card held against a phone.

In a lab on your own laptop, you can clone a login page and watch what a victim types into it. My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Dutch Police | ESET | Cleafy

By Bulls Eye

Lenovo ThinkPlus Fingerprint USB Drive Sold as Encrypted Was a Plain SD Card Inside

Thu, 29 Oct 2026 13:23:23 +0100

USB encryption from five makers opened without the password. Lenovo, Netac, KakaSoft, Nexcopy, SecZure. A Lenovo USB stick with a fingerprint reader was sold as hardware encrypted with AES-256. Inside sat an ordinary SD card. Nothing on it was encrypted. The fingerprint only switched the USB connection on.

The stick is the ThinkPlus FU100, a small black stick with a fingerprint sensor on top that opens with a finger or a password. It is marketed as hardware encrypted with AES-256, and a sales listing promises fingerprint protection, password protection and anti-leakage. Someone who bought one to carry private files had good reason to believe the fingerprint locked those files.

Xusheng Li develops a reverse engineering tool and its debugger. In 2025 he took an FU100 apart. Under the plastic was a small circuit board with an SD card on it. The data on that card was not encrypted in any way. The fingerprint reader decided one thing: whether the stick connected to the computer or stayed silent. The files on the card did not depend on it. Lenovo later described the flaw in its own advisory as a weakness that lets someone with physical access read the data stored on the drive.

He reported it to Lenovo on August 2, 2025. On August 27 a temporary fix was ready. It was a layer of epoxy over the SD card. A proper fix was planned for December.

The FU100 was the first case in a talk he gave in March 2026 at RE//verse, a conference for reverse engineers. One of his first slides said: do not trust encrypted USB drives, check what the vendor claims yourself.

The second Lenovo device was the ThinkPlus TSD303, an external SSD that also opens with a fingerprint or a password. Inside is a standard M.2 SSD, and here the data is encrypted. The weak point was the password. When the Lenovo program on the computer asked the drive for it, the drive sent the correct password back over the USB cable in plain text. The program then compared it with what the user typed. On his slide, the captured USB packet shows his test password in the last bytes, readable as text. Whoever could watch that traffic, or the memory of that program, could read the password and open the drive with it.

Three months after his report, Lenovo sent him a fix to test. In that version the drive sent an encrypted blob where the plain password used to be, and at first he took it for a hash of the password. He traced it back with the debugger. The blob came from SM4, a block cipher similar to AES, and its key was derived from something that looked like a timestamp. In his test that key was 2021012700000000. He fed the blob and that key into a decryption tool, and his test password came out. The fix was incomplete, because the program could derive the key, and so could someone who took the program apart.

His slide lists ten devices built on the same software kit, with the vendor names blacked out. The TSD303 is one of them, and the slide notes that other vendors using the kit are affected in the same way. Six of those devices sent the password in plain text. Two stored the data unencrypted on a micro SD card. Two sent the password with AES encryption that still gave it away.

The official description of the talk names one more brand among the devices he researched: Lexar, with its F35 Pro fingerprint stick. His slides black out the vendor names, so they do not show which failure belongs to it. The older Lexar F35 already had a CVE in 2022, CVE-2021-46390. The stick compared the password itself, but it sent the result back to the program on the computer, and three South Korean researchers changed that result so a wrong password got through.

The talk also covered the storage company Netac. It offers a program called NetacLockFile for its drives, a software tool that promises to encrypt files with the user’s password. It puts the locked files in container files on the stick, and in his test the program itself sat on the stick next to them.

He locked a PDF with it and opened the result in a hex editor. Part of the file was still readable. He worked out the pattern: of each block of 48 bytes, 16 were encrypted and 32 were left as they were. For his slide he put his own photo through it. The encrypted version is grainy, and his face is still easy to recognize.

Then he went looking for the key. He used time-travel debugging, a method that records a program while it runs so the run can be stepped through forwards and backwards afterwards. He followed the encrypted bytes back to the function that produced them, and from there to the key. The trail ended at constants inside the program file itself. The AES-256 key was a fixed 32-byte value embedded in the executable. The password was checked separately and had no part in the key. A copy of the same program was enough to open a locked file without the password.

He reported the fixed key to the company on October 19, 2025. No response came and no patch, and after more than 90 days he made it public in the talk.

In October 2026 he came back to the same program with OpenAI’s Codex, connected to his reverse engineering tool. He gave it one prompt: this is a file encryption utility, analyze its crypto system and see if it is secure. In about seven minutes it found the fixed key in the executable. The program wrote the user’s password into its diagnostic logs. It checked passwords with MD5. It encrypted blocks of 16 bytes one by one without an initialization vector, so identical input blocks produce identical output. Its SM4 option used another fixed key. In its fast mode, files larger than 1,024 bytes were only partly encrypted, in formats such as PDF, ZIP, PNG, JPEG, WAV and MPEG.

He then pointed the same setup at two products he had never studied. Both are copy protection. A company puts training material or legal documents on such a stick and hands it out, so that the person who gets it can view the files but not copy them.

KakaSoft USB Copy Protection 5.6.0.299 offers three levels. Normal hides and locks the files and does not encrypt them. High scrambles at most the first 16,385 bytes of a file with a key of a single byte, which allows only 256 possible keys, and it leaves the rest as plain data. Highest advertises 256-bit Blowfish encryption. The key for it comes from a salt in each file and an internal password, which the program builds from a seed stored inside itself with a modified version of MD5. The AI emulated that code, recovered the internal password, and decrypted the test file without the user’s password. That took about 26 minutes and six short prompts.

Nexcopy sells Copy Secure drives, and its product page says the protection is enforced in hardware, on the flash memory controller. On the drive he analyzed, Triple-DES protected the files. The key sat in a configuration file, and the viewer program opened that file with a fixed 32-byte certificate built into the app. The password sat in that same file as plain text, and the Mac viewer compared it with what was typed. The password and the check on the USB device only decided whether the official viewer carried on. Neither one went into the key. That took about ten minutes and five prompts.

He also went back to a drive he already knew. In 2024 he had written about YutianDun, a copy-protected USB drive sold by SecZure, in the magazine Paged Out!. It hides encrypted files from Windows Explorer and opens them through its own readers, which claim to block copying, screenshots and printing. A trace showed a login under a hidden account called Buffer, with the password 123456, before the administrator password had even been typed. That account does not appear in the user management screen. Behind that account sat another locked copy of the secret the file key is made from. The password 123456 unlocked it, and he decrypted the files. Further analysis turned up a second built-in account, System, with the fixed password SECZURE.COM. On two tested drives, both accounts opened the files without the administrator password. He calls it a backdoor from a technical perspective, and adds that this does not prove the maker meant harm.

When he published these findings in October 2026, he skipped the usual step of warning the makers first. His reason: a device that is already in an attacker’s hands cannot be recalled or updated easily.

This kind of mistake is old. In December 2009 the German security company SySS cracked a SanDisk USB stick that carried a FIPS 140-2 certificate. The CVE records from January 2010 describe SanDisk Cruzer Enterprise drives and three Kingston DataTraveler models. They validated passwords with a program running on the computer rather than in the drive hardware, and the drives of both brands also used a fixed 256-bit key. Sixteen years later, the sticks above repeat that mistake.

On these devices the password decided whether a program opened or a USB connection switched on. On most of them it had no part in the key that locked the files. When the key is a fixed value in the software, or the data is not encrypted at all, a password protects the program. The files stay open to whoever reads the card or takes the program apart.

Encryption that holds works the other way around. The key is derived from the password itself, through a deliberately slow function such as PBKDF2 or Argon2, so that each guess costs time. Or the check happens inside the drive’s own chip, and neither the password nor the key ever leaves it. Without the password there is nothing to compare and no key to find.

What to do:

→ Encrypt sensitive files yourself before they go on a stick, with software where the key comes from your password, such as VeraCrypt, BitLocker To Go on Windows Pro, or gpg
→ Count a fingerprint reader or a password screen on a stick as a lock on access, unless the maker shows that the key depends on it
→ Assume a copy-protected stick is readable for whoever receives it
→ Check whether your Lenovo model is on the list below

With gpg, one command does it:

1
gpg --symmetric --cipher-algo AES256 contract.pdf

gpg asks for a passphrase and derives the key from it, and the result is contract.pdf.gpg. Without that passphrase, the file stays closed on any machine.

Lenovo published security advisory LEN-210545 on January 13, 2026, rated high, with three CVEs:

→ CVE-2025-13453: some ThinkPlus USB drives let someone with physical access read the stored data
→ CVE-2025-13454: the ThinkPlus configuration software lets a local, logged-in user reach sensitive device information
→ CVE-2025-13455: the configuration software lets a local, logged-in user bypass device authentication and enroll an untrusted fingerprint

Affected models:

→ ThinkPlus FU100
→ ThinkPlus FU200
→ ThinkPlus TU800
→ ThinkPlus TSD303

Lenovo calls its fix a hardware-level solution. Owners call Lenovo’s service line in China, +86 400-640-1886, for a free upgrade. Lenovo checks the serial number, and the device is either sent back for replacement or gets a firmware upgrade on site. Lenovo advises backing up the data first, and wiping or formatting the device before it goes in. The second fix for the TSD303 arrived in December 2025, and in that version the drive checks the password itself. Netac never answered the report, and the talk slides list no patch. Neither Lenovo nor the researcher mentions attacks on owners.

On your own laptop, you can encrypt a file with AES-256 so that the key comes from your own password. My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Lenovo LEN-210545 | RE//verse 2026 slides | Xusheng Li, October 2026 research

By Bulls Eye