The government cited the recent hacks on Bank Sepah and cryptocurrency exchange Nobite as reasons to shut down internet access to virtually all Iranians.
Earlier this week, virtually everyone in Iran lost access to the internet in what was called a “near-total national internet blackout.”
At the time, it was unclear what happened or who was responsible for the shutdown, which has severely limited Iranians’ means to get information about the ongoing war with Israel, as well as their ability to communicate with loved ones inside and outside of the country.
Now Iran’s government has confirmed that it ordered the shutdown to protect against Israeli cyberattacks.
“We have previously stated that if necessary, we will certainly switch to a national internet and restrict global internet access. Security is our main concern, and we are witnessing cyberattacks on the country’s critical infrastructure and disruptions in the functioning of banks,” Fatemeh Mohajerani, Iran’s government spokesperson, was quoted as saying in a local news story. “Many of the enemy’s drones are managed and controlled via the internet, and a large amount of information is exchanged this way. A cryptocurrency exchange was also hacked, and considering all these issues, we have decided to impose internet restrictions.”
Tonga’s National Health Information System (NHIS) suffered a ransomware breach this week, says Dr ʻAna ʻAkauʻola his evening. The system has been shut down, and staff moved to manual operations.
The breach came to light during a parliament debate on the MEIDECC budget, when Deputy PM Dr Taniela Fusimalohi alerted MPs to the intrusion. Dr ʻAkauʻola confirmed she learned of the hack earlier this week and immediately summoned system administrators. She noted that staff member managing the NHIS “was unaware that it was a serious breach.”
The minister disclosed that hackers encrypted the NHIS and demanded payment, assuring MPs “the hackers won’t damage the information on the NHIS.” She also said she promptly emailed Dr Fusimalohi when she knew of the breach, who engaged the Australian High Commission.
Dr Fusimalohi confirmed an Australian cyber team arrived in Tonga today to help resolve the issue.
June 19 (Reuters) - Tata Consultancy Services (TCS.NS), opens new tab said none of its "systems or users were compromised" as part of the cyberattack that led to the theft of customer data at retailer Marks and Spencer (MKS.L), opens new tab, its client of more than a decade.
"As no TCS systems or users were compromised, none of our other customers are impacted" independent director Keki Mistry told its annual shareholder meeting.
The Reuters Daily Briefing newsletter provides all the news you need to start your day. Sign up here.
"The purview of the investigation (of customer) does not include TCS," Mistry added.
This is the first time India's No 1 IT services company has publicly commented on the cyber hack. M&S did not immediately respond to a request for comment.
TCS is one of the technology services providers for the British retailer. In early 2023, TCS reportedly, opens new tab won a $1 billion contract for modernising M&S' legacy technology with respect to its supply chain and omni-channel sales while increasing its online sales.
The "highly sophisticated and targeted" cyberattack which M&S disclosed in April will cost about 300 million pounds ($403 million) in lost operating profit, and disruption to online services is likely until July.
Last month, Financial Times reported that TCS is internally investigating whether it was the gateway for a cyberattack.
Mistry presided as the chairman at the company's annual shareholder meeting as Tata Group Chairman N Chandrasekaran skipped it due to "exigencies".
The chairman's absence comes as the Group's airline Air India plane with 242 people on board crashed after take-off in Ahmedabad last week, killing all passengers except one.
Reporting by Sai Ishwarbharath B and Haripriya Suresh, Editing by Louise Heavens
Securonix Threat Research uncovers SERPENTINE#CLOUD, a stealthy malware campaign abusing Cloudflare Tunnels to deliver in-memory Python-based payloads via .lnk phishing lures. Learn how this multi-stage attack evades detection, establishes persistence, and executes Donut-packed shellcode using Early Bird APC injection.
An ongoing malware campaign tracked as SERPENTINE#CLOUD has been identified as leveraging the Cloudflare Tunnel infrastructure and Python-based loaders to deliver memory-injected payloads through a chain of shortcut files and obfuscated scripts. For initial access, the threat actors are luring users to execute malicious .lnk files (shortcut files) disguised as documents to silently fetch and execute remote code. This kicks off a rather elaborate attack chain consisting of a combination of batch, VBScript and Python stages to ultimately deploy shellcode that loads a Donut-packed PE payload.
The shortcut files are delivered via phishing emails that contain a link to download a zipped document, often themed around payment or invoice scams. This assessment is based on the naming convention of the ZIP files observed, many of which included the word “invoice.”
Attribution remains unknown, though the attacker demonstrates fluency in English based on code comments and scripting practices. Telemetry indicates a strong focus on Western targets, with confirmed activity observed in the United States, United Kingdom, Germany and other regions across Europe and Asia. The use of Cloudflare for payload hosting allows the attackers to remain anonymous and since their infrastructure is secured behind a trusted network, monitored traffic to this network will rarely raise alarms or be flagged as suspicious by network monitoring tools.
The Qualys Threat Research Unit (TRU) has discovered two linked local privilege escalation (LPE) flaws.
The first (CVE-2025-6018) resides in the PAM configuration of openSUSE Leap 15 and SUSE Linux Enterprise 15. Using this vulnerability, an unprivileged local attacker—for example, via SSH—can elevate to the “allow_active” user and invoke polkit actions normally reserved for a physically present user.
The second (CVE-2025-6019) affects libblockdev, is exploitable via the udisks daemon included by default on most Linux distributions, and allows an “allow_active” user to gain full root privileges. Although CVE-2025-6019 on its own requires existing allow_active context, chaining it with CVE-2025-6018 enables a purely unprivileged attacker to achieve full root access.
This libblockdev/udisks flaw is extremely significant. Although it nominally requires “allow_active” privileges, udisks ships by default on almost all Linux distributions, so nearly any system is vulnerable. Techniques to gain “allow_active”, including the PAM issue disclosed here, further negate that barrier. An attacker can chain these vulnerabilities for immediate root compromise with minimal effort. Given the ubiquity of udisks and the simplicity of the exploit, organizations must treat this as a critical, universal risk and deploy patches without delay.
The Qualys Threat Research Unit (TRU) has developed proof-of-concept exploits to validate these vulnerabilities on various operating systems, successfully targeting the libblockdev/udisks flaw on Ubuntu, Debian, Fedora, and openSUSE Leap 15.
US-designated terrorist organization ELN oversees a vast digital operation that promotes pro-Kremlin and anti-US content.
The National Liberation Army (ELN), a Colombian armed group that also holds influence in Venezuela, has built a digital strategy that involves branding themselves as media outlets to build credibility, overseeing a diffuse cross-platform operation, and using these wide-ranging digital assets to amplify Russian, Iranian, Venezuelan, and Cuban narratives that attack the interests of the United States, the European Union (EU), and their allies.
In the 1960s, the ELN emerged as a Colombian nationalist armed movement ideologically rooted in Marxism-Leninism, liberation theology, and the Cuban revolution. With an army estimated to have 2,500 to 6,000 members, the ELN is Colombia’s oldest and largest active guerrilla group, with its operation extending into Venezuela. The ELN has maintained a strategic online presence for over a decade to advance its propaganda and maintain operational legitimacy.
The organization, which has previously engaged in peace talks with the Colombian state, has carried out criminal activities in Colombia and Venezuela, such as killings, kidnappings, extortions, and the recruitment of minors. After successive military and financial crises in the 1990s, the armed group abandoned its historical reluctance to participate in drug trafficking. The diversification into illegal funding has meant that their armed clashes target criminal groups, in addition to their primary ideological enemy, the state forces.
In the north-eastern Catatumbo area, considered one of the enclaves of international cocaine trafficking, the group has been involved in one of the bloodiest confrontations seen in Colombia in 2025. Since January 15, the violence has left 126 people dead, at least 66,000 displaced, and has further strained the group’s engagement with the latest round of peace talks initiated by the current Colombian government. In that region, the ELN has battled with the state and other criminal groups, such as paramilitaries and other guerrilla groups, for extended control of the area bordering Venezuela, an effort to connect the ELN’s other territories of influence to Colombia, such as the north and, at the other extreme, the western regions of Choco and Antioquia.
The US Department of State reaffirmed the ELN’s designation as a terrorist organization in its March 5, 2025, update of the Foreign Terrorist Organizations (FTOs) list. This classification theoretically prevents the group from operating on major social media platforms, as US social media platforms, such as Meta, YouTube, and X, maintain policies prohibiting terrorist organizations from using their services. However, the DFRLab found that the group’s substantial digital footprint spans over one hundred entities across websites, social media, closed messaging apps, and podcast services.
On June 16, GreyNoise observed exploit attempts targeting CVE-2023-28771 — a remote code execution vulnerability affecting Zyxel Internet Key Exchange (IKE) packet decoders over UDP port 500.
CVE: CVE-2023-28771
Exploit method: UDP port 500 (IKE packet decoder)
Date observed: June 16, 2025
Duration of activity: One day (June 16, 2025)
Unique IPs: 244
Top destination countries: U.S., U.K., Spain, Germany, India.
IP classification: All malicious per GreyNoise
Infrastructure: Verizon Business (all IPs geolocated to U.S.)
Spoofable traffic: Yes (UDP-based)
Observed Activity
Exploitation attempts against CVE-2023-28771 were minimal throughout recent weeks. On June 16, GreyNoise observed a concentrated burst of exploit attempts within a short time window, with 244 unique IPs observed attempting exploitation.
The top destination countries were the U.S., U.K., Spain, Germany, and India.
Historical analysis indicates that in the two weeks preceding June 16, these IPs were not observed engaging in any other scanning or exploit behavior — only targeting CVE-2023-28771.
SafetyDetectives’ Cybersecurity Team stumbled upon a clear web forum post where a threat actor publicized a database that allegedly belongs to VirtualMacOSX.com. The data purportedly belongs to 10,000 of its customers.
In a recent discovery, SafetyDetectives’ Cybersecurity Team stumbled upon a clear web forum post where a threat actor publicized a database that allegedly belongs to VirtualMacOSX.com. The data purportedly belongs to 10,000 of its customers.
What Is VirtualMacOSX.com?
According to its website, VirtualMacOSX serves 102 countries and has offered “Apple Macintosh cloud based computing since 2012. With the greatest range of cloud based Apple products and services available anywhere on the Web.”
Where Was The Data Found?
The data was found in a forum post available on the clear surface web. This well-known forum operates message boards dedicated to database downloads, leaks, cracks, and more.
What Was Leaked?
The author of the post included a 34-line sample of the database, the full database was set to be freely accessible to anyone with an account on the forum willing to either reply or like the post.
Our Cybersecurity Team analyzed a segment of the dataset to validate its authenticity. Although the data appeared genuine and we saw indicatives in invoices sent to VirtualMacOSX, we could not definitively confirm that the data belonged to VirtualMacOSX’s customers as, due to ethical considerations, we refrained from testing the exposed credentials.
The entire dataset consisted of 176,000 lines split across three separate .txt files named ‘tblcontacts,’ ‘tbltickets,’ and ‘tblclients.’
The sensitive information allegedly belonging to VirtualMacOSX’s customers included:
User ID
Full name
Company name
Email
Full physical address
Phone number
Password
Password reset key
We also saw customers’ financial data such as:
Bank name
Bank type
Bank code
Bank account
And User’s Support tickets containing:
User ID
IP Address
Full name
Email
Full Message
This type of data is critical as it might be employed by potential wrongdoers to plan and perform various types of attacks on the impacted clients.
The pro-Israeli hacktivist group Predatory Sparrow claimed on Tuesday to have hacked and taken down Iran’s Bank Sepah.
The group, which is also known by its Persian name Gonjeshke Darande, claimed responsibility for the hack on X.
“We, ‘Gonjeshke Darande,’ conducted cyberattacks which destroyed the data of the Islamic Revolutionary Guard Corps’ ‘Bank Sepah,’” the group wrote.
The group claimed Bank Sepah is an institution that “circumvented international sanctions and used the people of Iran’s money to finance the regime’s terrorist proxies, its ballistic missile program and its military nuclear program.”
According to the independent news site Iran International, there are reports of “widespread banking disruptions” across the country. Iran International said several Bank Sepah branches were closed on Tuesday, and customers told the publication that they were unable to access their accounts.
Ariel Oseran, a correspondent for i24NEWS, posted pictures of ATMs in Iran displaying an error message.
TechCrunch could not independently verify the group’s alleged cyberattack. We reached out to two Bank Sepah Iranian email addresses, but the messages returned an error. Bank Sepah’s affiliates in the U.K. and Italy did not immediately respond to requests for comment.
Predatory Sparrow did not respond to a request for comment sent to their X account, and via Telegram.
The alleged cyberattack on Bank Sepah comes as Israel and Iran are bombing each other’s countries, a conflict that started after Israel began targeting nuclear energy facilities, military bases, and senior Iranian military officials on Friday.
It’s unclear who is behind Predatory Sparrow. The group clearly fashions itself as a pro-Israel or at least anti-Iran hacktivist group and has targeted companies and organizations in Iran for years. Cybersecurity researchers believe the group has had success in the past and made credible claims.
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.
Issue Details
CVE-2025-23121
A vulnerability allowing remote code execution (RCE) on the Backup Server by an authenticated domain user.
Severity: Critical
CVSS v3.0 Score: 9.9
Source: Reported by watchTowr and CodeWhite.
Note: This vulnerability only impacts domain-joined backup servers.
Veeam Backup & Replication Security Best Practice Guide > Workgroup or Domain?
Affected Product
Veeam Backup & Replication 12.3.1.1139 and all earlier version 12 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
Veeam Backup & Replication 12.3.2 (build 12.3.2.3617)
CVE-2025-24286
A vulnerability allowing an authenticated user with the Backup Operator role to modify backup jobs, which could execute arbitrary code.
Severity: High
CVSS v3.1 Score: 7.2
Source: Reported by Nikolai Skliarenko with Trend Micro.
Affected Product
Veeam Backup & Replication 12.3.1.1139 and all earlier version 12 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
Veeam Backup & Replication 12.3.2 (build 12.3.2.3617)
CVE-2025-24287
A vulnerability allowing local system users to modify directory contents, allowing for arbitrary code execution on the local system with elevated permissions.
Severity: Medium
CVSS v3.1 Score: 6.1
Source: Reported by CrisprXiang working with Trend Micro Zero Day Initiative.
Affected Product
Veeam Agent for Microsoft Windows 6.3.1.1074 and all earlier version 6 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
Veeam Agent for Microsoft Windows 6.3.2 (build 6.3.2.1205)
Veeam Agent for Microsoft Windows is included with Veeam Backup & Replication and available as a standalone application.
Severity - Critical
Description of Problem
A vulnerability has been discovered in NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway). Refer below for further details.
Affected Versions
The following supported versions of NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities:
NetScaler ADC and NetScaler Gateway 14.1 BEFORE 14.1-43.56
NetScaler ADC and NetScaler Gateway 13.1 BEFORE 13.1-58.32
NetScaler ADC 13.1-FIPS and NDcPP BEFORE 13.1-37.235-FIPS and NDcPP
NetScaler ADC 12.1-FIPS BEFORE 12.1-55.328-FIPS
Details
NetScaler ADC and NetScaler Gateway contain the vulnerabilities mentioned below:
CVE ID Description Pre-conditions CWE CVSSv4
CVE-2025-5349 Improper access control on the NetScaler Management Interface Access to NSIP, Cluster Management IP or local GSLB Site IP CWE-284: Improper Access Control
CVSS v4.0 Base Score: 8.7
(CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)
CVE-2025-5777 Insufficient input validation leading to memory overread NetScaler must be configured as Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) OR AAA virtual server CWE-125: Out-of-bounds Read
CVSS v4.0 Base Score: 9.3
(CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)
Elastic Security Labs has observed the ClickFix technique gaining popularity for multi-stage campaigns that deliver various malware through social engineering tactics.
Our threat intelligence indicates a substantial surge in activity leveraging ClickFix (technique first observed) as a primary initial access vector. This social engineering technique tricks users into copying and pasting malicious PowerShell that results in malware execution. Our telemetry has tracked its use since last year, including instances leading to the deployment of new versions of the GHOSTPULSE loader. This led to campaigns targeting a broad audience using malware and infostealers, such as LUMMA and ARECHCLIENT2, a family first observed in 2019 but now experiencing a significant surge in popularity.
This post examines a recent ClickFix campaign, providing an in-depth analysis of its components, the techniques employed, and the malware it ultimately delivers.
Key takeaways
Today was an eventful day thanks to many interesting blog posts, e.g. from my friends at watchTowr. So I thought, why not publish a small quick-and-dirty blog post myself about a story from last week? This blog post may not be of the usual quality, but it was a good time to write it.
Law enforcement authorities from six countries took down the Archetyp Market, an infamous darknet drug marketplace that has been operating since May 2020.
Archetyp Market sellers provided the market's customers with access to high volumes of drugs, including cocaine, amphetamines, heroin, cannabis, MDMA, and synthetic opioids like fentanyl through more than 3,200 registered vendors and over 17,000 listings.
Over its five years of activity, the marketplace amassed over 612,000 users with a total transaction volume of over €250 million (approximately $289 million) in Monero cryptocurrency transactions.
As part of this joint action codenamed 'Operation Deep Sentinel' (led by German police and supported by Europol and Eurojust), investigators in the Netherlands took down the marketplace's infrastructure, while a 30-year-old German national suspected of being Archetyp Market's administrator was apprehended in Barcelona, Spain.
One Archetyp Market moderator and six of the marketplace's highest vendors were also arrested in Germany and Sweden.
In total, law enforcement officers seized 47 smartphones, 45 computers, narcotics, and assets worth €7.8 million from all suspects during Operation Deep Sentinel.
Apple OSes will soon transfer passkeys seamlessly and securely across platforms.
Apple this week provided a glimpse into a feature that solves one of the biggest drawbacks of passkeys, the industry-wide standard for website and app authentication that isn't susceptible to credential phishing and other attacks targeting passwords.
The import/export feature, which Apple demonstrated at this week’s Worldwide Developers Conference, will be available in the next major releases of iOS, macOS, iPadOS, and visionOS. It aims to solve one of the biggest shortcomings of passkeys as they have existed to date. Passkeys created on one operating system or credential manager are largely bound to those environments. A passkey created on a Mac, for instance, can sync easily enough with other Apple devices connected to the same iCloud account. Transferring them to a Windows device or even a dedicated credential manager installed on the same Apple device has been impossible.
Growing pains
That limitation has led to criticisms that passkeys are a power play by large companies to lock users into specific product ecosystems. Users have also rightly worried that the lack of transferability increases the risk of getting locked out of important accounts if a device storing passkeys is lost, stolen, or destroyed.
The FIDO Alliance, the consortium of more than 100 platform providers, app makers, and websites developing the authentication standard, has been keenly aware of the drawback and has been working on programming interfaces that will make the passkey syncing more flexible. A recent teardown of the Google password manager by Android Authority shows that developers are actively implementing import/export tools, although the company has yet to provide any timeline for their general availability. (Earlier this year, the Google password manager added functionality to transfer passwords to iOS apps, but the process is clunky.) A recent update from FIDO shows that a large roster of companies are participating in the development, including Dashlane, 1Password, Bitwarden, Devolutions, NordPass, and Okta.
Hackers have tried to break into the email accounts of a select number of Washington Post journalists, according to an internal Washington Post memo obtained by CNN.
The Post discovered the “possible targeted” hack of its email system last Thursday, prompting the newspaper to reset login credentials for all its employees on Friday, Washington Post Executive Editor Matt Murray said in a memo Sunday to employees.
“Although our investigation is ongoing, we believe the incident affected a limited number of Post journalists accounts, and we have contacted those whose accounts have been impacted,” Murray said.
“We do not believe this unauthorized intrusion impacted any additional Post systems or has had any impact for our customers,” he added.
It was not immediately clear who was responsible for the hack. Journalists are regular targets for both state-backed spies, who are interested in tracking their reporting before it becomes public, and cybercriminals, who are interested in extorting news organizations.
A spokesperson for The Post declined to comment when asked who might be responsible for the hack.
More than 46,000 internet-facing Grafana instances remain unpatched and exposed to a client-side open redirect vulnerability that allows executing a malicious plugin and account takeover.
The flaw is tracked as CVE-2025-4123 and impacts multiple versions of the open-source platform used for monitoring and visualizing infrastructure and application metrics.
The vulnerability was discovered by bug bounty hunter Alvaro Balada and was addressed in security updates that Grafana Labs released on May 21.