Click To Pray, the official prayer app of the Pope’s Worldwide Prayer Network, was found to have zero security by a security researcher. According to BobDaHacker, they discovered in January 2026 that the Vatican-linked app had zero security, allowing anyone to access user data through the API endpoint by simply typing in user IDs. They emailed nine individuals about the vulnerabilities as soon as they discovered them but received no responses and saw no changes for six months.

The information that anyone could get from the Click To Pray app’s database included first and last names, email addresses, and birthdates, among other information. You may not think this is much, but getting names and email addresses is more than enough for bad actors to start sending phishing emails to vulnerable users. BobDaHacker also pointed out that most of the app's users are likely older people who aren’t tech-savvy, so any enterprising scammer could tap into the app for a literal treasure trove of email addresses.

It was also easy to get the complete list automatically. The user ID assigned to new accounts is sequential, and since there’s no rate limiting for the API, all it takes is one GET request per user to capture all that information. Aside from this, the validation_hash used to verify the validity of an account signup is also stored in the clear, meaning anyone with access to the API can verify an account by opening their inbox. The email also had security issues that make it look like a phishing email, even if it’s legitimate.

You may think that a prayer app shouldn’t be much of a target for cybercriminals, especially as this has a small install base compared to the 16 billion accounts exposed in one of the largest data breaches in history. But the fact that it had almost 720,000 accounts as of July 2026 meant that there’s a lot of possible targets within that database. Even if just 1% of these users respond to an enterprising cybercriminal who harvested their email addresses from the app, that’s more than 7,000 different individuals who could lose money because of this leak.

BobDaHacker waited for six months for a response, but, unfortunately, no one related to the app responded to their concerns. Because of this, they contacted Nate Neslon, a security journalist for Dark Reading (who similarly received crickets after contacting them), who published a story about it. It was only after the news went live that the app’s security lapses were fixed, even if BobDaHacker wasn’t, at the very least, acknowledged by the makers of the app. Hopefully, no other hackers were aware of the weaknesses of the Click To Pray app.

Federal agents arrested 21-year-old Zyaire Dontaevious Zamarion Wilkins of North Lauderdale, Florida, on Tuesday and charged him with conspiracy to obtain information by computer for private financial gain, according to a 15-page criminal complaint first reported by WPLG Local 10. The FBI alleges Wilkins helped run an operation that embedded malware in eight video games, infected around 8,000 devices, and stole at least $220,000 from roughly 80 cryptocurrency wallets between May 2024 and February 2026. Investigators put a name to the scheme by following stolen Bitcoin to more than 150 gift cards, most of them spent on Uber Eats.

The complaint identifies the distribution channel only as a "popular digital distribution software company," but the games it lists, including BlockBlasters, Dashverse, Lunara, and PirateFi, match the titles named when the FBI began seeking victims of infected Steam games in March. The case is being prosecuted in Seattle federal court, near Valve's headquarters in Bellevue, Washington, and Wilkins' arrest is the first publicly reported in the investigation.

Wilkins allegedly financed and marketed the malware rather than writing it, with Local 10 reporting that agents had already searched the home of the unidentified developer who built the programs, and that Signal chats seized there tied Wilkins, operating under the handle Sibel.eth, to a $10,000 purchase of a remote access trojan and to discussions about tricking victims into approving transactions that emptied their wallets. That developer isn't named in the complaint and doesn't appear to have been charged.

The conspirators promoted the games on Discord, Telegram, X, and LinkedIn, and used bots to find users with large cryptocurrency holdings and message them directly, according to the complaint. Roughly 80 wallets were drained from 8,000 infections, a hit rate of about 1% consistent with that targeted approach. ZachXBT and vx-underground estimated BlockBlasters alone took more than $150,000 from between 261 and 478 victims, including $32,000 in donated cancer treatment funds taken from a Twitch streamer in September 2025.

