Critical Android flaw CVE-2026-58868 could allow remote code execution without user interaction on devices running Android 14 through 17.

Google has fixed CVE-2026-58868, a critical Android vulnerability affecting versions 14 through 17. The flaw is a critical Android vulnerability caused by a heap buffer overflow in the onOutputReceived function of FrameDecoder.cpp. The flaw can trigger an out-of-bounds write, potentially allowing a remote attacker to execute arbitrary code on a vulnerable device. Exploitation requires neither user interaction nor additional execution privileges, making it a potential zero-click attack.

“cve-2026-58868 In onOutputReceived of FrameDecoder.cpp, there is a possible out-of-bounds write due to a heap buffer overflow.” reads the advisory. “This could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation.”

Devices receive the fix through security patch level 2026-11-01 or later, depending on manufacturers and carriers. Google is not aware of active exploitation of the flaws in its November 2026 bulletin.

Google’s November 2026 Android security bulletin addresses 216 vulnerabilities, including 23 rated Critical. Two of these flaws, CVE-2026-58876 and CVE-2026-58936, affect the System component and could allow remote code execution without user interaction.

The bulletin also lists five other Critical flaws in the System component. Three could lead to privilege escalation, while two could cause denial-of-service conditions. Another Critical vulnerability affects the Framework component and could also allow remote code execution.

Six Critical vulnerabilities affect the Android kernel. Two involve Bluetooth code, three affect the protected Kernel-based Virtual Machine (pKVM), and one is in the Human Interface Device (HID) component. The most severe kernel flaw could allow a remote attacker to gain elevated privileges without user interaction.

The November 5 patch level also addresses Critical vulnerabilities in MediaTek modem code and a closed-source Qualcomm component. Google’s bulletin lists eight Critical MediaTek modem flaws, while MediaTek’s own November security bulletin details six of them: CVE-2026-20499 and CVE-2026-20545 through CVE-2026-20549.

MediaTek describes these six vulnerabilities as out-of-bounds write flaws caused by missing bounds checks, integer overflow or improper input validation. The company says it is not aware of any active exploitation in the wild.

The Qualcomm issue is tracked as CVE-2026-25285 and affects a closed-source component. Google does not provide further technical details in its bulletin.

One of the critical issues fixed by Google is CVE-2026-58882 (aka SMS of Death), which could allow attackers to remotely disable a phone by sending a specially crafted SMS message. The flaw affects decodeWapPdu, a function responsible for processing WAP Push messages, a type of content delivered through the SMS infrastructure.

The vulnerability is particularly concerning because exploitation reportedly requires no user interaction. An attacker only needs the victim’s phone number to send a malicious message. The message doesn’t appear in the SMS inbox, so the victim may have no indication of what caused the problem.

The issue also raises concerns about the reliability of mobile communications during an attack. According to a technical analysis published on October 29 by security researcher Mark B, a malformed WAP Push message can crash com.android.phone, the Android system component responsible for handling telephony functions. The crash can terminate ongoing calls, including emergency calls.

Tests on several Android phone models reportedly reproduced the crash consistently. The phone can also become stuck in a crash loop because Android retries processing the malicious message whenever the device starts. As a result, the device may continue crashing until the offending message is removed.

There is an important distinction, however. Google’s security bulletin and the CVE record identify the vulnerable decodeWapPdu function, but neither explicitly confirms that CVE-2026-58882 is the same issue described in the researcher’s SMS of Death report. The technical overlap is worth investigating, but the two reports shouldn’t be treated as definitively describing the same vulnerability without further confirmation.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CVE-2026-58868)

Apple warns German Bundestag lawmakers of mercenary spyware attacks; BSI urges victims to assume compromise.

The German government is warning politicians and public figures that they were targeted by government-backed spyware. The warning follows Apple’s notifications, which began reaching iPhones on October 29, according to the federal cybersecurity office, the BSI. The BSI says members of the Bundestag and other notable people got an Apple alert about an attack with so-called mercenary spyware.

“The Federal Office for Information Security ( BSI ) has learned that several members of the German Bundestag and other public figures have received a threat notification from Apple on their devices since October 29, 2026. In the notification, Apple states that it has detected an attack using so-called mercenary spyware . This is commercially developed, advanced spyware that has frequently been used in the past by state actors against specific, targeted individuals.” reads the notice issued by BSI.

“The BSI (Federal Office for Information Security) is unaware whether these notifications indicate actual compromises or merely signal attempted attacks.y “

“Germany’s digital minister, Karsten Wildberger, has confirmed that members of the Bundestag and the federal government received warnings from Apple that their iPhones may have been targeted by spyware.” states the report.

Digital minister Karsten Wildberger confirmed it on ARD’s Bericht aus Berlin on Sunday, saying there had been “a notification from Apple that certain devices may have been compromised” and that members of both the Bundestag and the federal government were among those warned. Digital minister said the BSI had reacted super quickly and written to everyone affected. Wildberger didn’t say how many politicians got the alerts or who they are.

“According to Wildberger, the BSI advised those affected to assume – as a precaution – that their device may have been compromised, because the alerts do not show whether an attack succeeded.” states Euronews.

The German government has not revealed who was targeted. Government spokesperson Stefan Kornelius told the Financial Times that officials are taking the incident and Apple’s warning very seriously. However, he did not say which government members received the alerts or whether Chancellor Friedrich Merz was among them. Apple has not commented on the reports, according to Euronews.

The Apple warning does not provide all the answers. Apple does not identify the governments behind these attacks, nor does it confirm whether a device was actually infected. Germany’s cybersecurity agency, the BSI, also says it is unclear whether the alerts indicate successful infections or only attempted attacks.

Apple says mercenary spyware is far more advanced than common cybercrime tools and that most users will never be targeted. This commercial surveillance software is often used on behalf of governments to spy on specific individuals. It can infect devices through so-called zero-click attacks, which do not require victims to open a message or click a link. In most cases, victims do not notice anything unusual.

Once a phone is compromised, the BSI says, attackers can read messages, including in encrypted apps, and access calls, contacts, calendars and location. They can also turn on the camera and microphone. That’s the whole phone, not a corner of it.

For recipients the BSI’s advice is concrete. Update the operating system immediately, unless you plan a forensic analysis, and consider turning on Lockdown Mode, which makes new attacks harder but doesn’t remove an existing infection. Lockdown Mode limits some features such as message attachments, link previews and FaceTime calls from unknown people, while calls and plain text messages keep working.

If the risk looks high, the BSI suggests replacing the device. That means resetting every account used on it and, to make repeat attacks harder, changing the phone number. Then set a new device passcode, change the passwords of your Apple account and email, and make sure two-factor authentication is on.

