One of the most unusual features of the malware is its use of zero-width Unicode characters to hide information about a stolen password inside what appears to be a normal configuration file.
CloudSyncD is distributed through a malicious disk image designed to look like a legitimate Zoom installer. The installer includes instructions telling users to bypass macOS Gatekeeper by going to System Settings and manually allowing the application to run.
Once the fake installer is launched, the first-stage program, called app_installer, displays a fake authorization window asking for the user’s administrator password. It checks the entered password locally using macOS’s dscl command. If the password is incorrect, the malware can continue prompting the victim.
The stolen password is not immediately sent to the attackers. Instead, the malware stores it inside a file called data.json. The password is Base64-encoded and placed inside a larger string containing random characters.
The malware then uses U+200B ZERO WIDTH SPACE and U+200C ZERO WIDTH NON-JOINER characters. These characters are invisible during normal viewing and encode the location and length of the hidden password. This technique allows malicious information to be concealed without obviously changing the appearance of the file.
The second stage is an embedded Mach-O executable capable of running on both Intel-based and Apple Silicon Macs. The malware attempts to execute the payload without initially writing it to disk. When that approach fails because of macOS security protections, it can create a temporary file and use the captured password with sudo to execute the backdoor with elevated privileges.
After execution, CloudSyncD collects information about the infected Mac, including hardware and operating-system details, account information and network-related data. It communicates with a command-and-control server and can periodically check for additional instructions.
Researchers observed check-ins occurring approximately every 8 to 16 seconds in analyzed samples. The backdoor can receive executable files or compressed archives, potentially allowing attackers to deploy additional malware on an infected system.
Most organizations around the world are spending more on cybersecurity than at any point in their history. Very few are spending it on the threats that are actually coming for them. That is the central tension running through PwC's 2027 Global Digital Trust Insights report, which drew responses from nearly 4,000 business and technology leaders spanning more than 70 countries.
Artificial intelligence sits at the core of the report's findings, and not in the way most organizations would prefer. Leaders surveyed identified attacks targeting their own AI systems as the single cyber threat they feel least prepared to handle. Over half of respondents, 53 percent, said they are not adequately defended against autonomous botnet attacks, where AI drives the probe and compromise of networks faster than human teams can respond. Adversarial attacks and data poisoning followed at 52 percent each, pointing to a defensive gap that has widened as attackers have adopted the same tools organizations are still trying to implement on the defense side.
Prompt injection sits squarely at the heart of this problem. Unlike conventional exploits that target code vulnerabilities, prompt injection manipulates the AI model itself, tricking it into leaking data, executing unauthorized commands, or acting entirely outside its designed purpose. OpenAI acknowledged in late 2025 that prompt injection, much like social engineering before it, is a problem that cannot be fully engineered away. The Open Worldwide Application Security Project has ranked it number one on its threat list for LLM applications for three consecutive updates, a position it has held since the list first debuted. The persistence of that ranking reflects not a shortage of incidents, but the structural difficulty of closing an attack surface that is, in effect, the model's own reasoning process.
Despite all of this, AI is simultaneously the security tool leaders trust most. The survey found it ranked first for threat detection and alerting across the respondent pool. The contradiction is in what comes next. Only 22 percent of leaders said they would let AI agents operate in cyber defense without requiring human sign-off on their actions. Fifty-five percent attributed this reluctance to reliability and maturity concerns, while 44 percent pointed to a skills shortage in AI oversight and governance.
That hesitation is not irrational, but it carries a cost. AI-driven attacks operate at a pace that leaves human response cycles behind. Requiring manual approval for every automated defensive action is, in practice, fighting a faster adversary at a slower speed. At some point, fully autonomous defense may not be optional. What makes that shift harder is that organizations have not settled on who would be accountable for it. The survey found that 29 percent of leaders placed AI security accountability with the CIO or CTO, 26 percent with a dedicated AI leadership role, and only 17 percent with the CISO. Eleven percent said responsibility was shared across multiple functions, which in most organizations means it belongs to no one in particular.
Budget signals at least suggest that leaders recognize the scale of the problem. Eighty-four percent of security and finance leaders said they expect cyber budgets to increase, with 58 percent naming AI as their top spending priority for the coming year.
The second major warning in PwC's report concerns quantum computing, and the picture there is, if anything, more concerning. Quantum computers capable of breaking the encryption that currently secures financial records, government communications, and enterprise data are not yet commercially operational. But the attack strategy does not require them to be. State-sponsored threat groups and other sophisticated actors are already collecting encrypted data now, banking on the ability to decrypt it once quantum capability matures. Most cryptography researchers put that window between 2030 and 2035, and the timeline for migrating large-scale cryptographic infrastructure is measured in years, not months. The National Institute of Standards and Technology finalized its first three post-quantum cryptography standards in August 2024, covering quantum-resistant key exchange and digital signatures, and told organizations explicitly that there is no reason to delay. PwC's survey found that only 21 percent of respondents are currently implementing those standards.
What makes this more urgent than a theoretical risk is that the harvesting is already underway. The FBI confirmed in August 2025 that a Chinese state-sponsored group tracked as Salt Typhoon had compromised more than 200 organizations spanning more than 80 countries, with nine major US telecommunications carriers among the confirmed victims. In at least one documented case, the group maintained undetected access to a telecom network for three years, collecting communications data throughout. That data, encrypted under today's standards, sits in storage waiting for the decryption capability that quantum hardware will eventually provide. Governments are beginning to respond with deadlines rather than guidelines. In June 2026, President Trump signed executive orders requiring federal agencies to migrate high-value systems to NIST-approved post-quantum cryptography standards by 2030 and 2031 respectively, with government contractors expected to follow. The private sector has no equivalent mandate, and PwC's survey makes clear that most organizations are not filling that gap on their own.
"Technology is moving incredibly fast, but the fundamentals of cybersecurity haven't changed," said Morgan Adamski, PwC's cyber, data and technology risk leader. "You can invest heavily in AI and the latest security tools, but if you don't have secure data, operational continuity, clear accountability and strong cyber hygiene underneath them, you're building on a weak foundation. The goal isn't to slow innovation down. It's to make sure your organization is resilient enough to keep up with it."
What the survey documents, across both AI and quantum, is the distance between knowing what needs to be done and actually doing it. The tools exist. The standards are published. The gap is operational, and the cost of that gap is rising by the month.