Payments from the scheme's Bitcoin wallet went to Bitrefill, a gift card service, where the 150-plus cards were purchased, agents said. A subpoena to Uber matched the cards to an account with deliveries at Wilkins' family home and his addresses at the University of West Florida. When agents searched the North Lauderdale house a week before the arrest, they seized several devices and three cryptocurrency wallet seed phrases, one belonging to a Monero wallet. Wilkins' transaction history showed $382,000 in cryptocurrency sent or received, per the complaint.

Wilkins faces up to 10 years in prison if convicted and was scheduled to appear in Fort Lauderdale federal court on July 15. Valve, whose storefront has seen a steady run of malware incidents over the past two years, including the Chemia Early Access game that shipped with three malware strains, hadn't responded to Local 10's request for comment as of publication.

A security researcher has published a method for lifting the client certificate off a Shark robot vacuum and using it to run root commands on other Shark vacuums across the same Amazon Web Services region, exposing live camera feeds, stored home maps, and Wi-Fi credentials held in plaintext. The researcher, who publishes under the handle tokay0, published the technique on Monday and says he first reported it to SharkNinja on March 1. As of the time of writing, the flaw is still unpatched, requiring a fix that sits entirely on SharkNinja's side of the cloud rather than on the robot.

The problem is an over-permissive AWS IoT policy. The certificate that a Shark vacuum uses to authenticate to Amazon's cloud broker was never restricted to the device carrying it, so a certificate pulled from one unit can subscribe to fleet-wide traffic and publish commands addressed to any device the broker serves. Those commands travel in an ordinary field called Exec_Command inside the per-device state document AWS keeps in the cloud, and a management daemon on the vacuum passes anything under 1,000 bytes from it to a shell.

The researcher tested the technique only on units he bought himself, including a cross-model reverse shell on an AV1102ARUS Shark IQ Robot Vacuum XL, which he then used to pull a live feed off that robot's onboard camera. Watching a single AWS region for 24 hours, he counted 1,517,605 unique Shark serial numbers, of which 673,816, or 44%, replied to a command probe. Those are devices observed responding, not devices he tested or compromised. Certificates are pinned to their AWS region, so a key lifted in one region only reaches devices in that region.

tokay0 says SharkNinja acknowledged his report on March 12, told him on April 27 that it was under review, and on July 3 promised a completion date by July 10 that never arrived. He also says the company downplayed the severity and questioned whether a CVE was warranted, despite a published disclosure policy that commits SharkNinja to "provide regular updates until the reported vulnerability is resolved." The company had posted nothing on the flaw as of July 16.

Remediation in this scenario doesn’t require a firmware update. Per Amazon, a non-compliant IoT policy is fixed by pushing a scoped version inside the operator's own AWS account until SharkNinja rescopes the policy or reissues the certificates.

SharkNinja's timeline is pretty similar to a vulnerability we saw with DJI Romo vacuums back in February, whereby an authorization flaw exposed roughly 6,700 vacuums, handing out camera feeds, audio, and floor plans; DJI patched it within weeks, and the researcher who found it later collected a $30,000 bounty. Cloud-side failures, where a backend fails to scope device access, have driven a run of robot-vacuum breaches and fueled interest in fully offline designs that keep mapping and camera data off any vendor cloud.

Supply-chain security firm Socket has published research findings describing a Go module that posed as a DNS and subdomain scanner while acting as a first-stage Windows malware loader. The firm then traced it to a network of 222 GitHub repositories across 190 accounts. The module published its first version on January 24 this year and has since accumulated more than 1,200 versions, over 700 of them malicious. Socket tracks the campaign as “Operation Muck and Load” and reported the module to the Go security team, which blocked it from the Go module proxy.

Go derives a pseudo-version from the commit timestamp and hash for any commit that lacks a semantic version tag. Socket attributes the sprawl to the threat actor's own GitHub Actions workflow, saying its timed commits could each be resolved as a version, inflating a scanner utility's release history into the hundreds.