The BSI recommends turning on Signal’s registration lock and WhatsApp’s two-step verification, with a new PIN for each. It also advises removing any linked devices you don’t recognize.

Anyone who received a warning can email the BSI Service Center at service-center@bsi.bund.de. This helps the agency work out how many people may be affected. The agency says a genuine Apple warning never asks you to click links, open files, install apps or profiles, or share passwords and codes. These warnings appear on the lock screen, in settings, by email and at the top of account.apple.com after you sign in.

The warnings weren’t limited to Germany. Beirut-based filmmaker Radwan Mortada said on X that Apple had warned him about another attack against his device. He had already been targeted by spyware in 2021.

According to his notice, Apple sent the latest warnings to users in 99 countries. Nobody has publicly identified the attackers or the government that may have ordered the attacks.

The BSI warned German lawmakers that Apple threat notifications may indicate compromised devices and urged recipients to contact the agency and take protective measures.

“Those affected who have received a corresponding warning message from Apple should therefore assume that their device may have been compromised.” BSI concludes. “In a letter dated October 30, 2026, the German Federal Office for Information Security (BSI) alerted members of the German Bundestag to the threat and informed them of necessary measures. Affected individuals were urged to contact the BSI directly .”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Bundestag)

Hackers reportedly hit Ukraine ‘s and Russia ‘s emergency alert apps, sending fake nuclear and attack warnings and raising concerns over public safety.

Ukraine and Russia both said on Sunday night that hackers had compromised their emergency alert apps and used them to send fake warnings about air raids and other attacks, including nuclear threats. The BBC reported the incident, but neither side’s claims have been independently confirmed.

Shortly before 11 p.m. local time (9 p.m. GMT), Ukraine’s widely used Air Alarm app sent the highest-level air raid warnings across the country. Some people, including residents of Kyiv, also received alerts about possible radiation, chemical attacks and street fighting. A message posted on Telegram said the app had likely been targeted by a cyberattack, confirmed there was no radiation threat and urged people to remain calm.

“Shortly before 23:00 local time (21:00 GMT), Ukraine’s widely usedair raid app sent red-level air raid warnings nation-wide, with additional warnings of radiation, chemical attacks, and street fighting sent to some residents in areas including Kyiv.” reports BBC.

“The Air Alarm application has probably been subjected to hostile interference. There is no radiation threat! Stay calm and follow our updates on our channel.” an alert on Telegram read.

The false alerts started at about 22:47 with a message that a radiation threat had been declared in Kyiv. At 22:48 came a message in Russian saying a nuclear alert would cover all of Ukraine and not to worry because “it’s Oreshnik flying”. Oreshnik is a Russian intermediate-range ballistic missile that can carry nuclear or conventional warheads, and Russia has the world’s biggest nuclear arsenal, with President Vladimir Putin repeatedly hinting he’s open to using every weapon available.

Two more alerts arrived at 22:49. One, in Ukrainian, warned of a chemical attack on Kyiv and told people not to go outside, and the other said street fighting was taking place in the city. Red, orange and green messages reached phones, and at 23:53 users got all-clear messages, each declaring one of the Kyiv threats over.

A Ukrainian intelligence body, which the BBC calls the Central Intelligence Agency, said there had been a failure in the app and urged people to use other sources of information. It added that the alerts triggered a radiation hazard signal on loudspeakers in the Lviv region, with no real threat.

“The Air Alert app is supported by the Ministry of Digital Transformation of Ukraine, and informs users instantly about the beginning and end of defence alerts. The ministry said it temporarily disabled the app for maintenance after it had “apparently been compromised”. states BBC.

“While the false alerts were quickly contained, cybersecurity experts suggested it was a new line in apparent Russian cyberattacks.”

The temporary shutdown of the Air Alert app also carries significant risks, even if it lasts only a short time. During an outage, users may not receive timely warnings about incoming attacks, leaving them with less time to reach shelters or take protective measures. This is particularly dangerous in a country where missile and drone attacks can happen with little warning.

The incident also highlights a difficult security trade-off: disabling a compromised alert system may prevent attackers from spreading false warnings, but it can temporarily remove a critical channel for delivering real emergency information. Any shutdown therefore needs reliable backup channels, such as sirens, official messaging services and other emergency communication systems.

Regional leaders tried to calm people. Svitlana Onyshchuk, head of the Ivano-Frankivsk region, said everything was calm, even though the app had shown a red-level alert for her region from 22:50 to 23:57. Natalya Zabolotna, her counterpart in Vinnytsia, confirmed a cyberattack on the app and warned people not to click the link in the message, which could be phishing.

Ukraine’s Centre for Countering Disinformation has advice for when the app isn’t working: turn on smartphone notifications, pay attention to sirens, and read only official sources. Oleksander Merezhko, chair of the foreign affairs committee in the Ukrainian parliament and a member of President Zelensky’s Servant of the People party, said the attack caused no panic. Ukrainians, especially in Kyiv, are used to practically non-stop alerts, he told the BBC, and the message in Russian aroused suspicion at once. The attackers picked a language that gave them away.

A few hours later, Russia’s ministry of emergency situations said its own app had suffered “a massive cyberattack” that sent fake information to the public. Ukrainian outlet UNN reported that the hack sent fake nuclear threat alerts inside Russia, citing Atesh, a partisan Ukrainian group operating in Russian-held territory. A screenshot Atesh shared on Telegram, described as purported, claimed nuclear warheads mounted on Ukrainian P1-Sun attack drones had been launched at all regions of Russia, opened with a “risk of getting lively” warning and told residents to stock up on three weeks of food and hide. The alert also had profanities.

Russia said it was still restoring the app but claimed the hack had not affected its wider alert system. It said people could still receive warnings through sirens, loudspeakers, text messages, TV and radio. The false alerts appeared minutes before a local ceasefire in Ukraine’s Kherson region ended on Sunday night. The truce had allowed civilians to leave Russian-occupied Oleshky. Although the fake warnings were quickly stopped, experts see the attack as a worrying escalation.

“I think it’s the first time it’s happened to an official Ukrainian information app, but I suspect it won’t be the last,” Herbert Lin, a senior research scholar for cyber policy and security at Stanford University, told BBC World Service’s Newsday programme.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Ukraine)

SMS of Death lets attackers crash Android call services with a hidden, zero-click message, blocking phone calls, even emergency calls too.

A specially manipulated SMS message is enough to crash Android’s phone service, interrupt ongoing calls, and temporarily render the smartphone unusable. The attack requires no interaction from the victim and can even compromise the ability to contact emergency services.

The vulnerability, dubbed the SMS of Death, is bringing renewed attention to the security of the messaging system in Android smartphones. The issue, documented by independent researcher Mark Blaszczyk, allows a remote attacker to cause a disruption in phone service by sending a single, specially crafted WAP Push message.

