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.
Apple finally adds TCC events to Endpoint Security!
Since the majority of macOS malware circumvents TCC through explicit user approval, it would be incredibly helpful for any security tool to detect this — and possibly override the user’s risky decision. Until now the best (only?) option was to ingest log messages generated by the TCC subsystem. This approach was implemented in a tool dubbed Kronos, written by Calum Hall Luke Roberts (now, of Phorion fame). Unfortunately, as they note, this approach did have it drawbacks:
A hacker claims to have stolen thousands of internal documents with user records and employee data after breaching the systems of Orange Group, a leading French telecommunications operator and digital service provider.
#Breach #Computer #Data #Email #Extortion #InfoSec #Jira #Leak #Orange #Ransom #S.A. #Security
CISA and the FBI said attackers deploying Ghost ransomware have breached victims from multiple industry sectors across over 70 countries, including critical infrastructure organizations.
#CISA #Computer #Cring #Critical #FBI #Ghost #InfoSec #Infrastructure #Ransomware #Security
A new variant of the XCSSET macOS modular malware has emerged in attacks that target users' sensitive information, including digital wallets and data from the legitimate Notes app.
A code analysis by the BSI shows that two-factor authentication could be bypassed in Nextcloud Server. Passwords were also stored in plain text.
A help desk phishing campaign targets an organization's Microsoft Active Directory Federation Services (ADFS) using spoofed login pages to steal credentials and bypass multi-factor authentication (MFA) protections.
#ADFS #Account #Computer #InfoSec #Lateral #MFA #Microsoft #Notification #Phishing #Push #Security #Takeover
Security researchers have discovered an arbitrary account takeover flaw in Subaru's Starlink service that could let attackers track, control, and hijack vehicles in the United States, Canada, and Japan using just a license plate.
#Account #Canada #Car #Computer #Hacking #InfoSec #Japan #Security #Starlink #Subaru #Takeover #USA
Yesterday we discovered another client-side JavaScript attack targeting +500 websites, including governments and universities. The injected scripts create hidden links in the Document Object Model (DOM), pointing to external websites, a programming interface for web documents.
A new ransomware campaign encrypts Amazon S3 buckets using AWS's Server-Side Encryption with Customer Provided Keys (SSE-C) known only to the threat actor, demanding ransoms to receive the decryption key.
