Security & IT News

It's been nearly 20 years since Google revealed Android, which the company described as the first "truly open" mobile operating system, setting Google-powered phones apart from the iPhone's aggressively managed experience. Over time, though, Android has become more aligned with Apple's approach. For the moment, users still have the final say in what software runs on their increasingly locked-down smartphones. Later this year, though, Google plans to seriously curtail that freedom in the name of security. In the coming weeks, Google will officially debut Android developer verification , which will require app makers outside the Play Store to register with their real names and pay a fee to Google. Failure to do so will block their apps from installation (sometimes called sideloading) on virtually all Android devices. Google says this is a necessary evolution of the platform's security model, but upending the status quo could push developers away from Android and risk the privacy of those that remain. This might make your phone a little safer, sure, but it won't stop people from getting scammed. At the same time, it could rob the Android ecosystem of what made it special in the first place. Read full article Comments

It’s hard to overstate the role that Wi-Fi plays in virtually every facet of life. The organization that shepherds the wireless protocol says that more than 48 billion Wi-Fi-enabled devices have shipped since it debuted in the late 1990s. One estimate pegs the number of individual users at 6 billion, roughly 70 percent of the world’s population. Despite the dependence and the immeasurable amount of sensitive data flowing through Wi-Fi transmissions, the history of the protocol has been littered with security landmines stemming both from the inherited confidentiality weaknesses of its networking predecessor, Ethernet (it was once possible for anyone on a network to read and modify the traffic sent to anyone else), and the ability for anyone nearby to receive the radio signals Wi-Fi relies on. Ghost in the machine In the early days, public Wi-Fi networks often resembled the Wild West, where ARP spoofing attacks that allowed renegade users to read other users' traffic were common. The solution was to build cryptographic protections that prevented nearby parties—whether an authorized user on the network or someone near the AP (access point)—from reading or tampering with the traffic of any other user. Read full article Comments

In the first part of this series , I detailed my journey into macOS security research, which led to the discovery of a type confusion vulnerability ( CVE-2024-54529 ) and a double-free vulnerability ( CVE-2025-31235 ) in the coreaudiod system daemon through a process I call knowledge-driven fuzzing . While the first post focused on the process of finding the vulnerabilities, this post dives into the intricate process of exploiting the type confusion vulnerability. I’ll explain the technical details of turning a potentially exploitable crash into a working exploit: a journey filled with dead ends, creative problem solving, and ultimately, success. The Vulnerability: A Quick Recap If you haven’t already, I highly recommend reading my detailed writeup on this vulnerability before proceeding. As a refresher, CVE-2024-54529 is a type confusion vulnerability within the com.apple.audio.audiohald Mach service in the CoreAudio framework used by the coreaudiod process. Several Mach message handlers, such as _XIOContext_Fetch_Workgroup_Port , would fetch a HALS_Object from the Object Map based on an ID from the Mach message, and then perform operations on it, assuming it was of a specific type ( ioct ) without proper validation. This incorrect assumption led to a crash when the code attempted to make a virtual call on an object whose pointer was stored inside the HALS_Object , as shown in the stack trace below: Process 82516 stopped * thread # 8, queue = 'com.apple.audio.system-event' , stop reason = EXC_BAD_ACCESS ( code = 1, address = 0xffff805cdc7f7daf ) frame # 0: 0x00007ff81224879a CoreAudio ` _XIOContext_Fetch_Workgroup_Port + 294 CoreAudio`_XIOContext_Fetch_Workgroup_Port: 0x7ff81224879a +291 : mov rax, qword ptr [ rdi] - 0x7ff81224879d +294 : call qword ptr [ rax + 0x168] 0x7ff8122487a3 +300 : mov dword ptr [ rbx + 0x1c], eax 0x7ff8122487a6 +303 : mov rdi, r13 (lldb) bt * thread # 8, queue = 'com.apple.audio.system-event' , stop reason = EXC_BAD_ACCESS ( code = 1, address = 0xffff805cdc7f7daf ) * frame # 0: 0x00007ff81224879a CoreAudio ` _XIOContext_Fetch_Workgroup_Port + 294 frame # 1: 0x00007ff812249c81 CoreAudio ` HALB_MIGServer_server + 84 frame # 2: 0x00007ff80f359032 libdispatch.dylib ` dispatch_mig_server + 362 frame # 3: 0x00007ff811f202ed CoreAudio ` invocation function for block in AMCP::Utility::Dispatch_Queue::install_mig_server ( unsigned int, unsigned int, unsigned int ( * )( mach_msg_header_t * , mach_msg_header_t * ) , bool, bool ) + 42 frame # 4: 0x00007ff80f33e7e2 libdispatch.dylib ` _dispatch_client_callout + 8 frame # 5: 0x00007ff80f34136d libdispatch.dylib ` _dispatch_continuation_pop + 511 frame # 6: 0x00007ff80f351c83 libdispatch.dylib ` _dispatch_source_invoke + 2077 frame # 7: 0x00007ff80f3447ba libdispatch.dylib ` _dispatch_lane_serial_drain + 322 frame # 8: 0x00007ff80f3453e2 libdispatch.dylib ` _dispatch_lane_invoke + 377 frame # 9: 0x00007ff80f346393 libdispatch.dylib ` _dispatch_workloop_invoke + 782 frame # 10: 0x00007

