Google has addressed a security flaw in the Python SDK for Vertex AI after researchers demonstrated that attackers could potentially intercept machine learning model uploads and substitute them with malicious files.
The issue was identified by researchers from Palo Alto Networks' Unit 42 team, who disclosed the findings through Google's bug bounty program. According to the researchers, the vulnerability could be exploited without compromising a target organization's cloud environment, stealing credentials, or tricking users through phishing campaigns. Instead, the attack relied on weaknesses in how the SDK handled temporary storage locations during model uploads.
Researchers referred to the technique as "Pickle in the Middle." They reported no evidence that the flaw had been exploited outside of controlled testing environments. Google has since released security updates, and organizations using Vertex AI are advised to upgrade to version 1.148.0 or newer.
Predictable Storage Names Created an Opening
The vulnerability originated from the SDK's automatic staging process.
When developers uploaded a machine learning model without manually specifying a Cloud Storage bucket, the SDK generated a temporary bucket name based on information such as the Google Cloud project identifier and deployment region.
The problem was not that the bucket name could be predicted. The problem was that the SDK only checked whether the bucket existed. It did not verify whether that bucket belonged to the project performing the upload.
Because Cloud Storage bucket names are globally unique across Google Cloud, an attacker could create the expected bucket before the victim did. If that happened, model files uploaded by the victim could be redirected into infrastructure controlled by the attacker.
In practical terms, a developer could believe a model was being uploaded to their own cloud environment while the files were actually being delivered elsewhere.
Attackers Could Replace Models Before Deployment
After receiving the uploaded files, an attacker could modify or replace the model before Vertex AI retrieved it for deployment.
This becomes particularly important because many machine learning workflows rely on serialization formats such as Pickle and Joblib. These formats are commonly used to save trained models, but they also contain functionality capable of executing instructions when the file is loaded.
As a result, a manipulated model may do more than generate predictions. It can potentially run arbitrary code inside the environment responsible for serving the model.
Unit 42 researchers demonstrated that this behavior could be abused to execute attacker-controlled code inside Vertex AI's serving infrastructure.
Researchers Exploited a Narrow Timing Window
The attack required the malicious file replacement to occur very quickly.
During testing, researchers observed that Vertex AI typically retrieved uploaded files roughly 2.5 seconds after the upload process completed.
To exploit this short interval, they created an automated Cloud Function that monitored the attacker-controlled bucket and immediately replaced newly uploaded files. The replacement process took approximately 1.4 seconds, allowing the malicious model to be swapped before Vertex AI accessed it.
This timing-based attack demonstrated that the vulnerability was practical under the right conditions rather than being a purely theoretical risk.
Proof-of-Concept Reached Beyond a Single Model
After achieving code execution, researchers tested what level of access could be obtained from the serving environment.
Their proof-of-concept extracted an OAuth token from the container's metadata service and used it to interact with resources available within Google's managed infrastructure.
According to the report, the token provided visibility into additional machine learning assets, model artifacts, TensorFlow files, BigQuery metadata, access control information, system logs, Kubernetes cluster identifiers, and internal infrastructure references.
The findings suggested that a successful compromise could potentially expose information beyond the originally targeted model deployment.
Exploitation Required Specific Conditions
The vulnerability was not universally exploitable.
Researchers noted that two requirements had to be met before the attack could succeed.
First, the expected default staging bucket could not already exist in the chosen deployment region. Second, the developer needed to rely on the SDK's default bucket-generation behavior rather than specifying a storage bucket manually.
The researchers noted that newly created Vertex AI projects often satisfy the first condition because the default bucket may not yet have been created.
Google Introduced Multiple Fixes
Unit 42 reported the issue to Google on March 5, 2026.
Google's initial response introduced additional randomness into bucket names by appending a UUID value, making bucket prediction substantially more difficult.
The company later strengthened the mitigation by implementing ownership validation checks. These checks ensure that automatically selected buckets belong to the project initiating the upload, preventing bucket-squatting attacks from succeeding.
The ownership verification mechanism was included in Vertex AI SDK version 1.148.0.
At the time the researchers published their findings, neither Google's Vertex AI security advisories nor the research report listed a CVE identifier for the vulnerability.
Recommendations for Organizations
Security teams using Vertex AI should verify that all environments are running updated versions of the google-cloud-aiplatform package. This includes development notebooks, machine learning pipelines, automated build systems, testing environments, and production deployments.
Researchers also recommend explicitly defining a staging bucket owned by the organization instead of relying on SDK defaults. This reduces the risk of storage misconfigurations and provides greater visibility into where machine learning artifacts are stored during deployment.
The disclosure is the latest example of how weaknesses in supporting cloud infrastructure can affect AI systems. As organizations continue moving model development and deployment into managed cloud platforms, security reviews must extend beyond the model itself to include storage, deployment pipelines, permissions, and the services that support the AI lifecycle.
Security researchers have disclosed a now-remediated flaw that could have allowed specially crafted notifications from common messaging and social networking applications to influence the behavior of Google Gemini on Android devices.
The research was conducted by SafeBreach researcher Or Yair, who found that Gemini's ability to access and process notifications could be abused to deliver hidden instructions through otherwise legitimate messages. According to the findings, the technique did not rely on malware or a rogue application being installed on a target device. Instead, any service capable of sending a notification, including WhatsApp, Slack, Signal, Instagram, Messenger, or SMS, could potentially be used to deliver malicious content.
The study builds on SafeBreach's earlier "Invitation Is All You Need" research, which demonstrated how malicious Google Calendar invitations could manipulate Gemini through indirect prompt injection. Following that disclosure, Google introduced new safeguards designed to prevent external content from influencing sensitive actions. Yair's latest work examined whether similar manipulation could still occur through a different source of user data.
At the center of the issue was Gemini's Utilities feature on Android. The functionality allows the assistant to read, manage, and respond to notifications from connected applications. Researchers found that under certain circumstances, notification text could be interpreted not only as information but also as instructions that influenced the assistant's responses and actions.
Because the feature is available on Android devices and not through Gemini's web version or iOS implementation, the attack scenario was limited to Android users who had granted Gemini access to notifications.
According to SafeBreach, the number of potential entry points was unusually large because notifications can originate from countless applications and online services. This meant attackers would not necessarily need direct access to a device. Delivering a crafted notification could be sufficient to introduce malicious instructions into Gemini's processing workflow.
One of the simpler demonstrations involved altering the information Gemini presented to users. Researchers showed that manipulated notifications could cause the assistant to relay fabricated messages while making them appear to originate from legitimate contacts. In some scenarios, Gemini could process real notifications first and then attribute attacker-controlled content to an actual sender already present in the notification queue.
The researchers noted that this type of deception could be particularly effective when users interact with Gemini through voice. For example, someone driving a vehicle may hear a message that appears to come from a manager, colleague, or trusted contact and have little opportunity to verify the information displayed on the screen.
The research also examined Google's post-Calendar security protections. According to Yair, Gemini included mechanisms intended to prevent sensitive actions from being triggered without proper authorization. These checks evaluated both the user's response and the assistant's preceding output to determine whether a requested action was consistent with the conversation.
During testing, direct attempts to inject hidden commands were repeatedly blocked. To overcome these restrictions, Yair developed a technique called "Fake Context Alignment," which sought to make a user's approval appear valid to Gemini's authorization system while obscuring the true request from the user.
One variation involved displaying a sensitive authorization prompt in a language unfamiliar to the victim. Researchers used an example where a request such as "Do you want to open the window?" appeared in Chinese while a harmless English-language question followed. If the user responded with "Yes," Gemini could potentially associate that response with the hidden authorization request rather than the visible conversation.
A second technique relied on differences between information displayed on-screen and information spoken aloud by Gemini's text-to-speech system. Researchers found that certain hidden content embedded within hyperlinks might not be read aloud. In a demonstration, the visible interface contained a sensitive authorization request while the spoken response presented a routine message, increasing the likelihood that a user would unknowingly approve an action.
SafeBreach reported that combining these techniques increased the chances of bypassing the authorization safeguards that Google had introduced after the earlier Calendar-based attack research.
Once authorization was obtained, the researchers demonstrated several potential outcomes. Through integrations with Google Home, Gemini could interact with connected smart-home devices, including windows, lighting systems, and boilers. Additional demonstrations involved opening websites that could expose a user's approximate location through IP address information or trigger file downloads.
The research also explored interactions with third-party applications. In one proof-of-concept scenario, Gemini followed a trusted web address that later redirected to a Zoom link, resulting in the device joining an online meeting. SafeBreach emphasized that this occurred within a controlled testing environment and stated that its own public domain was not configured to redirect users to Zoom. Instead, the redirect was performed through a local test server used during the demonstration.
Researchers additionally identified a persistence mechanism involving Gemini's memory capabilities. Unlike the earlier Calendar-based research, the notification technique enabled the assistant to store attacker-controlled information as long-term memory. In one demonstration, Gemini was persuaded to remember an incorrect name for the user. Because memory is associated with a Google account rather than a single device, inaccurate information could potentially appear wherever that account later accessed Gemini.
The study also demonstrated the creation of recurring automated tasks. Researchers showed that instructions could potentially be scheduled to execute repeatedly, including examples involving regular access to recent messages at specific times.
SafeBreach disclosed the findings to Google's Vulnerability Reward Program on August 17, 2025. Google classified the report as a high-priority issue and later confirmed that changes to its content-classification systems mitigated both the notification-based prompt injection technique and the related authorization bypass method. The company confirmed the remediation on November 14, 2025.
No CVE identifier was assigned to the issue, and SafeBreach stated that it found no evidence indicating the technique had been exploited in real-world attacks before the fixes were implemented.
Because Google's mitigation was deployed through server-side updates, users did not need to install a software update to receive protection. However, individuals seeking additional safeguards can restrict Gemini's access to notifications by disabling the Utilities feature through Connected Apps settings or by revoking the Google app's notification-reading permissions on Android.
The findings provide another example of the security challenges that emerge as AI assistants gain access to messages, notifications, calendars, and connected services. As these systems become increasingly capable of performing actions on behalf of users, researchers continue to examine how external content can influence AI-driven decision-making and whether existing safeguards are sufficient to prevent misuse.
A newly identified infostealer called Storm has emerged on underground cybercrime forums in early 2026, signalling a change in how attackers steal and use credentials. Priced at under $1,000 per month, the malware collects browser-stored data such as login credentials, session cookies, and cryptocurrency wallet information, then covertly transfers the data to attacker-controlled servers where it is decrypted outside the victim’s system.
This change becomes clearer when compared to earlier techniques. Traditionally, infostealers decrypted browser credentials directly on infected machines by loading SQLite libraries and accessing local credential databases. Because of this, endpoint security tools learned to treat such database access as one of the strongest indicators of malicious activity.
The approach began to break down after Google Chrome introduced App-Bound Encryption in version 127 in July 2024. This mechanism tied encryption keys to the browser environment itself, making local decryption exponentially more difficult. Initial bypass attempts relied on injecting into browser processes or exploiting debugging protocols, but these techniques still generated detectable traces.
Storm avoids this entirely by skipping local decryption. Instead, it extracts encrypted browser files and quietly sends them to attacker infrastructure, removing the behavioural signals that endpoint tools typically rely on. It extends this model by supporting both Chromium-based browsers and Gecko-based browsers such as Firefox, Waterfox, and Pale Moon, whereas tools like StealC V2 still handle Firefox data locally.
The data collected includes saved passwords, session cookies, autofill entries, Google account tokens, payment card details, and browsing history. This combination gives attackers everything required to rebuild authenticated sessions remotely. In practice, a single compromised employee browser can provide direct access to SaaS platforms, internal systems, and cloud environments without triggering any password-based alerts.
Storm also automates session hijacking. Once decrypted, credentials and cookies appear in the attacker’s control panel. By supplying a valid Google refresh token along with a geographically matched SOCKS5 proxy, the platform can silently recreate the victim’s active session.
This technique aligns with earlier research by Varonis Threat Labs. Its Cookie-Bite study showed that stolen Azure Entra ID session cookies can bypass multi-factor authentication, granting persistent access to Microsoft 365. Similarly, its SessionShark analysis demonstrated how phishing kits intercept session tokens in real time to defeat MFA protections. Storm packages these methods into a commercial subscription service.
Beyond credentials, the malware collects files from user directories, extracts session data from applications like Telegram, Signal, and Discord, and targets cryptocurrency wallets through browser extensions and desktop applications. It also gathers system information and captures screenshots across multiple monitors. Most operations run in memory, reducing the likelihood of detection.
Its infrastructure design adds resilience. Operators connect their own virtual private servers to Storm’s central system, routing stolen data through infrastructure they control. This setup limits the impact of takedowns, as enforcement actions are more likely to affect individual operator nodes rather than the core service.
Storm supports multi-user operations, allowing teams to divide responsibilities such as log access, malware build generation, and session restoration. It also automatically categorises stolen credentials by service, with visible rules for platforms including Google, Facebook, Twitter/X, and cPanel, helping attackers prioritise targets.
At the time of analysis, the control panel displayed 1,715 log entries linked to locations including India, the United States, Brazil, Indonesia, Ecuador, and Vietnam. While it is unclear whether all entries represent real victims or test data, variations in IP addresses, internet service providers, and data volumes suggest ongoing campaigns.
The logs include credentials associated with platforms such as Google, Facebook, Twitter/X, Coinbase, Binance, Blockchain.com, and Crypto.com. Such information often feeds into underground credential marketplaces, enabling account takeovers, fraud, and more targeted intrusions.
Storm is offered through a tiered pricing model: $300 for a seven-day trial, $900 per month for standard access, and $1,800 per month for a team licence supporting up to 100 operators and 200 builds. Use of an additional crypter is required. Notably, once deployed, malware builds continue operating even after a subscription expires, allowing ongoing data collection.
Security researchers view Storm as part of a broader evolution in credential theft. By shifting decryption to remote servers, attackers avoid detection mechanisms designed to identify on-device activity. At the same time, session cookie theft is increasingly replacing password theft as the primary objective.
The data collected by such tools often marks the beginning of further attacks, including logins from unusual locations, lateral movement within networks, and unauthorised access patterns.
Indicators of compromise include:
Alias: StormStealer
Forum ID: 221756
Registration date: December 12, 2025
Current version: v0.0.2.0 (Gunnar)
Build details: Developed in C++ (MSVC/msbuild), approximately 460 KB in size, targeting Windows systems
This advent of Storm underlines how cybercriminal tools are becoming more advanced, automated, and difficult to detect, requiring organisations to strengthen monitoring of sessions, user behaviour, and access patterns rather than relying solely on traditional credential protection methods.
Google has introduced one of the most extensive updates to Gmail in its history, warning that the scale of change driven by artificial intelligence may feel overwhelming for users. While some discussions have focused on surface-level changes such as switching email addresses, the company has emphasized that the real transformation lies in how AI is now embedded into everyday tools used by nearly two billion people. This shift requires far more serious attention.
At the center of this evolution is Gemini, Google’s artificial intelligence system, which is being integrated more deeply into Gmail and other core services. In a recent update shared through a short video message, Gmail’s product leadership acknowledged that the rapid pace of AI innovation can leave users feeling overloaded, with too many new features and decisions emerging at once.
Gmail has traditionally been built around convenience, scale, and seamless integration rather than strict privacy-first principles. Although its spam filters and malware detection systems are widely used and generally effective, they are not flawless. Importantly, Gmail has not typically been the platform users turn to for strong privacy assurances.
The introduction of Gemini changes this bbalance substantially. Google has clarified that it does not use email content to train its AI models. However, the way these tools function introduces new concerns. Features that automatically draft emails, summarize conversations, or search inbox content require access to emails that may contain highly sensitive personal or professional information.
To address this, Google describes Gemini as a temporary assistant that operates within a limited session. The company compares this interaction to allowing a helper into a private room containing your inbox. The assistant completes its task and then exits, with the accessed information disappearing afterward. According to Google, Gemini does not retain or learn from the data it processes during these interactions.
Despite these assurances, concerns remain. Even if the data is not stored long term, granting a cloud-based AI system access to private communications introduces an inherent level of risk. Additionally, while Google has denied automatically enrolling users into AI training programs, many of these AI-powered features are expected to be enabled by default. This shifts responsibility to users, who must actively decide how much access they are willing to allow.
This is not a decision that can be ignored. Once AI tools become integrated into daily workflows, they are difficult to remove. Relying on default settings or delaying action could result in long-term dependence on systems that users may not fully understand or control.
Shortly after promoting these updates, Gmail experienced a disruption that affected its core functionality. Users reported delays in sending and receiving emails, and Google acknowledged the issue while working on a fix. Initially, no estimated resolution time was provided. Later the same day, the company confirmed that the issue had been resolved.
According to Google’s official status update, the disruption was fixed on April 8, 2026, at 14:49 PDT. The cause was identified as a “noisy neighbor,” a term used in cloud computing to describe a situation where one service consumes excessive shared resources, negatively impacting the performance of others operating on the same infrastructure.
With a user base of approximately two billion, even a short-lived outage becomes of grave concern. More importantly, it emphasises the scale at which Gmail operates and reinforces why decisions around AI integration are critical for users worldwide.
The central issue now facing users is the balance between convenience and security. Google presents Gemini as a helpful and well-behaved assistant that enhances productivity without overstepping boundaries. However, like any guest given access to a private space, it requires clear rules and careful oversight.
This tension becomes even more visible when considering Google’s parallel efforts to strengthen security. The company recently expanded client-side encryption for Gmail on mobile devices. While this may sound similar to end-to-end encryption used in messaging apps, it is not the same. This form of encryption operates at an organizational level, primarily for enterprise users, and does not provide the same device-specific privacy protections commonly associated with true end-to-end encryption.
More critically, enabling this additional layer of encryption dynamically limits Gmail’s functionality. When it is turned on, several features become unavailable. Users can no longer use confidential mode, access delegated accounts, apply advanced email layouts, or send bulk emails using multi-send options. Features such as suggested meeting times, pop-out or full-screen compose windows, and sending emails to group recipients are also disabled.
In addition, personalization and usability tools are affected. Email signatures, emojis, and printing functions stop working. AI-powered tools, including Google’s intelligent writing and assistance features, are also unavailable. Other smart Gmail features are disabled, and certain mobile capabilities, such as screen recording and taking screenshots on Android devices, are restricted.
These limitations exist because encrypted data cannot be accessed by AI systems. As a result, users are forced to choose between stronger data protection and access to advanced features. The same mechanisms that secure information also prevent AI tools from functioning effectively.
This reflects a bigger challenge across the technology industry. Privacy and security measures often limit the capabilities of AI systems, which depend on access to data to operate. In Gmail’s case, these two priorities do not align easily and, in many ways, directly conflict.
From a wider perspective, this also highlights a fundamental limitation of email itself. The technology was developed in an earlier era and was not designed to handle modern cybersecurity threats. Its underlying structure lacks the robust protections found in newer communication platforms.
As artificial intelligence becomes more deeply integrated into everyday tools, users are being asked to make more informed and deliberate decisions about how their data is used. While Google presents Gemini as a controlled and temporary assistant, the responsibility ultimately lies with users to determine their comfort level.
For highly sensitive communication, relying solely on email may no longer be the safest option. Exploring alternative platforms with stronger built-in security may be necessary. Ultimately, this moment represents a critical choice: whether the convenience offered by AI is worth the level of access it requires.
More than 500 million devices currently running Windows 10 are approaching a critical turning point, as many of them are not eligible for an upgrade to Windows 11 due to hardware limitations. This has raised growing concerns about long-term security risks once support deadlines pass. In response, Google is actively promoting an alternative, positioning its ChromeOS Flex platform as a free way to modernize aging systems.
Google states that older laptops and desktops can be converted into faster, more secure, and easier-to-manage devices by installing ChromeOS Flex. The system is cloud-based and designed to extend the usability of existing hardware without requiring users to purchase new machines. Although ChromeOS Flex has been available for some time, Google has now made adoption simpler by introducing a physical USB installation kit. Developed in partnership with Back Market, the kit allows users to install the operating system more easily. It is priced at approximately $3 or €3, is reusable, and is supported by recycling-focused efforts such as Closing the Loop to reduce electronic waste.
The timing of this push is closely linked to Microsoft’s decision to end mainstream support for Windows 10 in October 2025. That shift has forced users into a difficult position: invest in new hardware or continue using an operating system that will no longer receive full security updates. While Microsoft does offer an Extended Security Updates (ESU) program, it is only a temporary solution. For individual users, coverage extends for roughly one additional year, while enterprise customers may receive longer support under specific licensing agreements.
The transition to Windows 11 has also been slower than expected. Adoption challenges, largely driven by strict hardware requirements, have resulted in an unusually large number of users remaining on Windows 10 even after its official lifecycle milestone. This contrasts with Microsoft’s earlier expectations of a smoother migration similar to the shift from Windows 7 to Windows 10, which had seen broader and faster adoption.
Google is also emphasizing environmental considerations as part of its messaging. The company highlights that manufacturing a new laptop contributes significantly to its overall carbon footprint. By extending the lifespan of existing devices, ChromeOS Flex helps reduce landfill waste and avoids emissions associated with producing new hardware. Google further claims that ChromeOS-based systems consume around 19% less energy on average compared to similar platforms.
Despite this, switching away from Windows remains a debated decision. Many users rely on the Windows ecosystem for software compatibility, workflows, and familiarity. However, for devices that cannot support Windows 11, alternatives such as ChromeOS Flex present a practical workaround. Even in cases where users purchase new computers, older machines can still be repurposed using such operating systems, for example within households.
At the same time, Microsoft is continuing to strengthen its Windows 11 ecosystem. Devices already running Windows 11 are being automatically updated to newer versions to maintain consistent security coverage. The company is using artificial intelligence to determine when systems are ready for upgrades and applying updates accordingly. While a similar approach could theoretically be applied to Windows 10 devices that meet upgrade requirements, this has not yet been implemented. It remains uncertain whether this could change as future deadlines approach.
Recent developments have also drawn attention to user hesitation around Windows 11. Reports indicated that a recent update disrupted a key Start menu function, even as official communication suggested there were no outstanding issues. Subsequent updates and documentation now indicate that previously known bugs have been resolved, with Microsoft steadily addressing issues since the platform’s release in late 2024.
Additional reporting suggests that all known issues in the current Windows 11 version have been marked as resolved in official tracking systems. This reflects ongoing improvements, though it also underlines the complexity of maintaining stability across large-scale operating system deployments.
For enterprise users, Microsoft is extending support in more flexible ways. Certain legacy versions of Windows 10, including enterprise and IoT editions released in 2016, are eligible for additional security updates. These updates are delivered through ESU programs available via volume licensing or cloud solution providers. However, Microsoft continues to describe this as a temporary measure rather than a permanent extension.
For individual users, the situation is more restrictive. Extended Security Updates are limited in duration, and once they expire, devices will no longer receive security patches, bug fixes, or technical support. However, the continued availability of such programs suggests that support timelines may evolve depending on broader user adoption patterns.
The wider ecosystem is also seeing alternative recommendations. Some industry discussions encourage migration to Linux-based systems, while Google’s ChromeOS Flex represents a more consumer-friendly option. With hundreds of millions of devices affected, the coming months will play a crucial role in determining whether users remain within the Windows ecosystem or begin shifting toward alternative platforms.
Privacy issues have always bothered users and business organizations. With the rapid adoption of AI, the threats are also rising. DuckDuckGo’s Duck.ai chatbot benefits from this.
The latest report from Similarweb revealed that traffic to Duck.ai increased rapidly last month. The traffic recorded 11.1 million visits in February 2026, 300% more than January.
The statistics seem small when compared with the most popular chatbots such as ChatGPT, Claude, or Gemini.
Similarweb estimates that ChatGPT recorded 5.4 billion visits in February 2026, and Google’s Gemini recorded 2.1 billion, whereas Claude recorded 290.3 million.
For DuckDuckGo, the numbers show a good sign, as the bot was launched as beta in 2025, and has shown a sharp rise in visits.
DuckDuckGo browser is known for its privacy, and the company aims to apply the same principle to its AI bot. Duck.ai doesn't run a bespoke LLM, it uses frontier models from Meta, Anthropic, and OpenAI, but it doesn't expose your IP address and personal data.
Duck.ai's privacy policy reads, "In addition, we have agreements in place with all model providers that further limit how they can use data from these anonymous requests, including not using Prompts and Outputs to develop or improve their models, as well as deleting all information received once it is no longer necessary to provide Outputs (at most within 30 days, with limited exceptions for safety and legal compliance),”
What is the reason for this sudden surge? The bot has two advantages over individual commercial bots like ChatGPT and Gemini, it offers an option to toggle between multiple models and better privacy security. The privacy aspect sets it apart. Users on Reddit have praised Duck.ai, one person noting "it's way better than Google's," which means Gemini.
In March, Anthropic rejected a few applications of its technology for mass surveillance and weapons submitted by the Department of Defense. The DoD retaliated by breaking the contract. Soon after, OpenAI stepped in.
The incident stirred controversies around privacy concerns and ethical AI use. This explains why users may prefer chatbots like Duck.ai that safeguard user data from both the government and the big tech.
Google has formally begun rolling out a comprehensive verification framework for Android developers, a move aimed at tackling the persistent problem of malicious applications being distributed by actors who operate without revealing their identity. The company’s decision reflects growing concerns within the mobile ecosystem, where anonymity has often enabled bad actors to bypass accountability and circulate harmful software at scale.
This rollout comes in advance of a stricter compliance requirement that will first take effect in September across key markets including Brazil, Indonesia, Singapore, and Thailand. These regions are being used as initial enforcement zones before the policy is gradually expanded worldwide next year, signaling Google’s intent to standardize developer accountability across its global Android ecosystem.
Under the new system, developers who distribute Android applications outside of the official Google Play marketplace will now be required to register through the Android Developer Console and verify their identity credentials. This requirement is particularly substantial for developers who rely on alternative distribution methods such as direct APK sharing, enterprise deployment, or third-party app stores, as it introduces a layer of traceability that previously did not exist.
At the same time, Google clarified that developers already publishing applications through Google Play and who have completed existing identity verification processes may not need to take further action. In such cases, their applications are likely to already comply with the updated requirements, reducing friction for those operating within the official ecosystem.
Explaining how this change will affect end users, Matthew Forsythe, Director of Product Management for Android App Safety, emphasized that the vast majority of users will not notice any difference in their day-to-day app installation experience. Standard app downloads from trusted sources will continue to function as usual, ensuring that usability is not compromised for the general public.
However, the experience changes when a user attempts to install an application that has not been registered under the new verification system. In such cases, users will be required to proceed through more advanced installation pathways, such as Android Debug Bridge or similar technical workflows. These methods are typically used by developers and experienced users, which effectively limits exposure for less technical individuals.
This design introduces a deliberate separation between general users and advanced users. While everyday users are shielded from potentially unsafe applications, power users retain the flexibility to install software manually, albeit with additional steps that reinforce intentional decision-making.
To further support developers, Google is integrating visibility into its core development tools. Within the next two months, developers using Android Studio will be able to directly view whether their applications are registered under the new system at the time of generating signed App Bundles or APK files. This integration ensures that compliance status becomes part of the development workflow rather than a separate administrative task.
For developers who have already completed identity verification through the Play Console, Google will automatically register eligible applications under the new framework. This automation reduces operational overhead and ensures a smoother transition. However, in cases where applications cannot be automatically registered, developers will be required to complete a manual claim process to verify ownership and bring those apps into compliance.
In earlier guidance, Google also outlined how sideloading, the practice of installing apps from outside official stores, will function under this system. Advanced users will still be able to install unregistered APK files, but only after completing a multi-step verification process designed to confirm their intent.
This process includes an authentication step to verify the user’s decision, followed by a one-time waiting period of up to 24 hours. The delay is not arbitrary. It is specifically designed to disrupt scam scenarios in which attackers pressure users into quickly installing malicious applications before they have time to reconsider.
Forsythe explained that although this process is required only once for experienced users, it has been carefully structured to counter high-pressure social engineering tactics. By introducing friction into the installation process, the system aims to reduce the success rate of scams that rely on urgency and manipulation.
This development is part of a wider industry tendency toward tightening control over app ecosystems and improving user data protection. In a parallel move, Apple has recently updated its Developer Program License Agreement to impose stricter rules on how third-party wearable applications handle sensitive data such as live activity updates and notifications.
Under Apple’s revised policies, developers are explicitly prohibited from using forwarded data for purposes such as advertising, user profiling, training machine learning models, or tracking user location. These restrictions are intended to prevent misuse of real-time user data beyond its original functional purpose.
Additionally, developers are not allowed to share this forwarded information with other applications or devices, except for authorized accessories that are explicitly approved within Apple’s ecosystem. This ensures tighter control over how data flows between devices.
The updated agreement also introduces further limitations. Developers are barred from storing this data on external cloud servers, altering its meaning in ways that change the original content, or decrypting the information anywhere other than on the designated accessory device. These measures collectively aim to preserve data integrity and minimize the risk of misuse.
Taken together, this charts a new course across the technology industry toward stronger governance of developer behavior, application distribution, and data handling practices. As threats such as malware distribution, financial fraud, and data exploitation continue to evolve, platform providers are increasingly prioritizing transparency, accountability, and user protection in their security strategies.
Hackers associated with North Korea hacked the behind-the-scenes software that operates various online functions to steal login credentials that could trigger cyber operations, according to Google.
Threat actors hacked Axios, a program that links apps and web services, by installing their malicious software in an update. An expert at Sentinel said that “Every time you load a website, check your bank balance, or open an app on your phone, there’s a good chance Axios is running somewhere in the background making that work.”
The malicious software has been removed. But if it were successful, it could carry out data theft and other cyberattacks. The software is open-source, not a proprietary commercial product. This means the code can be openly licensed and changed by the users.
Experts described the incident as a supply chain attack in which hackers could compromise downstream entities. According to experts, you don’t have to click anything or make a mistake, as the software you trust does it for you.
Google attributed the hack to a group it tracks as UNC1069. In a February report, Google stated that the group has been active since at least 2018 and is well-known for focusing on the banking and cryptocurrency sectors.
According to a statement from John Hultquist, principal analyst for Google's threat intelligence group, "North Korean hackers have deep experience with supply chain attacks, which they primarily use to steal cryptocurrency."
The U.S. government claims that North Korea uses stolen cryptocurrency to finance its weapons and other initiatives while avoiding sanctions.
A request for comment was not immediately answered by North Korea's mission to the United Nations.
The hackers created versions of the malware that could infect macOS, Windows, and Linux operating systems, according to an analysis published by cybersecurity firm Elastic Security.
According to Elastic, "the attacker gained a delivery mechanism with potential reach into millions of environments" as a result of the hackers' techniques. The number of times the dangerous program was downloaded was unclear.
Attempts to get in touch with the hackers failed.