WAP Push (Wireless Application Protocol Push) is a particular message transmitted over the mobile network, generally in the form of a binary SMS, which contains structured data and is processed automatically by the smartphone without requiring user intervention. Unlike a traditional SMS, it can carry notifications, links to Internet resources, and configurations for mobile services.

The most worrying aspect is the execution method. It’s a zero-click attack, in which the recipient doesn’t have to open the message, select a link, or authorize any action. The content is automatically processed by the operating system and can cause the process responsible for phone functionality to crash.

The vulnerability affects “WapPushOverSms“, an Android framework component located in the “frameworks/opt/telephony” path, responsible for interpreting and managing WAP Push messages received by the device.

The technical cause lies in the incorrect handling of a numeric value used during message interpretation. Specifically, the “decodeWapPdu()” function, the researcher explains, reads the length of the WSP header through a value encoded as “uintvar” , initially returned as a 64-bit number. The value is subsequently converted to a 32-bit integer without prior range checking. This operation can transform a seemingly valid number into a negative value, which is then used to determine the size of an array. The consequence of this is a “NegativeArraySizeException” exception, thrown when Android attempts to allocate a negative-sized array. The exception is not handled correctly in the processing path and causes the “com.android.phone” process, responsible for telephony functions, to terminate.

The researcher demonstrated that a five-byte WSP header can generate the value “-2147483648“, which is sufficient to trigger the issue. Therefore, it is not necessary to transmit particularly large amounts of content to cause the issue.

“A 5-byte uintvar of 88 80 80 80 00 decodes to 0x80000000. Cast to a signed 32-bit int, that is -2147483648. Allocating new byte[-2147483648] throws an uncaught NegativeArraySizeException on the telephony main thread, killing com.android.phone:” reads the analysis.

An invisible attack that also interrupts emergency calls

The message is transmitted as a data SMS via the WAP Push channel on port 2948. Unlike a regular SMS, it isn’t displayed in the message inbox and doesn’t generate a user-recognizable notification. The sender’s number isn’t normally visible in the conversation, and when the device receives the message, Android automatically starts processing it. A crash in the phone process causes a temporary loss of connectivity and interrupts active voice calls, including those to emergency services.

According to the researcher’s published evidence, each message processing can cause a disruption in telephone service lasting about one to two seconds, during which the component is rebooted. However, the problem can become much more serious if the message is processed repeatedly.

One of the most significant aspects of SMS of Death is the ability to transform a simple crash into a persistent Denial of Service condition. The malicious message can remain in the incoming SMS queue and be reprocessed during subsequent delivery attempts. The telephone operator’s retransmission mechanism can also contribute to a repeat of the event, causing further service disruptions.

The researcher reports observing intermittent crashes for up to a week after receiving a single message. Sending around twenty specially crafted messages can render the device unusable for an extended period. In more severe cases, the phone process can continue to crash during system startup, triggering a condition similar to a boot loop. Recovery may require using the Android Debug Bridge (ADB) on a computer, directly intervening in the queue of messages waiting to be processed. For a typical user, this is far from a simple procedure.

A threat to communications availability

SMS of Death demonstrates how a cyberattack doesn’t necessarily have to involve information theft, code execution, or device control to have significant consequences. In this case, the target is phone service availability, a crucial feature especially when contacting emergency services. The ability to interrupt communications without any user interaction makes this vulnerability particularly sensitive. To reduce exposure, it’s important to check the Android security patch level installed and apply available updates, paying particular attention to devices no longer receiving manufacturer support.

Testing conducted by Mark Blah has shown that the issue is reproducible on several devices, including the Google Pixel 9 and Samsung smartphones from the Galaxy and Galaxy A families. The vulnerable code appears to be present on Android versions ranging from Android 12 to Android 17. However, the availability of the fix is ​​not uniform across all generations of the operating system.

According to documentation published by the researcher, Google has distributed a fix via the October 2026 security update for Android 14, 15, 16, and 17. Older devices, such as those running Android 12 and 13, may remain exposed if they do not receive corrective updates.

About the author: Salvatore Lombardo (X @Slvlombardo)

Electronics engineer and Clusit member, for some time now, espousing the principle of conscious education, he has been writing for several online magazine on information security. He is also the author of the book “La Gestione della Cyber Security nella Pubblica Amministrazione”. “Education improves awareness” is his slogan.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, SMS of Death)

A critical Signal flaw could keep calls active after hang-up, exposing microphone or camera. Update to a fixed version immediately.

A critical vulnerability, tracked as CVE-2026-113380 (CVSS score 9.3 of 10), in Signal ’s calling library could allow a malicious caller to interfere with call termination, potentially leaving the victim’s microphone and camera active after they believe the conversation has ended. The flaw affects versions before 2.72.0 of the library RingRTC, which the messaging app uses to provide voice and video calling.

It highlights a security problem that deserves attention beyond a single messaging application: ending a call should be an immediate control action, not something that can be delayed by traffic coming from the other participant.

According to the technical report published on GitHub, the vulnerability stems from how RingRTC handles events in the finite-state machine (FSM) that manages a call. The application places events in a queue for processing, but a malicious peer can flood that queue with events and prevent the local hang-up operation from being handled in a timely manner.

“A local hang-up is not a kill switch: it is just one more event placed at the back of the call’s finite-state-machine event queue. The remote peer is trusted with that queue — there is no rate limit on peer-originated events and no priority lane for hang-up.” reads the technical report published on GitHub, “Flood the queue with junk and the hang-up waits behind attacker noise forever, so the call (microphone, possibly camera) is never torn down.”

People expect that pressing the hang-up button ends the call and turns off the microphone and camera. But if the system is too busy processing other events, it may delay the command to end the call, leaving the audio or video active longer than expected.

The report explains that someone taking part in a call could exploit this weakness by sending enough events to overload the system’s queue. This could stop the other person from ending the call properly, potentially keeping the microphone active and possibly the camera too.

The underlying problem is not that Signal’s end-to-end encryption has been broken. Rather, it concerns the handling of call state and the reliable termination of a session. Encryption cannot protect users from every flaw in the software that controls when a communication session begins or ends.

The vulnerability concerns RingRTC versions earlier than 2.72.0 and can affect Signal clients that embed a vulnerable build of the library. According to the CSIRT Toscana advisory, the affected application versions are Signal for Android before 8.27.0, Signal for iOS before 8.30.0, and Signal Desktop before 8.29.0.

The official RingRTC fix and the comparison between versions 2.71.0 and 2.72.0 document the software changes. Users should install the latest available Signal release for their device rather than relying on the library version alone.

The technical report also includes a conceptual Python proof of concept. It models the difference between a queue in which a flood can bury a hang-up event and one in which critical events receive priority. The demonstration is synthetic and offline, with no network activity or real calls, so it illustrates the underlying logic rather than providing a working exploit.

