For a hobby project built in my spare time to provide a simple community service, Have I Been Pwned sure has, well, "escalated". Today, we support hundreds of thousands of website visitors each day, tens of millions of API queries, and hundreds of millions of password searches. We're processing billions of compromised records each year provided by breached companies, white hat researchers, hackers and law enforcement agencies. And it's used by every conceivable demographic: infosec pros, "mums and dads", customer support services, and, according to the data, more than half the Fortune 500 who are actively monitoring the exposure of their domains. So yeah, "escalated" seems fair!

Amidst all the time spent processing data, we've been trying to figure out where to invest energy in building new stuff. In essence, data breaches are pretty simple: you've got a bunch of exposed email addresses attributed to a source, sitting next to a whole bunch of fields we describe with metadata. Our goal has always been to help people use this data to do good after bad things happen, and today we're launching a bunch of new features to do just that. So, here goes:

New Features, New Plans

In the beginning (ok, in "recent years"), there was one plan we referred to as "Pwned", and within that, there were various levels. For example, the entry-level plan has been "Pwned 1," and to this day, more than half our subscriptions are on it. That's "a coffee a month" for a simple service that, by the raw numbers, does precisely what most of our subscribers are looking for. These are typically small businesses that make a handful of API queries or monitor a domain or two with a few email addresses. It's simple, effective and... insufficient for larger organisations. So, we added Pwned 2, 3 and 4, and they all added more RPMs for email searches and more capacity for searching larger domains. Then we added Pwned 5, which added stealer log support, and somewhere along the way also added Pwned Ultra tiers for making large numbers of API requests. As a result, that one "plan" added more and more stuff at different levels and ultimately became a bit kludgy.

Today, we're launching a bunch of new features to better support the volume and privacy needs of our subscribers, and we're shuffling our existing plans to help do this. Here's what they now look like:

1. Core: The fundamentals, largely being what we already had and designed for entry-level use cases
2. Pro: Contains a bunch of the new features designed for larger orgs and those searching domains on behalf of customers
3. High RPM: The old "Ultra" plan levels, designed solely for making large volumes of requests to the email search API
4. Enterprise: We've had this for many years now, and it's a more tailored offering

So, that's the high-level overview. Let's now look at all the new stuff and everything that changes:

Supporting MSPs Monitoring on Behalf of Third Parties

For most people, this won't sound particularly exciting, but I'm putting it up front because I'll refer to it when describing the more important stuff shortly. In the past, we've had the following carve-out in our terms of use, namely, what you're not permitted to use the service for:

the benefit of a third party (including for use by a related entity or for the purpose of reselling or otherwise making the Services available to any third party for commercial benefit)

This excluded managed service providers from, for example, monitoring their customers' domains as part of their services. That clause has now been revised with the preceding text:

unless you have purchased a Paid Service which expressly allows you to do so

Which means we can now welcome MSPs to the Pro and High RPM tiers. They can't just take HIBP and use it to create a competing product (for obvious reasons, that's a pretty standard clause within many online services), but they can absolutely add it to the offerings they provide to their own customers. And we're adding new features to make it easier to do just that, for example:

Automating Domain Verification

Preserving privacy whilst still providing a practical, effective service has always been a balancing act, one I think we've gotten pretty spot on. But the hoops people have had to jump through for domain verification, in particular, have been cumbersome. An organisation wanting to add a bunch of its domains has had to go through the process one by one via the web interface, then verify control over them one by one. They'd spend a lot of time doing kludgy, repetitive work. Today, we're launching two new ways of adding domains in a much more automated fashion, and the first is the verifying via DNS API:

Successfully adding a pre-defined TXT record to DNS is solid proof that whoever is attempting to search that domain genuinely controls it. As well as the old kludgy way of doing it in the browser, waiting for DNS to propagate, then coming back to the browser to complete the verification, we can now fully automate the process via API. Here's how it works:

1. Call the HIBP API to generate the TXT record token
2. Call the API on your DNS provider to add the token to the TXT record
3. Call another HIBP API to validate that the token exists

This is easily scripted in your language of choice, and you can enumerate it over as many domains as you like. You can also keep retrying step 3 above as often as needed when DNS takes a little while to do its thing. It's all now fully documented in the latest version of the API, and ready to roll. But what if you don't control the DNS? Perhaps it's a cumbersome process in your org, or you're an MSP monitoring your customers' domains, but you don't have control of DNS. That's where the verifying by email API comes in:

We've long had a verification process that involves choosing one of several standard aliases on a domain to email a verification token to. You do this via the dashboard, grab the token sent to the email, paste it back into the dashboard and the domain is now verified. The new API makes that much easier, especially when multiple domains are being verified. Here's how it works:

1. Call the HIBP API and specify one of the pre-defined aliases to send a verification email to
2. Click the link in the email and approve the domain to be added to the requester's account

And that's it. We see this being particularly useful for MSPs who can now send a heap of emails on their customers' domains, and so long as someone receives it and clicks the link, that's the verification process done. That API is also now fully documented and ready to roll and is accessible to all Pro plan subscribers.

Auto-verifying Subdomains

This one was just unnecessarily frustrating for larger customers who spread email addresses over multiple subdomains. Let's say a company owns example.com and they successfully verify control of it, but then they distribute their email addresses by region. They end up with addresses @apac.example.com and @emea.example.com and so on, and in the past, needed to verify each subdomain separately.

Turns out we have 154 votes for this feature in User Voice, which is substantially more than I expected. So, in keeping with the theme of the Pro plan making it easier on larger orgs, anyone on that level can now add their apex domain, verify it accordingly, then go to town adding all the subdomains they want without the need for verifying each one.

Bringing K-Anonymity Searches to the Masses

Until today, every time you took out a subscription via the public website and started searching email addresses, it looked like this:

GET https://haveibeenpwned.com/api/v3/breachedaccount/test@example.com

Clearly, this involved sending the email address to HIBP's service. Whilst we don't store those addresses, if you're sending data to a service in this fashion, there's always the technical capability for us to see that piece of PII and associate it back to the requester via their API key. This approach is what we'll refer to as "direct email search". Let's now look at k-anonymity searches, and I'll break it down into a few simple steps:

1. Start by creating a SHA-1 hash of the address to be searched, so for test@example.com, that's:

   567159D622FFBB50B11B0EFD307BE358624A26EE

2. Take the first 6 characters of the hash and pass them to the new API:

   GET https://haveibeenpwned.com/api/v3/breachedaccount/range/567159

   What's really important here is that those 6 characters are the only identifier sent to HIBP and they're completely useless in identifying which address was actually searched for (that link also explains why SHA-1 is perfectly reasonable for this)
3. HIBP then responds with the suffixes of every hash we have that matches that prefix and for each one, the breaches it's appeared against:

   {
     "hashSuffix": "D622FFBB50B11B0EFD307BE358624A26EE",
     "websites": [
         "Adobe",
         "Stratfor",
         "Yahoo",
         ...
     ]
   },
   ...

   The prefix presently contains 393 suffixes, and if one of them matches the remaining characters of the hash of the full email address, you know that's the address you're looking for.

This is the same methodology we've been using for years with the Pwned Passwords search, and we're currently serving about 18 billion requests a month, so it seems that lots of people have easily gotten to grips with it. It's a pretty simple technical concept with great privacy attributes, and it's fully documented on the API page.

K-anonymity searches are now available to all Pro and High RPM subscribers at the same rate limit as the direct searches. That rate limit is shared, so you can either make 100% of them to k-anon or 100% to the direct search or go 50/50. We're really happy with the privacy aspects of this API and we know it ticks a box a lot of orgs have been asking for.

Unsmoothing the API Rate Limit

Previously, when you took out a 10-request-per-minute API key, we implemented a rate limit of 1 request every 6 seconds. The same logic applied to all the higher-tier products, too, and the reason was simply to distribute the load across each minute more evenly or in other words, "smoothing" the rate at which requests were made. That was important earlier on as the underlying Azure infrastructure had to support that traffic, and sudden bursts could be problematic.

But the other thing that was problematic is that people (quite reasonably) assumed that they could make 10 fast requests, wait a minute, then go again. This led to support overhead for us and customer frustration, and neither is good.

With these latest updates, 10RPM (and all the other RPMs) is now implemented exactly as it sounds - 10 requests in any one-minute block. Here's our Azure API Management policy:

In other words, we've "unsmoothed" it. You can hammer the service 10 times in quick succession, then wait a minute, and you won't see a single HTTP 429 "Too many requests" response. Equally, if you're on a 12,000 RPM plan (and you can actually send that many requests quickly!), you won't see an unexpected 429. We can do this now because of the way we serve a huge amount of content from Cloudflare's edge, unburdening the underlying infrastructure from sudden spikes.