Across the confirmed repositories, Socket found the same workflow: it sets the Git email to ischhfd83@rambler.ru, sets the visible commit username to the current repository owner, and then force-pushes a rewritten log file every minute. That split generated owner-attributed activity across disposable accounts while leaving one reusable fingerprint. Socket counted a repository only when both the email and the workflow appeared together, resulting in 222 repositories as the confirmed minimum.

The module's main.go launches a hidden PowerShell command that downloads content from muckcoding.com, decodes it with certutil, and runs the result with execution-policy bypass. Socket describes the decoded script as a multi-layer loader using Base64 encoding and XOR decryption, with a Turkish-language comment in one layer that translates to "run directly, no other step is needed."

Rather than hardcoding a payload URL, the resolver retrieves text from public platforms, searches it for the marker string "LastW," then decrypts the trailing blob with a hardcoded key to recover the actual download location. Primary dead drops include Pastebin and a paste service called Rlim, with fallbacks across YouTube, Instagram, Telegram, Google Docs, and GitCode. If defenders remove one paste or block the final archive URL, the actor can update the resolver content without touching the first-stage loader.

The resolved URL points to a password-protected 7-Zip archive hosted as a GitHub release asset. The loader extracts it into a directory named to resemble a legitimate Microsoft Photos install and launches Microsoft.exe from that path with a hidden window. Decoded payload stages map to AsyncRAT, Quasar, and Remcos-style RAT detections alongside infostealer behavior.

Socket confirmed at least 14 unique malware files across the analyzed set, including Trojan loaders and downloaders, Vidar infostealer, dropper and spyware payloads, and XMRig-related Monero cryptominers. One Loader.exe appeared byte-identically across four separate repositories.

Lure themes span MetaMask and Trust Wallet integrations, seed-phrase utilities, Binance and PayPal automation, Telegram and Discord bots, and game cheats for PUBG, Valorant, and Escape from Tarkov. One PUBG repository, nrevv1lad/Pubg-DESYNC-Menu, presented itself as an external cheat with an installation guide while hosting a Vidar-linked Loader.exe in its source tree.

Socket assesses with high confidence that Operation Muck and Load belongs to the same cluster that Sophos documented in June last year. Sophos researchers Matt Wixey and Andrew O'Donnell traced 141 GitHub repositories, 133 of them backdoored, to the same ischhfd83@rambler.ru address. Sophos also identified "Muck" as one of the actor's aliases, a label now embedded in the muckcoding.com and muckdeveloper.com domains.

Neither GitHub nor the Go team has commented beyond the proxy block.

The Chat Control 1.0 law that enables warrantless mass scanning of digital communications has been voted against multiple times by the EU Parliament. And yet, just like a movie zombie, it keeps getting resurrected by various legal sleight-of-hand moves. Yesterday, one of those tricks worked, as Chat Control 1.0 passed (or rather, was not rejected) in a forced re-vote that required an absolute majority (50% + 1) for active refusal. This brings back the law until 2028, and sets a different stage for September's upcoming discussion on Chat Control 2.0.

After the impending publication in the EU Official Journal, online direct-communication platforms will be allowed to mass-scan their users' data without the need for a warrant, under the guise of looking for child sexual abuse material (CSAM).

The scanning is not mandatory, but big tech firms will have a legal mechanism to rifle through user data. EU firms have historically refrained from doing so, presenting privacy and data sovereignty as selling points, but the legal door is nevertheless now officially open.

The obvious platforms where monitoring can now take place will be e-mail and chat services. Immediate examples include Gmail, iCloud, Hotmail, Discord, Instagram, Slack, Teams, Snapchat, Xbox, and Google Chat.

Although the law's scope is for "interpersonal communications services," the legal mechanism might hypothetically extend to some gray areas like Google Drive, where sending someone a link to a cloud file could be within the scope of the law.

It's worth noting that "direct communication" isn't restricted to one-to-one chats, as it includes group chats; just not public or undirected communications. Additionally, EU law enforcement is still beholden to the same warrant requirement as before — Chat Control 1.0 does not grant a blank pass to authorities to mass-scan user data, or request companies to do so without a targeted warrant.