This is an important distinction. The fact that the vulnerability has been made public does not mean attackers are already exploiting it. However, because it could expose private conversations, updating Signal promptly is a sensible precaution, especially for people who use it to discuss sensitive matters.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, mobile)

Citizen Lab confirmed Pegasus on a Serbian rector’s iPhone 6 days before elections, raising the known civil society spyware target count to 16.

The Citizen Lab published a research note confirming that the iPhone of Vladan Đokić, Rector of the University of Belgrade, was infected with NSO Group’s Pegasus spyware sometime in 2026. The infection used a zero-click exploit, meaning Đokić did nothing to trigger it. No tap, no opened file, nothing.

“In collaboration with the SHARE Foundation, we found with high confidence that Professor Vladan Đokić, Rector of the University of Belgrade, and prominent supporter of the Serbian student movement, was hacked with NSO Group’s Pegasus spyware in 2026.” states Citizen Lab.

Đokić became a prominent figure in Serbia’s student-led pro-democracy movement after refusing to facilitate a government crackdown on protesters. Serbian authorities raided his offices on March 31, seizing computers and servers. The Citizen Lab found the infection with high confidence and describes the investigation as ongoing.

The timing raises questions. The discovery came just six days before Serbia’s snap parliamentary elections on October 25. Until September, Đokić had been publicly named as a possible candidate to lead the Student List. Since he spoke out against the crackdown, pro-government media have repeatedly attacked him.

Citizen Lab explained what a Pegasus infection means. Once installed, the spyware can give its operator the same access to a device as its owner. This includes private and encrypted messages, and the ability to turn on the microphone and camera without the owner’s knowledge.

“With the assistance of the SHARE Foundation, the Citizen Lab analyzed forensic artifacts collected from Vladan Đokić’s Apple iPhone at his request and with his consent.” reads the report. “We found with high confidence that it was infected with NSO Group’s Pegasus spyware in 2026. The infection leveraged a zero-click exploit.”

In a statement published by the university, Đokić called the spyware “another attempt of intimidation.” He called for an independent investigation, the public release of its findings, and criminal prosecution of those responsible.

“Additionally, we note that Rade Bajić, who, as a prosecutor, investigated official corruption in a failed project in Belgrade, received an Apple Threat Notification.” continues Citizen Labs.

The Citizen Lab also flagged Rade Bajić, a senior prosecutor who worked on the “Generalštab” case, a corruption investigation into the removal of heritage protections from a Belgrade site to clear the way for a luxury development backed by a company linked to Jared Kushner, President Trump’s son-in-law. Bajić says he was removed from the investigation in November 2025 without explanation, and spoke at a student protest in February denouncing political interference in the case.

He received an Apple Threat Notification on August 13 and a reminder on August 27. The Citizen Lab treats this as a high-confidence indicator that his device was likely targeted with mercenary spyware. Forensic analysis of his device is still ongoing and no confirmation of infection has been published yet.

These two cases bring the known total to at least 16 members of Serbian civil society targeted or infected with commercial spyware in 2026. In September, the SHARE Foundation, with support from Citizen Lab and Amnesty International, reported an earlier wave of attacks. The victims included a student protester confirmed to have been infected with Pegasus, opposition party members, and local officials. Those cases occurred around the period leading up to Serbia’s March local elections. The latest confirmed case was discovered just six days before the October parliamentary elections.

Serbia’s security service dismissed the September reports as purely trivial sensationalism and said it operates within Serbian law. Citizen Lab did not identify who was behind the attack on Đokić’s phone. Pegasus is sold only to governments and state agencies, which limits the number of possible operators.

If you received an Apple Threat Notification, treat your device as compromised until a technical expert confirms otherwise. In Serbia, contact the SHARE Foundation. Everywhere else, Access Now’s Digital Security Helpline supports journalists, human rights defenders, and activists. Enable Lockdown Mode on your iPhone immediately, keep iOS updated, and get your close contacts and colleagues screened as well.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Pegasus)

Android trojan Hirudo replaces genuine banking apps with modified versions to steal credentials and bypass security checks, enabling financial fraud.

ThreatFabric researchers detailed a new Android banking trojan called Hirudo that takes a genuinely different approach to defeating banking security. Instead of throwing a fake login screen over the real app, it uninstalls the real app and puts a modified copy in its place.

“What sets it apart is the lengths its operators go to once a bank is in their sights: rather than overlaying a fake screen on top of the genuine banking app, Hirudo attempts to replace the banking app itself with a modified copy that quietly disables the bank’s own security checks from the inside.” reads the analysis published by ThreatFabric.

Eight Indonesian banking apps from seven banks already have specially designed replacements ready. The malware’s credential-stealing code also targets users in Indonesia, China, India, Mexico, Morocco, and Thailand.

Hirudo is delivered as a second app hidden inside a convincing dropper. The dropper looks like a legitimate shopping app, short drama platform, or adult video service. It loads real content through a WebView to make the app look genuine. If it detects a banking app on the device and finds that Hirudo is not yet installed, it displays a fake in-app update prompt.

One dropper analysed by researchers goes a step further. During installation, it creates a deliberately broken VPN connection that cuts off the device’s internet access while Hirudo is installed. This does not fully bypass Google Play Protect, but ThreatFabric believes the technique is designed to weaken online reputation checks and code analysis while the malicious APK is being installed. Hirudo is then installed as a separate app from the dropper. Before it can carry out its malicious activities, it must obtain its own Accessibility and notification permissions.

When the payload detects a target banking app, it checks the app’s signing certificate against a stored reference, then shows a fake update prompt and immediately opens Android’s uninstaller without waiting for the user to tap confirm. It downloads the patched replacement in parallel.

“Hirudo keeps a registry of 42 financial apps, but only eight Indonesian apps, across seven banks, have dedicated replacement downloads. For these, the RAT detects the installed banking app through Accessibility, checks its signing certificate against a stored reference, then shows a fake “update” prompt.” reads the analysis. “It opens Android’s uninstaller for the genuine app without waiting for the user to tap, and downloads the bank-specific replacement in parallel.”

The replacement keeps the original package name and version number, but it’s signed with a public test key rather than the bank’s real certificate. Android won’t install it as an update over a properly signed app, which is why the original has to go first. That requirement is a real constraint: the victim can interrupt it. But if they don’t, what follows is clever enough to matter.

The bank’s original code remains almost unchanged. Only one line is added to the app’s Application class. This line loads a built-in hooking engine when the app starts. The engine uses two open-source frameworks: YAHFA to modify Java methods and Dobby to modify native functions. It activates only when it finds a trigger file created by the RAT on the device. Without this file, the modified banking app appears harmless.

