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.
helpnetsecurity.com 20.08.2025 - Apple has fixed yet another vulnerability (CVE-2025-43300) that has apparently been exploited as a zero-day in targeted attacks.
CVE-2025-43300 is an out-of-bounds write issue that could be triggered by a vulnerable device processing a malicious image file, leading to exploitable memory corruption.
The vulnerability affects the Image I/O framework used by Apple’s iOS and macOS operating systems.
Apple has fixed this flaw with improved bounds checking in:
iOS 18.6.2 and iPadOS 18.6.2
iPadOS 17.7.10
macOS Sequoia 15.6.1
macOS Sonoma 14.7.8
macOS Ventura 13.7.8
With Apple claiming the discovery of the vulnerability, it’s unlikely that we will soon find out who is/was leveraging it and for what.
But even though these attacks were apparently limited to targeting specific individuals – which likely means that the goal was to delivery spyware – all users would do well to upgrade their iDevices as soon as possible.
Google has issued an urgent security update for its Chrome browser, addressing a critical zero-day vulnerability that is being actively exploited by attackers.
The flaw, tracked as CVE-2025-6554, is a type confusion vulnerability in Chrome’s V8 JavaScript engine, which underpins the browser’s ability to process web content across Windows, macOS, and Linux platforms.
The vulnerability was discovered by Clément Lecigne of Google’s Threat Analysis Group (TAG) on June 25, 2025. According to Google, attackers have already developed and deployed exploits targeting this flaw in the wild, prompting the company to act quickly.
Google on Monday released a fresh Chrome 137 update to address three vulnerabilities, including a high-severity bug exploited in the wild.
Tracked as CVE-2025-5419, the zero-day is described as an out-of-bounds read and write issue in the V8 JavaScript engine.
“Google is aware that an exploit for CVE-2025-5419 exists in the wild,” the internet giant’s advisory reads. No further details on the security defect or the exploit have been provided.
However, the company credited Clement Lecigne and Benoît Sevens of Google Threat Analysis Group (TAG) for reporting the issue.
TAG researchers previously reported multiple vulnerabilities exploited by commercial surveillance software vendors, including such bugs in Chrome. Flaws in Google’s browser are often exploited by spyware vendors and CVE-2025-5419 could be no different.
According to a NIST advisory, the exploited zero-day “allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page”. It should be noted that the exploitation of out-of-bounds defects often leads to arbitrary code execution.
The latest browser update also addresses CVE-2025-5068, a medium-severity use-after-free in Blink that earned the reporting researcher a $1,000 bug bounty. No reward will be handed out for the zero-day.
The latest Chrome iteration is now rolling out as version 137.0.7151.68/.69 for Windows and macOS, and as version 137.0.7151.68 for Linux.
In this post I’ll show you how I found a zeroday vulnerability in the Linux kernel using OpenAI’s o3 model. I found the vulnerability with nothing more complicated than the o3 API – no scaffolding, no agentic frameworks, no tool use.
Recently I’ve been auditing ksmbd for vulnerabilities. ksmbd is “a linux kernel server which implements SMB3 protocol in kernel space for sharing files over network.“. I started this project specifically to take a break from LLM-related tool development but after the release of o3 I couldn’t resist using the bugs I had found in ksmbd as a quick benchmark of o3’s capabilities. In a future post I’ll discuss o3’s performance across all of those bugs, but here we’ll focus on how o3 found a zeroday vulnerability during my benchmarking. The vulnerability it found is CVE-2025-37899 (fix here), a use-after-free in the handler for the SMB ‘logoff’ command. Understanding the vulnerability requires reasoning about concurrent connections to the server, and how they may share various objects in specific circumstances. o3 was able to comprehend this and spot a location where a particular object that is not referenced counted is freed while still being accessible by another thread. As far as I’m aware, this is the first public discussion of a vulnerability of that nature being found by a LLM.
Before I get into the technical details, the main takeaway from this post is this: with o3 LLMs have made a leap forward in their ability to reason about code, and if you work in vulnerability research you should start paying close attention. If you’re an expert-level vulnerability researcher or exploit developer the machines aren’t about to replace you. In fact, it is quite the opposite: they are now at a stage where they can make you significantly more efficient and effective. If you have a problem that can be represented in fewer than 10k lines of code there is a reasonable chance o3 can either solve it, or help you solve it.
Benchmarking o3 using CVE-2025-37778
Lets first discuss CVE-2025-37778, a vulnerability that I found manually and which I was using as a benchmark for o3’s capabilities when it found the zeroday, CVE-2025-37899.
CVE-2025-37778 is a use-after-free vulnerability. The issue occurs during the Kerberos authentication path when handling a “session setup” request from a remote client. To save us referring to CVE numbers, I will refer to this vulnerability as the “kerberos authentication vulnerability“.
A vulnerability has been identified and remediated in all supported versions of the Commvault software. Webservers can be compromised through bad actors creating and executing webshells.
Exploiting this vulnerability requires a bad actor to have authenticated user credentials within the Commvault Software environment. Unauthenticated access is not exploitable. For software customers, this means your environment must be: (i) accessible via the internet, (ii) compromised through an unrelated avenue, and (iii) accessed leveraging legitimate user credential
For the third time in as many months, Apple has released an emergency patch to fix an already exploited zero-day vulnerability impacting a wide range of its products.
The new vulnerability, identified as CVE-2025-24201, exists in Apple's WebKit open source browser engine for rendering Web pages in Safari and other apps across macOS, iOS, and iPadOS. WebKit is a frequent target for attackers because of how deeply integrated it is with Apple's ecosystem.
Did you know there’s widespread exploitation of FortiNet products going on using a zero day, and that there’s no CVE? Now you do.
In April 2021 I participated in Pwn2Own Vancouvver competition as a single player, and successfully demonstrated a 0-day virtual machine escape exploit with code execution on Parallels hypervisor. Today I am finally releasing the exploit source code together with a technical walkthrough video talk that I gave on Zero Day Engineering livestream in November 2021.
Volexity has uncovered active in-the-wild exploitation of two vulnerabilities allowing unauthenticated remote code execution in Ivanti Connect Secure VPN appliances. An official security advisory and knowledge base article have been released by Ivanti that includes mitigation that should be applied immediately. However, a mitigation does not remedy a past or ongoing compromise. Systems should simultaneously be thoroughly analyzed per details in this post to look for signs of a breach.
(0Day) Microsoft Exchange ChainedSerializationBinder Deserialization of Untrusted Data Remote Code Execution Vulnerability