Thanks to two amendments in yesterday's vote, end-to-end-encrypted (E2EE) communications means (ex: WhatsApp) stay exempt. That means that for now, Chat Control 1.0 isn't a commandment to break encryption, something that has been regularly suggested by lawmakers around the world.

It's as good a time as any to remind people that Instagram messages are no longer E2EE as of May, and that although WhatsApp's messages are encrypted, the service leaks out every single bit of metadata about them — sender, recipient, time, size, etc. As always, Signal is recommended as a privacy-focused communications app.

This latest development in the EU parliament is eliciting widespread public outcry due to the nature of the law itself, but also due to the manner in which it happened. Critics and opponents of the rule are suggesting this move is unprecedented.

Chat Control 1.0 has already been shot down repeatedly, most recently in March. However, European Parliament President Roberta Metsola forced a second reading of the law, and invoked Rule 163's "urgent procedure" mechanism. This had many effects, including bringing up a law that was voted against for discussion yet again; turning the decision into a denial vote (vote-to-deny, not vote-to-pass); exploiting the second-reading requirement that demands an absolute majority vote (50% + 1); and letting the President herself set the schedule. Metsola scheduled the second reading to the very last day before the European Parliament summer recess.

The result was that out of 720 representatives, only 607 actually cast a vote. Of those, 315 (over half) voted against Chat Control 1.0. That figure did not meet the supermajority threshold of 361, which was calculated against a full chamber.

Opponents to Chat Control have posted resources at the Fight Chat Control website, including a breakdown of member-state and individual representative voting positions and contact information.

Ever since the advent of agentic AI, security researchers have been yelling from the top of their lungs about how it's a bad idea to grant user-level permissions to an LLM — for all purposes, a program with non-deterministic outputs and inconsistent handling of inputs. A research paper on HalluSquatting from researchers at Tel Aviv University, Technion, and Intuit, shows how easily one can fool modern AI bots and harness them into a massive army of AI agents, with the research showing that agents can hallucinate potentially malicious code repositories up to 85% of the time.

The mechanism for HalluSquatting (aka "adversarial hallucination squatting") is surprisingly simple, and takes advantage of the fact that when met with unfamiliar terms, bots will not know they're incorrect and hallucinate a "correct" answer. Adding to that, the methods the bots use to come up with said answer are predictable, for example, owner/repository or toolname/toolname GitHub URLs. This is different than just standard typo-squatting, as it exploits the hallucination mechanism itself.

An attacker first identifies an application, code repository, programming library, or bot skill that's gained popularity only in recent months or years — let's say, a new GitHub repo with the URL OriginalOwner/WindowsTelemetryOff. As the bots' training data is not recent enough to contain information about it, GitHub URLs owner/repo combinations SuperHacker/WindowsTelemetryOff , and WindowsTelemetryOff/WindowsTelemetryOff look just as peachy. Likewise, WindowsTelemetryOf and WindowTelemetryOff (note the typos) will be valid candidates.

The attacker then creates a malicious repository using those generated names. When Claude or another code agent is asked to "run the windowstelemetryoff scripts" or a similar instruction, chances are they'll hallucinate the repo name (sometimes even having run a web search), run into the malicious version that looks like the original, and happily run whatever's in there.

From that point, all bets are off now that the attacker's code is running on the user's machine. The most obvious outcome could be creating a reverse shell (the user's machine opens a command line that's controlled remotely). Now having access to the user's account, the attacker can siphon off their data and passwords, install software, run crypto miners, or harness their AI agent for further malfeasance, all with the power of entire data centers at their disposal.

And here's the kicker: just the one HalluSquatted piece of software has the potential to bait and reel in tens of thousands of bots, if not more, in a proverbial blink of an eye. A crafty attacker would be kind enough to include all the original code in their poisoned version, adding yet another layer of unawareness to the mix.