Once activated, the engine runs inside the banking app and controls how it responds to security checks. If the app asks for its signing certificate, the engine returns the genuine one. If it checks which accessibility services are enabled, the engine returns an empty list. It also removes the flag that blocks screenshots, allowing the attacker to view and record the banking screen remotely.

Play Integrity checks are sent over plain HTTP to a server controlled by the operator, which returns an acceptable result. Researchers highlight two important points. First, the keybox used for attestation has been leaked publicly, and at least two of its certificates are already on Google’s revocation list. Second, a valid Play Integrity response does not prove that the app has not been tampered with. In this case, the response was relayed through the operator’s server rather than generated through a genuine integrity check.

The lures don’t spread through side-loaded APKs from shady forums. They’re served from Amazon CloudFront, tied to campaign tracking through OpenInstall attribution, and linked to Meta Pixel IDs connecting specific branding to specific campaign groups. Some download routes were still live through late September and into October 2026. The operator APK-processing panel, which rebuilds dropper and payload APKs into finished lures and patched banking apps, was reachable without authentication, with cloud storage buckets and credentials left exposed, a significant operational security failure that helped ThreatFabric map the operation.

Records from August 2026 included thousands of credential entries split across campaign groups, device records, lock-screen history, and financial profiles with monthly income and risk score fields. Operators annotated records they considered “phished,” which signals a workflow built to convert stolen data into actual fraud rather than just collect it.

ThreatFabric’s conclusion on the defensive side is worth reading directly: “once an app can be replaced, its locally produced signals — signature, accessibility list, integrity verdict — must be treated as attacker-influenced and verified server-side.” A valid Play Integrity verdict from a relayed request is not a green light. A clean accessibility list from a patched app is not evidence there’s no controlling service running. The signals the app produces locally are no longer trustworthy, and any bank relying on them as blockers rather than inputs to server-side risk scoring is running on assumptions this trojan was designed to exploit.

“Hirudo marks a deliberate escalation in how Android bankers approach hardened applications. By moving its tampering inside the target app, the operation shifts the contest from the device to the application’s own integrity checks, and from a bespoke patch to a reusable engine that can be retargeted at other apps and regions.” concludes the report. “The defensive conclusion is consistent across every capability we examined: signals produced locally by an app that may have been replaced cannot be trusted on their own.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Android malware)

Bitdefender finds Midnight Mimosa, preinstalled Android malware on cheap MediaTek phones that fakes ad clicks, drops apps and builds a proxy botnet.

Bitdefender researchers discovered a campaign called Midnight Mimosa involving preinstalled Android malware on low-cost phones from different brands that use MediaTek platforms. The malware is built into the device firmware and may be hidden in different system packages depending on the model. It is already on the phone before the owner turns it on for the first time and cannot be removed.

The malware has system-level privileges, allowing it to install and remove apps, grant permissions and download code from a remote server without the user’s knowledge. This gives its operators control over the infected devices and allows them to use them for different purposes, including building a large botnet. The campaign appears to be mainly financially motivated.

“This scheme is likely designed mainly to generate revenue. The operators carry out ad and click fraud, collect device and installed-app information, and turn infected devices into residential-proxy relay nodes, making them zombies in botnets.” Bitdefender states. “This creates an additional revenue stream, as access to botnets for DDoS attacks is a hot commodity. The larger the botnet, the more money they can charge.”

The money comes from several places. The operators run ad and click fraud, collect device and installed-app information, and turn infected phones into residential proxy relay nodes. Botnet access for DDoS attacks is a hot commodity, and the larger the botnet, the more they can charge.

The system app doesn’t register the fraudulent clicks itself. The revenue comes from cover apps it drops onto the phone, such as real-looking weather, app-lock, note and OCR apps. Those load genuine ads through a legitimate ad SDK, while an invisible window on top registers ads being shown, and the ad network credits the cover app, not the hidden component.

Bitdefender spotted it through behavior, not a signature. A package called com.android.system.lite looked like a core Android component but didn’t act like one: it repeatedly enabled sensitive access, including Accessibility and Notification Access, and silently installed and removed unrelated apps. It had no icon and an app label of just “System”, and its real machinery sat in a native library that only woke up at runtime.

“The investigation began with App Anomaly Detection, a technology in Bitdefender Mobile Security, which flagged com.android.system.lite: a package carrying the name and appearance of a core system component while behaving like nothing of the sort.” continues the cybersecurity firm. “Most mobile security still runs on a single assumption: scan an app, and if it’s deemed clean, it’s safe. Bitdefender’s App Anomaly Detection (introduced in 2023) exists because, in practice, the theory often doesn’t hold up. Apps can sit dormant and turn hostile weeks later, sometimes only if certain conditions are met (targeted malware). Such apps can pass every static check, only to later pull their real payload from a server or cleverly unpack it from native code.”

The first package discovered was only one version of the malware. The same core code was also found in packages named com.android.sys.prot, com.android.sys.gmsprot and com.android.sys.bcprot, with different digital signing certificates. Bitdefender explains that the main threat is not the package name itself, but the malicious code shared by all these versions.

The malware can silently install at least 32 different apps disguised as useful tools, including app lockers, weather apps, file managers, icon tools, OCR tools and audio editors. It gives itself access to Android’s Accessibility, Notification Access and SMS read/write features. Bitdefender did not observe the malware using the notification or SMS permissions, but the operators could activate them when needed. The malware also repeatedly enables and disables these permissions after short periods.

The install trick is neat and nasty. Before dropping a payload app, the malware disables the Google Play Store app, apparently to dodge Play Protect, then re-enables it afterward, and a safety net turns it back on when the user is present so nothing looks odd. It can also record Google Play as the install source for apps that never came from Play, though real Play apps carry a server-side signature block called frosting, and the forged ones don’t have it.

Under the hood, a native library called libeasy.so decrypts a hidden framework, which fetches a remote configuration from a command server disguised as a weather API. The framework then loads further plugins that run the in-process ad fraud and the silent installs, and it can update itself with new code from the server. The plugins and payloads travel as files with misleading extensions, like JARs named .o and APKs served as .png, so a sample examined offline often holds no active payload at all.

The ad fraud is tunable. The plugin shows ads in full-screen activities and overlays nobody asked for, triggered when the screen turns on or by commands from the operator. It marks those surfaces as secure, so they don’t show up in screenshots or screen recordings, and it fires synthetic clicks with daily caps and timing limits to look organic. The cover apps act as peers in an ad mesh, so one app can drive impressions that another app renders and gets paid for.

One payload app, com.mobile.applock.en, is something else entirely: a single-purpose TCP proxy with no ads and no interface that enrolls the phone as a relay node.

