bleepingcomputer.com
By Lawrence Abrams
November 11, 2025
The Rhadamanthys infostealer operation has been disrupted, with numerous
The Rhadamanthys infostealer operation has been disrupted, with numerous “customers” of the malware-as-a-service reporting that they no longer have access to their servers.
Rhadamanthys is an infostealer malware that steals credentials and authentication cookies from browsers, email clients, and other applications. It is commonly distributed through campaigns promoted as software cracks, YouTube videos, or malicious search advertisements.
The malware is offered on a subscription model, where cybercriminals pay the developer a monthly fee for access to the malware, support, and a web panel used to collect stolen data.
According to cybersecurity researchers known as g0njxa and Gi7w0rm, who both monitor malware operations like Rhadamanthys, report that cybercriminals involved in the operation claim that law enforcement gained access to their web panels.
In a post on a hacking forum, some customers state that they lost SSH access to their Rhadamanthys web panels, which now require a certificate to log in rather than their usual root password.
"If your password cannot log in. The server login method has also been changed to certificate login mode, please check and confirm, if so, immediately reinstall your server, erase traces, the German police are acting," wrote one of the customers.
Another Rhadamanthys subscriber claimed they were having the same issues, with their server's SSH access now also requiring certificate-based logins.
"I confirm that guests have visited my server and the password has been deleted.rootServer login became strictly certificate-based, so I had to immediately delete everything and power down the server. Those who installed it manually were probably unscathed, but those who installed it through the "smart panel" were hit hard," wrote another subscriber.
A message from the Rhadamanthys developer says they believe German law enforcement is behind the disruption, as web panels hosted in EU data centers had German IP addresses logging in before the cybercriminals lost access.
G0njxa told BleepingComputer that the Tor onion sites for the malware operation are also offline but do not currently have a police seizure banner, so it is unclear who exactly is behind the disruption.
Multiple researchers who have spoken to BleepingComputer believe this disruption could be related to an upcoming announcement from Operation Endgame, an ongoing law enforcement action targeting malware-as-a-service operations.
Operation Endgame has been behind numerous disruptions since it launched, including against ransomware infrastructure, and the AVCheck site, SmokeLoader, DanaBot, IcedID, Pikabot, Trickbot, Bumblebee, Smokeloader, and SystemBC malware operations.
The Operation Endgame website currently has a timer stating that new action will be disclosed on Thursday.
BleepingComputer contacted the German police, Europol, and the FBI, but has not received a reply at this time.
bleepingcomputer.com
By Sergiu Gatlan
November 7, 2025
Cisco warned this week that two vulnerabilities, which have been used in zero-day attacks, are now being exploited to force ASA and FTD firewalls into reboot loops.
The tech giant released security updates on September 25 to address the two security flaws, stating that CVE-2025-20362 enables remote threat actors to access restricted URL endpoints without authentication, while CVE-2025-20333 allows authenticated attackers to gain remote code execution on vulnerable devices.
When chained, these vulnerabilities allow remote, unauthenticated attackers to gain complete control over unpatched systems.
The same day, CISA issued an emergency directive ordering U.S. federal agencies to secure their Cisco firewall devices against attacks using this exploit chain within 24 hours. CISA also mandated them to disconnect ASA devices reaching their end of support (EoS) from federal organization networks.
Threat monitoring service Shadowserver is currently tracking over 34,000 internet-exposed ASA and FTD instances vulnerable to CVE-2025-20333 and CVE-2025-20362 attacks, down from the nearly 50,000 unpatched firewalls it spotted in September.
Now exploited in DoS attacks
"Cisco previously disclosed new vulnerabilities in certain Cisco ASA 5500-X devices running Cisco Secure Firewall ASA software with VPN web services enabled, discovered in collaboration with several government agencies. We attributed these attacks to the same state-sponsored group behind the 2024 ArcaneDoor campaign and urged customers to apply the available software fixes," a Cisco spokesperson told BleepingComputer this week.
"On November 5, 2025, Cisco became aware of a new attack variant targeting devices running Cisco Secure ASA Software or Cisco Secure FTD Software releases affected by the same vulnerabilities. This attack can cause unpatched devices to unexpectedly reload, leading to denial of service (DoS) conditions."
CISA and Cisco linked the attacks to the ArcaneDoor campaign, which exploited two other Cisco firewall zero-day bugs (CVE-2024-20353 and CVE-2024-20359) to breach government networks worldwide starting in November 2023. The UAT4356 threat group (tracked as STORM-1849 by Microsoft) behind the ArcaneDoor attacks deployed previously unknown Line Dancer in-memory shellcode loader and Line Runner backdoor malware to maintain persistence on compromised systems.
On September 25, Cisco fixed a third critical vulnerability (CVE-2025-20363) in its Cisco IOS and firewall software, which can allow unauthenticated threat actors to execute arbitrary code remotely. However, it didn't directly link it to the attacks exploiting CVE-2025-20362 and CVE-2025-20333, saying that its Product Security Incident Response Team was "not aware of any public announcements or malicious use of the vulnerability."
Since then, attackers have started exploiting another recently patched RCE vulnerability (CVE-2025-20352) in Cisco networking devices to deploy rootkit malware on unprotected Linux boxes.
More recently, on Thursday, Cisco released security updates to patch critical security flaws in its Contact Center software, which could enable attackers to bypass authentication (CVE-2025-20358) and execute commands with root privileges (CVE-2025-20354).
"We strongly recommend all customers upgrade to the software fixes outlined in our security advisories," Cisco added on Thursday.
| The Verge theverge.com
by
Robert Hart
Oct 30, 2025, 4:53 PM GMT+1
Huge cyber breaches are on the horizon thanks to AI-powered web browsers like ChatGPT Atlas and Comet, experts warn.
Web browsers are getting awfully chatty. They got even chattier last week after OpenAI and Microsoft kicked the AI browser race into high gear with ChatGPT Atlas and a “Copilot Mode” for Edge. They can answer questions, summarize pages, and even take actions on your behalf. The experience is far from seamless yet, but it hints at a more convenient, hands-off future where your browser does lots of your thinking for you. That future could also be a minefield of new vulnerabilities and data leaks, cybersecurity experts warn. The signs are already here, and researchers tell The Verge the chaos is only just getting started.
Atlas and Copilot Mode are part of a broader land grab to control the gateway to the internet and to bake AI directly into the browser itself. That push is transforming what were once standalone chatbots on separate pages or apps into the very platform you use to navigate the web. They’re not alone. Established players are also in the race, such as Google, which is integrating its Gemini AI model into Chrome; Opera, which launched Neon; and The Browser Company, with Dia. Startups are also keen to stake a claim, such as AI startup Perplexity — best known for its AI-powered search engine, which made its AI-powered browser Comet freely available to everyone in early October — and Sweden’s Strawberry, which is still in beta and actively going after “disappointed Atlas users.”
In the past few weeks alone, researchers have uncovered vulnerabilities in Atlas allowing attackers to take advantage of ChatGPT’s “memory” to inject malicious code, grant themselves access privileges, or deploy malware. Flaws discovered in Comet could allow attackers to hijack the browser’s AI with hidden instructions. Perplexity, through a blog, and OpenAI’s chief information security officer, Dane Stuckey, acknowledged prompt injections as a big threat last week, though both described them as a “frontier” problem that has no firm solution.
“Despite some heavy guardrails being in place, there is a vast attack surface,” says Hamed Haddadi, professor of human-centered systems at Imperial College London and chief scientist at web browser company Brave. And what we’re seeing is just the tip of the iceberg.
With AI browsers, the threats are numerous. Foremost, they know far more about you and are “much more powerful than traditional browsers,” says Yash Vekaria, a computer science researcher at UC Davis. Even more than standard browsers, Vekaria says “there is an imminent risk from being tracked and profiled by the browser itself.” AI “memory” functions are designed to learn from everything a user does or shares, from browsing to emails to searches, as well as conversations with the built-in AI assistant. This means you’re probably sharing far more than you realise and the browser remembers it all. The result is “a more invasive profile than ever before,” Vekaria says. Hackers would quite like to get hold of that information, especially if coupled with stored credit card details and login credentials often found on browsers.
Another threat is inherent to the rollout of any new technology. No matter how careful developers are, there will inevitably be weaknesses hackers can exploit. This could range from bugs and coding errors that accidentally reveal sensitive data to major security flaws that could let hackers gain access to your system. “It’s early days, so expect risky vulnerabilities to emerge,” says Lukasz Olejnik, an independent cybersecurity researcher and visiting senior research fellow at King’s College London. He points to the “early Office macro abuses, malicious browser extensions, and mobiles prior to [the] introduction of permissions” as examples of previous security issues linked to the rollout of new technologies. “Here we go again.”
Some vulnerabilities are never found — sometimes leading to devastating zero-day attacks, named as there are zero days to fix the flaw — but thorough testing can slash the number of potential problems. With AI browsers, “the biggest immediate threat is the market rush,” Haddadi says. “These agentic browsers have not been thoroughly tested and validated.”
But AI browsers’ defining feature, AI, is where the worst threats are brewing. The biggest challenge comes with AI agents that act on behalf of the user. Like humans, they’re capable of visiting suspect websites, clicking on dodgy links, and inputting sensitive information into places sensitive information shouldn’t go, but unlike some humans, they lack the learned common sense that helps keep us safe online. Agents can also be misled, even hijacked, for nefarious purposes. All it takes is the right instructions. So-called prompt injections can range from glaringly obvious to subtle, effectively hidden in plain sight in things like images, screenshots, form fields, emails and attachments, and even something as simple as white text on a white background.
Worse yet, these attacks can be very difficult to anticipate and defend against. Automation means bad actors can try and try again until the agent does what they want, says Haddadi. “Interaction with agents allows endless ‘try and error’ configurations and explorations of methods to insert malicious prompts and commands.” There are simply far more chances for a hacker to break through when interacting with an agent, opening up a huge space for potential attacks. Shujun Li, a professor of cybersecurity at the University of Kent, says “zero-day vulnerabilities are exponentially increasing” as a result. Even worse: Li says as the flaw starts with an agent, detection will also be delayed, meaning potentially bigger breaches.
It’s not hard to imagine what might be in store. Olejnik sees scenarios where attackers use hidden instructions to get AI browsers to send out personal data or steal purchased goods by changing the saved address on a shopping site. To make things worse, Vekaria warns it’s “relatively easy to pull off attacks” given the current state of AI browsers, even with safeguards in place. “Browser vendors have a lot of work to do in order to make them more safe, secure, and private for the end users,” he says.
For some threats, experts say the only real way to keep safe using AI browsers is to simply avoid the marquee features entirely. Li suggests people save AI for “only when they absolutely need it” and know what they’re doing. Browsers should “operate in an AI-free mode by default,” he says. If you must use the AI agent features, Vekaria advises a degree of hand-holding. When setting a task, give the agent verified websites you know to be safe rather than letting it figure them out on its own. “It can end up suggesting and using a scam site,” he warns.
source: OpenAI openai.com
October 30, 2025
Now in private beta: an AI agent that thinks like a security researcher and scales to meet the demands of modern software.
Today, we’re announcing Aardvark, an agentic security researcher powered by GPT‑5.
Software security is one of the most critical—and challenging—frontiers in technology. Each year, tens of thousands of new vulnerabilities are discovered across enterprise and open-source codebases. Defenders face the daunting tasks of finding and patching vulnerabilities before their adversaries do. At OpenAI, we are working to tip that balance in favor of defenders.
Aardvark represents a breakthrough in AI and security research: an autonomous agent that can help developers and security teams discover and fix security vulnerabilities at scale. Aardvark is now available in private beta to validate and refine its capabilities in the field.
How Aardvark works
Aardvark continuously analyzes source code repositories to identify vulnerabilities, assess exploitability, prioritize severity, and propose targeted patches.
Aardvark works by monitoring commits and changes to codebases, identifying vulnerabilities, how they might be exploited, and proposing fixes. Aardvark does not rely on traditional program analysis techniques like fuzzing or software composition analysis. Instead, it uses LLM-powered reasoning and tool-use to understand code behavior and identify vulnerabilities. Aardvark looks for bugs as a human security researcher might: by reading code, analyzing it, writing and running tests, using tools, and more.
Diagram titled “AARDVARK — Vulnerability Discovery Agent Workflow” showing a process flow from Git repository to threat modeling, vulnerability discovery, validation sandbox, patching with Codex, and human review leading to a pull request.
Aardvark relies on a multi-stage pipeline to identify, explain, and fix vulnerabilities:
Analysis: It begins by analyzing the full repository to produce a threat model reflecting its understanding of the project’s security objectives and design.
Commit scanning: It scans for vulnerabilities by inspecting commit-level changes against the entire repository and threat model as new code is committed. When a repository is first connected, Aardvark will scan its history to identify existing issues. Aardvark explains the vulnerabilities it finds step-by-step, annotating code for human review.
Validation: Once Aardvark has identified a potential vulnerability, it will attempt to trigger it in an isolated, sandboxed environment to confirm its exploitability. Aardvark describes the steps taken to help ensure accurate, high-quality, and low false-positive insights are returned to users.
Patching: Aardvark integrates with OpenAI Codex to help fix the vulnerabilities it finds. It attaches a Codex-generated and Aardvark-scanned patch to each finding for human review and efficient, one-click patching.
Aardvark works alongside engineers, integrating with GitHub, Codex, and existing workflows to deliver clear, actionable insights without slowing development. While Aardvark is built for security, in our testing we’ve found that it can also uncover bugs such as logic flaws, incomplete fixes, and privacy issues.
Real impact, today
Aardvark has been in service for several months, running continuously across OpenAI’s internal codebases and those of external alpha partners. Within OpenAI, it has surfaced meaningful vulnerabilities and contributed to OpenAI’s defensive posture. Partners have highlighted the depth of its analysis, with Aardvark finding issues that occur only under complex conditions.
In benchmark testing on “golden” repositories, Aardvark identified 92% of known and synthetically-introduced vulnerabilities, demonstrating high recall and real-world effectiveness.
Aardvark for Open Source
Aardvark has also been applied to open-source projects, where it has discovered and we have responsibly disclosed numerous vulnerabilities—ten of which have received Common Vulnerabilities and Exposures (CVE) identifiers.
As beneficiaries of decades of open research and responsible disclosure, we’re committed to giving back—contributing tools and findings that make the digital ecosystem safer for everyone. We plan to offer pro-bono scanning to select non-commercial open source repositories to contribute to the security of the open source software ecosystem and supply chain.
We recently updated our outbound coordinated disclosure policy which takes a developer-friendly stance, focused on collaboration and scalable impact, rather than rigid disclosure timelines that can pressure developers. We anticipate tools like Aardvark will result in the discovery of increasing numbers of bugs, and want to sustainably collaborate to achieve long-term resilience.
Why it matters
Software is now the backbone of every industry—which means software vulnerabilities are a systemic risk to businesses, infrastructure, and society. Over 40,000 CVEs were reported in 2024 alone. Our testing shows that around 1.2% of commits introduce bugs—small changes that can have outsized consequences.
Aardvark represents a new defender-first model: an agentic security researcher that partners with teams by delivering continuous protection as code evolves. By catching vulnerabilities early, validating real-world exploitability, and offering clear fixes, Aardvark can strengthen security without slowing innovation. We believe in expanding access to security expertise. We're beginning with a private beta and will broaden availability as we learn.
Private beta now open
We’re inviting select partners to join the Aardvark private beta. Participants will gain early access and work directly with our team to refine detection accuracy, validation workflows, and reporting experience.
We’re looking to validate performance across a variety of environments. If your organization or open source project is interested in joining, you can apply here.
| Brave brave.com
Authors
Shivan Kaul Sahib
Artem Chaikin
AI browsers remain vulnerable to prompt injection attacks via screenshots and hidden content, allowing attackers to exploit users' authenticated sessions.
This is the second post in a series about security and privacy challenges in agentic browsers. This vulnerability research was conducted by Artem Chaikin (Senior Mobile Security Engineer), and was written by Artem and Shivan Kaul Sahib (VP, Privacy and Security).
Building on our previous disclosure of the Perplexity Comet vulnerability, we’ve continued our security research across the agentic browser landscape. What we’ve found confirms our initial concerns: indirect prompt injection is not an isolated issue, but a systemic challenge facing the entire category of AI-powered browsers. This post examines additional attack vectors we’ve identified and tested across different implementations.
On request, we are withholding one additional vulnerability found in another browser for now. We plan on providing more details next week.
As we’ve written before, AI-powered browsers that can take actions on your behalf are powerful yet extremely risky. If you’re signed into sensitive accounts like your bank or your email provider in your browser, simply summarizing a Reddit post could result in an attacker being able to steal money or your private data.
As always, we responsibly reported these issues to the various companies listed below so the vulnerabilities could be addressed. As we’ve previously said, a safer Web is good for everyone. The thoughtful commentary and debate about secure agentic AI that was raised by our previous blog post in this series motivated our decision to continue researching and publicizing our findings.
Prompt injection via screenshots in Perplexity Comet
Perplexity’s Comet assistant lets users take screenshots on websites and ask questions about those images. These screenshots can be used as yet another way to inject prompts that bypass traditional text-based input sanitization. Malicious instructions embedded as nearly-invisible text within the image are processed as commands rather than (untrusted) content.
How the attack works:
Setup: An attacker embeds malicious instructions in Web content that are hard to see for humans. In our attack, we were able to hide prompt injection instructions in images using a faint light blue text on a yellow background. This means that the malicious instructions are effectively hidden from the user.
Trigger: User-initiated screenshot capture of a page containing camouflaged malicious text.
Injection: Text recognition extracts text that’s imperceptible to human users (possibly via OCR though we can’t tell for sure since the Comet browser is not open-source). This extracted text is then passed to the LLM without distinguishing it from the user’s query.
Exploit: The injected commands instruct the AI to use its browser tools maliciously.
bleepingcomputer.com By Bill Toulas
October 10, 2025
The FBI has seized last night all domains for the BreachForums hacking forum operated by the ShinyHunters group mostly as a portal for leaking corporate data stolen in attacks from ransomware and extortion gangs.
The FBI seized a BreachForums domain used by the ShinyHunters group as a data leak extortion site for the widespread Salesforce attacks, with the threat actor stating that law enforcement also stole database backups for the notorious hacking forum.
The domain, Breachforums.hn, was previously used to relaunch the hacking forum this summer, but the site was soon taken offline again after some of its alleged operators were arresteds.
In October, the domain was converted into a Salesforce data leak site by Scattered Lapsus$ Hunters, a gang claiming to consist of members linked to the Shiny Hunters, Scattered Spider, and Lapsus$ extortion groups, to extort companies impacted by the Salesforce data theft attacks.
On Tuesday, both the clearnet breachforums.hn data leak site and its Tor counterpart went offline. While the Tor site was quickly restored, the breachforums domain remained inaccessible, with its domains switched to Cloudflare nameservers previously used for domains seized by the U.S. government.
Last night, the FBI completed the action, adding a seizure banner to the site and switching the domain's name servers to ns1.fbi.seized.gov and ns2.fbi.seized.gov.
According to the seizure message, law enforcement authorities in the U.S. and France collaborated to take control of the BreachForums web infrastructure before the Scattered Lapsus$ Hunters hacker began leaking data from Salesforce breaches.
However, with the Tor dark web site still accessible, the threat actors claim they will begin leaking Salesforce data tonight at 11:59 PM EST for companies that do not pay a ransom.
Backups since 2023 under FBI control
In addition to taking down the data leak site, ShinyHunters confirmed that law enforcement gained access to archived databases for previous incarnations of the BreachForums hacking forum.
In a Telegram message confirmed by BleepingComputer to be signed with ShinyHunters' PGP key, the threat actor said the seizure was inevitable and added that "the era of forums is over."
From the analysis conducted after law enforcement's action, ShinyHunters concluded that all BreachForums database backups since 2023 have been compromised, along with all escrow databases since the latest reboot.
The gang also said that the backend servers have been seized. However, the gang's data leak site on the dark web is still online.
The ShinyHunters team stated that no one in the core admin team has been arrested, but they will not launch another BreachForums, noting that such sites should be viewed as honeypots from now on.
According to the threat actor's message, after RaidForum's takedown, the same core team planned multiple forum reboots, using admins like pompompurin as fronts.
The cybercriminals emphasized that the seizure does not affect their Salesforce campaign, and the data leak is still scheduled for today at 11:59 PM EST.
The gang's data leak site on the dark web shows a long list of companies affected by the Salesforce campaing, among them FedEx, Disney/Hulu, Home Depot, Marriott, Google, Cisco, Toyota, Gap, McDonald's, Walgreens, Instacart, Cartier, Adidas, Sake Fifth Avenue, Air France & KLM, Transunion, HBO MAX, UPS, Chanel, and IKEA.
According to the hackers, they stole more than one billion records containing customer information.
The most recent relaunch of the BreachForums in its classic form was announced by ShinyHunters in July 2025, a few days after law enforcement authorities in France arrested four administrators of previous reboots, including the individuals with the usernames ShinyHunters, Hollow, Noct, and Depressed.
At the same time, U.S. authorities announced charges against Kai West, a.k.a. 'IntelBroker,' a high-profile member of the BreachForums cybercrime ecosystem.
In mid-August, BreachForums went offline, and ShinyHunters published a PGP-signed message stating that the forum's infrastructure had been seized by France's BL2C unit and the FBI, warning that there would be no further reboots.
Update 10/10/25: Updated story with more details.
bleepingcomputer.com
By Sergiu Gatlan
September 3, 2025
Update September 04, 06:27 EDT: Updated the list of cybersecurity companies whose Salesforce instances were breached in the Salesloft supply chain attack.
Workiva, a leading cloud-based SaaS (Software as a Service) provider, notified its customers that attackers who gained access to a third-party customer relationship management (CRM) system stole some of their data.
The company's cloud software helps collect, connect, and share data for financial reports, compliance, and audits. It had 6,305 customers at the end of last year and reported revenues of $739 million in 2024.
Its customer list includes 85% of the Fortune 500 companies and high-profile clients such as Google, T-Mobile, Delta Air Lines, Wayfair, Hershey, Slack, Cognizant, Santander, Nokia, Kraft Heinz, Wendy's, Paramount, Air France KLM, Mercedes-Benz, and more.
According to a private email notification sent to affected Workiva customers last week and seen by BleepingComputer, the threat actors exfiltrated a limited set of business contact information, including names, email addresses, phone numbers, and support ticket content.
"This is similar to recent events that have targeted several large organizations. Importantly, the Workiva platform and any data within it were not accessed or compromised," the company explained. "Our CRM vendor notified us of unauthorized access via a connected third-party application."
Workiva also warned impacted customers to remain vigilant, as the stolen information could be used in spear-phishing attacks.
"Workiva will never contact anyone by text or phone to request a password or any other secure details. All communications from Workiva come through our trusted official support channels," it said.
Salesforce data breaches
While Workiva didn't share more details regarding this attack, BleepingComputer has learned that this incident was part of the recent wave of Salesforce data breaches linked to the ShinyHunters extortion group that impacted many high-profile companies.
Most recently, Cloudflare disclosed that it was forced to rotate 104 Cloudflare platform-issued tokens stolen by ShinyHunters threat actors, who gained access to the Salesforce instance used for customer support and internal customer case management in mid-August.
ShinyHunters has been targeting Salesforce customers in data theft attacks using voice phishing (vishing) since the start of the year, impacting companies such as Google, Cisco, Allianz Life, Farmers Insurance, Workday, Qantas, Adidas, and LVMH subsidiaries, including Dior, Louis Vuitton, and Tiffany & Co.
More recently, the extortion group has shifted to using stolen OAuth tokens for Salesloft's Drift AI chat integration with Salesforce to gain access to customer Salesforce instances and extract sensitive information, such as passwords, AWS access keys, and Snowflake tokens, from customer messages and support tickets.
Using this method, ShinyHunters also gained access to a small number of Google Workspace accounts in addition to stealing Salesforce CRM data and breaching the Salesforce instances of multiple cybersecurity companies, including Zscaler, Tenable, CyberArk, Elastic, BeyondTrust, Proofpoint, JFrog, Rubrik, Cato Networks, and Palo Alto Networks.
Unknown threat actors have breached the National Nuclear Security Administration's network in attacks exploiting a recently patched Microsoft SharePoint zero-day vulnerability chain.
NNSA is a semi-autonomous U.S. government agency part of the Energy Department that maintains the country's nuclear weapons stockpile and is also tasked with responding to nuclear and radiological emergencies within the United States and abroad.
A Department of Energy spokesperson confirmed in a statement that hackers gained access to NNSA networks last week.
"On Friday, July 18th, the exploitation of a Microsoft SharePoint zero-day vulnerability began affecting the Department of Energy, including the NNSA," Department of Energy Press Secretary Ben Dietderich told BleepingComputer. "The Department was minimally impacted due to its widespread use of the Microsoft M365 cloud and very capable cybersecurity systems."
Dietderich added that only "a very small number of systems were impacted" and that "all impacted systems are being restored."
As first reported by Bloomberg, sources within the agency also noted that there's no evidence of sensitive or classified information compromised in the breach.
The APT29 Russian state-sponsored threat group, the hacking division of the Russian Foreign Intelligence Service (SVR), also breached the U.S. nuclear weapons agency in 2019 using a trojanized SolarWinds Orion update.
Attacks linked to Chinese state hackers, over 400 servers breached
On Tuesday, Microsoft and Google linked the widespread attacks targeting a Microsoft SharePoint zero-day vulnerability chain (known as ToolShell) to Chinese state-sponsored hacking groups.
"Microsoft has observed two named Chinese nation-state actors, Linen Typhoon and Violet Typhoon exploiting these vulnerabilities targeting internet-facing SharePoint servers," Microsoft said.
"In addition, we have observed another China-based threat actor, tracked as Storm-2603, exploiting these vulnerabilities. Investigations into other actors also using these exploits are still ongoing."
Dutch cybersecurity firm Eye Security first detected the zero-day attacks on Friday, stating that at least 54 organizations had already been compromised, including national government entities and multinational companies.
Cybersecurity firm Check Point later revealed that it had spotted signs of exploitation going back to July 7th targeting dozens of government, telecommunications, and technology organizations in North America and Western Europe.
bleepingcomputer.com -
npm has taken down all versions of the real Stylus library and replaced them with a "security holding" page, breaking pipelines and builds worldwide that rely on the package.
A security placeholder webpage is typically displayed when malicious packages and libraries are removed by the admins of npmjs.com, the world's largest software registry primarily used for JavaScript and Node.js development.
But that isn't quite the case for Stylus: a legitimate "revolutionary" library receiving 3 million weekly downloads and providing an expressive way for devs to generate CSS.
Stylus 'accidentally banned by npmjs'
As of a few hours ago, npmjs has removed all versions of the Stylus package and published a "security holding package" page in its place.
"Stylus was accidentally banned by npmjs," earlier stated Stylus developer Lei Chen in a GitHub issue. The project maintainer is "currently waiting for npmjs to restore access to Stylus."
"I am the current maintainer of Stylus. The Stylus library has been flagged as malicious..., which has caused many [libraries] and frameworks that depend on Stylus to fail to install," also posted Chen on X (formerly Twitter). "Please help me retweet this msg in the hope that the npmjs official team will take notice of this issue."
bleepingcomputer.com - The Lumma infostealer malware operation is gradually resuming activities following a massive law enforcement operation in May, which resulted in the seizure of 2,300 domains and parts of its infrastructure.
Although the Lumma malware-as-a-service (MaaS) platform suffered significant disruption from the law enforcement action, as confirmed by early June reports on infostealer activity, it didn't shut down.
The operators immediately acknowledged the situation on XSS forums, but claimed that their central server had not been seized (although it had been remotely wiped), and restoration efforts were already underway.
Gradually, the MaaS built up again and regained trust within the cybercrime community, and is now facilitating infostealing operations on multiple platforms again.
According to Trend Micro analysts, Lumma has almost returned to pre-takedown activity levels, with the cybersecurity firm's telemetry indicating a rapid rebuilding of infrastructure.
"Following the law enforcement action against Lumma Stealer and its associated infrastructure, our team has observed clear signs of a resurgence in Lumma's operations," reads the Trend Micro report.
"Network telemetry indicates that Lumma's infrastructure began ramping up again within weeks of the takedown."
An ongoing outage at IT giant Ingram Micro is caused by a SafePay ransomware attack that led to the shutdown of internal systems, BleepingComputer has learned.
Update 7/6/25: Added Ingram Micro's confirmation it suffered a ransomware attack below. Also updated ransom note with clearer version.
An ongoing outage at IT giant Ingram Micro is caused by a SafePay ransomware attack that led to the shutdown of internal systems, BleepingComputer has learned.
Ingram Micro is one of the world's largest business-to-business technology distributors and service providers, offering a range of solutions including hardware, software, cloud services, logistics, and training to resellers and managed service providers worldwide.
Since Thursday, Ingram Micro's website and online ordering systems have been down, with the company not disclosing the cause of the issues.
BleepingComputer has now learned that the outages are caused by a cyberattack that occurred early Thursday morning, with employees suddenly finding ransom notes created on their devices.
The ransom note, seen by BleepingComputer, is associated with the SafePay ransomware operation, which has become one of the more active operations in 2025. It is unclear if devices were actually encrypted in the attack.
It should be noted that while the ransom note claims to have stolen a wide variety of information, this is generic language used in all SafePay ransom notes and may not be true for the Ingram Micro attack.
Cisco has removed a backdoor account from its Unified Communications Manager (Unified CM), which would have allowed remote attackers to log in to unpatched devices with root privileges.
Cisco Unified Communications Manager (CUCM), formerly known as Cisco CallManager, serves as the central control system for Cisco's IP telephony systems, handling call routing, device management, and telephony features.
The vulnerability (tracked as CVE-2025-20309) was rated as maximum severity, and it is caused by static user credentials for the root account, which were intended for use during development and testing.
Learn about the new permission prompt for sites that connect to local networks.
Published: June 9, 2025
Chrome is adding a new permission prompt for sites that make connections to a user's local network as part of the draft Local Network Access specification. The aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks, and to reduce the ability of sites to use these requests to fingerprint the user's local network.
To understand how this change impacts the web ecosystem, the Chrome team is looking for feedback from developers who build web applications that rely on making connections to a user's local network or to software running locally on the user's machine. From Chrome 138, you can opt-in to these new restrictions by going to chrome://flags/#local-network-access-check and setting the flag to "Enabled (Blocking)".
Note: Chrome previously experimented with restricting access to local network devices with Private Network Access, which required CORS preflights where the target device opted in to being connected to, instead of gating all local network accesses behind a permission prompt. Local Network Access replaces that effort, after PNA was put on hold. Thank you to everyone who helped test PNA and provide feedback to us—it has been incredibly valuable and helped guide us to our new Local Network Access permission approach.
What is Local Network Access?
Local Network Access restricts the ability of websites to send requests to servers on a user's local network (including servers running locally on the user's machine), requiring the user grant the site permission before such requests can be made. The ability to request this permission is restricted to secure contexts.
A prompt with the text 'Look for and connect to any device on your local network.'
Example of Chrome's Local Network Access permission prompt.
Many other platforms, such as Android, iOS, and MacOS have a local network access permission. For example, you may have granted this permission to access the local network to the Google Home app when setting up new Google TV and Chromecast devices.
What kinds of requests are affected?
For the first milestone of Local Network Access, we consider a "local network request" to be any request from the public network to a local network or loopback destination.
A local network is any destination that resolves to the private address space defined in Section 3 of RFC1918 in IPv4 (e.g., 192.168.0.0/16), an IPv4-mapped IPv6 address where the mapped IPv4 address is itself private, or an IPv6 address outside the ::1/128, 2000::/3, and ff00::/8 subnets.
Loopback is any destination that resolves to the "loopback" space (127.0.0.0/8) defined in section 3.2.1.3 of RFC1122 of IPv4, the "link-local" space (169.254.0.0/16) defined in RFC3927 of IPv4, the "Unique Local Address" prefix (fcc00::/7) defined in Section 3 of RFC4193 of IPv6, or the "link-local" prefix (fe80::/10) defined in section 2.5.6 of RFC4291 of IPv6.
A public network is any other destination.
Note: In the future, we plan to extend these protections to cover all cross-origins requests going to destinations on the local network. This would include requests from a local server (for example, https://router.local) to other servers on the local network, or from a local server to localhost.
Because the local network access permission is restricted to secure contexts, and it can be difficult to migrate local network devices to HTTPS, the permission-gated local network requests will now be exempted from mixed content checks if Chrome knows that the requests will be going to the local network before resolving the destination. Chrome knows a request is going to the local network if:
The request hostname is a private IP literal (e.g., 192.168.0.1).
The request hostname is a .local domain.
The fetch() call is annotated with the option targetAddressSpace: "local".
// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");
// Example 2: .local domain is exempt from mixed content.
fetch("http://router.local/ping");
// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");
// Example 4: Adding the targetAddressSpace option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
targetAddressSpace: "local",
});
What's changing in Chrome
Chrome 138
Our initial version of Local Network Access is ready for opt-in testing in Chrome 138. Users can enable the new permission prompt by setting chrome://flags#local-network-access-check to "Enabled (Blocking)". This supports triggering the Local Network Access permission prompt for requests initiated using the JavaScript fetch() API, subresource loading, and subframe navigation.
A demo site is available at https://local-network-access-testing.glitch.me/ for triggering different forms of local network requests.
Known issues and limitations
The new permission prompt is currently only implemented on Desktop Chrome. We are actively working on porting it to Android Chrome. (Tracked in crbug.com/400455013.)
WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834), and WebRTC (crbug.com/421223919) connections to the local network are not yet gated on the LNA permission.
Local network requests from Service Workers currently require that the service worker's origin has previously been granted the Local Network Access permission.
If your application makes local network requests from a service worker, you will currently need to separately trigger a local network request from your application in order to trigger the permission prompt. (We are working on a way for workers to trigger the permission prompt if there is an active document available—see crbug.com/404887282.)
Chrome 139 and beyond
Our intent is to ship Local Network Access as soon as possible. Recognizing that some sites may need additional time to be updated with Local Network Access annotations, we will add an Origin Trial to let sites temporarily opt-out of the secure contexts requirement before we ship Local Network Access by default. This should provide a clearer migration path for developers, especially if you rely on accessing local network resources over HTTP (as these requests would be blocked as mixed content if requested from an HTTPS page in browsers that don't yet support the Local Network Access mixed content exemption).
We will also be adding a Chrome enterprise policy for controlling which sites can and cannot make local network requests (pre-granting or pre-denying the permission to those sites). This will allow managed Chrome installations, such as those in corporate settings, to avoid showing the warning for known intended use cases, or to further lock down and prevent sites from being able to request the permission at all.
We plan to continue integrating the Local Network Access permission with different features that can send requests to the local network. For example, we plan to ship Local Network Access for WebSockets, WebTransport, and WebRTC connections soon.
We will share more information as we get closer to being able to fully launch Local Network Access in Chrome.
As AI and digital technologies advance, the European cyber threat landscape continues to evolve, presenting new challenges that require stronger partnerships and enhanced solutions. Ransomware groups and state-sponsored actors from Russia, China, Iran, and North Korea continue to grow in scope and sophistication, and European cyber protection cannot afford to stand still.
That is why, today, in Berlin, we are announcing a new Microsoft initiative to expand our longstanding work to help defend Europe’s cybersecurity. Implementing one of the five European Digital Commitments I shared in Brussels five weeks ago, we are launching a new European Security Program that adds to the company’s longstanding global Government Security Program.
This new program expands the geographic reach of our existing work and adds new elements that will become critical to Europe’s protection. It puts AI at the center of our work as a tool to protect traditional cybersecurity needs and strengthens our protection of digital and AI infrastructure.
We are launching the European Security Program with three new elements:
Lovable is accused of failing to fix security flaws that exposed information about users, a growing vulnerability as vibe coding’s popularity surges.
Lovable, the popular vibe coding app that describes itself as the fastest-growing company in Europe, has failed to fix a critical security flaw, despite being notified about it months ago, according to a new report by an employee at a competitor.
The service offered by Lovable, a Swedish startup that bills its product as “the last piece of software,” allows customers without any technical training to instantly create websites and apps using only natural language prompts.
The employee at AI coding assistant company Replit who wrote the report, reviewed by Semafor, says he and a colleague scanned 1,645 Lovable-created web apps that were featured on the company’s site. Of those, 170 allowed anyone to access information about the site’s users, including names, email addresses, financial information and secret API keys for AI services that would allow would-be hackers to run up charges billed to Lovable’s customers.
The vulnerability, which was made public on the National Vulnerabilities Database on Thursday, highlights a growing security problem as artificial intelligence allows anyone to become a software developer. Each new app or website created by novices is a potential sitting duck for hackers with automated tools that target everything connected to the internet. The advent of amateur vibe coding raises new questions about who is responsible for securing consumer products in an era where developers with zero security know-how can build them.
Arla Foods has confirmed to BleepingComputer that it was targeted by a cyberattack that has disrupted its production operations.
The Danish food giant clarified that the attack only affected its production unit in Upahl, Germany, though it expects this will result in product delivery delays or even cancellations.
"We can confirm that we have identified suspicious activity at our dairy site in Upahl that impacted the local IT network," stated an Arla spokesperson.
"Due to the safety measures initiated as a result of the incident, production was temporarily affected."
Arla Foods is an international dairy producer and a farmer-owned cooperative with 7,600 members. It employs 23,000 people in 39 countries.
The firm has an annual revenue of €13.8 billion ($15.5 billion), and its products, including the brands Arla, Lurpak, Puck, Castello, and Starbucks, are sold in 140 countries worldwide.
The company told BleepingComputer that it is currently working to resume operations at the impacted facility, which should bring results before the end of the week.
"Since then, we've been working diligently to restore full operations. We expect to return to normal operations at the site in the next few days. Production at other Arla sites is not affected."
Considering that the first reports about a disruption at Arla's production operations surfaced on Friday, it is bound to cause shortages in some cases.
"We have informed our affected customers about possible delivery delays and cancellations," explained Arla's spokesperson.
BleepingComputer has asked the firm if the attack involved data theft or encryption, both staples of a ransomware attack, but Arla declined to share any additional information at this time.
Meanwhile, there have been no announcements about Arla on ransomware extortion portals, so the type of attack and the perpetrators remain unknown.
It's time to update your Macs again! This time, I'm not burying the lede. CVE-2025-31250, which was patched in today's release of macOS Sequoia 15.5, allowed for…
…any Application A to make macOS show a permission consent prompt…
…appearing as if it were coming from any Application B…
…with the results of the user's consent response being applied to any Application C.
These did not have to be different applications. In fact, in most normal uses, they would all likely be the same application. Even a case where Applications B and C were the same but different than Application A would be relatively safe (if somewhat useless from Application A's perspective). However, prior to this vulnerability being patched, a lack of validation allowed for Application B (the app the prompt appears to be from) to be different than Application C (the actual application the user's consent response is applied to).
Spoofing these kinds of prompts is not exactly new. In fact, the HackTricks wiki has had a tutorial on how to perform a similar trick on their site for a while. However, their method requires:
the building of an entire fake app in a temporary directory,
the overriding of a shortcut on the Dock, and
the simple hoping that the user clicks on the (now) fake shortcut.
This vulnerability requires none of the above.
TCC
As I explained in my first ever article on this site, TCC is the core permissions system built into Apple's operating systems. It is used by sending messages to the tccd daemon (or rather, by using functions in the private TCC framework). The framework is a private API, so developers don't call the functions directly (instead, public API's call the functions under-the-hood as needed). However, all this wrapping cannot hide the fact that the control mechanism is still simply sending messages to the daemon.
The daemon uses Apple's public (but proprietary) XPC API for messaging (specifically the lower-level dictionary-based API). Prior to this vulnerability being patched, any app with the ability to send XPC messages to tccd could send it a specifically-crafted message that, as described above, would make it display a permission prompt as if it were from one app but then apply the user's response to a completely separate app. But how was this possible, and was it even hard? Before I answer these questions, we need to detour into what will, at first, seem like a completely unrelated topic.
A hacker breached the GitLab repositories of multinational car-rental company Europcar Mobility Group and stole source code for Android and iOS applications, as well as some personal information belonging to up to 200,000 users.
#Android #Breach #Code #Computer #Data #Europcar #GitLab #InfoSec #Security #Source #iOS
Are you willing to hack and take control of Chinese websites for a random person for up to $100,000 a month?
Someone is making precisely that tantalizing, bizarre, and clearly sketchy job offer. The person is using what looks like a series of fake accounts with avatars displaying photos of attractive women and sliding into the direct messages of several cybersecurity professionals and researchers on X in the last couple of weeks.