CVSSv3 Score: 9.8 CVE-2025-15467Parsing CMS AuthEnvelopedData message with maliciously crafted AEAD parameters can trigger a stack buffer overflow. A stack buffer overflow may lead to a crash, causing Denial of Service, or potentially remote code execution. When parsing CMS AuthEnvelopedData structures that use AEAD ciphers such as AES-GCM, the IV (Initialization Vector) encoded in the ASN.1 parameters is copied into a fixed-size stack buffer without verifying that its length fits the destination. An attacker can supply a crafted CMS message with an oversized IV, causing a stack-based out-of-bounds write before any authentication or tag verification occurs. Applications and services that parse untrusted CMS or PKCS#7 content using AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable. Because the overflow occurs prior to authentication, no valid key material is required to trigger it. While exploitability to remote code execution depends on platform and toolchain mitigations, the stack-based write primitive represents a severe risk.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the CMS implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3 and 3.0 are vulnerable to this issue.OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. Revised on 2026-03-13 00:00:00

A headline feature introduced in the latest release of Windows 11, 25H2 is Administrator Protection . The goal of this feature is to replace User Account Control (UAC) with a more robust and importantly, securable system to allow a local user to access administrator privileges only when necessary. This blog post will give a brief overview of the new feature, how it works and how it’s different from UAC. I’ll then describe some of the security research I undertook while it was in the insider preview builds on Windows 11. Finally I’ll detail one of the nine separate vulnerabilities that I found to bypass the feature to silently gain full administrator privileges. All the issues that I reported to Microsoft have been fixed, either prior to the feature being officially released (in optional update KB5067036 ) or as subsequent security bulletins. Note: As of 1st December 2025 the Administrator Protection feature has been disabled by Microsoft while an application compatibility issue is dealt with. The issue is unlikely to be related to anything described in this blog post so the analysis doesn’t change. The Problem Administration Protection is Trying to Solve UAC was introduced in Windows Vista to facilitate granting a user administrator privileges temporarily, while the majority of the user’s processes run with limited privileges. Unfortunately, due to the way it was designed, it was quickly apparent it didn’t represent a hard security boundary, and Microsoft downgraded it to a security feature. This was an important change as it made it no longer a priority to fix bypasses of the UAC which allowed a limited process to silently gain administrator privileges. The main issue with the design of UAC was that both the limited user and the administrator user were the same account just with different sets of groups and privileges. This meant they shared profile resources such as the user directory and registry hive . It was also possible to open an administrators process’ access token and impersonate it to grant administrator privileges as the impersonation permission checks didn’t originally consider if an access token was “elevated” or not, it just considered the user and the integrity level. Even so, on Vista it wasn’t that easy to silently acquire administrator privileges as most routes still showed a prompt to the user. Unfortunately, Microsoft decided to reduce the number of elevation prompts a user would see when modifying system configuration and introduced an “auto-elevation” feature in Windows 7. Select Microsoft binaries could be opted in to be automatically elevated. However, it also meant that in some cases it was possible to repurpose the binaries to silently gain administrator privileges. It was possible to configure UAC to always show a prompt, but the default, which few people change, would allow the auto-elevation. A good repository of known bypasses is the UACMe tool which currently lists 81 separate techniques for gaining administrator p