The research team found that an LLM will hallucinate the location of a recent code repository up to 85% of the time, a figure that can reach 100% for trending agentic skills. Every single model is widely affected, up to and including Anthropic's mighty Claude Opus 4.5. At the application level, the figures are better, but still pretty bad.

The scientists are working on common LLM-backed programming applications, including Cursor, Windsurf, and OpenClaw, among others. In this scenario, the bots stand a better chance given they're working with more context information, but even still, the success rates for hacking ranged from 20%-35% for Cursor, Gemini CLI, and Copilot, and increased massively to close to 80-100% on OpenClaw and its variants. The exploit mechanism doesn't even need to be crafted specifically for any bot; the researchers' results show it's universal and transferable, too.

The mean hallucination rate for names of sample GitHub repositories published in 2025 is 92.4%, while predictably, bots get the URLs wrong 0.9% for those from 2019 or earlier, though that's arguably still a concerning figure. The most effective mitigation is adjusting workflow: instructing bots to always run web searches before installing software, and providing them with additional context. Unfortunately, that's not the default way most people appear to use them.

Cybersecurity professionals have long advocated for not blindly trusting a bot's actions and severely restricting the access level granted to AI agents. And yet it's not uncommon to see bots with wide-ranging permissions over users' machines, API keys, access keys, and service accounts, to name a few — all in a bid to make it "easier" for the bot to vibe-code their pointy-haired-boss' latest brilliant idea.

The CERT Coordination Center (CERT/CC), a U.S. government-backed cybersecurity group at Carnegie Mellon University's Software Engineering Institute, disclosed a firmware flaw on July 6 that can hand attackers full administrative control over several Tenda networking devices. The vulnerability, tracked as CVE-2026-11405, is an undocumented authentication backdoor in the affected models' firmware that bypasses the normal login process and grants access to the devices' web management interface without valid credentials. Compounding the risk, there is currently no security patch available, as Tenda — a Shenzhen-based budget networking brand with a large presence in India and other markets — is yet to respond despite CERT/CC reaching out on the issue.

CERT/CC lists five affected firmware versions spanning the FH1201, W15E, AC10, AC5, and AC6 router families. The advisory, which credits an anonymous researcher for the finding, does not describe this list as exhaustive. The list covers only the specific builds the researcher reported to CERT/CC, as there is no vendor-confirmed scope. According to the advisory, the flaw resides inside the routers' built-in web server, where an undocumented authentication routine allows administrative access without requiring the configured administrator credentials.

Like most consumer routers, Tenda devices provide a password-protected web management interface for configuring Wi-Fi settings, firewall rules, DNS servers, firmware updates, port forwarding, parental controls, and other core networking features. Because these interfaces control most aspects of a router's operation, they are typically protected by authentication mechanisms designed to prevent unauthorized users from making changes that could compromise an entire home or business network.

According to the advisory, the affected firmware initially performs authentication as expected, verifying the administrator password with a standard MD5-based check. However, when that verification fails, the login routine quietly follows a second, undocumented code path. Instead of immediately rejecting the login attempt, the firmware retrieves another password stored internally under the configuration key sys.rzadmin.password and compares it directly against the user-supplied password using the standard C library function strcmp().

If the supplied password matches this hidden value, the firmware immediately creates a valid administrator session with full privileges. Even more concerning, the associated username is never validated, meaning any username can be used as long as the hidden password is supplied. As a result, the mechanism effectively bypasses the router's configured administrator account altogether.

While CERT/CC did not disclose the hidden password itself, the existence of an undocumented secondary authentication path significantly weakens the security model of affected devices. Unlike conventional authentication vulnerabilities that stem from implementation errors, this is a separate login path rather than a flaw in the existing one, granting administrative access through credentials that are neither documented nor exposed through the router's management interface. Whether that path was placed there deliberately or left in as a forgotten development feature is unclear. CERT/CC draws no conclusion on intent, and Tenda's silence settles nothing.

