Listen to this Post
A New Warning for the npm Ecosystem
The npm ecosystem is facing another disturbing reminder that software supply-chain attacks are becoming more creative, stealthy, and difficult to detect. Security researchers have uncovered six malicious npm packages that use an attacker-controlled Ethereum wallet as a hidden delivery mechanism for malware infrastructure.
Instead of hard-coding command-and-control servers directly into JavaScript, the packages query the Ethereum blockchain and extract network information from a transaction. The blockchain effectively becomes a dead drop: an attacker can change the infrastructure without having to republish the malicious package.
The discovery is particularly concerning because the campaign combines several techniques already associated with sophisticated supply-chain operations, including package hijacking, disguised functionality, multi-stage payload delivery, and blockchain-based infrastructure resolution.
Sonatype Discovers Six Malicious Packages
Sonatype Research Labs identified the six packages on August 10, 2026, and published its analysis the same day.
The researchers are tracking the activity under sonatype-2026-005899 and sonatype-2026-005901. All six packages contain essentially the same underlying malicious payload, despite being presented as different npm projects.
The affected packages are:
@kolbo/mcp
agentgui
godot-kit
envpack-conf
postcss-initial-provider
tailwindcss-motion-advanced
The investigation found that the packages did not simply connect to a fixed malicious IP address. Instead, their loader contacted the Ethereum network, searched for a specific outbound transaction from an attacker-controlled wallet, and extracted data from the transaction that ultimately revealed the malware’s next C2 infrastructure.
Ethereum Becomes Part of the Attack Chain
The most interesting part of this campaign is how the attackers use cryptocurrency infrastructure.
Normally, malware contains a hard-coded command-and-control address or retrieves one from a remote configuration server. That creates a weakness for the attacker: security researchers can identify the server, block it, or take it offline.
The npm malware takes a different approach.
The malicious loader queries Ethereum for a transaction associated with a specific wallet. It then reads bytes embedded in the transaction’s recipient address.
Those bytes are decoded as two IPv4 addresses.
The first address acts as the primary C2 endpoint, while the second serves as a backup.
The blockchain therefore
That distinction is important.
Why a Blockchain Dead Drop Is So Effective
Using blockchain data as an infrastructure-discovery mechanism gives attackers an unusual degree of flexibility.
Once the malicious npm package has been published, the attackers can potentially change the infrastructure referenced by the package simply by creating or modifying the relevant blockchain transaction.
The package does not necessarily need to be updated.
The attacker-controlled wallet becomes a kind of publicly accessible configuration channel.
Anyone running the malicious package can query the blockchain and receive the latest infrastructure information.
This is one reason blockchain-based malware communication has attracted increasing attention from security researchers. Public blockchains are difficult to censor globally, widely replicated, and designed to preserve transaction history.
For an attacker, that creates a resilient rendezvous mechanism.
Sonatype Finds More Than a Simple Loader
The investigation revealed that the malware was more sophisticated than previously documented examples of the technique.
The loader could communicate with multiple Ethereum RPC providers rather than depending on a single blockchain gateway.
It could also race requests against several providers, allowing it to use whichever response arrived first.
The code supported batching requests as well, improving efficiency when interacting with blockchain infrastructure.
If those mechanisms failed, the malware had another fallback.
It could turn to the Blockscout API to locate the necessary transaction.
This redundancy matters because malware operators understand that individual infrastructure providers can be blocked or disrupted.
Instead of creating one point of failure, the attackers built multiple paths to the same information.
The Malware Has a Second Fallback
The resilience does not stop at blockchain retrieval.
After determining the C2 addresses, the loader contacts the server and attempts to retrieve additional payload stages.
If the normal request fails, the malware can retry and attempt to recover the payload from a response header.
That gives the attackers yet another method of delivering their next stage.
The downloaded content is then decoded and can either execute directly within the existing Node.js process or be launched as a detached child process.
This creates multiple execution paths and makes the loader more flexible than a simple malicious npm install script.
The Attack Uses a Multi-Stage Architecture
The architecture can be simplified into a chain:
npm package → malicious loader → Ethereum wallet → blockchain transaction → C2 IP addresses → second-stage payload → execution
This approach separates the initial infection mechanism from the infrastructure used for later stages.
That separation is valuable to attackers because defenders may identify one component without immediately discovering the entire campaign.
If the C2 infrastructure changes, the attackers can potentially update the blockchain-controlled pointer instead of changing every infected package.
Three Legitimate Packages Were Hijacked
Sonatype identified two distinct routes through which the malware reached npm users.
Three of the packages appear to have been legitimate projects whose publishing accounts were compromised:
@kolbo/mcp
agentgui
godot-kit
The attackers did not completely replace the original software.
Instead, the malicious loader was appended to an existing file while the original functionality remained available.
That is a particularly dangerous tactic because users may install the package, run it successfully, and never realize that malicious code has been added alongside the legitimate functionality.
Trust Becomes the Weapon
This is where package hijacking becomes particularly dangerous.
Developers naturally trust packages they recognize.
A package that has existed for months or years, has documentation, has legitimate functionality, and appears to behave normally can receive significantly less scrutiny than a newly created package with an obviously suspicious name.
Attackers exploit that trust.
The malicious code can hide behind the reputation of the original project while the package continues performing its expected job.
For security teams, this means that reputation alone can no longer be treated as proof of package safety.
Three Packages Were Built for the Attack
The other three packages appear to have been created with malicious functionality already embedded:
envpack-conf
postcss-initial-provider
tailwindcss-motion-advanced
Unlike the hijacked projects, these packages were not simply modified versions of previously trusted software.
They were published with plausible functionality designed to make them appear useful.
One contained package-configuration functionality.
Another provided a working PostCSS plugin.
The third concealed the loader inside a minified utility file.
Why Purpose-Built Packages Still Matter
Purpose-built malicious packages often rely on social engineering and naming.
An attacker does not necessarily need a famous package.
They may instead create a name that sounds sufficiently legitimate to appear in search results, developer discussions, automated suggestions, or dependency-resolution workflows.
This is particularly dangerous in modern development environments where developers increasingly use AI coding assistants and automated tooling to discover packages.
A malicious package with a convincing name can potentially become part of a project before a human carefully examines its source.
The Connection to DPRK-Linked Activity
The Ethereum wallet used by the campaign matches a wallet previously documented by researchers at OpenSourceMalware.
Those researchers referred to the technique as NullReceiver and associated the activity they investigated with the DPRK-linked Contagious Interview campaign, which has been connected to the Lazarus group.
Sonatype independently confirmed the wallet match and identified similarities in the tradecraft.
The researchers also noted similarities involving package hijacking and blockchain-based retrieval of follow-on infrastructure.
Attribution should nevertheless be treated carefully.
A matching wallet and overlapping techniques can provide strong investigative clues, but infrastructure can sometimes be reused, copied, or deliberately imitated.
The technical behavior is therefore more important for defenders than the attribution label itself.
The Broader Pattern: Supply-Chain Attacks Are Evolving
The npm ecosystem has repeatedly demonstrated why software dependencies are such an attractive target.
Developers rarely inspect every line of every dependency.
Modern applications can contain hundreds or thousands of packages, including transitive dependencies that developers may never knowingly select.
That creates an enormous attack surface.
The attackers do not necessarily need to compromise the final application directly.
They can target something the application trusts.
And once malicious code enters the dependency chain, it can potentially inherit the application’s permissions, credentials, network access, filesystem access, and build environment.
AI Development Makes the Problem More Complicated
The timing is especially significant as AI-assisted development becomes increasingly common.
AI coding assistants can suggest packages, generate installation commands, write dependency declarations, and assemble projects at extraordinary speed.
That productivity comes with a security challenge.
If an AI system encounters a package with a convincing name and plausible documentation, it may recommend the package without understanding its reputation or supply-chain history.
This creates a new question for development teams:
Can an automated coding workflow distinguish useful software from a carefully disguised supply-chain trap?
The answer cannot simply be “trust the AI.”
Dependency verification has to become part of the automated workflow.
What Makes This Campaign Different?
The most notable feature is not simply that six npm packages contained malware.
Malicious npm packages are unfortunately nothing new.
What makes this campaign stand out is the infrastructure architecture.
The attackers have separated several components:
Package layer: delivers the loader.
Blockchain layer: provides dynamic infrastructure information.
C2 layer: delivers additional payloads.
Execution layer: runs the recovered malware.
Each layer can potentially change independently.
That creates a more flexible attack system.
Deep Analysis: How the Attack Chain Works
From a defensive perspective, security teams should think about the package as a loader rather than the complete malware.
The following conceptual flow represents what the researchers observed:
npm install | v
Malicious JavaScript loader
|
v
Query Ethereum RPC providers
|
v
Locate attacker-controlled transaction
|
v
Extract encoded bytes
|
v
Decode IPv4 addresses
|
+> Primary C2 | +> Secondary C2 | v
Retrieve second stage
|
v
Decode downloaded payload
|
+++
| |
v v
Node.js process Child process
The important defensive lesson is that simply blocking the observed C2 addresses may not be sufficient.
The package can potentially obtain different addresses through the blockchain.
Deep Analysis: Investigating Installed Packages
Organizations should begin by identifying whether any affected package versions exist in development machines, CI/CD runners, production servers, containers, or build environments.
A basic npm inventory can start with:
npm ls --all
For projects using lockfiles, defenders should also search the dependency metadata:
grep -RniE \n'@kolbo/mcp|agentgui|godot-kit|envpack-conf|postcss-initial-provider|tailwindcss-motion-advanced' \npackage.json package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml 2>/dev/null
The goal is not simply to find direct dependencies.
Security teams should also investigate whether the packages were pulled in transitively.
Deep Analysis: Examine Package Contents
If an affected package is discovered, do not immediately assume that deleting the package completes the investigation.
First preserve evidence where appropriate.
Then inspect the installed package and its installation metadata.
For example:
npm cache ls npm ls <package-name>
Defenders can also inspect JavaScript files for suspicious network and process-execution behavior:
grep -RniE \n'child_process|exec|spawn|eval|fetch|axios|http|https|ethereum|rpc|blockscout' \nnode_modules/<package-name> 2>/dev/null
These commands are useful for triage, but they are not proof that a package is malicious. Legitimate packages can also use networking or process-management APIs.
Deep Analysis: Search for Blockchain Indicators
Because this campaign uses Ethereum as an infrastructure-discovery mechanism, traditional indicators such as IP addresses may not be enough.
Defenders should look for code referencing:
eth_call
eth_getTransactionByHash
eth_getLogs
Ethereum RPC endpoints
Blockscout
wallet addresses
transaction hashes
hexadecimal decoding
IPv4 conversion
Security monitoring should therefore consider both traditional network indicators and blockchain-related infrastructure.
Deep Analysis: Investigate Node.js Execution
A second-stage payload executed inside a Node.js environment can have access to significant privileges depending on where the package runs.
CI/CD systems deserve particular attention.
Build runners often contain:
NPM tokens
Git credentials
Cloud credentials
SSH keys
Environment variables
API keys
Signing credentials
Internal source code
A compromised dependency running during a build can potentially turn a software-development environment into a credential-harvesting opportunity.
Deep Analysis: Look Beyond the npm Directory
Incident response should not stop at node_modules.
If a malicious package was executed, investigators should examine:
ps aux
and, where appropriate, network connections:
ss -tpn
They should also inspect shell history, CI logs, environment variables, recently modified files, authentication records, and outbound network activity.
The objective is to determine whether the package merely existed on disk or actually executed the follow-on payload.
Deep Analysis: Rotate Exposed Secrets
If an affected package executed inside an environment containing credentials, assume those credentials may have been exposed until proven otherwise.
Potentially affected secrets can include:
npm tokens
GitHub tokens
GitLab tokens
AWS credentials
Azure credentials
Google Cloud credentials
SSH keys
Database passwords
Private API keys
CI/CD secrets
Secrets should be rotated according to the
Deleting the malicious dependency does not revoke credentials that may already have been stolen.
The Hardest Problem Is Trust
The most uncomfortable lesson from this incident is that successful supply-chain attacks often do not look like attacks.
A hijacked package may continue working.
A malicious plugin may compile normally.
A package may pass basic functionality testing.
A developer may see no obvious warning.
Meanwhile, a few lines of appended JavaScript can quietly establish a completely separate execution chain.
This is why software security cannot depend solely on whether an application “works.”
Package Managers Need Stronger Defenses
The npm ecosystem has already introduced numerous security mechanisms, including provenance information, package signing initiatives, automated scanning, and account protections.
But attackers continue to adapt.
Package publication needs stronger behavioral controls.
A sudden change in package contents should trigger additional scrutiny.
Unexpected network activity from a package that previously performed no network operations should also be treated as suspicious.
And maintainers should have stronger protections against account takeover.
Developers Also Need to Change Their Habits
Developers do not need to manually audit every dependency.
That would be unrealistic.
But they should become more selective about adding new packages.
Before installing an unfamiliar dependency, check its publication history, maintainer identity, repository activity, download patterns, dependencies, release changes, and security reputation.
A package name that looks familiar is not enough.
The difference between tailwindcss-motion-advanced and a legitimate package may be only a few characters, yet that difference can determine whether an attacker gains code execution.
The Rise of Dynamic Malware Infrastructure
The blockchain technique illustrates a larger evolution in malware design.
Attackers increasingly want infrastructure that can survive takedowns.
Static IP addresses are easy to block.
Domains can be seized.
Command servers can be dismantled.
But decentralized or externally controlled configuration channels can make infrastructure more difficult to eliminate.
The attackers are effectively separating where the malware is installed from where it learns what to contact next.
That is a powerful design principle.
What Undercode Say:
The npm Ecosystem Is Becoming a Battlefield
The latest campaign shows that software supply-chain attacks are no longer crude attempts to publish obviously malicious packages.
Attackers are designing entire delivery architectures.
The six packages demonstrate how legitimate developer workflows can be turned against the people using them.
Ethereum Is Being Used as Infrastructure, Not Currency
The cryptocurrency angle is easy to misunderstand.
The attackers are not primarily interested in stealing Ethereum through this technique.
They are abusing the blockchain as a distributed information channel.
The transaction becomes a storage location for infrastructure data.
Blockchain Gives Attackers Flexibility
The major advantage is dynamic configuration.
An attacker can potentially alter the destination without changing the original npm package.
That creates an additional layer between the malicious code and the infrastructure it eventually contacts.
Package Hijacking Remains Extremely Dangerous
Hijacked packages are arguably more dangerous than obviously malicious ones.
Developers already trust them.
They may already exist inside internal applications.
They may have established documentation and usage history.
That credibility becomes part of the attack.
Functionality Can Be a Disguise
A malicious package does not have to be broken.
In fact, keeping the legitimate functionality operational can make detection significantly harder.
The package continues doing what developers expect while executing additional malicious code.
AI-Assisted Development Changes the Threat Model
Modern developers increasingly depend on automated recommendations.
An attacker who successfully creates a convincing package name may therefore have more opportunities to enter AI-generated projects.
Package discovery itself needs security controls.
CI/CD Systems Are Especially Valuable
A malicious dependency executed during development can reach environments that are much more valuable than an ordinary workstation.
Build systems frequently contain secrets.
They also have access to source repositories and deployment infrastructure.
That makes supply-chain compromise a potential bridge into the broader organization.
Blockchain Indicators Should Enter Threat Hunting
Security teams traditionally hunt for domains, IP addresses, hashes, and filenames.
This campaign suggests another category.
They should also look for blockchain wallet addresses, RPC endpoints, transaction identifiers, and unusual hexadecimal decoding logic.
Multiple Fallbacks Reveal Mature Tradecraft
The use of multiple Ethereum RPC providers and Blockscout indicates that the attackers were thinking about resilience.
They were not building a single-path malware loader.
They were building redundancy.
C2 Redundancy Makes Blocking Harder
Even if defenders discover one C2 address, the package may be able to obtain another.
That reduces the value of simple IP-based blocking.
Behavioral detection becomes more important.
Package Reputation Is Not Enough
A package can have a legitimate history and still become compromised.
Trust must therefore be continuous rather than permanent.
A trusted dependency should remain subject to integrity monitoring.
Lockfiles Are Important but Not Perfect
Lockfiles can help organizations identify exactly which versions were installed.
But they do not automatically determine whether those versions were safe.
A compromised version can still be perfectly represented in a lockfile.
Dependency Monitoring Needs Historical Context
Security teams should know not only what packages are installed today.
They should also know when they changed.
A package update that introduces unexpected code or behavior deserves investigation.
The Attack Illustrates Infrastructure Decoupling
The
That architecture gives attackers operational flexibility.
It also complicates incident response.
Attribution Is Less Important Than Detection
The connection to DPRK-linked activity is significant.
But defenders should not rely on attribution to determine whether something is dangerous.
The observed behavior itself provides enough reason for investigation.
Supply-Chain Security Must Become Behavioral
Static scanning is useful.
Software composition analysis is useful.
Malware signatures are useful.
But none of them should be considered sufficient on their own.
Organizations need behavioral monitoring as well.
Developers Need Better Package Intelligence
Package managers could provide stronger warnings about sudden ownership changes, suspicious releases, unusual install behavior, and maintainer anomalies.
The more intelligence developers receive before installation, the smaller the attack window becomes.
Automated Security Should Inspect Dependencies
Security checks should run automatically during pull requests and builds.
Developers should not be forced to remember every security indicator manually.
Automation is essential because modern dependency graphs are too large for manual inspection.
The Real Target May Be the Developer
A developer’s machine can provide access to credentials, repositories, cloud environments, and internal systems.
The npm package is therefore only the initial foothold.
The actual objective may be much larger.
Supply-Chain Attacks Can Become Identity Attacks
If malware steals developer credentials, attackers may later authenticate as legitimate users.
That can make subsequent activity look like normal development behavior.
This is one reason credential rotation matters after suspected execution.
Ethereum Creates a New Hunting Surface
Organizations may need to monitor outbound requests to public blockchain APIs from development environments.
A normal frontend application may have no reason to interact with Ethereum RPC infrastructure.
That makes unusual blockchain traffic potentially valuable as an indicator.
Security Teams Should Assume Adaptation
Once this technique becomes publicly documented, defenders will begin blocking known indicators.
Attackers will likely respond.
They can modify wallets, transactions, RPC providers, package names, and payloads.
The technique is therefore more important than the individual indicators.
npm Security Is Now Enterprise Security
The npm registry is not merely a developer convenience.
It is part of the software production pipeline.
A compromise there can ultimately affect production systems.
The Attack Shows Why Least Privilege Matters
If a package does not need access to sensitive credentials, it should not have them.
Build environments should be designed so that a compromised dependency cannot automatically access everything.
Network Segmentation Can Reduce Damage
Development, CI, staging, and production environments should not have unrestricted connectivity.
Segmentation can prevent an initial package compromise from becoming an enterprise-wide incident.
Dependency Allowlisting Can Help
Organizations with strict software requirements can maintain approved package lists.
That does not eliminate risk, but it reduces exposure to arbitrary package installation.
Package Pinning Can Reduce Surprise
Pinning versions helps control unexpected updates.
It should be combined with vulnerability intelligence and integrity verification rather than used as a standalone defense.
Security Teams Should Monitor Maintainer Changes
Account takeover can transform a legitimate project into a malicious one.
Unexpected maintainer changes should therefore receive additional scrutiny.
The Blockchain Trick Is a Warning
The technique demonstrates that attackers do not need to control every communication channel themselves.
They can abuse public infrastructure.
That makes traditional takedown strategies less effective.
Resilience Is Becoming an Attacker Priority
The malware includes fallback mechanisms at multiple levels.
That is a strong indication that reliability is becoming part of malicious software engineering.
Defenders Need the Same Mindset
Security teams should design defenses assuming that one detection mechanism will fail.
If DNS blocking fails, what happens?
If an IP is blocked, what happens?
If an RPC provider disappears, what happens?
Thinking through those alternatives reveals where attackers may have built resilience.
The Biggest Risk Is Silent Execution
The most dangerous supply-chain malware does not necessarily crash the application.
It succeeds quietly.
The application works.
The developer continues working.
The attacker continues operating.
This Campaign Should Be Treated as a Strategic Warning
The six packages are important individually.
But the broader lesson is far more important.
Software dependencies are becoming increasingly sophisticated delivery mechanisms for long-lived intrusion campaigns.
The Future of Supply-Chain Defense Is Multi-Layered
Organizations need package integrity, identity security, runtime monitoring, network controls, credential protection, CI/CD isolation, and behavioral detection.
No single tool can solve the problem.
Developers Should Not Be Blamed
The complexity of modern dependency ecosystems makes perfect manual inspection impossible.
Security must increasingly be built into tooling.
Vendors Have a Role Too
Package registries, cloud providers, security vendors, and development platforms need to collaborate around suspicious package behavior.
Attackers operate across ecosystems.
Defenders should do the same.
The Ethereum Dead Drop Is the Real Story
The six npm packages are the immediate threat.
The more important development is the idea behind them.
A blockchain can be transformed into a resilient malware configuration system.
That is exactly the kind of technique defenders should expect to see evolve.
Final Undercode Assessment
This campaign is another reminder that modern malware is becoming less dependent on traditional command-and-control infrastructure.
The attackers are blending package ecosystems, blockchain technology, public APIs, and multi-stage execution into a single delivery mechanism.
For organizations running Node.js, the safest response is not simply to remove six package names.
It is to investigate whether they executed, determine what they contacted, review the credentials available to them, and verify that no second-stage payload remains.
The npm ecosystem will continue to be targeted because it sits directly inside the software-development supply chain.
The question is no longer whether attackers will exploit that trust.
It is how quickly defenders can detect them when they do.
✅ Six npm Packages Were Identified
Sonatype Research Labs reported six npm packages containing the same underlying malicious payload on August 10, 2026.
The six packages identified in the report are @kolbo/mcp, agentgui, godot-kit, envpack-conf, postcss-initial-provider, and tailwindcss-motion-advanced.
✅ Ethereum Was Used to Retrieve C2 Information
The malware queried Ethereum-related infrastructure and extracted encoded information associated with a transaction.
The recovered data represented two IPv4 addresses used as primary and secondary C2 infrastructure.
✅ Multiple Retrieval Mechanisms Were Present
The loader supported multiple Ethereum RPC providers and could fall back to Blockscout when necessary.
The investigation also found additional fallback behavior for retrieving the second-stage payload.
⚠️ DPRK/Lazarus Attribution Requires Caution
Sonatype confirmed that the wallet matched one previously documented by OpenSourceMalware and observed similar tradecraft.
However, infrastructure overlap alone should not be treated as absolute proof of operator identity, because attackers can reuse, imitate, or deliberately expose infrastructure associated with another group.
✅ The Campaign Represents a Supply-Chain Risk
The combination of hijacked packages, purpose-built packages, malicious loaders, dynamic C2 resolution, and follow-on payloads creates a genuine software supply-chain threat.
Organizations using affected versions should investigate installation and execution history rather than simply assuming that uninstalling the package resolves the incident.
Prediction
(+1) Blockchain-Based Malware Infrastructure Will Become More Common
The use of Ethereum as a malware configuration channel demonstrates an idea that other threat actors can reproduce.
As defenders become better at blocking traditional domains and IP addresses, attackers are likely to experiment with public, decentralized, and difficult-to-censor infrastructure for retrieving configuration data.
(+1) npm Security Will Move Toward More Behavioral Detection
Future dependency-security systems are likely to place greater emphasis on what packages actually do after installation.
Unexpected blockchain communication, dynamic C2 discovery, child-process creation, obfuscated network code, and unusual post-install behavior could become important automated signals.
(+1) CI/CD Environments Will Receive More Attention
Attackers understand that compromising a developer dependency can expose highly valuable credentials.
As a result, development machines, build runners, package registries, and automated deployment systems will increasingly become primary targets rather than secondary ones.
(-1) Traditional IP Blocking Will Become Less Reliable
Static indicators will remain useful, but campaigns capable of dynamically resolving infrastructure can change their destinations without replacing the original malware.
That means defenders who depend exclusively on IP and domain blocking could increasingly find themselves one step behind.
(+1) Dependency Security Will Become a Core Development Requirement
The long-term direction is clear: software composition analysis, package provenance, maintainer verification, runtime monitoring, secret protection, and CI/CD isolation will become increasingly important parts of ordinary software engineering.
The npm ecosystem is too deeply embedded in modern development for supply-chain security to remain an optional security exercise.
▶️ Related Video (76% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: www.infosecurity-magazine.com
Extra Source Hub (Possible Sources for article):
https://www.reddit.com/r/AskReddit
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