Websites that authenticate users through links and codes sent in text messages are imperiling the privacy of millions of people, leaving them vulnerable to scams, identity theft, and other crimes, recently published research has found. The links are sent to people seeking a range of services, including those offering insurance quotes, job listings, and referrals for pet sitters and tutors. To eliminate the hassle of collecting usernames and passwords—and for users to create and enter them—many such services instead require users to provide a cell phone number when signing up for an account. The services then send authentication links or passcodes by SMS when the users want to log in. Easy to execute at scale A paper published last week has found more than 700 endpoints delivering such texts on behalf of more than 175 services that put user security and privacy at risk. One practice that jeopardizes users is the use of links that are easily enumerated, meaning scammers can guess them by simply modifying the security token, which usually appears at the right of a URL. By incrementing or randomly guessing the token—for instance, by first changing 123 to 124 or ABC to ABD and so on—the researchers were able to access accounts belonging to other users. From there, the researchers could view personal details, such as partially completed insurance applications. Read full article Comments

While our previous two blog posts provided technical recommendations for increasing the effort required by attackers to develop 0-click exploit chains, our experience finding, reporting and exploiting these vulnerabilities highlighted some broader issues in the Android ecosystem. This post describes the problems we encountered and recommendations for improvement. Audio Attack Surface The Dolby UDC is part of the 0-click attack surface of most Android devices because of audio transcription in the Google Messages application. Incoming audio messages are transcribed before a user interacts with the message. On Pixel 9, a second process com.google.android.tts also decodes incoming audio. Its purpose is not completely clear, but it seems to be related to making incoming messages searchable. Both processes decode audio using all decoders available on the device, including the UDC, which is integrated by the OEMs of most devices, though the bulk of incoming messages use a small number of audio formats. In particular, it is very unlikely that an incoming message will contain audio in formats supported by the Dolby UDC, as Android devices do not provide encoders for these formats, and they are mostly used by commercial media, such as movies and TV shows. Removing the UDC and other uncommonly-used decoders from the 0-click attack surface of Android would protect users from the worst consequences of vulnerabilities in these codecs. The explosion of AI-powered features on mobile phones has the potential to greatly increase their 0-click attack surface. While this trade-off can sometimes benefit users, it is important for mobile vendors to be aware of the impact on security. It is not uncommon for software changes to unintentionally increase the amount of code that can be exercised by attackers remotely. Ongoing review of how new features affect 0 and 1-click attack surfaces coupled with deliberate decisions are necessary to protect users. Bug Discovery Time Frames One surprising aspect of this research was how quickly we found both vulnerabilities used in the exploit chain. Project Zero reviewed the Dolby UDC as a part of a one-week team hackathon, and it took less than two days for Ivan to find CVE-2025-54957. Likewise, Seth found CVE-2025-36934 after less than one day of reviewing the BigWave driver. Of course, it’s easy to forget the effort that went into finding these attack surfaces– the Dolby hackathon required roughly three weeks of preparation to study the entry points of the codec and set-up tooling to debug it, and likewise, reviewing the BigWave driver involved a driver analysis tool that took roughly 4 weeks to develop. We also reviewed other audio codecs with mixed results before reviewing the Dolby UDC. Still, the time investment required to find the necessary vulnerabilities was small compared to the impact of this exploit, especially for the privilege escalation stage. Moreover, a lot of the time we spent finding the UDC bug was a one-time co

