Apple users are being urged to exercise caution when following troubleshooting instructions found online after cybersecurity experts underlined a growing social engineering tactic that tricks victims into pasting malicious commands into the macOS Terminal application. Rather than exploiting a flaw in macOS itself, the scam relies on convincing users to voluntarily execute commands that can install malware, grant attackers remote access, or expose sensitive information stored on their devices.
Often referred to as a "copy-paste" scam, the technique targets users unfamiliar with Terminal, a command-line interface included with macOS that enables direct interaction with the operating system through text-based commands. While the application is commonly used by developers, system administrators and advanced users to automate tasks or manage system settings, executing unfamiliar commands without understanding their function can introduce significant security risks.
Unlike traditional malware campaigns that exploit software vulnerabilities, this attack depends almost entirely on social engineering. Cybercriminals impersonate trusted sources or create convincing troubleshooting scenarios to persuade victims that running a Terminal command is necessary to fix a technical issue, improve security or restore system performance. Once executed, however, the command may download malicious software, establish remote access, alter security settings or perform other unauthorized actions without the user's awareness.
Depending on the instructions provided, attackers could gain access to documents, photographs, emails, browser data, financial information, saved credentials and contact lists stored on the Mac. Some malicious scripts may also deploy keylogging software capable of recording everything a victim types, including usernames, passwords and other confidential information. In more severe cases, attackers could install ransomware or persistence mechanisms that allow them to retain access to the compromised system even after a restart.
Security researchers note that the scam can begin through multiple channels. Victims may receive phishing emails or text messages containing the malicious command, encounter it in online discussion forums disguised as a legitimate solution, or visit fraudulent websites presenting it as an official troubleshooting step. Attackers have also been observed posing as technical support representatives over the phone, carefully instructing victims to open Terminal and manually type commands under the pretense of resolving an issue.
The rise of generative artificial intelligence has introduced another avenue for abuse. Threat actors may intentionally publish malicious commands across public websites and discussion platforms in an effort to influence AI-powered assistants through a technique known as indirect prompt injection. If an AI system retrieves or references poisoned content while responding to a user's troubleshooting request, it could inadvertently recommend unsafe commands. Although AI tools continue to improve their safeguards, cybersecurity experts advise users to independently verify any command before executing it on their systems.
The attack typically follows a similar pattern. After directing a user to open the Terminal application located within the Utilities folder inside Applications, the attacker provides one or more commands and claims they are required to diagnose, repair or secure the computer. In reality, those commands may download remote administration tools, retrieve additional payloads from external servers, modify system configurations or provide unauthorized access to the attacker's infrastructure.
Because the attack depends on user participation rather than exploiting a software flaw, many victims may not immediately recognize they are being targeted. Individuals unfamiliar with Terminal often have little reason to question commands presented by someone claiming to represent Apple, a software vendor or a technical support service. Similarly, users searching online for solutions may encounter malicious instructions embedded within forum posts or copied across multiple websites, making them appear credible.
To help reduce the effectiveness of these attacks, Apple introduced additional safeguards in recent versions of macOS. When users who do not regularly work in Terminal attempt to paste commands copied from websites, messaging platforms, email applications or chatbots, the operating system may interrupt the action with a warning indicating that the pasted content could contain malware or compromise privacy. Rather than automatically executing the command, the prompt encourages users to reconsider before proceeding.
Apple has also expanded malware detection capabilities within Terminal. If the operating system identifies known malicious content or scripts, it can block execution and notify the user that the pasted command has been prevented because it poses a security risk. These protections are designed to slow down impulsive actions and reduce the likelihood of users unknowingly compromising their own systems.
Cybersecurity professionals emphasize that no security warning should replace careful judgment. Users should never execute Terminal commands they do not fully understand, regardless of whether the instructions originate from an email, text message, online forum, chatbot or unsolicited phone call. Requests accompanied by pressure tactics or claims that immediate action is required should be treated with particular suspicion, as creating a false sense of urgency remains one of the most common techniques used in phishing campaigns.
Experts also caution against assuming that information found on public forums or generated by AI assistants is inherently trustworthy. Malicious instructions can spread rapidly across the internet and may be reproduced by multiple sources, giving them an appearance of legitimacy. Verifying guidance through official Apple documentation or other trusted security resources before executing any command remains one of the most effective ways to avoid becoming a victim of Terminal-based social engineering attacks.
Experts discovered a secret browsing-history collector built into its official store variant, and have withdrawn the ModHeader from Google and Microsoft.
An empty allow-list kept the collector switched off and it was dormant, and no proof has surfaced that it retrieved or sent even one browsing domain.
Stripe OLT, a UK cybersecurity organization analyzed the code against Google’s Web Store signature and verified the collector shipped within the authentic extension, not a fake one.
Stripe OLT’s study covers the Chrome build and its 900,000 users (an estimate); and Edge and its 700,000 users. Microsoft removed the listing on July 3rd whereas Google pulled the Chrome listing a week after, on July 10th.
Variant 7.0.18 still edits HTTP headers as shown. The same minimized background also consists of another system. On the first attempt, it makes a device fingerprint and deploys a hardcoded encryption key. As the user browses, it takes the domain from each page that user opens, encodes it, and gathers it locally, up to 1000 different domains.
A scheduler combines your fingerprint with the encrypted list, uploads it to api.stanfordstudies[.]com, and deletes the local copy once a day. If the collector were turned on, browsers using it wouldn't all beacon at once because the upload time is offset per install. The same pipeline is described in separate teardowns by researcher Yunus Aydin on version 7.0.17 and HackIndex on version 7.0.18.
The collector functions only if your browser matches an entry on an internal allow-list, but the list ships empty. Every time, the check fails, and the pipeline stops before it gathers even a single domain.
The small change is populating the list, without any click and no new permissions from the users, sent as a routine update. The endpoint URL, the scheduler, the storage logic, and the hardcoded key are all on the same device.
But not everything was silent. The extension pinged extensions-hub[.]com with the product, version, and browser when it was installed, updated, and uninstalled.
Additionally, it was evident that the piece had been running because a script that runs on every page had already recorded actual request metadata in plain text to local storage.
Developers and organizations using the Jscrambler npm package are being urged to audit their systems after multiple malicious releases were uploaded to the npm registry through a compromised publishing credential. The incident transformed a trusted development dependency into a malware delivery mechanism capable of stealing credentials, browser sessions, cryptocurrency wallets, and sensitive configuration files from Windows, macOS, and Linux systems. Jscrambler has confirmed the compromise was limited to its Code Integrity npm package and has advised users to upgrade to version 8.22.0 after revoking the affected publishing credentials and strengthening its release pipeline.
Security researchers first identified version 8.14.0 as the initial compromised release after discovering that it introduced a previously undocumented npm "preinstall" lifecycle hook. Unlike the legitimate 8.13.0 release, the malicious package included new files that were absent from Jscrambler's public source repository. During installation, the package silently unpacked and executed a native binary tailored to the victim's operating system, allowing the malware to run before developers ever interacted with the package itself. Socket detected the malicious release within minutes of publication, highlighting how quickly software supply chain attacks can unfold.
Technical analysis showed the package concealed separate native payloads for Linux, Windows, and macOS inside an obfuscated container embedded within the package. A lightweight loader selected the appropriate binary for the host operating system, wrote it to a temporary directory under a randomized filename, granted execution permissions where required, and launched it as a background process with minimal user visibility. Researchers also noted that these components never appeared in the project's public GitHub repository, suggesting the malicious code bypassed the project's normal development workflow and was introduced during package publication.
The payload itself is a Rust-based infostealer engineered to harvest assets commonly found on developer workstations and build infrastructure. Investigators found code targeting cloud credentials associated with AWS, Microsoft Azure, and Google Cloud, browser-stored passwords and cookies, cryptocurrency wallets, Bitwarden vault data, communication platforms such as Slack, Discord and Telegram, and developer secrets that could provide access to production environments. Researchers also observed the malware searching for configuration files belonging to AI-assisted development tools, including Claude Desktop, Cursor, Windsurf, Visual Studio Code and Zed, where API keys and Model Context Protocol credentials are frequently stored.
Beyond credential theft, the malware incorporated platform-specific capabilities intended to strengthen its foothold on compromised systems. Analysts found Linux-specific code interacting with eBPF, a kernel technology that allows programs to execute within the operating system kernel, although the precise purpose of this functionality remains under investigation. Windows and macOS variants incorporated persistence mechanisms designed to survive system reboots, while encrypted command-and-control communications complicated static analysis and hindered efforts to identify the attackers' infrastructure. Runtime monitoring also identified outbound connections associated with the campaign's command infrastructure.
The campaign expanded rapidly after the initial discovery. Additional malicious versions, including 8.16.0, 8.17.0, 8.18.0 and 8.20.0, were subsequently identified. While the earlier releases relied on npm's preinstall hook to execute the malware automatically during installation, later versions embedded the same payload directly into the package's runtime code. This change allowed the malware to execute when the package was imported or its command-line interface was launched, reducing the effectiveness of mitigations such as disabling lifecycle scripts during installation. Researchers described the shift as an example of attackers quickly adapting to evolving software supply chain defenses.
Further investigation by JFrog linked the malware to an evolved variant of the IronWorm infostealer. According to the researchers, the malware extends beyond information theft by attempting to propagate itself across the npm ecosystem. The code searches compromised systems for npm authentication tokens, validates the stolen credentials, identifies valuable packages, injects malicious components into package archives, and attempts to publish trojanized versions directly to the npm registry. JFrog also reported that the malware broadens its search to include VPN configurations, password managers, Tor-related files and directories associated with penetration testing frameworks, indicating an effort to compromise developers, security researchers and enterprise engineering teams alike.
The incident adds to a growing series of attacks targeting open source software distribution channels, where compromising trusted packages offers attackers access to developer workstations and CI/CD pipelines instead of directly attacking production systems. Because these environments often contain deployment credentials, signing keys, cloud secrets and proprietary source code, a single compromised dependency can expose far more than the application that depends on it. Researchers have increasingly warned that software supply chain attacks are shifting toward development infrastructure, making continuous dependency monitoring and rapid package verification critical components of modern software security.
Organizations that installed any affected version should immediately upgrade to Jscrambler 8.22.0 or later, investigate development workstations and build systems for signs of compromise, and assume any credentials accessible to the affected environment have been exposed. Security teams should rotate cloud credentials, npm and GitHub tokens, API keys, browser sessions and other secrets, inspect lockfiles and build logs for compromised package versions, and review systems for persistence artifacts before returning affected machines to service.
Experts from Mozilla Zero Day Investigative Network (0DIN) AI security platform said that the exploit takes place without any warning, no exploit code, and no malicious command approved by anyone.
Experts showed how a threat actor could deploy an interactive shell on a developer’s system via Claude Code to launch a cloned project with no malicious code in the repository.
The attack tactic relies on three patterns that show no signs of exploit:
oDIN experts said that this technique requires no malicious parts in the cloned repository as the AI agent automates the full attack line, also comprising a level that impersonates a user error.
Once successful, the threat actor would get a shell with developer’s privileges, allowing them access to API keys, environment variables, making establish persistence, and local configuration files.
“Claude Code never decided to open a shell. It decided to fix an error. The reverse shell is three indirection steps away from anything Claude Code actually evaluated: an error message it trusted, a script that fetched a value, and a DNS record it never saw,” oDIN experts said. “The attacker now has an interactive shell running as the developer's own user.”
Currently, the attack tactic is just a concept, but experts warn that hackers could effectively spread such GitHub repositories via fake job postings, direct messages, tutorials, and blog posts.
To avoid such exploits in future, oDIN researchers advise that AI agents should reveal the full deployment chain of setup instructions, like scripts and code retrieved dynamically at runtime.
The first tool is called Amadey, a malware-as-a-service platform for disrupting devices and deploying infected payloads for ransomware and related attacks. Amadey was first discovered in 2018 and in 2025, it exploited GitHub as it stored system info from malicious devices and deployed custom payloads.
The second tool is called StealC, it is an infostealer-as-a-service tool that steals cryptocurrency wallets, browser extensions, authentication cookies, and login credentials.
Amadey and StealC are distinct tools that function autonomously. They are widely used, but many people use them in their personal cybercrime operations.
The tools depend on the same infrastructure to function. Microsoft made this link after analyzing the tools using AI. The discovery allowed Microsoft to stop both tools simultaneously.
“This action goes after the cybercrime ‘assembly line,’ where coordinated tools drive ransomware, financial fraud, and disruptions to public services. Amadey and StealC are often used alongside each other: Amadey helps attackers gain access to devices, while StealC steals passwords and sensitive information. Together, they form a critical link in the chain,” Microsoft said.
Companies gathered proof that the tools shared the same infrastructure and invoked RICO statutes against organized crime. This resulted in treating the two tools as part of a single scam.
Microsoft has disrupted over 200 C2 servers and shut down criminal control of over 18,000 compromised computers. Europol also assisted in the operation to track down the culprits and recovered around 27 million stolen login details and found $47 million worth of crypto assets tied to cybercriminals.
“During this action, 326 servers and 142 domains were actioned by law enforcement and the private sector partners, severely crippling the malware’s distribution network. By taking down these tools simultaneously, the collaboration between law enforcement and private parties has increased friction for cybercriminals, making it harder for attacks to succeed, spread, or recover,” Europol said.
Other firms that helped in “Operation Endgame” are ESET, IBM X-Force, ESET, Mitsui Bussan Secure Directions, and Bitsight.
According to Europol, another tool that disrupted Operation Endgame was SocGholish. It is a malware installer tied to the Russian cybercrime group Evil Corp. that distributes via hacked websites. If you visit such sites, you will be tricked into installing malware apps mimicking as browser extensions or genuine software.
IBM researchers have developed a new semiconductor architecture that could dramatically increase the number of transistors packed onto a silicon chip while improving both computing performance and energy efficiency. The company's experimental design, known as NanoStack, represents a departure from conventional chip scaling by expanding vertically instead of relying solely on shrinking transistor dimensions.
According to IBM, the new architecture has the potential to accommodate approximately 100 billion transistors on a silicon chip roughly the size of a fingernail. Although the technology remains in the research phase and is still years away from commercial manufacturing, the announcement underlines one of the industry's latest efforts to overcome the physical limitations confronting modern semiconductor development.
IBM says NanoStack is comparable to a 0.7-nanometre technology generation, placing it below the 1-nanometre threshold that has long been viewed as a significant milestone in chip manufacturing. While node names such as 2 nm or 0.7 nm no longer represent the exact physical dimensions of transistors, they generally indicate successive generations of manufacturing technology that deliver greater transistor density, improved performance, and lower power consumption.
In laboratory testing, IBM reported that its prototype achieved up to 50% higher performance than its previously demonstrated 2 nm research chip while consuming as much as 70% less energy under comparable conditions. Those improvements, if successfully translated into commercial manufacturing, could support faster artificial intelligence workloads, improve cloud computing efficiency, reduce power consumption in data centres, and extend battery life in mobile devices.
Rather than focusing exclusively on making individual transistors smaller, NanoStack introduces a new architectural approach by stacking multiple layers of transistors vertically. Traditional semiconductor manufacturing has primarily increased computing capability by placing more transistors across the surface of a silicon wafer. As transistor miniaturization approaches fundamental physical limits, researchers are increasingly exploring three-dimensional designs that use vertical space to continue increasing transistor density without proportionally expanding chip size.
Transistors serve as the fundamental electronic switches inside every processor, enabling calculations performed by smartphones, personal computers, gaming systems, enterprise servers, networking equipment, and the rapidly expanding infrastructure supporting artificial intelligence. As more transistors are integrated into a processor, chips are generally able to execute more operations simultaneously, improving computational performance across a wide range of applications.
The continued drive toward higher transistor density has historically been guided by Moore's Law, the observation that the number of transistors integrated onto a chip approximately doubles every two years. For decades, that trend has driven advances in computing performance while reducing the cost of processing power. However, maintaining that pace has become increasingly difficult as transistor dimensions approach atomic scales, where issues such as heat generation, electrical leakage, manufacturing complexity, and quantum effects become far more challenging to manage.
IBM's NanoStack architecture represents one possible response to those constraints by building upward rather than outward. Industry researchers often compare this concept to urban development. Instead of constructing additional houses across limited land, engineers create increasingly taller buildings to accommodate more occupants within the same footprint. Similarly, vertically stacking transistor layers allows exponentially more computing elements to occupy the same silicon area.
The concept also distinguishes IBM's research from other advanced semiconductor initiatives pursuing three-dimensional integration. While several major chip manufacturers have already adopted various forms of 3D packaging and transistor architectures, IBM's proposal seeks to extend vertical integration even further, reflecting the growing industry focus on architectural innovation as conventional transistor scaling becomes more difficult.
Despite its promise, vertically stacked semiconductor designs introduce substantial engineering challenges. Heat generated by densely packed transistors becomes more difficult to dissipate as additional layers are added, potentially affecting reliability and long-term performance. Extremely thin insulating materials separating transistors may also allow unintended electrical leakage, making it harder for components to switch cleanly between operating states. Engineers must additionally solve complex manufacturing problems involving layer alignment, interconnections between stacked components, power delivery, fabrication precision, and production yield before such architectures can be manufactured at commercial scale.
Although NanoStack remains an experimental technology, IBM's latest research illustrates how semiconductor innovation is evolving beyond simply reducing transistor size. Future advances are increasingly expected to depend on new chip architectures, advanced materials, and sophisticated three-dimensional integration techniques capable of delivering the computing performance required by artificial intelligence, high-performance computing, cloud infrastructure, and next-generation consumer electronics.
Security researchers have identified six vulnerabilities in the widely deployed U-Boot bootloader that could allow attackers to execute malicious code during the earliest stages of a device's startup process. If successfully exploited, the flaws could enable firmware-level attacks capable of bypassing security protections before the operating system loads and establishing malware designed to remain on affected systems.
As one of the most widely used open-source bootloaders, U-Boot plays a fundamental role in the startup sequence of embedded Linux devices by initializing hardware and loading the operating system. It is integrated into a broad range of technologies, including enterprise server Baseboard Management Controllers (BMCs), networking equipment, industrial control systems, Internet of Things (IoT) devices, and numerous other embedded appliances.
Because the bootloader executes before the operating system and endpoint security tools become active, vulnerabilities at this stage can have far-reaching consequences. An attacker who gains control during the boot process may be able to interfere with the system's trusted startup sequence before conventional security controls have an opportunity to detect or prevent malicious activity.
One of U-Boot's primary security mechanisms is Verified Boot, which uses cryptographic signatures to verify the authenticity of firmware and operating system images before they are executed. During startup, only images signed with a trusted cryptographic key are intended to be loaded, helping prevent unauthorized or modified firmware from running on the device.
In a technical report published this week, firmware security company Binarly disclosed six vulnerabilities affecting U-Boot's Flattened Image Tree (FIT) signature verification code. The FIT framework is responsible for validating firmware images during the boot process, making it a critical component of the platform's chain of trust.
According to Binarly, researchers examined the verification logic because of its importance in maintaining firmware integrity during startup. Their analysis uncovered six distinct vulnerabilities ranging from denial-of-service conditions that can interrupt the boot process to flaws capable of enabling arbitrary code execution while processing untrusted firmware images.
The researchers said two of the vulnerabilities could potentially allow arbitrary code execution during firmware verification, while the remaining four can be exploited to trigger crashes during the boot process. Since these weaknesses affect the validation of firmware before the operating system starts, a successful exploit could allow malicious instructions to execute before higher-level security mechanisms become operational.
The disclosed vulnerabilities include a flaw identified as BRLY-2026-037 that can cause U-Boot to crash when processing a specially crafted firmware image and, under certain conditions, may also permit arbitrary code execution. BRLY-2026-038 is a memory corruption vulnerability that could enable attackers to execute malicious code during firmware signature verification. BRLY-2026-039 involves an out-of-bounds read that may force U-Boot to access memory beyond the firmware image, resulting in a system crash. BRLY-2026-040 is a null pointer dereference vulnerability that allows crafted firmware images to terminate the bootloader unexpectedly. BRLY-2026-041 stems from insufficient validation of externally stored firmware data and can also be used to crash vulnerable systems. The sixth flaw, BRLY-2026-042, involves unbounded recursion that can exhaust available stack memory and prevent the bootloader from completing the startup process.
Binarly noted that much of the affected code has been present since U-Boot version 2013.07, meaning the vulnerabilities could impact more than 50 stable releases of the project. Because many hardware manufacturers maintain customized downstream versions of U-Boot within their own firmware, the potential exposure extends beyond the upstream project to a large number of commercial products deployed across multiple industries.
If the arbitrary code execution vulnerabilities are successfully exploited, attackers could gain execution during one of the earliest phases of system initialization. Operating at this level may allow threat actors to alter the boot sequence, disable firmware security mechanisms, deploy persistent firmware malware, or perform other privileged actions before the operating system begins loading.
Firmware-based attacks can also be considerably more difficult to identify than malware operating within the operating system. Since malicious activity occurs before the operating system initializes, traditional endpoint security software and many monitoring tools may have limited visibility into the compromise, allowing malicious modifications to remain undetected for extended periods.
Binarly also noted that exploitation does not necessarily require physical access to a device. Systems equipped with Baseboard Management Controllers that support remote firmware updates could become vulnerable if an attacker first compromises the management interface. In such cases, a specially crafted firmware image could be uploaded and processed during the update process, potentially triggering the identified vulnerabilities.
The researchers reported all six vulnerabilities to the U-Boot maintainers and submitted patches addressing each issue. Those fixes have since been accepted into the project's upstream codebase. However, because U-Boot is incorporated into firmware by individual hardware manufacturers, vendors must integrate the patches into their own firmware releases before updates become available to customers.
Organizations operating embedded systems should monitor firmware advisories issued by their hardware vendors and apply security updates as they become available. Restricting access to firmware management interfaces, securing remote administration services such as BMCs, and verifying firmware authenticity before deployment can further reduce exposure while patches are being distributed.
Devices that have reached end-of-life or no longer receive firmware updates may remain permanently vulnerable, underscoring the long-term security challenges posed by legacy embedded systems that continue operating long after vendor support has ended.