“Our insights reveal these payload applications being installed and removed repeatedly on the same devices. This churn helps the operation reduce the length of time a payload remains visible in the app list, rotate hashes, and change the active monetization module, while the underlying system component stays in place.” states the report. “Beyond generating revenue for operators, the devices can be turned into residential-proxy relay nodes, essentially becoming part of botnets and potentially helping launch DDoS attacks when called upon.”

It connects to a control host over raw TCP on port 6000, rotates across four domains, and pipes traffic between the controller and whatever target the server names. Bitdefender notes an erratum here: the IP it first reported as the control server turned out to be a sinkhole, not a command server.

The campaign relays on Google Play to target Android users. Thirteen apps published there talk to the same servers, under at least two developer accounts and thirteen different signing certificates. They passed Play review, they provide some real function, and they also show ads outside the app, sometimes while the phone sits idle. They don’t have the privileges of the preinstalled packages, but Bitdefender calls them dangerous anyway.

Scale is large. Over roughly two years, the family showed up on thousands of unique devices in more than 150 countries, led by Mexico, France and Italy, followed by the United States, Germany, Brazil and Spain. Two separate regional centers with a long tail behind them is what hardware moving through international online marketplaces looks like, not a single carrier’s channel.

“As we mentioned earlier, Zediel-signed firmware is not the only way malware is shipped. The operators use many other devices, most of them likely visual clones of real phones, to embed the same malware.” states the report. “Beyond the generic user agent strings, many of the affected models are counterfeit devices that borrow flagship names they have nothing to do with. Fake iPhones include: “i17 Pro Max”, “i16_Pro_Max”, or “17_Pro_Max”, and an “iPadAirPro” for the tablet line.“

The phones are often fake models. Some report names such as “i17 Pro Max,” “S25 Ultra” and “Note 18 Ultra,” even though these models do not exist. Others use fake codes that make them look like real Samsung devices. The two most common models are from budget brands: Doogee’s S200 X and Cubot’s KINGKONG X. A public discussion on the XDA forum also describes users finding a hidden com.android.sys.* package that returned under a different name after they removed it.

Who installed the malware? Many affected phones use firmware signed with certificates linked to Shenzhen Zediel. Bitdefender confirmed that these certificates were used to sign firmware on affected devices, but it could not establish how the malware got there or whether the certificate owner knew about it. Other infected phones do not use Zediel-signed firmware, so the malware could have been added by a device manufacturer, a firmware integrator, a logistics partner or another party in the supply chain.

The activity also has a longer history. Bitdefender linked the malware’s infrastructure, through shared domains, to Dr.Web’s Android.Joker family in 2021 and its Android.Phantom and Click families in 2025. The operation now also includes residential proxyware. For defenders, the key is to detect the malware’s core code and command server, and to monitor its behavior. Blocking specific package names is not enough because the attackers can easily change them.

Clearing an infected phone isn’t something an owner can do by uninstalling, because the root component sits in the system partition. It takes firmware-level cleanup or disabling the component over ADB, and neither is realistic for most people who own these phones. The durable fix sits with the vendors and marketplaces that ship and sell the affected firmware.

The two defenses users rely on, store review and the ability to uninstall, don’t apply here, which is why Bitdefender calls preinstalled malware a different threat class.

Users cannot rely on app store checks or simply uninstalling the malware. Bitdefender considers preinstalled malware a separate category of threat for this reason.” concludes the report. “Preinstalled malware is a different threat class. Every user-facing defense assumes the owner is in the loop at installation: the install prompt, the store review, Play Protect, and the ability to uninstall afterwards.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, preinstalled Android malware)

Apple patched zero-day CVE-2026-86950 in CoreGraphics, exploited in sophisticated targeted attacks against specific iOS users.

Apple has released security updates for iOS, iPadOS and macOS to fix a zero-day vulnerability, tracked as CVE-2026-86950, in CoreGraphics that may have been exploited in attacks against specific individuals. The flaw is an out-of-bounds write that can lead to arbitrary code execution when the system processes a specially crafted file.

The vulnerability affects iOS 26.7 and earlier versions before iOS 27, as well as iPadOS 26.7 and earlier and supported versions of macOS Tahoe and macOS Sequoia. Apple released iOS 26.7.1, iPadOS 26.7.1, macOS Tahoe 26.7.1 and macOS Sequoia 15.8.1 to address the issue.

“Processing a maliciously crafted file may lead to arbitrary code execution. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 27.” reads Apple’s advisory. “Description: “An out-of-bounds write issue was addressed with improved bounds checking.”

The more important sentence, however, is the one that turns this from another vulnerability disclosure into a security incident worth watching. Apple says it knows of a report that the flaw may have been exploited in an “extremely sophisticated attack against specific targeted individuals” running versions of iOS before iOS 27.

Apple hasn’t disclosed who was targeted, how many people were affected, whether the attacks succeeded, or when exploitation started. It also hasn’t explained how attackers delivered the malicious files. That leaves an important part of the attack chain unknown.

CoreGraphics handles graphics and rendering functions across Apple’s operating systems, including processing content such as images and PDFs. Attackers can trigger the flaw by tricking the victim into opening a malicious file sent through a web page, an email attachment, or a messaging application, However, Apple hasn’t confirmed any of these delivery methods for CVE-2026-86950.

That distinction matters. A crafted file doesn’t need to look like an obvious executable for a vulnerability in a system component that processes content to become useful to an attacker. The security boundary can be crossed while the operating system is simply doing what it’s designed to do: interpreting a file.

Meta Product Security discovered and reported the vulnerability to Apple. The involvement of Meta is particularly interesting because the company has previously identified attacks involving Apple vulnerabilities and targeted users of its messaging platforms.

Last year, WhatsApp disclosed that a vulnerability in its iOS and macOS applications, tracked as CVE-2025-55177, was likely chained with Apple’s ImageIO zero-day CVE-2025-43300 in zero-click attacks against fewer than 200 users. There is no evidence that the new CoreGraphics vulnerability was used through WhatsApp, and SecurityWeek reported that it was seeking clarification from Meta.

That uncertainty is worth keeping intact. It would be easy to connect the two incidents simply because Meta reported the new Apple flaw, but the available information doesn’t establish that link.

The patch itself is also interesting because Apple has fixed the vulnerability in the older operating system branches rather than treating the move to the latest major release as the only answer. Apple released iOS 26.7.1 and iPadOS 26.7.1 for supported iPhones and iPads, while macOS Tahoe 26.7.1 and macOS Sequoia 15.8.1 address the problem on Macs.

CISA had not yet added CVE-2026-86950 to its Known Exploited Vulnerabilities catalog.

This isn’t the first Apple vulnerability this year to carry an exploitation warning. In February, Apple patched CVE-2026-20700, a memory corruption issue in the dynamic linker, or dyld, after reporting that it had been weaponized in sophisticated attacks.