With the advent of a potential Dolby Unified Decoder RCE exploit, it seemed prudent to see what kind of Linux kernel drivers might be accessible from the resulting userland context, the mediacodec context. As per the AOSP documentation , the mediacodec SELinux context is intended to be a constrained (a.k.a sandboxed) context where non-secure software decoders are utilized. Nevertheless, using my DriverCartographer tool, I discovered an interesting device driver, /dev/bigwave that was accessible from the mediacodec SELinux context. BigWave is hardware present on the Pixel SOC that accelerates AV1 decoding tasks, which explains why it is accessible from the mediacodec context. As previous research has copiously affirmed , Android drivers for hardware devices are prime places to find powerful local privilege escalation bugs. The BigWave driver was no exception - across a couple hours of auditing the code, I discovered three separate bugs, including one that was powerful enough to escape the mediacodec sandbox and get kernel arbitrary read/write on the Pixel 9. The (Very Short) Bug Hunt The first bug I found was a duplicate that was originally reported in February of 2024 but remained unfixed at the time of re-discovery in June of 2025, over a year later, despite the bugfix being a transposition of two lines of code. The second bug presented a really fascinating bug-class that is analogous to the double-free kmalloc exploitation primitive - but with a different linked list entirely. However it was the third bug I discovered that created the nicest exploitation primitive. Fixes were made available for all three bugs on January 5, 2026. The Nicest Bug Every time the /dev/bigwave device is opened, the driver allocates a new kernel struct called inst which is stored in the private_data field of the fd . Within the inst is a sub-struct called job , which tracks the register values and status associated with an individual invocation of the BigWave hardware to perform a task. In order to submit some work to the bigo hardware, a process uses the ioctl BIGO_IOCX_PROCESS , which fetches Bigwave register values from the ioctl caller in AP userland, and places the job on a queue that gets picked up and used by a separate thread, the bigo worker thread. That means that an object whose lifetime is inherently bound to a file descriptor is transiently accessed on a separate kernel thread that isn’t explicitly synced to the existence of that file descriptor. During BIGO_IOCX_PROCESS ioctl handling, after submitting a job to get executed on bigo_worker_thread , the ioctl call enters wait_for_completion_timeout with a timeout of 16 seconds waiting for bigo_worker_thread to complete the job. After those 16 seconds, if bigo_worker_thread has not signaled job completion, the timeout period ends and the ioctl dequeues the job from the priority queue. However, if a sufficient number of previous jobs were stacked onto the bigo_worker_thread , it is possible that bigo_worker_

Over the past few years, several AI-powered features have been added to mobile phones that allow users to better search and understand their messages. One effect of this change is increased 0-click attack surface, as efficient analysis often requires message media to be decoded before the message is opened by the user. One such feature is audio transcription. Incoming SMS and RCS audio attachments received by Google Messages are now automatically decoded with no user interaction. As a result, audio decoders are now in the 0-click attack surface of most Android phones. I’ve spent a fair bit of time investigating these decoders, first reporting CVE-2025-49415 in the Monkey’s Audio codec on Samsung devices. Based on this research, the team reviewed the Dolby Unified Decoder, and Ivan Fratric and I reported CVE-2025-54957 . This vulnerability is likely in the 0-click attack surface of most Android devices in use today. In parallel, Seth Jenkins investigated a driver accessible from the sandbox the decoder runs in on a Pixel 9, and reported CVE-2025-36934. As I’ve shared this research, vendors as well as members of the security community have questioned whether such vulnerabilities are exploitable, as well as whether 0-click exploits are possible for all but the most well-resourced attackers in the modern Android Security environment. We were also asked whether code execution in the context of a media decoder is practically useful to an attacker and how platforms can reduce the risks such a capability presents to users. To answer these questions, Project Zero wrote a 0-click exploit chain targeting the Pixel 9. We hope this research will help defenders better understand how these attacks work in the wild, the strengths and weaknesses of Android’s security features with regards to preventing such attacks, and the importance of remediating media and driver vulnerabilities on mobile devices. The exploit will be detailed in three blog posts. Part 1 of this series will describe how we exploited CVE-2025-54957 to gain arbitrary code execution in the mediacodec context of a Google Pixel 9. Part 2 of this series will describe how we exploited CVE-2025-36934 to escalate privileges from mediacodec to kernel on this device. Part 3 will discuss lessons learned and recommendations for preventing similar exploits on mobile devices. The vulnerabilities discussed in these posts were fixed as of January 5, 2026. The Dolby Unified Decoder The Dolby Unified Decoder component (UDC) is a library that provides support for the Dolby Digital (DD) and Dolby Digital Plus (DD+) audio formats. These formats are also known as AC-3 and EAC-3 respectively. A public specification is available for these formats. The UDC is integrated into a variety of hardware and platforms, including Android, iOS, Windows and media streaming devices. It is shipped to most OEMs as a binary ‘blob’ with limited symbols, which is then statically linked into a shared library. On the Pixel 9, the UDC is i