It's a little thing, but it'll solve a lot of unnecessary frustration for a bunch of people, including us. That's implemented across every single plan, too, so everyone benefits.

We Just Wanna Go (Even) Fast(er)

Here's our challenge today: how do we enable millions of people a day to search through billions of records with near instantaneous results... and do it affordably? They're somewhat competing objectives, but every now and then, we find this one neat trick that dramatically improves things. About 18 months ago, I wrote about how we were Hyperscaling HIBP with Cloudflare Workers and Caching. The basic premise is that, as people search the service, we build a cache in Cloudflare's 300+ edge nodes that includes the entire hash range just searched for (see the k-anon section above). We flush that out on every new breach load and as it builds back up to the full 16^6 possible cachable hash ranges, our origin load approaches zero and everything gets served from the edge. Almost, because we have the following problem I described in the post:

However, the second two models (the public and enterprise APIs) have the added burden of validating the API key against Azure API Management (APIM), and the only place that exists is in the West US origin service. What this means for those endpoints is that before we can return search results from a location that may be just a short jet ski ride away, we need to go all the way to the other side of the world to validate the key and ensure the request is within the rate limit.

Or at least we had that problem, which we've just solved with a simple fix. The quoted problem stemmed from the fact that, to ensure everyone adhered to the rate limit, we performed the APIM check before returning any data. That meant always waiting for packets to make a round trip to America, even when the data was cached nearby. But what we realised is that adhering to the rate limit can be eventually enforced; it really doesn't matter too much if a request or two in excess of the rate limit slips through, then we enforce it. The reason why that epiphany is important is that with that in mind, we can start returning data to the client immediately whilst doing the APIM check asynchronously. If the request exceeds the rate limit, Cloudflare will block subsequent requests until the client starts making requests within their limit. So, the rate limit check is no longer a blocking call; it's a background process that doesn't delay us returning results.

What that means is a dramatic reduction in the time til first byte:

That's almost a 40% reduction in wait time! It's an awesome example of how continuous investment in the way we run this thing yields tangible results that make a meaningful difference to the value people get from the service.

Passkeys!

Just one more thing...

This is all new, all free and all available to everyone, whether they have a paid subscription or not. Remember when I got phished last year? I sure do, and I vowed to use that experience to maximise the adoption of passkeys wherever possible. So, putting my money (and time) where my mouth is, we've now launched passkeys as an alternate means of signing into your dashboard:

This saves you needing a "magic" link via email on every sign-in, and whilst it doesn't constitute 2FA (the passkey becomes a single factor used to sign in), it massively streamlines how you access the dashboard. And because we never used passwords for access in the first place, the only account-takeover risk our customers face is someone gaining access to either their email account or to where they store their passkeys (in either case, they have much bigger problems!).

Here's how it works: start by signing into your dashboard, then heading over to the "Passkeys" section on the left of the screen and adding a new one:

The name is so you can keep track of which passkey you save where. I save most of mine in 1Password, but you can also save them on a physical U2F key or in your browser, for example. Clicking "Continue" will cause your browser to prompt you for the location where you'd like to store it and again, that's 1Password for me:

And that's it - we're done!

So, how does it work? Check this out, and don't blink or you'll miss it:

Compared to typing in your email address, hitting the "Sign In" button, flicking over to the mailbox, waiting for the mail to arrive, then clicking the link, we're down from let's call it 30 seconds to about 3 seconds. Nice 😎

Even though there isn't much security benefit to doing this on HIBP (you can still sign in via email, too), we wanted to build this as an example of just how easy it is. It took Stefán about an hour to build a first cut of this (with support from Copilot), and, aside from the dev time, building passkey support into your website is totally free. There are no external services you need to pay for, no hardware to buy or special crypto concepts to grasp. Passkeys are dead simple, and web developers with even a passing interest in security and usability should be adding support for them right now. We also wanted to make sure they were freely available to anyone, regardless of whether you have a paid subscription, because security like this should be the baseline, not a paid extra. So, go and give them a go in HIBP now.

And just in case you want to really geek out on how passkeys work, Stefán presented this at NDC Security in Oslo earlier this month:

All the Plans and Future Changes for Existing Subscribers

It's easiest just to see the whole overview all in one image (or jump over to the pricing page on the website), and it largely reflects everything described above:

One immediate difference to how we've previously represented the plans is that the annual price is now shown as a monthly figure. It turns out that the vast majority of our subscribers choose annual billing, so leading with the per-month pricing puts the least relevant figures front and centre. As we looked around at other services, that was a pretty consistent trend, especially when one annual subscription is more cost-effective than renewing a monthly one 12 times (annual is roughly 10x a year's worth of month-by-month payments).

Another change is that we're going to cap the number of larger domains (those with over 10 breached addresses) that can be searched on each subscription. Let me explain why: Every time we load a data breach, each record in the breach is checked against each domain being monitored. In 2025, we added 2.9 billion breached records, and we have 400k monitored domains. Multiply those out, and we're looking at 1.16 quadrillion checks for our subscribers each year. This is all handled by SQL queries, so it's not like we're getting hit with human overhead at scale, but we're getting hit hard with SQL costs. Across everything we pay to run this service (storage, app hosting, functions, API management, App Insights, bandwidth, etc.), the SQL bill is more than the total for all other services combined. In addition to how we currently calculate plan size based on breached email count, we're adding a cap on the number of domains per plan.

Only domains with more than 10 breached addresses are included in the cap.

The “10” threshold aligns with the existing requirement for a domain to need a subscription at all, and means this change impacts only a single-digit percentage of subscribers. It also helps filter out noise so the cap reflects domains that actually matter. For those larger domains beyond the cap, all current alerts will continue to work just fine until they run a search. At that time, they'll have the option to upgrade the plan or reduce the number of domains. But none of that affects existing subscribers now:

There will be no changes to existing plans until at least August 2 this year.

We do an annual price revision each August, and that's already factored into the table above. That applies to any new subscriptions immediately, but it won't touch existing ones until August 2 at the earliest. The revised pricing only kicks in on the next subscription renewal after that date, so it could be as late as August 2027 if you're an existing subscriber. The same goes for the cap on the number of domains being monitored - there's no impact on existing subscribers until at least August. That leaves plenty of time to cancel, downgrade, upgrade, or just do nothing, and the plan will automatically roll over to the new one. We'll be emailing everyone in the coming days with details of precisely what will change.