Successful exploitation grants an attacker unrestricted control over the router's configuration. With administrator access, an attacker could modify network settings, change DNS servers to redirect internet traffic, disable security protections, replace administrator credentials, or enable additional remote access features. As routers serve as the gateway between local devices and the internet, compromising one can expose every connected system on the network to further attacks.

Pending official Tenda firmware updates, CERT/CC recommends disabling remote web management wherever possible to prevent attackers from reaching the administrative interface over the internet. The organization also advises limiting local network exposure, noting that while changing a router's default LAN IP address may reduce opportunistic discovery by automated scanning tools, it does not protect against determined attackers performing targeted network reconnaissance.

The disclosure echoes the concerns the Federal Communications Commission (FCC) cited when it added certain foreign-made networking products to its Covered List in March, preventing new models from receiving the authorization required for import and sale in the U.S. The FCC argued that compromised consumer routers can provide attackers with a foothold into home and small-business networks. An undocumented administrator backdoor in widely sold networking equipment — combined with the absence of a vendor patch or response — illustrates the type of supply-chain security risk regulators seek to address.

The Internet is buzzing over news that 19-year-old Estonian "hacker" Peter Stokes got nabbed by the authorities and extradited to the U.S. on digital crime charges, mostly thanks to Microsoft Windows' built-in telemetry. The FBI seemingly subpoenaed Microsoft, which coughed up telemetry logs that contained both Stokes' GDID (Global Device Identifier) and websites he visited using his main Windows machine.

The existence of GDID isn't new by itself, as Windows telemetry's data collection has been extensively analyzed and reported on. It's also been known, and publicly explained by Microsoft, that the extended telemetry modes (Full/Optional instead of Required/Basic) can upload lists of URLs analyzed by SmartScreen and Defender, together with the GDID. In fact, using the Edge browser in this setup can even send every visited URL. The court documents do not reveal which exact mechanism triggered the telemetry upload, though.

This data collection has long been the source of heated debate and general public disgust. Even though the data is genuinely useful and necessary for debugging (by Microsoft or systems administrators in enterprise environments), the fact that it comes enabled by default in Windows Home and Professional editions is questionable. The fact that those versions don't have a simple, user-facing "Off" switch to fully disable telemetry also adds insult to injury.

The Peter Stokes arrest appears to be the first public case where these Windows GDIDs were both used as a tracking identifier and contained telemetry data including some of the URLs the defendant visited. The case also prompted a renewed analysis of the GDID by a security researcher that you might want to look into. From what we can ascertain, it's likely Stokes had his Windows telemetry set to Optional/Full, as Required/Basic doesn't appear to transmit URLs by default.

Using the telemetry GDID, the FBI easily connected the dashing rogue to his ngrokaccount, because he used that tool in the same session in which he accessed his Facebook and Snapchat accounts. The agents also established a link between travel records, a New York IP address, and a rental at the Empire Hotel, likely facilitated by the photos Stokes posted of his hotel room. The criminal mastermind was equally sneaky (read: not) in his visit to Thailand.

As many hackers do, he enjoyed some time off playing an obscure game, in this case Ubisoft's Growtopia, shortly before accessing his Apple logins, as well as the aforementioned Facebook and Snapchat logins over the following weeks. Besides Microsoft, Google and Apple also collaborated on the hunting effort, with Google linking Stokes' phishing phone number to the same exact IP address and date where he created the ngrok account. Ever the stealthy craftsman, Stokes had created the ngrok account using the same GMail address connected to a second phone number where he made phishing calls from.

While it's easy and arguably quite necessary to hoist pitchforks at Microsoft for collecting detailed information about billions of computers by default, security professionals will be quick to remind users that Windows' telemetry is merely one of the many ways to track a user. Even if not by malice, a lot of software simply requires GDID-like identifiers for things like tracking usage, subscription and licensing limitations, activation requests, and hardware detection. And every company behind such software can be subpoenaed by authorities, as exemplified in Stokes' case by Microsoft, Google, Apple, ngrok, and others. Even privacy-oriented services like Proton are careful enough to describe what they can and cannot reveal to authorities under a court order.

