Listen to this Post
A New Kind of Deception Is Hiding in Plain Sight
Cybercriminals are finding a clever way to make malicious internet scanning look legitimate: they are pretending to be the automated crawlers used by some of the world’s biggest artificial intelligence companies.
According to research from GreyNoise, attackers have been impersonating crawler identities associated with OpenAI, Anthropic, Google, Perplexity and Amazon while scanning websites for exposed credentials, configuration files and other sensitive information. The campaign involved 824 IP addresses spread across 795 separate /24 networks, demonstrating how widely distributed the activity was.
The discovery is particularly concerning because many website owners have learned to distinguish between ordinary bots and legitimate AI crawlers using something as simple as a User-Agent string. That assumption is increasingly dangerous. A User-Agent is only text supplied by the connecting client, meaning an attacker can copy the identity of a legitimate crawler without actually being associated with the company whose name appears in the request.
GreyNoise’s investigation shows that this is not merely theoretical spoofing. The forged crawlers were looking for exactly the kinds of files that can expose the keys to an organization’s digital infrastructure, including .env files, AWS credential files, Git configuration files, private keys and password stores.
The Original Report in Brief
The original report shared by Cybersecurity News Everyday highlights a GreyNoise investigation into attackers disguising automated scanners as AI crawlers. The activity involved fake identities belonging to major AI companies and cloud platforms, with the scanners searching exposed web servers for secrets and configuration information.
The most important finding is that the attackers were not simply pretending to be one crawler. Multiple AI crawler identities appeared in the same scanning operation, allowing the malicious traffic to blend into an increasingly common category of internet activity.
GreyNoise identified 824 source addresses associated with the suspicious activity. More importantly, the addresses did not correspond to the official crawler infrastructure published by the companies being impersonated.
That distinction is critical. A website might see a request claiming to originate from GPTBot or ClaudeBot and assume it is harmless. But if the IP address does not belong to the organization’s documented crawler network, the name itself proves almost nothing.
Attackers Are Exploiting Trust in AI Brands
Artificial intelligence companies have created a new class of internet traffic. AI crawlers visit websites for search, indexing, content discovery, training-related purposes and user-triggered retrieval.
As that traffic has grown, organizations have started creating special rules around it. Some permit recognized AI bots, while others block or restrict them. Security products, web servers, analytics platforms and firewalls may also use crawler names to classify incoming requests.
Attackers can exploit this growing familiarity.
Instead of arriving as an obviously suspicious scanner, a malicious system can identify itself as a recognizable AI crawler. The request may then look ordinary in logs, dashboards or automated filtering systems.
This is the core weakness exposed by the campaign: identity declared inside an HTTP request is not the same thing as verified identity.
The 824-Address Network Reveals a Larger Operation
GreyNoise observed the suspicious activity across 824 IP addresses distributed through 795 separate /24 networks. That distribution makes the campaign considerably harder to dismiss as a single compromised server or isolated scanning host.
The research found that several forged AI crawler names appeared in almost identical volumes and were associated with the same underlying HTTP client fingerprint. That gave researchers a way to connect apparently different crawlers to the same broader scanning behavior.
The campaign was observed between July 28 and August 23, 2026, with activity increasing toward the end of the observation period.
The significance of this pattern is greater than the number 824 alone. Distributed infrastructure allows attackers to rotate addresses, evade simplistic IP-based blocking and make a single campaign appear to originate from hundreds of unrelated systems.
The Attackers Were Hunting for Secrets
The most disturbing part of the activity was not the fake User-Agent. It was what the scanners were requesting.
GreyNoise reported requests targeting files and locations commonly associated with exposed secrets, including .env files, AWS credential files, Git configuration files, private keys and password stores.
An exposed .env file can be particularly dangerous because developers frequently use it to store database passwords, API tokens, cloud credentials, application secrets and other configuration values.
A single forgotten file can therefore provide an attacker with information that unlocks multiple systems.
The same principle applies to /.aws/credentials. If cloud credentials are accidentally exposed through a web server, attackers may be able to move from a simple web request toward cloud infrastructure.
Git configuration files can also reveal repository information, credentials or internal paths that help an attacker understand how an application is constructed.
The Missing robots.txt Request Became a Major Clue
One of
The suspicious traffic did not request /robots.txt, even though legitimate crawlers commonly use the file to determine which areas of a website they should or should not access. GreyNoise specifically observed that the forged crawler traffic never requested /robots.txt during the analyzed activity.
This creates an important behavioral distinction.
A genuine crawler is generally interested in discovering and processing web content according to rules. A credential-hunting scanner has a different objective. It already knows the filenames it wants and can go directly to them.
That difference in behavior helped researchers distinguish the fake identities from the real services they claimed to represent.
User-Agent Strings Cannot Prove Who Is Behind a Request
The fundamental security lesson is straightforward: a User-Agent header is not an identity credential.
A server receiving an HTTP request cannot assume that a request claiming to be GPTBot, ClaudeBot, PerplexityBot or another recognized crawler actually came from that organization.
An attacker can copy the string.
This is why security controls based exclusively on User-Agent allowlisting can create a dangerous blind spot. If an organization says, “Allow this User-Agent because it belongs to a trusted AI company,” an attacker may simply reproduce the same text.
The request looks trusted while the infrastructure behind it remains completely unrelated.
Google-Extended Creates an Especially Interesting Warning
The investigation uncovered an unusual example involving
GreyNoise reported that Google-Extended generated 263,849 forged sessions in the observed activity. The important detail is that Google-Extended is not itself a conventional crawler User-Agent. It is a control used in robots.txt to manage how Google’s systems use content for certain AI-related purposes.
That means attackers were effectively using a string associated with AI-content controls as another disguise.
This demonstrates how complicated the AI crawler ecosystem has become. Website operators now have to distinguish between search crawlers, AI crawlers, user-triggered fetchers, robots.txt directives and other machine-readable identities.
Attackers are watching the same ecosystem and learning which names administrators are likely to trust.
The Attack Is About Credential Theft, Not AI Crawling
It is important not to confuse this campaign with legitimate AI crawling.
OpenAI, Anthropic, Google, Perplexity and Amazon operate legitimate automated systems. The problem described by GreyNoise is that criminals are copying those identities.
The
This distinction matters because organizations should not respond by assuming that every AI crawler is malicious. Instead, they should verify whether the traffic actually originates from the infrastructure associated with the claimed service and examine what the crawler is doing.
Why Exposed .env Files Remain a Serious Problem
The continued targeting of .env files highlights an old security problem that remains surprisingly effective.
Developers often rely on environment files during application development because they provide a convenient way to store configuration values outside source code.
The danger begins when those files are accidentally placed inside publicly accessible directories.
Automated scanners do not need to understand the application. They can simply request predictable paths and move on to the next target.
This makes .env harvesting an ideal activity for large-scale automated campaigns.
Cloud Credentials Can Turn a Web Leak Into a Major Incident
The risk becomes much greater when exposed credentials belong to cloud infrastructure.
A leaked application password may provide access to one service. A leaked cloud credential could potentially expose storage, databases, virtual machines, APIs or other infrastructure depending on its permissions.
This is why credential discovery is such an attractive first step for attackers.
The scanning system does not need to know which organization is behind a website. It only needs to find one badly protected secret.
Automation handles the scale.
The Campaign Also Shows Why Configuration Security Matters
Cybersecurity often focuses heavily on sophisticated vulnerabilities, but attackers continue to benefit from simple configuration mistakes.
An outdated application, exposed development server, publicly accessible backup file or incorrectly configured cloud resource can provide the same practical result as a complicated exploit.
The GreyNoise findings reinforce a basic principle: anything accidentally exposed to the internet will eventually be scanned.
The question is no longer whether someone will search for the file.
The question is whether the file will still be there when they arrive.
The Connection to Vite Exposure Risks
GreyNoise also associated portions of the observed activity with attempts involving CVE-2025-30208, a Vite development-server arbitrary file disclosure issue. Related reporting identifies affected Vite versions and notes that the vulnerability can expose files through crafted requests.
This illustrates how attackers combine broad reconnaissance with known vulnerability paths.
A scanner can first search for an exposed credential file. If that fails, it may identify a vulnerable service and attempt another route toward sensitive information.
For defenders, this means that vulnerability management and secret management cannot be treated as separate worlds.
A vulnerable development server and an exposed .env file can become two pieces of the same attack chain.
AI Crawlers Are Becoming Part of the Security Perimeter
For years, organizations treated search engine crawlers primarily as a traffic-management issue.
The AI boom changed that.
Websites now receive traffic associated with AI search, AI assistants, content discovery and automated retrieval systems. Organizations may want to allow certain crawlers while blocking others.
That makes AI crawler identity increasingly valuable.
Whenever a trusted identity controls access, attackers have an incentive to forge it.
The GreyNoise research suggests that AI crawler impersonation is becoming another form of security evasion rather than simply a content-management problem.
Distributed Scanning Makes Blocking More Difficult
Blocking a handful of suspicious IP addresses is easy.
Blocking hundreds of addresses distributed across hundreds of networks is much harder.
Attackers can rotate infrastructure, use cloud providers, compromise devices or operate through different hosting environments. A static blocklist may therefore become outdated quickly.
GreyNoise’s fingerprinting approach is important because it looks beyond individual addresses and examines characteristics shared by the traffic.
That is a more durable defensive strategy than simply blocking one IP after another.
Behavioral Detection Is Becoming More Valuable
The most useful lesson from this campaign may be that defenders should analyze what a crawler does, not just what it calls itself.
A legitimate crawler that suddenly requests /.env, /.aws/credentials or private key files should immediately attract attention.
A crawler that never requests /robots.txt but repeatedly probes secret-bearing paths should also be treated differently from a conventional content crawler.
Behavior provides context that a User-Agent string cannot.
What Website Owners Should Check First
Organizations should begin by reviewing whether sensitive files are publicly reachable.
Search for accidentally exposed .env files, cloud credential files, private keys, backup files, Git directories and development configuration.
The goal should not be to discover whether attackers have already accessed those files. The goal should be to make sure the files cannot be accessed in the first place.
If sensitive files are required locally, they should be stored outside publicly served directories whenever possible.
Rotate Credentials After Exposure
If a secret has been publicly accessible, simply deleting the file may not be enough.
Credentials should be treated as compromised and rotated.
API keys should be revoked and replaced. Cloud credentials should be regenerated. Database passwords should be changed where appropriate.
Organizations should also investigate logs to determine whether the exposed resource was requested.
The difference between “we removed the file” and “we removed the file and invalidated the secret” can be enormous.
Do Not Trust AI Crawler Names Alone
Security teams should avoid making access decisions exclusively from User-Agent strings.
Where possible, crawler traffic should be validated against the official infrastructure information published by the claimed organization. GreyNoise specifically found that the 824 addresses in the observed cluster did not correspond to the published crawler ranges for the organizations being impersonated.
Even that should not become the only control.
A defense-in-depth strategy should combine source verification, rate limiting, behavioral analysis, application logging and strict access controls around sensitive resources.
Logging Can Reveal the Difference
Web logs can provide valuable evidence when investigating this type of activity.
Security teams should look for requests containing known AI crawler names that originate from unexpected networks.
They should also investigate crawler traffic that repeatedly requests sensitive filenames or unusual paths.
A request claiming to be a legitimate AI crawler but immediately probing .env, AWS credentials and Git configuration is fundamentally different from a normal crawler requesting HTML pages.
That behavioral difference should be reflected in detection rules.
Rate Limiting Can Reduce Automated Harvesting
Rate limiting will not solve identity spoofing, but it can reduce the efficiency of automated scanning.
An attacker attempting to enumerate thousands of sensitive paths across a large collection of websites can be slowed down when suspicious request patterns trigger throttling.
Rate limits should be designed carefully because legitimate crawlers can also generate high traffic.
The key is to combine rate limits with path sensitivity and behavioral indicators rather than blindly restricting all automated traffic.
AI Companies Also Face an Identity Challenge
The problem is not limited to website owners.
AI companies increasingly need mechanisms that allow websites to distinguish their genuine crawlers from impersonators.
Published IP ranges provide one useful method, but the broader industry may eventually need stronger machine identity standards.
As AI agents and automated systems become more common, simple User-Agent declarations are unlikely to remain sufficient for establishing trust.
The internet is entering a period where machines increasingly need to prove not just what they claim to be, but who authorized them to connect.
Deep Analysis: Commands and Defensive Investigation
Command 1 — Search Web Logs for Fake AI Crawlers
A practical first step is to identify requests claiming to originate from AI crawlers.
grep -Ei 'GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|PerplexityBot|Google-Extended|Amazonbot' access.log
This does not prove malicious activity. It simply creates a starting dataset for investigation.
Command 2 — Find Requests for Exposed Environment Files
Security teams can search access logs for common secret-bearing paths.
grep -Ei '/.env|/.aws/credentials|/.git/config|id_rsa|private.key' access.log
Any successful response to these paths deserves immediate investigation.
Command 3 — Identify Successful Responses
The next step is determining whether the sensitive files were actually served.
awk '$9 ~ /^2/ && $7 ~ /\/.env|\/.aws\/credentials|\/.git\/config/' access.log
A blocked request is one thing. A successful HTTP response containing a sensitive file is a potential incident.
Command 4 — Compare Claimed Identity With Source Infrastructure
Do not stop at the User-Agent.
grep -Ei 'GPTBot|ClaudeBot|PerplexityBot' access.log | awk '{print $1, $7, $9, $12}'
Review the source IP, requested path, response code and User-Agent together.
Command 5 — Hunt for Repeated Secret Probing
Attackers commonly test multiple predictable filenames.
grep -Ei '/.env(.|/|$)|/.aws/credentials|/.git/config|id_rsa|credentials' access.log | sort | uniq -c | sort -nr
This can expose repeated automated attempts that may otherwise disappear inside normal web traffic.
Command 6 — Inspect Requests That Skip Normal Crawling Behavior
If a claimed crawler immediately requests credential files without first behaving like a normal crawler, that pattern deserves attention.
grep -Ei 'GPTBot|ClaudeBot|PerplexityBot|Amazonbot' access.log | grep -Ei '.env|credentials|private|.git'
The purpose is behavioral correlation, not simply identifying a suspicious User-Agent.
Command 7 — Search for Secret Files on Web Roots
Administrators should audit publicly served directories.
find /var/www -type f ( -name '.env' -o -name 'credentials' -o -name '.pem' -o -name 'id_rsa' ) -print
The exact web-root location varies by deployment, so organizations should adapt the command to their infrastructure.
Command 8 — Review Git Exposure
Git metadata should rarely be publicly accessible.
find /var/www -type d -name '.git' -print
If a .git directory exists under a public web root, investigate immediately.
Command 9 — Check for Unexpected Cloud Credentials
Cloud credentials should never be casually stored in publicly accessible application directories.
find /var/www -type f -iname 'credential' -o -iname '.key' -o -iname '.pem'
The command is intended as an audit starting point and should be adjusted for the organization’s directory structure.
Command 10 — Build Detection Around Behavior
The strongest detection strategy is not “block every AI crawler.”
It is closer to:
claimed AI crawler + unrecognized source + sensitive-file probing = high-risk event
That combination gives security teams much more useful context than a User-Agent alone.
What Undercode Say:
AI Identity Has Become an Attack Surface
The most important lesson from this campaign is that AI crawler identity itself is becoming an attack surface. As more organizations create rules around AI bots, attackers have a new set of trusted names they can imitate.
Trust Is Moving Too Quickly
The cybersecurity industry spent years teaching administrators to recognize malicious bots. Now organizations are being asked to distinguish between legitimate AI automation, unwanted AI scraping and malicious systems pretending to be legitimate AI automation.
User-Agent Filtering Is No Longer Enough
A User-Agent should be treated as metadata, not authentication. It can help classify traffic, but it should never be considered proof that a request came from OpenAI, Anthropic, Google, Perplexity or Amazon.
The Real Target Is Often the Configuration Layer
Attackers do not necessarily need to exploit a sophisticated zero-day when a forgotten configuration file can provide passwords, API keys or cloud credentials in seconds.
Automation Changes the Economics of Attacks
A human attacker might spend minutes examining one website. An automated scanner can inspect thousands of websites while looking for exactly the same predictable mistakes.
The 824 IP Addresses Matter
The 824-address figure demonstrates the scale and distribution of the campaign. The attackers were not relying on one obvious server that could simply be blocked.
Fingerprinting Provides a Stronger Signal
GreyNoise’s ability to correlate different crawler identities through shared traffic characteristics demonstrates why behavioral fingerprinting can outperform simple User-Agent matching.
robots.txt Can Become a Behavioral Clue
The absence of /robots.txt requests does not automatically prove that a crawler is malicious, but in this campaign it helped separate the fake crawlers from legitimate crawler behavior.
Credential Files Remain High-Value Targets
.env, cloud credential and Git configuration files remain attractive because they can contain information that immediately helps attackers move deeper into an environment.
Cloud Security and Web Security Are Connected
A web server is not isolated from cloud infrastructure when it contains cloud credentials. A simple web exposure can therefore become an infrastructure security problem.
Developers Remain Part of the Security Perimeter
Security is not limited to firewalls and endpoint protection. Development practices determine what files reach production and what secrets become publicly accessible.
Development Servers Are Especially Dangerous
Development tools can contain functionality that was never intended to be exposed directly to the public internet. The Vite-related exposure referenced in the research is a reminder of this risk.
Attackers Follow Predictable Paths
Automated scanners succeed because many mistakes are predictable. Once attackers know where developers commonly place secrets, they can turn those assumptions into automated reconnaissance.
The AI Boom Creates New Trust Relationships
Websites now have more reasons than ever to recognize AI-related traffic. Every new trusted category creates another identity that attackers can potentially impersonate.
Defenders Should Verify Before Allowing
Allowlisting should be based on multiple signals whenever possible. A name alone is too weak to establish trust.
Logs Are Becoming More Valuable
A suspicious request may look harmless in isolation. A sequence of hundreds of credential-file requests from the same fingerprint tells a completely different story.
Security Teams Need Context
The best detection systems combine IP reputation, User-Agent, requested path, request frequency, response status and behavioral fingerprints.
Blocking Should Not Be Blind
Automatically blocking every AI crawler could interfere with legitimate services. The goal should be accurate classification rather than indiscriminate blocking.
Secret Management Must Be Continuous
Finding a secret once is not enough. Organizations need processes that prevent secrets from being committed, deployed or served accidentally.
Exposed Secrets Should Be Considered Compromised
If an API key or password was publicly accessible, deleting the file does not undo the exposure. The credential should generally be rotated.
AI Crawler Spoofing Is Not Going Away
The more valuable AI crawler identities become, the more incentive attackers have to imitate them.
The Internet Is Becoming More Machine-Driven
Automated systems already make up a significant portion of web traffic. Security architecture must therefore assume that machine-to-machine interactions can be manipulated.
Machine Identity Needs Stronger Standards
Long term, the industry will likely need better ways for automated agents to prove their identity than a plain-text User-Agent header.
Security Controls Must Evolve
Defenses created for a web dominated by human browsers are increasingly inadequate for an environment filled with crawlers, AI agents, automated scanners and autonomous software.
AI Makes Reconnaissance Easier
AI itself is not required for this particular campaign to be dangerous. Traditional automation is already capable of scanning enormous numbers of systems. AI can potentially make future versions more adaptive and selective.
Attackers Are Learning the Language of AI
Using the names of OpenAI, Anthropic, Google and other companies is not accidental. Those names have become recognizable signals in modern web infrastructure.
Trust Can Become a Vulnerability
Whenever a security control says “this source is trusted,” attackers eventually attempt to imitate that source.
The Best Defense Is Layered
IP verification, behavioral analytics, strict file permissions, secret scanning, vulnerability management, logging and credential rotation should work together.
Security Teams Should Hunt Before Alerts Arrive
Organizations should proactively search their logs for sensitive-file probing rather than waiting for a security product to identify the campaign.
Developers Should Treat Public Web Roots as Hostile
Anything placed under a public web directory should be assumed to be discoverable by automated scanners.
Small Mistakes Can Create Large Incidents
One forgotten .env file can potentially expose credentials that connect an otherwise ordinary website to databases, cloud services or third-party APIs.
AI Crawler Policies Need Reassessment
Organizations that previously created allowlists based only on crawler names should review those rules and determine whether they still provide meaningful protection.
The 824 Sources Are a Warning Signal
The number should not be interpreted as the total size of the campaign. It represents the infrastructure GreyNoise observed. The actual ecosystem of spoofed scanners could be broader.
Attribution Should Remain Careful
The available research demonstrates spoofed crawler activity and malicious scanning behavior, but that does not automatically identify a specific criminal group or government behind it.
The Threat Is More Important Than the Brand Names
The deeper issue is not that attackers chose OpenAI or Anthropic. The deeper issue is that the internet still relies heavily on self-declared machine identities.
AI Security Is Becoming Web Security
As AI agents increasingly interact with websites, protecting those interactions will become inseparable from ordinary application and web security.
Undercode’s Bottom Line
The biggest mistake organizations can make after this discovery is believing that a familiar AI crawler name means familiar infrastructure. It does not.
The GreyNoise investigation is a warning that attackers are adapting to the modern web’s growing dependence on automated AI traffic. The defense is not to fear every crawler, but to verify identities, restrict sensitive files, monitor behavior and assume that anything exposed to the public internet will eventually be tested.
Verified Research
✅ GreyNoise reported a cluster involving 824 IP addresses, with the activity associated with forged AI crawler identities and distributed across hundreds of networks.
Verified Targeting
✅ The scanners were observed requesting sensitive resources including .env variants, AWS credential files, Git configuration files, private keys and other credential-related paths.
Verified Impersonation
✅ GreyNoise found that the suspicious addresses did not match the published crawler IP ranges of the legitimate organizations being impersonated, while several forged crawler names shared the same underlying fingerprint.
Important Qualification
❌ The evidence does not establish that OpenAI, Anthropic, Google, Perplexity or Amazon were responsible for the scanning. Their crawler identities were being spoofed, and the research does not by itself establish the ultimate identity of the attackers.
Prediction
(+1) Stronger AI Crawler Verification Will Become Normal
Organizations are likely to move away from trusting User-Agent strings alone and toward combinations of IP verification, behavioral analysis, rate limiting and stronger machine-identity mechanisms.
(+1) Secret Scanning Will Become More Aggressive
Security platforms will increasingly treat .env, cloud credentials, Git metadata and private keys as high-priority web exposure indicators and automatically alert when external systems probe them.
(+1) AI Agent Identity Will Become a Major Security Topic
As AI agents gain broader access to websites and APIs, proving that an automated client is genuinely associated with the organization it claims to represent will become increasingly important.
(-1) Crawler Spoofing Will Continue to Increase
Attackers have little reason to abandon the technique while User-Agent-based trust remains widespread. More AI brands and agent identities could become targets for impersonation.
(-1) Exposed Credentials Will Remain One of the Easiest Entry Points
Even as attackers develop more sophisticated techniques, poorly protected configuration files and credentials will continue to offer a cheap and highly scalable path into vulnerable environments.
(+1) Behavioral Detection Will Become the Stronger Defense
The organizations best positioned to resist this threat will be those that analyze what automated clients actually do rather than trusting what they claim to be.
(-1) AI Traffic Will Become Harder to Classify
The boundary between legitimate crawlers, AI agents, scraping systems, security scanners and malicious automation will continue to become less obvious, forcing defenders to rely on multiple signals rather than simple labels.
(+1) The Lesson Will Spread Beyond AI Crawlers
The same principle applies to search engines, monitoring services, security scanners and other trusted automated clients: a declared identity is not proof of identity.
Final Outlook
(+1) The positive outcome is that this type of research gives defenders a clear warning before spoofed AI identities become an even more deeply embedded evasion technique. If organizations respond by removing exposed secrets, verifying crawler infrastructure and adopting behavioral detection, the attack surface can be reduced significantly.
(-1) The negative outcome is that organizations that continue trusting User-Agent strings will remain vulnerable to increasingly convincing automated impersonation. As AI becomes more deeply integrated into the web, attackers will have more identities to imitate—and more opportunities to hide in traffic that appears legitimate at first glance.
▶️ Related Video (80% 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: x.com
Extra Source Hub (Possible Sources for article):
https://www.reddit.com
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