A new frontier artificial intelligence model, Gemini 4 Argon, has been introduced by Google through its Fairwind Program for initial distribution to trusted cybersecurity defenders. In addition to internal security teams using this model, the company expects wider access as it collects feedback from early users.
As a software engineering, enterprise knowledge work, and cybersecurity operations solution, Argon is designed to handle complex software engineering and knowledge management tasks. A model developed by Google will be able to identify, validate and patch critical vulnerabilities independently in security environments, thereby expanding the use of artificial intelligence for vulnerability research and remediation.
Argon will be available to trusted defenders and the company's own teams without cyber-specific guardrails, according to the company. As part of this approach, vetted security professionals will be given full access to the model's capabilities when investigating and addressing threats. In September, Fairwind, a limited access AI security tool for governments, Google Cloud customers and cybersecurity partners, launched.
A significant finding has already been made as a result of its early deployment, Wiz, which is using Argon as part of its Scan for Good initiative, reported that it identified a previously unknown critical vulnerability in healthcare software used by hospitals worldwide. The vulnerability may expose sensitive personal information, although Google has not disclosed the name of the affected software or whether the issue has been resolved.
Google also reports significantly improved vulnerability detection performance compared with Gemini 3.8 Flash Cyber. A security test conducted by Argon on complex codebases identified security weaknesses, while a test conducted by Wiz on live web applications demonstrated improvements in attack surface discovery, vulnerability identification, and proof-of-concept generation.
A phased approach is being taken by Google to the wider release, with the model currently restricted to internal teams and vetted defenders. Moreover, the company is participating in the U.S. government's voluntary pre-release process and will refine its safeguards after receiving feedback from early testers in order to broaden the availability to developers, enterprises, and individuals.
Argon will be designed to reject requests attempting to support cyber or chemical, biological, radiological, and nuclear attacks as part of its broader rollout, while also preserving the support of legitimate dual-purpose research as part of its broader rollout. Additionally, Google is monitoring the model's internal activity for signs of misuse. Indirect prompt injection is also being investigated.
In Google's opinion, Argon is protected against attempts to manipulate it through malicious instructions or external content. The Fairwind program provides another layer of control around access by monitoring the model’s reasoning and actions, and stopping execution when behavior goes beyond the intended task.
Organizations participating in the program have been vetted and their use has been restricted to authorized defense activities such as threat simulation, reverse engineering, and malware analysis for research or security purposes. Partners are not permitted to share or distribute access to the model. Google has not provided a date of general availability yet.
Upon initial deployment of Argon Defender, API customers and Google AI Ultra subscribers should have access, although the broader deployment of Argon will be dependent on the results of ongoing safety and security evaluations.
Researchers at Truffle Security tested 543,699 API keys, database passwords, and access tokens found in public GitHub repositories last July. Every single one authenticated. The median credential had been sitting in publicly readable code for 784 days.
The findings come from a scan of The Stack v3, a 224-million-repository snapshot of public GitHub code assembled to train large language models. The crawl closed on August 7, 2025. Eleven months later, when Truffle Security ran live verification against each issuing provider, more than half a million credentials still worked. That number is more than double the 221,303 live credentials the company found when it ran a similar scan against 7.6 petabytes of Hugging Face training data earlier this year.
The oldest credential in the dataset was last touched on June 13, 2009. It lives inside an Erlang web server configuration file, and it was still valid 16.1 years after it was committed. Behind it: an FTP login inside a GPS logger's C source code from September 2009, replicated across 62 repositories, and an AWS key tucked inside a Rails S3 config from November of that same year. Truffle Security declined to name the repositories because the credentials in them still work.
A Protection That Only Faces Forward
GitHub has progressively tightened its defenses around exposed credentials. The platform made secret scanning alerts free for all public repositories in February 2023. Push protection, which blocks a commit before it reaches the remote branch if it carries a recognised secret, became generally available in May 2023 and was switched on by default for all public repositories on February 29, 2024.
GitHub's secret scanning covers more than 200 token types and patterns from over 180 service providers. The rollout had a measurable effect on new leaks. Among credential shapes the system recognises and blocks, Truffle Security found a 53 percent drop in the rate of fresh exposures across the twelve months following the default rollout, compared to the twelve months before it. Slack tokens fell 64 percent, GitHub's own tokens and AWS access keys each fell 59 percent.
But push protection has no mechanism to reach the credentials already there. Of the 543,699 live credentials, 199,843 landed after push protection became the default in February 2024. Developers either bypassed the block or committed credential types the system does not recognise.
That second category is the larger problem. Truffle Security found that 51.8 percent of every live credential in the dataset is a shape that a default-configured public repository will accept without objection. Database connection strings, private keys, and Google API keys all fall outside the default block list. Push protection focuses on specific, highly identifiable secrets and misses generic ones. Connection strings and private keys are classified as generic patterns, and blocking them requires an organisation to go into settings and explicitly opt in.
The Gemini Problem
The Google API key situation illustrates the limits of pattern-based blocking in particularly sharp terms. The 33,343 live Google API keys in Truffle Security's dataset include 31,374 that authenticate specifically to Gemini, Google's AI model platform. Their median leak date is February 2025, meaning the entire population is younger than the push protection rollout.
Google API keys carry the prefix `AIzaSy` whether they were created for Google Maps, Firebase, or Gemini. GitHub's pattern list recognises the prefix but marks it as not push-protected, because a Maps key sitting in client-side JavaScript is not a secret by design. Google's own approach to API keys was historically built around the assumption that these keys would live in client-side code, exposed to anyone who opened a browser's developer tools. The problem is that Gemini runs on the same key format, turning what developers were trained to treat as a non-sensitive identifier into a billable AI credential. One pattern cannot distinguish between the two uses, so nothing gets blocked, and the keys that matter arrive alongside the keys that do not.
Revocation is the Deciding Variable
The most instructive comparison in the data is between providers that automatically revoke leaked tokens and those that do not.
npm committed 101,886 tokens to public code. One remains live. GitHub committed 73,048 tokens; 260 survived. Hugging Face committed 30,437; 15 are still valid. Each of these platforms runs an automated pipeline that kills a token the moment it is detected in public code.
The contrast with database credentials is stark. Of 12,985 Postgres connection strings in the dataset, 11,465 are still live, an 88 percent survival rate. MySQL connection strings survive at 75 percent. MongoDB, where the detector only reports a URI it successfully connected to, returned all 51,067 live.
Push protection blocks secrets at the door. Automated revocation kills them wherever they are. The Truffle Security data shows that the second mechanism is the one that changes the outcome, and for the majority of credential types sitting in public repositories right now, no provider is running it.
The practical guidance from the researchers: treat any committed credential as compromised regardless of whether anything flagged it, scan your own repository history rather than assuming the push-time block was sufficient, and favour credentials that expire automatically. Most of what Truffle Security found would have been harmless long ago if it had ever been given a finite lifetime.
Researchers at OX Security have flagged 101 npm packages that silently subscribe developers to WhatsApp spam channels the moment they are installed. The campaign abuses the open-source Baileys library, an unofficial implementation of the WhatsApp API that developers use to build customer support bots, chat managers, and automation tools, to carry out the subscriptions without any visible prompt or warning.
The packages have collectively been downloaded roughly 490,000 times, with 116,000 of those downloads occurring in the last 30 days. The single most downloaded package, `ourin-baileys`, accounts for 130,589 installs on its own, nearly a quarter of the campaign's total reach. As of publication, the majority of the 101 packages remain live on npm. Sixteen had been removed, and seven of those were pulled before researchers could review the code to determine which variant of the malware they carried.
The campaign did not begin in 2026. The oldest package in OX Security's list, `alipclutch-baileys`, was first published in October 2025. Several others date to December 2025, meaning this operation has been running quietly on the registry for close to a year before receiving a formal write-up.
Three Ways to Hide the Same Payload
OX Security researchers Nir Zadok, Moshe Siman Tov Bustan, and Vitalii Chepurko identified three distinct variants of the malware, each handling the subscription routine differently.
The first variant, found in 19 packages, fetches channel IDs from GitHub at runtime. By hosting the target list externally, operators can swap out which accounts receive new followers without ever publishing a new package version to npm. One package, `@rixxcodex/baileys`, hides the GitHub URL inside media-download code using Base64 encoding so it is unlikely to catch the eye of anyone skimming the source.
The second variant, covering 60 packages, simply embeds the channel IDs in cleartext inside the source code. Two packages took additional steps to bury this, placing the subscription logic inside an upstream connection handler and inside a file named after the Signal cryptographic protocol, a location most developers would never think to inspect.
The third variant, found in 14 packages, encodes the hardcoded channel IDs using Base64. One package in this group, `neuralwhatsapp`, takes a slightly different approach: rather than storing a channel ID directly, it resolves its target from a hardcoded WhatsApp invite code at runtime.
The Follower Inflation Business
The goal is not data theft or ransomware deployment. The channels identified in this campaign are mostly small bot-seller and marketplace accounts, largely Indonesian, where follower counts function as social proof for selling bot scripts, premium APKs, social media boosting services, and in-game resources.
Among the specific channels researchers identified: Neural has 798 followers and markets game-currency sales through a platform called JualanRSS, which deals in in-game resources including food, ore, stone, timber, and gold. MONTE-BMG has 1,000 followers. CORTANA TECH has 1,300 and points visitors to a dedicated website. Fyxzpedia.ID-Utama, with 4,800 followers, sells WhatsApp and Telegram bot scripts and bot-building services outright. One Spanish-language channel called Redes Oficiales sits at 19,000 followers and is linked to a YouTube creator, pushing back against the assumption that this is a purely Indonesian operation.
The threat actors mute these channels on the victim's device after subscribing them, so the added follower count appears organic to outside observers. A channel with thousands of followers reads as trustworthy, and that manufactured trust is the product being sold to the operators running these marketplaces.
One channel, MONTE-BMG, illustrates how the monetisation funnel actually works. It posts what appears to be a screenshotted sales negotiation in Arabic, ending with a group invite link. That link leads to a brand-new channel with only 12 followers, whose own description contains yet another group invite. The inflated parent channel is only the entry point. The actual transaction gets moved progressively deeper into a private chain of groups where there is no public record.
Beyond follower inflation, the SafeDep research team noted earlier this year that some Baileys forks in this campaign also inject the package author's advertising URL into every image and video the bot sends, a second payload the follower-count headline tends to obscure.
One Coordinated Operation, Many Names
OX Security found that 32 channels are followed by more than one package across this campaign. The single most reused channel, identified by the ID `120363400911374213@newsletter`, is targeted by ten separate packages. One remote channel list hosted on GitHub feeds five different packages simultaneously, meaning the operator can retarget all five installations by editing a single file.
Operators routinely publish near-identical packages under slightly different names to preserve the campaign when individual listings get removed. `noxleyss` and `@noxleyss/baileys`, for example, carry the same code under different publisher accounts.
Details of the abuse first emerged in August 2026 when SafeDep identified Baileys npm forks making installers' WhatsApp accounts follow attacker-controlled channels. Earlier this month, the Xygeni Security Research Team separately detailed another Baileys modification, `@dappaoffc/baileys-mod`, which subscribed developers' authenticated WhatsApp bot sessions to attacker-controlled newsletter channels.
The campaign follows a pattern OX Security has tracked on npm before. An earlier operation used the same registry to host fake Cloudflare CAPTCHA pages designed to redirect visitors to ClickFix phishing infrastructure. The registry's scale and the institutional trust developers place in what appear to be legitimate forks of known libraries make it a dependable distribution channel for this kind of abuse.
Because the packages carry none of the classic malware signatures, no API token theft, no heavy obfuscation across the board, no destructive payload, standard threat detection tools are likely to miss them entirely. That is precisely why most of these packages have remained live for months.
What Developers Should Do
Security recommends checking whether your WhatsApp account has been added to unknown channels and blocking or reporting any that appear. Developers should avoid any npm package that requires connecting a personal WhatsApp account and should add detection rules to their pipelines flagging known malicious Baileys forks. Remote channel-list URLs identified in these packages can be added to URL-reputation and threat-intelligence pipelines for ongoing monitoring.
A cyberattack on Polish healthcare software company Qbusoft has left patient records from its Medyc platform potentially in the hands of attackers, coming just weeks after a separate, larger breach hit another Polish medical software provider and rattled the country's entire health data infrastructure.
The attacker exploited an SQL injection vulnerability in Medyc's application interface during late August, according to a breach notification published last week by the Addiction and Psychiatric Treatment Center in Inowrocław, one of the healthcare facilities running the platform. SQL injection is one of the oldest and best-documented attack techniques in security research, allowing an attacker to manipulate a web application into pulling data directly from its database. Despite decades of awareness about the flaw, it remains a recurring entry point in healthcare system compromises.
Qbusoft confirmed on Friday that the attackers obtained names, national identification numbers, home addresses, phone numbers and email addresses. In Poland, the national identification number, called a PESEL, functions similarly to a Social Security number in the United States and is a standard credential for identity verification across government services, banking and healthcare. Its theft puts affected patients at real risk of identity fraud.
The company said it had not confirmed the theft of clinical records. But the Inowrocław center told patients that Qbusoft found evidence the attacker ran scripts specifically targeting database tables containing medical information, making it "highly likely" that medical records were also pulled. The data in scope for that facility included hospital treatment records and discharge summaries from patients treated at its Day Treatment Unit for Addiction Treatment between July 2024 and August 2026.
The intrusion occurred on August 22-23 and went undetected until the night of September 8-9, a gap of more than two weeks. By that point, the attacker had already transferred an encrypted archive of the database outside Qbusoft's systems. Some fields, including names and PESEL numbers, had been encrypted in the database. Qbusoft nonetheless advised the affected center to assume the attackers could decrypt that information without difficulty, given the specifics of how the protection was implemented.
Qbusoft patched the vulnerability on the day the breach was detected, restricted database access permissions, rotated passwords and technical credentials, and introduced additional monitoring. The company has not publicly commented on the incident through any official statement.
That silence drew a sharp response from Digital Affairs Minister Krzysztof Gawkowski, who said the Central Bureau for Combating Cybercrime had opened an investigation and criticized Qbusoft for failing to notify CERT Polska or the national incident response team for the healthcare sector before authorities reached out. "Hiding attacks by companies is the biggest mistake, as it always puts citizens at risk," Gawkowski said. Poland's data protection authority separately announced that its president had ordered a formal audit of Qbusoft.
Medyc, which has operated as a cloud-based platform since 2014, is used across Polish medical practices and clinics for electronic medical records, patient scheduling, electronic prescriptions, referrals, sick notes, telemedicine and administrative billing. In a public notice, the company warned that its infrastructure had faced repeated attack attempts since the incident and that users might see temporary slowdowns or restricted access to certain modules.
The Same Attacker?
Polish cybersecurity publication Zaufana Trzecia Strona reported that a person or group using the alias "fingerprint" contacted the outlet claiming responsibility for the Medyc attack. The publication had previously linked that alias to the MyDr breach, a separate incident involving another Polish healthcare software vendor. Polish broadcaster RMF FM also reported that the same attackers behind MyDr were likely responsible for the Medyc intrusion, though Polish authorities have not formally attributed the attack to any individual or group.
The alleged attacker claimed to have obtained records on 5 million patients and 8 million private photographs, some of which Zaufana Trzecia Strona said may depict patients in sensitive medical settings. Neither figure has been independently confirmed, and the stolen data has not been made public. The actor reportedly framed the operations as an effort to expose weak security rather than profit from the data.
The MyDr breach, confirmed in August, potentially affected close to 19 million people across more than 12,000 healthcare facilities, involving over 2 terabytes of stolen data including names, PESEL numbers, prescription histories, diagnoses and appointment records. Poland has roughly 36.5 million residents, meaning the MyDr incident alone touched the records of nearly half the country's population. The Inowrocław treatment center caught up in the Medyc breach was also among the organizations affected by MyDr.
Gawkowski said Polish authorities had observed a surge in criminal activity targeting healthcare organizations in recent weeks and were preparing new regulations in response, including mandatory security certification for healthcare technology companies and tighter controls on how private vendors handle medical data. Poland recorded a 144 percent year-on-year rise in reported cybersecurity incidents in 2025. The consecutive breaches of Medyc and MyDr, both software vendors connecting thousands of clinics to national health infrastructure, have made clear that the weakest link in Poland's health data chain is not the government platform but the private companies sitting in front of it.