If you're wondering the steps Stokes took to cover his tracks, though, you'd be looking at a small list. He did route his connections through a VPN hosted at servers from Tzulo along with the developer-oriented ngrok tunneling service and teleport.sh. Unfortunately, the modern digital world allows for many forms of identification, and hiding one's source IP address is merely one of them.

Using a VPN is recommended for digital anonymity, but it's merely the first of many necessary steps and can even backfire when not set up carefully. If misconfigured, a VPN may allow certain applications and operating system features to talk to the outside world using the original IP instead of the hidden one. Plus, the VPN will not stop the operating system or any application from sending out identifying information to begin with.

Perhaps more worryingly still, modern-day device and user fingerprinting is far more insidious and hard to counter. For example, plain web browsers are notorious leakers of personal information, as data-harvesting companies can weaponize features like TLS levels, HTML5 Canvas functionality, the fonts list, and even Widevine DRM in a combination that uniquely identifies a visitor. Stokes now has plenty of time to read up on the EFF's surveillance self-defense guides and get acquainted with the scripts at the Privacy Is Sexy website.

If you read or watch any privacy tutorial on the internet, one of the first tips will be to start using anonymized email addresses in some form — providing a fake email that redirects to your real one. Many email providers offer this functionality, and so does Apple's basic paid iCloud plan with the Hide My Email feature. But apparently Apple's implementation of the feature is trivial to crack — which means anyone can find your real email address with little effort, according to 404 Media.

The privacy vulnerability has been known to Apple for just over a year, and was first reported by Tyler Murphy, co-founder of data removal company EasyOptOuts. The folks at 404 Media claim they tested the vulnerability themselves and that, sure enough, it takes minimal effort to figure out the real address behind the fake alias — with a 100% success rate.

Apple doesn't seem to be bothered by the issue, given that Murphy revealed the problem in June 2025, and the company only executed a fix in March 2026. Post-fix, however, Murphy verified the issue remained (and apparently the last time he heard back from Apple back was in May, when the company said said it was still investigating). There are no further updates, it seems, and this is poor optics for a company that talks a big game about user data privacy.

Neither the researcher nor 404 media divulged the exact mechanism, despite the one-year timeframe being well past the common 90-day security vulnerability disclosure window. This is likely to avoid putting a lot of users at risk of exposure, considering that Apple has passed one billion paid subscribers. Even if only 1% of users use Hide My Email, that still accounts for 10 million people.

Given the lack of technical details, it's hard to pin down where the problem could lie. Accidental revelations of aliased emails have happened several times, by the hand of client software trying to be helpful and "fixing" the reply path, and by servers mismanaging email headers.

Perhaps adding insult to injury, Apple recently stated that it's going to move Hide My Email addresses to their own domain, "private.icloud.com", making it easy for websites to reject such addresses in a bid to always have users' real contact info. Murphy suggested that the company stop sales of the Hide My Email feature until the data leak matter is resolved, but, again, there's been no response.

Late spring and early summer in the cybersecurity world were marked by multiple Windows exploits, thanks to the efforts of the controversial hacker figure Nightmare Eclipse. One of the better-known exploits is BlueHammer, a race condition in Windows Defender that gets you a shell with access to the SYSTEM user with just a small script — in other words, the keys to the kingdom in exchange for a double-click. Microsoft released a patch on April 14, but as a clear illustration of the lack of cybersecurity awareness, CISA (the U.S. cyber-defense agency) yesterday marked BlueHammer as actively exploited in ransomware campaigns.

That marks about a month and a half since the patch, and it illustrates quite clearly that when it comes to computer security, the publication of a patch is almost always the easy part; getting that patch into every device that needs it is the real tricky bit. The patch is part of standard Windows updates, too, so there's really no technical reason for not installing it. Additionally, since BlueHammer gets the attackers a SYSTEM shell, the ransomware in question may encrypt parts of the OS or the boot process rather than "just" the data files, potentially making machines unusable on top.