The pattern is more relevant than the individual CVE. Attackers targeting a small number of people don’t need a vulnerability that affects millions of devices indiscriminately. They need a reliable flaw in a component that processes content, a way to get that content in front of the target, and an exploitation chain that can survive the platform’s security controls.

The practical response is straightforward. Organizations managing Apple devices should identify systems still running affected releases and prioritize the relevant security updates, particularly where devices belong to executives, researchers, journalists, government personnel or other users who may face targeted attacks.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Apple)

RatHat combines AI-driven screen control, Android debugging abuse and advanced credential theft to give attackers deep control of infected phones.

RatHat is the new Android trojan you should know about. Zimperium researchers just published a breakdown of a strain they’ve traced to China-based operators, and what makes it different isn’t the credential theft, which is standard fare by now. It’s what it does to get there.

It starts the way most mobile fraud does: a text message or a shady ad pointing to a fake app store. Once someone installs the APK, the malware doesn’t just ask for permissions and hope.

“RatHat is primarily distributed through deceptive phishing sites promoted via malvertising, smishing campaigns, and third-party forums, luring victims into manually downloading malicious APKs that appear to be legitimate apps” reads the report published by Zimperium.

The dropper hides its payload in two encrypted files. Both use the same simple decoding process: skip a 24-byte header, read the data length, apply a basic XOR and subtraction operation to each byte, and then decompress the result with Gzip. The second stage is a DEX file loaded directly into memory through reflection. It contains the code needed to unpack and install the final malware.

The droppers also abuse native Android SessionInstaller APIs to get around restrictions on app installation and Accessibility Services, allowing the malware to install its payload and access protected APIs.

RedHat uses four anti-analysis techniques. First, it modifies the ZIP container in ways Android ignores but tools such as unzip and apktool cannot handle correctly. Second, it uses a 61 MB AndroidManifest.xml containing unusual data blocks that can make analysis tools crash or run out of memory. Third, the DEX code contains invalid pseudo-instructions that break disassemblers even though Android can still run the app. Finally, strings are encrypted using StringFog and an additional custom scheme that swaps bytes and applies a 16-byte XOR key.

The malware also checks for debuggers, ptrace, debug settings, Frida, Xposed, root indicators and emulators, making analysis much harder.

The malware first tries to gain access to Android’s Accessibility Service. It then uses that access to silently enable Developer Options and Wireless Debugging on the victim’s phone. It doesn’t need a second device, a cable, or a user to manually approve a USB debugging connection.

This is the most interesting part of the attack. RatHat uses the same Accessibility Service to read the ADB pairing code directly from the phone’s screen. It then pairs with the phone’s own debug interface without any user interaction. In simple terms, the malware tricks the phone into giving itself control.

The malware then places two disguised native binaries in /data/local/tmp. Both are written in Go. One, liblocal-service.so, works as a shell command tool and handles persistence, battery settings and permission changes that are not visible in the main app code. The other, libmedia_codec.so, is a modified FRP reverse-proxy client. Its role is to create a tunnel that lets the attacker connect remotely to the phone’s ADB shell from anywhere on the internet.

The credential theft itself runs on three tracks. There’s a standard Accessibility-based keylogger reading text fields, a second component scraping URLs straight out of browser address bars, and then something considerably more interesting: a hardware-level keylogger running from that same ADB shell, reading raw touch coordinates off /dev/input. Paired with a JSON file mapping out keypad layouts for every major phone brand, a screen tap becomes a digit. It’s a workaround for FLAG_SECURE, custom keyboards, and lock-screen protections all at once, because none of those defenses touch the input driver itself.

On the banking side, RatHat serves fake overlays on top of real banking and payment apps, WeChat and Alipay included, to grab PINs and login credentials while the person thinks they’re using the real interface. Combine that with SMS interception for 2FA codes and you’ve got full account takeover without the victim noticing anything unusual happened.

RatHat serializes the phone’s live Accessibility tree into XML and sends it to a mainstream generative AI assistant, which returns screen coordinates and text so the malware can decide where to tap next. The report puts it plainly:

“Generative AI UI-Automation Engine: This is a particularly unique feature.” continues the report.”The malware serializes the device’s live Accessibility tree to XML and communicates with one of the world’s most popular Generative AI assistants (Figure 4). This AI is used for non-malicious actions including:

• Resolving a named target’s centre coordinates on the screen as JSON to direct synthetic clicks.
• Resolving a target’s actual on-screen text from the XML (without translating).
• Signaling automatic navigation commands like SCROLL_DOWN.”

That single change is what separates RatHat from a decade of scripted Android RATs. Old-school automation breaks the moment a button moves or a layout changes on a new OS version. An AI reading the screen in real time doesn’t care. It just looks and taps, the same way a person would.

Persistence is where things get properly ugly. Uninstall the app and it throws up a fake Google Play error to cancel the removal. Manage to force it through anyway, and the Go agent running outside the app’s lifecycle notices, silently reinstalls the APK, and re-grants every permission, accessibility included, without a single tap from the user. As the researchers describe it:

RatHat uses several communication channels to maintain control of infected Android devices and steal data. The app registers with its C&C server over HTTP and keeps a WebSocket connection open for real-time communication. A separate Go-based agent runs a local server and uses a disguised FRP component to expose it to the internet, allowing attackers to bypass NAT and firewall protections. The C&C infrastructure can receive credentials, SMS messages, files, app lists, lock-screen data and logs, while sending commands, updates, screen-monitoring tools and other components to the device.

There is still an important weak point: the attack needs Accessibility Service access to get started. That makes a basic security rule more important than ever: don’t give Accessibility permissions to apps that have no clear reason to use them, even if the app provides a convincing explanation.

“RatHat’s multi-tiered architecture, reliance on out-of-lifecycle daemons, and use of real-time GenAI decision loops illustrate why traditional, signature-based mobile security controls are insufficient.” concludes the report.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, RatHat)

Google has patched a high-severity zero-day in the Pixel cellular modem after finding evidence that the vulnerability was exploited in limited, targeted attacks.

Google has released its September 2026 Pixel security update, addressing a large set of vulnerabilities, including a high-severity flaw, tracked as CVE-2026-58704 (CVSS score of 8.0), in the cellular modem that has already been exploited in the wild.

“In Cellular Modem, there is a possible permission bypass due to a logic error in the code. This could lead to remote (proximal/adjacent) escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.” reads the advisory.

The vulnerability is an elevation-of-privilege issue caused by a permission bypass resulting from a logic error in the modem code. Google said there are indications that the flaw may have been used in “limited, targeted exploitation.”

“There are indications that CVE-2026-58704 may be under limited, targeted exploitation.” states Google.