Note: if you had an old Pwned 5 subscription for the sake of stealer log access, we'll be rolling all those folks over to Pro 1 and applying a permanent discount code to ensure there's no change in price by moving to the higher plan (it'll actually drop slightly). That'll be explained in the upcoming email, it just made more sense to keep stealer logs in Pro and move people over, and this'll just give them free access to all the new stuff too.

Speaking of which, the thing that (almost) nobody reads but everyone is subject to has been revised to reflect the changes described above - the Terms of Use. For the first time, we've also summarised all the changes and linked through to an archive of the old ones, so if you really love digging through a long document prepared by lawyers, this should make you happy 😊

We're Still Doing Credit Cards via Stripe

While I'm here, just a quick comment on our ongoing Stripe dependency and, as a result, the necessity to pay for public services via credit card. I've written before about some of the challenges we've faced with customers' requests to pay by other means and how, push comes to shove, they (almost) always find a way around internal barriers. Let me share a recent empirical anecdote about this:

Just the other day, I had a call with a Fortune 500 company that was initially interested in our enterprise services. As the discussion unfolded, it became evident that the public services would more than suffice and that the enterprise route was too burdensome for their particular use case. Be that as it may, the procurement lady on the call was adamant that payment by credit card was impossible, even going to the extent of making a pretty bold statement:

No Fortune 500 company is going to pay for services like this via credit card!

O RLY? If only I had the data to check that claim... 😊 Based on a list of their domains, 132 unique Fortune 500 companies have paid for our services by credit card. The real number will be higher because many more of their domains are not on that list, or purchases have been made via an email address not on the corporate domain. Let's call it somewhere between a quarter and a third of the Fortune 500 who've puschased direct via the world's most common payment method. In other words, a significantly different number from the "zero" claim.

I've dropped the hard facts here out of both frustration from our dealings with unnecessarily artificial barriers and in support of the folks out there who, just like me in my corporate days, had to deal with "Neville" in procurement. Per that linked blog post, push back against "corporate policy" prohibiting payment by card, and statistically, you'll likely find you're not the 1 in 160 who can't make a simple payment.

Summary

We're continuing to massively invest in expanding HIBP in every way we can find. Nearly 3 billion additional breached records last year, hundreds of billions of free Pwned Passwords queries during that time, a bunch of new tweaks and features everyone gets access to and, of course, all the new stuff we've rolled into the higher plans. These new features are the culmination of a huge volume of work dating back to November, when I took this pic of our little team during our planning meeting together in Oslo.

We all hope it helps people use our Have I Been Pwned services to do more good after bad things happen.

Plus: Apple makes big claims about the effectiveness of its Lockdown Mode anti-spyware feature, Russia moves to implement homegrown encryption for 5G, and more.

This year, AI agents took the center stage – as a defensive capability, but more pressingly as a risk many organizations haven't caught up with

Silver Fox is back in Japan, spoofing tax and HR emails timed to the one season when no one thinks twice about opening them

A text that looks like it came straight from a courthouse is making the rounds across the U.S. And yes, I got it too. 

First things first, that’s a scam. And to be clear: DON’T SCAN THAT QR CODE. 

It’s the same playbook as last year’s toll road scams, just dressed up with a little more authority and a lot more pressure. 

Before doing anything, our team ran it through McAfee’s Scam Detector. It immediately flagged the message as suspicious, and that’s exactly the kind of moment this tool is built for. When something feels just real enough to second guess, it gives you a clear signal before you click, scan, or spiral. 

How the scam works 

The text claims you’ve missed a payment, violated a law, or have some kind of outstanding “case.” It then pushes you to scan a QR code or click a link to resolve it quickly. 

From there, one of two things usually happens: 

1. You’re taken to a fake payment page designed to steal your money, or 
2. You’re prompted to download something that gives scammers access to your device or data  

Either way, the goal is the same: get you to act fast before you have time to question it. 

The red flags in this message 

• Urgent, threatening language about fines, penalties, or legal action  
• Vague accusations with no real details about what you supposedly did  
• Official-looking formatting like case numbers, clerk signatures, and judge names  
• Copy-paste consistency across states: McAfee employees in New York and California received nearly identical messages with the same names  

There are reports of this scam popping up nationwide, but the rule is simple: law enforcement does not text you to demand payment or resolve legal issues. 

What to do if you scanned the QR code 

First, don’t panic. Then: 

• Do not pay anything or enter personal information  
• Do not delete apps you were told to install (this can make it harder to detect what happened)  
• Run a device scan using a trusted security tool like McAfee’s free antivirus  
• Keep an eye on your financial accounts and logins for unusual activity  

And that, my friends, is scam number one in this week’s This Week in Scams (new format, we’re experimenting a little).  

Let’s get into what else is on our radar. 

What to Know About an Alleged Crunchyroll Breach 

Anime streaming platform Crunchyroll is investigating claims of a data breach involving customer support ticket data, potentially impacting millions of users. 

According to TechCrunch, access appears to involve a third-party vendor system, a reminder that even strong security setups still rely on people and partners, which can introduce risk in everyday moments. 

Even if you’ve never entered your credit card into a support form, these tickets can still include: 

• Email addresses  
• Usernames  
• Screenshots or account details  
• Conversations that reveal habits, subscriptions, or personal context  

That’s more than enough for scammers to build highly believable follow-ups. 

Why this matters right now 

When breaches like this surface, scammers don’t wait. They use the moment to send emails and messages that feel timely, relevant, and legitimate. 

For example, scammers might send messages pretending to be Crunchyroll and suggesting you “click this link to secure your account” after the breach. In reality, that “security check” exposes your information.

This is where tools like Scam Detector come back into play, flagging suspicious links and messages even when they reference real companies or real events. 

What to do if you have a Crunchyroll account 

• Change your password, especially if you’ve reused it elsewhere  
• Turn on two-factor authentication  
• Be cautious of emails referencing the breach or asking you to “secure your account”  
• Avoid clicking links and go directly to the official site instead  

How McAfee Helps You Stay Ahead of Scams and Breaches

McAfee+ Advanced gives you multiple layers working together so you’re not left figuring it out in the moment: 

• Scam Detector flags suspicious texts, emails, links, and even deepfake videos before you engage  
• Safe Browsing helps block risky sites if you do click or scan  
• Device Security helps detect and remove malicious apps or downloads  
• Identity Monitoring alerts you if your personal info shows up where it shouldn’t, so you can act fast  
• Personal Data Cleanup helps remove your information from data broker sites, making you a harder target in the first place  
• Secure VPN keeps your data private, especially on public Wi-Fi  

Plus our instant QR code scam checks will flag suspicious QR codes before you scan them.

Safety tips to carry into next week 

• Slow down when a message creates urgency. That’s the hook  
• Don’t scan QR codes or click links from unexpected texts  
• Go directly to official websites instead of using links sent to you  
• Use tools that flag scams in real time so you don’t have to guess  

The reality is, these scams are designed to look normal. You shouldn’t have to be an expert to spot them. That’s why McAfee’s here to help. 

We’ll be back next week with more scams making headlines. 

The post Got a “Court Notice” Text? Ignore It. Plus, the Crunchyroll Breach: This Week in Scams appeared first on McAfee Blog.

Experts say that an American ground operation targeting nuclear sites in Iran would be incredibly complicated, put troops’ lives at great risk—and might still fail.

The Telegram-based Xinbi Guarantee black market sells services that help prop up scam operations. British officials just hit the highly lucrative marketplace with sweeping sanctions.

US lawmakers are pressing Tulsi Gabbard to reveal whether using a VPN can strip Americans of their constitutional protections against warrantless surveillance.

From drones to missiles to submarines, the $30.5 billion defense startup wants to transform how the tools of war are made. It’s not all going as planned.

Tax season is prime time for scammers. And in 2026, the scams are more convincing, more targeted, and increasingly powered by AI. 

In this guide, we break down this year’s biggest tax scams from the IRS Dirty Dozen and show how tools like McAfee’s Scam Detector help flag malicious links, scan suspicious QR codes, and analyze risky messages across text, email, and social media to help you stay ahead of fraud. 

The need for that kind of protection is clear. New McAfee research shows: 

• 82% of Americans are concerned about tax fraud  
• 67% are seeing the same or more scam messages than last year  
• 40% say scams are more sophisticated  
• Only 29% feel very confident they can spot a deepfake scam  
• Nearly 1 in 4 Americans say they’ve lost money to a tax scam  

Tax scams are not just increasing. They are getting harder to recognize in the moment. 

What is the IRS Dirty Dozen? 

The IRS Dirty Dozen is the agency’s annual list of the most common and dangerous tax scams targeting individuals and businesses. 

The 2026 list highlights a clear shift toward: 

• AI-driven impersonation  
• QR code and link-based phishing  
• Social media misinformation  
• Refund and credit manipulation schemes  

These scams are designed to create urgency, confusion, and quick decisions. That combination is what makes them effective. 

The IRS Dirty Dozen for 2026 and how to spot each scam 

Below is a full breakdown of all 12 scams identified by the IRS, along with what to look for and how protection tools can help. 

#	Scam Type	How It Works	Red Flags	How McAfee Helps
1	IRS impersonation (email, text, DM)	Messages claim to be from the IRS asking you to verify info or claim a refund	Urgent tone, links, QR codes, unexpected outreach	Scam Detector flags suspicious messages and links across text, email, and social. Safe browsing blocks fake IRS sites if you click
2	AI voice scams and robocalls	AI-generated calls mimic IRS agents or officials	Threats, payment pressure, spoofed caller ID	Scam Detector helps validate follow-up messages or links tied to the call. Identity monitoring helps detect if your info is being used in impersonation attempts
3	Fake charities	Scammers pose as charities to collect donations or data	Emotional appeals, vague organization details	Scam Detector flags suspicious donation links. Safe browsing blocks fraudulent charity sites. Personal Data Cleanup reduces exposure to targeting lists
4	Social media tax misinformation	Viral posts push fake deductions or “tax hacks”	Promises of large refunds or loopholes	Scam Detector’s screenshot analysis lets you check social posts and DMs before acting, helping identify misleading or risky claims
5	IRS account takeover scams	Criminals use stolen data to access IRS accounts	Alerts about account changes you didn’t initiate	Identity monitoring and alerts notify you if your data is exposed. Device security helps prevent malware used to steal credentials
6	Abusive capital gains schemes (Form 2439)	Fake or inflated claims tied to investment credits	Complicated filings tied to unfamiliar organizations	Scam Detector flags suspicious messages and links. Safe browsing blocks fraudulent filing sites tied to these schemes
7	Fake self-employment tax credit	Misleading claims about eligibility for large credits	“You qualify” messaging without verification	Safe browsing blocks scam sites attempting to capture personal or tax info
8	Ghost tax preparers	Preparers refuse to sign returns or provide credentials	No PTIN, vague business identity	Scam Detector helps assess suspicious messages or outreach. Identity monitoring adds protection if your data is shared with a bad actor
9	Non-cash donation schemes	Inflated valuations used to reduce tax liability	Unrealistic deductions, aggressive promoters	Scam Detector flags suspicious offers and links. Safe browsing blocks sites attempting to collect sensitive financial data
10	Overstated withholding scams	False income or withholding reported to inflate refunds	Encouragement to “boost” refund numbers	Scam Detector flags misleading content. Device security helps protect against malware tied to fake filing tools
11	Spear phishing targeting tax pros	Emails designed to steal client or business data	Unexpected document requests, attachments	Scam Detector detects phishing attempts. Safe browsing blocks malicious links. Device security helps prevent malware installs
12	Offer in Compromise scams	Companies overpromise tax debt relief and charge high fees	High-pressure sales tactics, guaranteed outcomes	Scam Detector flags suspicious outreach. Personal Data Cleanup reduces targeting. Identity monitoring helps catch misuse of your data

How McAfee helps protect you from tax scams 

Tax scams rarely rely on just one tactic. A message leads to a link. A link leads to a fake site. A fake site leads to stolen data or payment. 

That is why protection needs to work across the full chain, not just one moment. 

McAfee goes beyond traditional antivirus by combining multiple layers of digital protection into one app, helping you stay safer before, during, and after a scam attempt. 

Here is how each layer helps: 

• Scam Detector helps flag suspicious messages, links, and AI-driven scams across text, email, and social media. It can also scan QR codes and analyze screenshots of messages that feel off.  

• Safe browsing tools help block risky websites, including fake IRS portals and lookalike domains designed to steal personal and financial information.  

• Secure VPN helps keep your connection private, especially on public Wi-Fi where sensitive activity like filing taxes or accessing financial accounts can be exposed.  

• Identity monitoring and alerts notify you if your personal information, like your Social Security number or email, appears in places it should not, helping you act quickly if identity theft is attempted.  

• Personal Data Cleanup helps reduce your exposure by removing your information from high-risk data broker sites that scammers use to target you.  

• Device and account security helps protect the devices and accounts you rely on every day, adding another layer of defense against malware, phishing, and unauthorized access.  

Together, these protections help you do more than react to scams. They help you spot them earlier, avoid risky situations, and recover faster if something goes wrong.

The post How to Protect Yourself Against Tax Scams in 2026 appeared first on McAfee Blog.

Cloud VMs offer unmatched speed, scale and flexibility – all of which could eventually count for little if they’re left to fend for themselves

As war reshapes the Gulf, the satellite infrastructure the world relies on to see conflict clearly is being delayed, spoofed, and privately controlled—and nobody is sure who is responsible.

The crowdsourced website and app Mahsa Alert provides citizens in Iran with crucial information amid the country’s ongoing war with the US and Israel—and an internet blackout.

As IT infrastructure expands, visibility and control often lag behind – until an incident forces a reckoning

Attachment to smart devices and biometric surveillance leaves Americans more vulnerable to police searches than ever. Left unchecked it will only get worse.

A family in Chicago has been terrified to leave their apartment. Agents could be anywhere.

Under a Homeland Security program, police departments around the US are signing up to assist in immigration enforcement. The cops of Carroll, New Hampshire, are going all in—and they’re likely not alone.

Watching OpenClaw do its thing must be like watching the first plane take flight. It's a bit rickety and stuck together with a lot of sticky tape, but squint and you can see the potential for agentic AI to change the world as we know it. And I don't think that's hyperbolic. A lot of what people claim to have done with it is hyperbolic, and as with all new tech, the challenge is to cut through the noise and find the value. Stay tuned for more on that, as I've already found some really useful applications for it to help me do my job better, which I think I should devote my next weekly vid to just that.

First heard as US and Israeli strikes on Iran began, the shortwave broadcast has since been traced to a US military base in Germany—but its purpose and its operator remain unclear.

A financially motivated data theft and extortion group is attempting to inject itself into the Iran war, unleashing a worm that spreads through poorly secured cloud services and wipes data on infected systems that use Iran’s time zone or have Farsi set as the default language.

Experts say the wiper campaign against Iran materialized this past weekend and came from a relatively new cybercrime group known as TeamPCP. In December 2025, the group began compromising corporate cloud environments using a self-propagating worm that went after exposed Docker APIs, Kubernetes clusters, Redis servers, and the React2Shell vulnerability. TeamPCP then attempted to move laterally through victim networks, siphoning authentication credentials and extorting victims over Telegram.

In a profile of TeamPCP published in January, the security firm Flare said the group weaponizes exposed control planes rather than exploiting endpoints, predominantly targeting cloud infrastructure over end-user devices, with Azure (61%) and AWS (36%) accounting for 97% of compromised servers.

“TeamPCP’s strength does not come from novel exploits or original malware, but from the large-scale automation and integration of well-known attack techniques,” Flare’s Assaf Morag wrote. “The group industrializes existing vulnerabilities, misconfigurations, and recycled tooling into a cloud-native exploitation platform that turns exposed infrastructure into a self-propagating criminal ecosystem.”

On March 19, TeamPCP executed a supply chain attack against the vulnerability scanner Trivy from Aqua Security, injecting credential-stealing malware into official releases on GitHub actions. Aqua Security said it has since removed the harmful files, but the security firm Wiz notes the attackers were able to publish malicious versions that snarfed SSH keys, cloud credentials, Kubernetes tokens and cryptocurrency wallets from users.

Over the weekend, the same technical infrastructure TeamPCP used in the Trivy attack was leveraged to deploy a new malicious payload which executes a wiper attack if the user’s timezone and locale are determined to correspond to Iran, said Charlie Eriksen, a security researcher at Aikido. In a blog post published on Sunday, Eriksen said if the wiper component detects that the victim is in Iran and has access to a Kubernetes cluster, it will destroy data on every node in that cluster.

“If it doesn’t it will just wipe the local machine,” Eriksen told KrebsOnSecurity.

Aikido refers to TeamPCP’s infrastructure as “CanisterWorm” because the group orchestrates their campaigns using an Internet Computer Protocol (ICP) canister — a system of tamperproof, blockchain-based “smart contracts” that combine both code and data. ICP canisters can serve Web content directly to visitors, and their distributed architecture makes them resistant to takedown attempts. These canisters will remain reachable so long as their operators continue to pay virtual currency fees to keep them online.

Eriksen said the people behind TeamPCP are bragging about their exploits in a group on Telegram and claim to have used the worm to steal vast amounts of sensitive data from major companies, including a large multinational pharmaceutical firm.

“When they compromised Aqua a second time, they took a lot of GitHub accounts and started spamming these with junk messages,” Eriksen said. “It was almost like they were just showing off how much access they had. Clearly, they have an entire stash of these credentials, and what we’ve seen so far is probably a small sample of what they have.”

Security experts say the spammed GitHub messages could be a way for TeamPCP to ensure that any code packages tainted with their malware will remain prominent in GitHub searches. In a newsletter published today titled GitHub is Starting to Have a Real Malware Problem, Risky Business reporter Catalin Cimpanu writes that attackers often are seen pushing meaningless commits to their repos or using online services that sell GitHub stars and “likes” to keep malicious packages at the top of the GitHub search page.

This weekend’s outbreak is the second major supply chain attack involving Trivy in as many months. At the end of February, Trivy was hit as part of an automated threat called HackerBot-Claw, which mass exploited misconfigured workflows in GitHub Actions to steal authentication tokens.

Eriksen said it appears TeamPCP used access gained in the first attack on Aqua Security to perpetrate this weekend’s mischief. But he said there is no reliable way to tell whether TeamPCP’s wiper actually succeeded in trashing any data from victim systems, and that the malicious payload was only active for a short time over the weekend.

“They’ve been taking [the malicious code] up and down, rapidly changing it adding new features,” Eriksen said, noting that when the malicious canister wasn’t serving up malware downloads it was pointing visitors to a Rick Roll video on YouTube.

“It’s a little all over the place, and there’s a chance this whole Iran thing is just their way of getting attention,” Eriksen said. “I feel like these people are really playing this Chaotic Evil role here.”

Cimpanu observed that supply chain attacks have increased in frequency of late as threat actors begin to grasp just how efficient they can be, and his post documents an alarming number of these incidents since 2024.

“While security firms appear to be doing a good job spotting this, we’re also gonna need GitHub’s security team to step up,” Cimpanu wrote. “Unfortunately, on a platform designed to copy (fork) a project and create new versions of it (clones), spotting malicious additions to clones of legitimate repos might be quite the engineering problem to fix.”

Update, 2:40 p.m. ET: Wiz is reporting that TeamPCP also pushed credential stealing malware to the KICS vulnerability scanner from Checkmarx, and that the scanner’s GitHub Action was compromised between 12:58 and 16:50 UTC today (March 23rd).