While stating that "people don't patch their machines" is a broad statement that won't surprise anyone in the field, a recent report from security vendor Absolute claims the application of critical OS patches across Windows 11 and 10 lags 127 days (over 4 months) on average, and that figure basically doubled since last year. Even in enterprise settings, Absolute says the average time-to-patch is shockingly high at 76 days, or 2.5 months. While one vendor's claims aren't gospel, the figures aren't too hard to believe; plus, they're averages, meaning half the machines purportedly go unpatched for longer than those timeframes.

Depending on the source, estimates on the percentage of Windows 10 machines can vary between 15% (PassMark) and 26% (StatCounter). Calling it 20% for simplicity's sake, that's 1 out of 5 machines almost guaranteed to be unpatched. Techies like us know full well that Microsoft has extended security updates (ESU) for Windows 10 twice now, with the new real EOL now being October 14, 2027. The problem is, although enrolling a machine into ESU is trivial, the lack of public awareness essentially guarantees these machines will remain vulnerable until they're upgraded or replaced.

Meanwhile, Nightmare Eclipse says they're "done with taking a break", and that "July will be an incredibly interesting month because [they] will drop some really interesting and possibly insanely controversial findings."

"Think out of the box" is painted onto millions of motivation posters across the world, a shooting message for middle managers and eliciting eyerolls from most everyone else. And yet that's exactly what the researchers at Mozilla's 0din did, by tricking Claude into running malware in a roundabout yet deceptively simple way, by merely asking it to initialize a project from a pretty clean-looking GitHub repository.

An attacker would then have control over the developer's own account, accessing all their secrets, API keys, code, documents, browser sessions, and passwords. They could even install additional malware to maintain permanent access. Suffice to say, almost every bot agent is susceptible to this type of attack, though Claude is the default choice for programming tasks.

Here's how it works. All a victim developer has to do is tell Claude to initialize a project from a malicious GitHub repository (or tell it to configure it after cloning it themselves). Said repo looks pretty clean, with just a handful of scaffolding files, and most importantly, nothing that will trigger security tools, whether remote, local, or even Claude's own checks.

Claude will clone the repo. The first file it will process will be a "readme" or Markdown file describing how to initialize a Python environment with the Axiom package, a commonly used monitoring tool. So far, this appears completely legitimate. However, there's a fake Axiom startup script that will simply error out the first time it's run. This is the first step that tricks the box, because in order to be helpful and solve the problem, it'll run another innocuous-looking command to initialize Axiom: "python3 -m axiom init".

This then triggers a shell script that downloads a bit of software to run, another standard operation that won't raise an eyebrow. But the second trick is that instead of downloading from a malicious URL that could be scanned, the script reads the DNS text records of a specific domain — in this case, the domain "_axiom-config.m100.cloud". This too looks kosher enough, as for example, e-mail and by extension its configuration tools extensively rely on TXT records.

The said TXT record contains an encoded (base64) string that just opens a reverse shell, meaning it'll open a shell on the user's machine, but redirected to the attacker's server for input. At this point, the malfeasants can fish out everything that the user has access to and proceed to run software as the user. Meanwhile, all that Claude and the victim see is an "Environment ready" message or similar.

If you've been counting, this is three steps of indirection, none of which in isolation look like anything much out of the ordinary. Very few (if any) security scanning tools would even flag the repository, and none of the activity, save for the actual opening of a remote shell, even looks particularly odd. An enterprise environment with very tightly controlled network access could catch it, but that's not where the vast majority of developers operate in. It's also worth stressing that this particular implementation is just one example of a concept that can be applied to even more indirect and elaborate methods.

The 0din team concludes its report by stating the reasonably obvious: that developers should never blindly trust an unknown project as trusted code, and naturally, not trust the AI tool itself for security analysis purposes. As for the agents themselves, 0din states they need to inspect what actually will run and how, instead of simply following steps.