As usual, the IT giant has not disclosed who exploited the vulnerability, how many devices were targeted, or what the attacks were designed to achieve.

The vulnerability is particularly notable because it does not require user interaction. According to the CVE record, exploitation can result in remote, proximal or adjacent privilege escalation without requiring additional execution privileges.

The technical details suggest that an attacker able to reach the vulnerable modem environment could exploit the permission bypass to obtain higher privileges. The attack vector is classified as adjacent rather than broadly Internet-facing, an important distinction when assessing the practical exploitation requirements.

The flaw resides in a critical component of moder architecture. Unlike vulnerabilities affecting applications or higher-level Android components, CVE-2026-58704 resides in the cellular modem, a security-sensitive component responsible for communications between the device and mobile networks.

Modem vulnerabilities have historically attracted attention because they can operate below much of the Android application security model. They can also provide attackers with a path toward privileged access without relying on conventional malicious applications or phishing.

In this case, however, Google has not publicly described the complete attack chain. There is also no evidence in the company’s advisory identifying the operation as the work of a commercial spyware vendor or a specific state-sponsored group.

The limited-targeted nature of the exploitation is nevertheless notable.

It suggests that exploitation was not necessarily widespread and may have been directed at a small number of selected devices. Without additional information from Google or independent researchers, the targets and objectives remain unknown.

CVE-2026-58704 is only one of many vulnerabilities addressed by Google’s September Pixel release.

Google’s official Pixel bulletin lists additional security issues affecting components including the kernel, modem, bootloader, telephony stack, Trusted Execution Environment, GPU, Bluetooth, NFC, pKVM and several proprietary Pixel components. The bulletin includes multiple critical-severity vulnerabilities, including remote-code-execution flaws affecting the IP Multimedia Subsystem, libpixelimsmedia, VPU, modem, telephone and BigOcean components.

The broader September Android security bulletin also addresses additional vulnerabilities across the Android platform. Google states that devices using the 2026-09-05 security patch level or later are protected against the issues covered by the Pixel bulletin and the September Android Security Bulletin.

Google’s wording is deliberately limited: it says there are indications that CVE-2026-58704 may be under limited, targeted exploitation.

That is different from saying that the vulnerability is being widely exploited.

At the same time, the confirmation that exploitation has occurred changes the risk profile for affected Pixel users. A vulnerability that exists only as a theoretical security issue can be evaluated differently from one for which exploitation has already been observed.

The absence of public attribution also leaves several questions unanswered.

Was the vulnerability discovered and exploited by a private surveillance company? Was it used by a state-linked operation? Was it part of a broader intrusion chain targeting specific individuals?

At this stage, there is insufficient public evidence to answer those questions.

In the past, exploits of this kind have been used by nation-state actors and commercial spyware vendors.

What is clear is that Google considered the issue serious enough to disclose exploitation and include the fix in its September Pixel security release.

Google recommends that supported Pixel devices receive the latest security update. The 2026-09-05 security patch level addresses the vulnerabilities listed in the September Pixel bulletin as well as those covered by the Android security bulletin.

For users and organizations managing Pixel fleets, the exploitation status of CVE-2026-58704 makes timely patching particularly important.

The incident also highlights a broader security reality: the attack surface of a smartphone extends far beyond the applications installed by the user.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Pixel Modem)

Researchers built a WeChat worm that spreads through incoming calls without user action. Tencent has blocked the exploit.

Researchers at Calif created a WeChat worm that can take over an account through an incoming call, even if the victim never answers or touches the phone.

The attack works only when the caller already appears in the victim’s WeChat contacts. Calif reported the flaw to Tencent in July, and Tencent has blocked the exploit for all users. The good news is that researchers found no evidence that attackers used the flaw in real-world attacks, but the case shows how dangerous zero-click vulnerabilities can be.

“Simply by calling a victim, WeWorm can hijack their account and call their friends, spreading from phone to phone.” reads the report at Calif. “If exploited, actors can compromise over a billion phones (or accounts), upending livelihoods and breaking communities worldwide.”

Researchers built a demo WeChat worm that spread between three test phones without requiring any action from the victims. They started with a Pixel 10a and called an iPhone 17e, exploiting the flaw while the phone was still ringing. After taking control of the iPhone, they used it to call another Pixel 10a and compromise that device too. In other words, one compromised account can become the starting point for the next attack.

The exploit works within seconds and gives the attacker full control of the victim’s WeChat account. They can read and send messages, make calls and use the account as if they were the victim. The victim does not need to answer or touch the phone. Even answering the call does not stop the attack. Declining the call blocks that attempt, but the attacker can simply try again later.

The main limitation is that the attacker must already be a WeChat contact. However, compromising one of the victim’s friends could provide a way around that restriction.

“The victim does not need to answer the call, or interact with their phone at all. Even if they do answer, they hear nothing, and the exploit still succeeds. Declining the call stops that attempt, but the attacker can simply try again later, for example, while the victim is asleep.” the researchers explain. “This exploit requires the attacker to be on the victim’s friend list. But that’s not much of a barrier: an attacker can compromise one of your friends first and use their account to reach you.”

Calif published both Android and iOS RCE demos. The firm did not disclose technical details about the issue and will present the full analysis at a conference. For now, defenders have no clear indicators to search for, and users cannot tell if attackers targeted them with a call.

Combined with other Android and iOS flaws, the attack could also lead to full device control.

Researchers say AI helped them find the flaw and build an RCE exploit in about two days. They then built the worm in another week. They argue that AI is making advanced attack capabilities available to less-skilled attackers, increasing the risk of zero-click threats.

Researchers say the goal of publishing the findings is to raise awareness and encourage governments and technology companies to work together on AI security.

The WeChat flaw comes from a memory corruption bug in the app’s VoIP system. Researchers are keeping the technical details private for now and plan to present their full analysis at a future security conference.

The team believes this bug is just one example of the unusual attack surfaces found in messaging apps. They are researching similar weaknesses in other apps and working with developers to reduce these risks. Some changes may require cooperation from platform owners. Once the work progresses, they plan to publish more details about the WeChat flaw.

In August, Tencent released versions Android 8.0.77 and iOS 8.0.76 that addressed the issue.

WeChat is Tencent’s messaging and social platform, launched in 2011 and now much more than a chat app. It lets users send messages, make voice and video calls, create group chats and share content through Moments. It also includes official accounts, video channels, games, search and Mini Programs, which provide services such as shopping, bookings and deliveries without requiring separate apps.

In China, its local version, Weixin, also integrates Weixin Pay for mobile payments. Tencent reported 1.418 billion combined monthly active users for Weixin and WeChat at the end of 2025, making the platform one of the world’s largest messaging ecosystems.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, mobile)