Attackers are increasingly abusing Microsoft’s decades-old MSHTA utility to stealthily deliver stealers, loaders, and persistent malware through phishing, fake software downloads, and LOLBIN-based attack chains.
The post Legacy Windows Tool MSHTA Fuels Surge in Silent Malware Attacks appeared first on SecurityWeek.
The security defect can be exploited remotely, without authentication, to execute arbitrary code and leak sensitive information.
The post Unpatched ChromaDB Vulnerability Can Lead to Server Takeover appeared first on SecurityWeek.
The stolen credit card data was released as a free download, allegedly in response to seller misconduct.
The post B1ack’s Stash Marketplace Gives Away 4.6 Million Stolen Credit Cards appeared first on SecurityWeek.
The organizations best prepared to face disruption are those that align security, continuity and risk management around what the business cannot afford to lose.
The post Cyber Resilience is the New Business Continuity Plan appeared first on SecurityWeek.
Not by name, but Laurie Anderson quotes me in one of the tracks of her new album:
My favorite quote is from a cryptologist who said “If you think technology will solve your problems, you don’t understand technology and you don’t understand your problems.”
Also in interviews:
“Of course, it’s ridiculous, outrageous, blah, blah, blah,” Anderson says about the ad. ‘But, I mean, my favorite quote on this is from a cryptologist who said, ‘If you think technology will solve your problems, you don’t understand technology  and you don’t understand your problems.’ And I think I’m completely on board with that.”
People are telling me that she has been reciting this quote in performances for years. (I lost track of her since college and her 1981 hit “O Superman.”)
The origins of the quote is from Roger Needham:
If you think cryptography can solve your problem, you don’t understand your problem and you don’t understand cryptography.
I modified the quote in the preface to my 2000 book Secrets and Lies:
A few years ago I heard a quotation, and I am going to modify it here: If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.
I can’t tell you why me in 2000 didn’t credit Needham by name. I should have.
I have used the quote pretty consistently since then. Somewhere along the line I dropped “security” from the phrase, and now say it more like Anderson quotes me:
If you think technology will solve your problem, you don’t understand your problem and you don’t understand technology.
I sometimes use singular and sometimes use plural. Sometimes I say “the problem” and “the technology.” But I think the quote flows better ending with just the word “technology.”
If you’re worried about deepfake likenesses of yourself showing up online, you’re not alone; YouTube is worried for you. It wants to protect you by having you upload a selfie video and government ID to its site.
The idea is that the video giant will use its own AI to patrol the service for fake videos using your likeness. In exchange, you get the chance to have them taken down.
This isn’t available for everyone, though. It’s for celebs, those in vulnerable jobs, and now, most YouTube creators.
YouTube has been working on this concept, which it calls its “likeness detection” system, since it first floated the idea publicly in September 2024. That December, it launched a partnership with the Creative Artists Agency that saw it using the technology with sporting and entertainment figures.
In October last year, it expanded likeness detection to cover more creators, and then in March it expanded it again to cover politicians and journalists. And last month, it widened the net again, offering the service to Hollywood celebs. They can use it regardless of whether they have a YouTube account, it added.
Now, in its latest move, anyone 18 or older with a selfie and ID can sign up. At least in theory, as it hasn’t rolled out to everyone yet. It’s also for faces only; AI-generated voice clones are another problem entirely.
Privacy advocates warned that YouTube’s likeness detection system could normalize handing biometric data to large tech platforms, even if YouTube says the data is only used to improve likeness detection models with creator permission.
On the help page for the likeness detection service, YouTube says creators can separately choose whether their face and voice templates are used to improve its likeness detection models.
“When you sign up for Likeness detection, you also have the option to allow YouTube to use your face and voice templates to develop and improve likeness detection models. This helps us build better, more accurate likeness detection technologies.”
Adding:
“You can opt out of YouTube’s use of this data for development and improvement of likeness models at any time.”
YouTube supports legislation intended to tackle deepfakes, such as the NO FAKES and TAKE IT DOWN acts. These are designed to help stop the misappropriation of someone’s image online. TAKE IT DOWN, which became law a year ago, focuses purely on “nonconsensual intimate imagery.” But that doesn’t cover other kinds of deepfakes, such as fake politicians or celebrity endorsements. Those are becoming increasingly common. NO FAKES, which hasn’t yet become law, is far broader in scope, assigning people federal rights over their own image.
Deepfakes, intimate and otherwise, are definitely a threat, especially for YouTubers who become popular. And the barrier to entry is lowering all the time. Google’s own DeepMind researchers found most generative AI misuse isn’t sophisticated; it’s mundane likeness manipulation by anyone with a browser.
So do you hand over your face and government ID for your protection, to a company whose broader data collection practices have faced years of scrutiny, and hope its policies don’t change? Or do you skip it and hope that the deepfake merchants don’t decide to target you?
Creators commenting on YouTube’s video revealing the service six months ago were less than impressed. One commenter said:
“I was 100% on board, up until the ID upload. That makes me very uncomfortable.”
Echoing several others who complained that it’s difficult to get takedown requests actioned, another added:
“If YouTube actually acted upon these kinds of reports, then I’d be more in favour of this.”
Whether you decide to sign up for the service or not, just be sure to do it with your eyes open.
The 13-country effort, named Operation Ramz, targeted cyber threats in the Middle East and North Africa region.
The post 201 Arrested in Crackdown on Cybercrime in Middle East, North Africa appeared first on SecurityWeek.
Patched in April, the underlying vulnerability allows local attackers to elevate their privileges to root.
The post PoC Released for DirtyDecrypt Linux Kernel Vulnerability appeared first on SecurityWeek.
The vulnerability, CVE-2026-8153, affects Universal Robots PolyScope 5 and it can be exploited for OS command injection.
The post Critical Vulnerability Exposes Industrial Robot Fleets to Hacking appeared first on SecurityWeek.
Until this past weekend, a contractor for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository that exposed credentials to several highly privileged AWS GovCloud accounts and a large number of internal CISA systems. Security experts said the public archive included files detailing how CISA builds, tests and deploys software internally, and that it represents one of the most egregious government data leaks in recent history.
On May 15, KrebsOnSecurity heard from Guillaume Valadon, a researcher with the security firm GitGuardian. Valadon’s company constantly scans public code repositories at GitHub and elsewhere for exposed secrets, automatically alerting the offending accounts of any apparent sensitive data exposures. Valadon said he reached out because the owner in this case wasn’t responding and the information exposed was highly sensitive.
A redacted screenshot of the now-defunct “Private CISA” repository maintained by a CISA contractor.
The GitHub repository that Valadon flagged was named “Private-CISA,” and it harbored a vast number of internal CISA/DHS credentials and files, including cloud keys, tokens, plaintext passwords, logs and other sensitive CISA assets.
Valadon said the exposed CISA credentials represent a textbook example of poor security hygiene, noting that the commit logs in the offending GitHub account show that the CISA administrator disabled the default setting in GitHub that blocks users from publishing SSH keys or other secrets in public code repositories.
“Passwords stored in plain text in a csv, backups in git, explicit commands to disable GitHub secrets detection feature,” Valadon wrote in an email. “I honestly believed that it was all fake before analyzing the content deeper. This is indeed the worst leak that I’ve witnessed in my career. It is obviously an individual’s mistake, but I believe that it might reveal internal practices.”
One of the exposed files, titled “importantAWStokens,” included the administrative credentials to three Amazon AWS GovCloud servers. Another file exposed in their public GitHub repository — “AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems. According to Caturegli, those systems included one called “LZ-DSO,” which appears short for “Landing Zone DevSecOps,” the agency’s secure code development environment.
Philippe Caturegli, founder of the security consultancy Seralys, said he tested the AWS keys only to see whether they were still valid and to determine which internal systems the exposed accounts could access. Caturegli said the GitHub account that exposed the CISA secrets exhibits a pattern consistent with an individual operator using the repository as a working scratchpad or synchronization mechanism rather than a curated project repository.
“The use of both a CISA-associated email address and a personal email address suggests the repository may have been used across differently configured environments,” Caturegli observed. “The available Git metadata alone does not prove which endpoint or device was used.”
The Private CISA GitHub repo exposed dozens of plaintext credentials for important CISA GovCloud resources.
Caturegli said he validated that the exposed credentials could authenticate to three AWS GovCloud accounts at a high privilege level. He said the archive also includes plain text credentials to CISA’s internal “artifactory” — essentially a repository of all the code packages they are using to build software — and that this would represent a juicy target for malicious attackers looking for ways to maintain a persistent foothold in CISA systems.
“That would be a prime place to move laterally,” he said. “Backdoor in some software packages, and every time they build something new they deploy your backdoor left and right.”
In response to questions, a spokesperson for CISA said the agency is aware of the reported exposure and is continuing to investigate the situation.
“Currently, there is no indication that any sensitive data was compromised as a result of this incident,” the CISA spokesperson wrote. “While we hold our team members to the highest standards of integrity and operational awareness, we are working to ensure additional safeguards are implemented to prevent future occurrences.”
A review of the GitHub account and its exposed passwords show the “Private CISA” repository was maintained by an employee of Nightwing, a government contractor based in Dulles, Va. Nightwing declined to comment, directing inquiries to CISA.
CISA has not responded to questions about the potential duration of the data exposure, but Caturegli said the Private CISA repository was created on November 13, 2025. The contractor’s GitHub account was created back in September 2018.
The GitHub account that included the Private CISA repo was taken offline shortly after both KrebsOnSecurity and Seralys notified CISA about the exposure. But Caturegli said the exposed AWS keys inexplicably continued to remain valid for another 48 hours.
CISA is currently operating with only a fraction of its normal budget and staffing levels. The agency has lost nearly a third of its workforce since the beginning of the second Trump administration, which forced a series of early retirements, buyouts, and resignations across the agency’s various divisions.
The now-defunct Private CISA repo showed the contractor also used easily-guessed passwords for a number of internal resources; for example, many of the credentials used a password consisting of each platform’s name followed by the current year. Caturegli said such practices would constitute a serious security threat for any organization even if those credentials were never exposed externally, noting that threat actors often use key credentials exposed on the internal network to expand their reach after establishing initial access to a targeted system.
“What I suspect happened is [the CISA contractor] was using this GitHub to synchronize files between a work laptop and a home computer, because he has regularly committed to this repo since November 2025,” Caturegli said. “This would be an embarrassing leak for any company, but it’s even more so in this case because it’s CISA.”
Data breach notification letters have become a familiar routine. They usually start with “We value your privacy” and offer a year of free credit monitoring. But the most important part is often hidden in the middle:
A list of what actually got out.
A leaked email address is not a leaked admin password. A hashed credential is not a session token. There is no universal post-breach checklist. The right response depends on the data exposed, so read the notice carefully and match your response to the level of exposure.
Continue reading What to Do When a Third-Party Data Breach Puts Your Website at Risk at Sucuri Blog.
We recently updated our privacy policy for the first time since 2022. Most of the changes are clarifications, reorganizations, and improvements in transparency, particularly around how third-party tools that run parts of our site operate. But one change is substantive enough that we want to address it directly.
We want to know how we’re doing with our advocacy: which campaigns get your attention and which do not, which topics you are very interested in, which less so, and which not at all. It helps us to do our work better and to prioritize or rethink our strategies as we push to build support for freedom, justice and innovation around the world.
So, to give us a rough picture of how we’re doing, we are introducing the option for you to provide explicit, opt-in consent for us to see how you interact with the emails we send you. That includes whether you open emails, and whether you click on the links inside them.
We know what you’re thinking: Doesn’t EFF strongly oppose nonconsensual tracking? You bet we do. Sneaky email tracking is ubiquitous on the web and EFF’s opposition to it remains unchanged. We have never used email tracking pixels and we’re not changing that. We’re not building profiles and we’re not sharing the data and we’re definitely not selling it.
But we do want to give you the option of allowing us to learn about how our communications are landing with you. Here’s how consent will work. We will ask, and if you say yes, we’ll be able to see whether you opened an email or not, and whether you clicked on any links. That's it.
If you say no, or ignore the ask entirely, nothing will change and we’ll do no tracking.
If you say yes, you can change your mind and opt out at any time by clicking an opt-out link in any future email or by contacting membership@eff.org.
We have heard many EFF members say that EFF is one of the only organizations that they trust with consent to track their emails. That trust is important, and we do not take it lightly. But it led us to think that if we ask, enough of you would agree that we could have a better picture of how our campaigns and other emails to you are landing and that, in turn, could help us decide what to double down on and what to change.
By giving you a real ability to consent, EFF is taking a very different path than most of the web. Asking isn’t the norm; it’s more or less never an option to say no and dark patterns often make it hard even if it looks like you can. Unfortunately, estimates have shown that 2/3s of emails received by users contain tracking, regardless of whether the senders received explicit consent at the time when a recipient signs up to receive their mailings. Automatic, nonconsensual tracking doesn’t have to be the default, and it shouldn’t be.
We hope our approach works and it inspires others. It shouldn’t be an abnormality that users are not tracked by default, and that only users who feel comfortable doing so choose to consent to tracking. We hope that our example will show mailing platforms, organizations, and users that a privacy-protective approach is better and worth doing and can still give an email sender a solid understanding what campaigns and other messages resonate with recipients. We weighed this decision carefully. We know that email tracking is something we've criticized when used covertly or without meaningful consent and that many people don’t like at all. For EFF, an opt-in requirement isn't a formality. It's the key distinction between a sneaky strategy and an aboveboard relationship with you. And to us, it’s just a common sense approach based on respect.
It’s also consistent with our advocacy and approach to technology. We have said for many years that strong consumer privacy laws must require real opt-in consent before data is collected. And we have walked our talk in other ways as well, including in pushing for Do Not Track policies and in Privacy Badger, which protects you from ads and trackers that violate the principle of user consent.
Again, this behavior has been our suggestion for privacy policies, and privacy laws. In 2022 we released a guide for nonprofits that recommended the following:
Not tracking email open rates can, unfortunately, sometimes cause list “hygiene” problems, because it becomes difficult to know whether email subscribers on your list are still interested. You can send occasional emails to ensure subscribers want to receive emails, either using open or click tracking, and informing people that the purpose of that specific email is to determine active subscribers. The essential point is to let users know when you are using tracking, and to do it in a limited way when possible....
The Internet Archive found that while they preferred to use no open tracking in their emails to subscribers, too many unreachable email addresses had been added to their list over the years, and some email addresses had even become spam traps. To continue working with their email service provider, they needed to activate some tracking. They needed email open data to know whether an email address was still active or not; but they didn’t need or want gender, age, or demographic data. They settled on informing users that their email open rates are being tracked, and offering the alternate option to sign up for plain-text versions of their emails, which won't transmit any data at all.
In 2019, we recommended that all strong consumer privacy laws must include opt-in consent for data collection. We wrote:
Right to opt-in consent
New legislation should require the operators of online services to obtain opt-in consent to collect, use, or share personal data, particularly where that collection, use, or transfer is not necessary to provide the service.
Any request for opt-in consent should be easy to understand and clearly advise the user what data the operator seeks to gather, how they will use it, how long they will keep it, and with whom they will share it. This opt-in consent should also be ongoing—that is, the request should be renewed any time the operator wishes to use or share data in a new way, or gather a new kind of data. And the user should be able to withdraw consent, including for particular purposes, at any time.
Opt-in consent is better than opt-out consent. The default should be against collecting, using, and sharing personal information. Many consumers cannot or will not alter the defaults in the technologies they use, even if they prefer that companies do not collect their information.
We are sticking to those recommendations, which unfortunately are not yet the law, and following our principles.
We hope that you will feel comfortable opting in, but we also respect that you need to make that decision for yourself, and that you may need to change it as you go. We’ll do our part to make that as clear and easy as possible. And if you do agree, we’ll be grateful for getting a chance to learn a little more about how we’re doing, hopefully in ways that can make us even more effective at ensuring that technology supports freedom, justice and innovation for all the people of the world.
The rest of the update is largely about being more precise and provide more transparency into our practices.
Cookies on eff.org: The new policy tightens our cookie practices. Previously, we carved out exceptions for "remember me" and logged-in users; now we don't use persistent ID cookies on the eff.org domain at all. We also clarified that other EFF-operated sites‚ like acteff.org and shopeff.org‚ have their own cookie policies and that our policies aren’t the ones that apply there. We’re not happy that you have to navigate multiple policies like this, but it’s one of the ways that the cookie ecosystem has gotten unfortunately complex. We want to be sure you know that and know where to look for all the information.
Third-party tool transparency: Similarly, while the vast majority of EFF’s public-facing websites, online tools and tech projects are created internally, self-hosted, and self-maintained, some of them are not. In this new policy, we are working to be more detailed and explicit in the new policy about those third-party services, and how they operate under their own privacy policies, not solely ours.
To help you understand exactly what choices you have when using these tools, we're publishing dedicated Privacy Guides for each of them. The first is live now for our shop, which runs on Shopify: EFF Shopify Privacy Guide. Guides for our other third-party tools are coming soon. As always, we recommend installing Privacy Badger to limit exposure from third-party tracking.
Overall, EFF believes that when a project like the Atlas of Surveillance doesn't exist, and we think it should, we build it and maintain it. But what matters most to us is protecting your digital rights. So the time required to maintain and upgrade the tools we have built has to be weighed against our need to build new projects to fight new fights. And sometimes, a tool that was needed when we built it, like EFF’s Action Center, can be replaced by something that can take some of the weight off our internal staff.
To help make space for new projects, we carefully investigate services we rely on—like our campaign tools, payment processors, and online shop—and look for third party options that are the best in the industry and offer a level of privacy our users deserve. In this new privacy policy we try to give you as much information about those third-party services as we can.
GDPR data management: We added a clear, dedicated process for users in the EU and elsewhere to request deletion of their personal data. Email info@eff.org with the subject line "GDPR Data Deletion Request" and we'll respond within the legally required timeframe.
Data retention: We reorganized and clarified how long we keep different types of records (communications, financial records, donation paperwork) into a cleaner list. The substance is unchanged, but the structure should make it easier to find what's relevant to you.
Action Center: You may notice that the previous policy included a dedicated section on our Action Center - how we handled your campaign participation data, what we retained, and so on. That section is gone because we're transitioning our campaign tools to a third-party provider. This is the kind of situation the new third-party transparency language addresses: that provider operates under its own privacy policy, which we'll link to in its dedicated Privacy Guide. Our commitment to your privacy in those contexts doesn't change‚ it just lives in a different place now.
The fundamentals remain what they've always been: we don't sell your information, we don't share it with third parties without your real (not manufactured or dark-patterned) consent, outside of legal requirements we cannot change. We actively push back on legal demands we believe are improper. EFF's mission is to protect your digital rights, and our own practices will continue to reflect that. The changes we’ve described above will help us in that mission.
You can read the full updated policy at eff.org/policy. If you have questions, we're always reachable at info@eff.org.
Login