On Thursday, a team of researchers led by Microsoft announced that they had discovered, and possibly patched, what they're terming a biological zero-day—an unrecognized security hole in a system that protects us from biological threats. The system at risk screens purchases of DNA sequences to determine when someone's ordering DNA that encodes a toxin or dangerous virus. But, the researchers argue, it has become increasingly vulnerable to missing a new threat: AI-designed toxins. How big of a threat is this? To understand, you have to know a bit more about both existing biosurveillance programs and the capabilities of AI-designed proteins. Catching the bad ones Biological threats come in a variety of forms. Some are pathogens, such as viruses and bacteria. Others are protein-based toxins, like the ricin that was sent to the White House in 2003. Still others are chemical toxins that are produced through enzymatic reactions, like the molecules associated with red tide . All of them get their start through the same fundamental biological process: DNA is transcribed into RNA, which is then used to make proteins. Read full article Comments

As we careen toward a future in which Google has final say over what apps you can run , the company has sought to assuage the community's fears with a blog post and a casual "backstage" video. Google has said again and again since announcing the change that sideloading isn't going anywhere, but it's definitely not going to be as easy. The new information confirms app installs will be more reliant on the cloud, and devs can expect new fees, but there will be an escape hatch for hobbyists. Confirming app verification status will be the job of a new system component called the Android Developer Verifier, which will be rolled out to devices in the next major release of Android 16. Google explains that phones must ensure each app has a package name and signing keys that have been registered with Google at the time of installation. This process may break the popular FOSS storefront F-Droid . It would be impossible for your phone to carry a database of all verified apps, so this process may require Internet access. Google plans to have a local cache of the most common sideloaded apps on devices, but for anything else, an Internet connection is required. Google suggests alternative app stores will be able to use a pre-auth token to bypass network calls, but it's still deciding how that will work. Read full article Comments

Over the past year, Meta has blanketed TV screens around the world with commercials touting the privacy of Whatsapp, its encrypted messenger with a monthly user base of 3 billion people. “It’s private,” one ad campaign featuring the former cast of the Modern Family TV show says. “On Whatsapp, no one can see or hear your personal messages … not even us,” a different series of ads declares. “Serious risks to user data” On Monday, the former head of security for the Meta-owed messaging app filed a federal whistleblower lawsuit that tells a far different narrative. The suit, filed in US District Court for the District of Northern California, recites a litany of purported security and privacy flaws that Meta not only didn’t fix after becoming aware of them, but also kept secret, allegedly in violation of a $5 billion settlement then-Whatsapp parent company Facebook reached with the Federal Trade Commission. The complaint was filed by Attaullah Baig, who became head of WhatsApp security in 2021. Read full article Comments

Extensions installed on almost 1 million devices have been overriding key security protections to turn browsers into engines that scrape websites on behalf of a paid service, a researcher said. The 245 extensions, available for Chrome, Firefox, and Edge, have racked up nearly 909,000 downloads, John Tuckner of SecurityAnnex reported . The extensions serve a wide range of purposes, including managing bookmarks and clipboards, boosting speaker volumes, and generating random numbers. The common thread among all of them: They incorporate MellowTel-js , an open source JavaScript library that allows developers to monetize their extensions. Intentional weakening of browsing protections Tuckner and critics say the monetization works by using the browser extensions to scrape websites on behalf of paying customers, which include AI startups, according to MellowTel founder Arsian Ali. Tuckner reached this conclusion after uncovering close ties between MellowTel and Olostep , a company that bills itself as "the world's most reliable and cost-effective Web scraping API." Olostep says its service “avoids all bot detection and can parallelize up to 100K requests in minutes.” Paying customers submit the locations of browsers they want to access specific webpages. Olostep then uses its installed base of extension users to fulfill the request. Read full article Comments