Listen to this Post
A Trusted Build Became the Delivery System
Modern software development depends on trust chains that are often invisible to the people using them. Developers trust package registries, repositories trust CI/CD systems, and organizations trust cryptographic signatures and provenance records to tell them whether software came from a legitimate source.
The latest compromise involving @7nohe/openapi-react-query-codegen exposes how dangerous that trust can become when the publishing workflow itself is misconfigured. According to Socket’s research, attackers managed to publish 10 malicious versions of the npm package on August 28, 2026, affecting every maintained release line. The package has roughly 150,000 weekly downloads, meaning the potential blast radius extends well beyond a single development project.
The incident is particularly concerning because the malicious releases were not simply unsigned or obviously suspicious packages. Socket found that all 10 carried valid npm provenance attestations generated through GitHub Actions trusted publishing. In other words, the software could appear legitimate to security systems checking where and how the package was built.
That is what makes this incident more than another malicious npm package story. It is a warning that a legitimate signature does not automatically mean legitimate source code.
The Package at the Center of the Attack
@7nohe/openapi-react-query-codegen is designed to generate type-safe code for applications using OpenAPI specifications and React Query/TanStack Query. Packages like this are commonly installed as development dependencies, which puts them directly inside developer laptops, build systems and CI/CD runners.
That distinction matters. A malicious package installed on a developer workstation can potentially access far more than the application itself. Development machines often contain GitHub credentials, npm tokens, cloud credentials, SSH keys, environment variables, source code and configuration files.
Socket reported that the compromised package specifically targeted cloud credentials, package-registry credentials, GitHub Actions secrets and AI-agent configuration. The payload also contained self-propagation functionality associated with the Mini Shai-Hulud campaign.
Ten Malicious Versions Were Released
The attackers did not compromise only one version and wait. They published malicious releases across every maintained branch.
The affected versions identified by Socket are:
0.0.0-365d4eb738d3146583431948d3ba6e27a32556be
0.0.0-ec7876d6c917dad516ba69bbfafc948b834bf0ab
0.5.4
0.5.5
1.6.3
1.6.4
2.2.1
2.2.2
3.0.3
3.0.4
The last known-good releases for the maintained branches were 0.5.3, 1.6.2, 2.2.0 and 3.0.2.
The Attack Was Delivered in Two Waves
The malicious releases were published in two waves on August 28, roughly 20 minutes apart. This suggests that the attackers were not merely experimenting with one compromised build. They deliberately pushed malicious versions across multiple release lines.
The first wave affected several branches, followed by a second wave that added additional releases and ultimately placed 3.0.4 at the latest release position during the period examined by Socket.
This strategy is important because developers frequently rely on version ranges rather than manually selecting every exact package version. A compromised release inserted into an actively used version branch can therefore reach environments without anyone deliberately selecting a suspicious version.
The Malware Executed During Installation
The danger was not limited to downloading a malicious file. The compromised releases contained mechanisms capable of executing attacker-controlled code during installation.
Socket identified a bundled JavaScript loader named 3FWCvzduYZg.js. The loader was heavily obfuscated and used encryption to conceal its second-stage payload before executing it. The second stage targeted credentials and configuration data and contained self-propagation capabilities.
Several release versions used binding.gyp as part of their execution path, while later versions also included a preinstall script. That created a direct opportunity for malicious code to run while a developer or CI system installed the package.
This is one of the most dangerous characteristics of software supply-chain attacks: the victim may not need to execute the malicious application manually. The act of installing a dependency can be enough.
GitHub Actions Was the Critical Weak Point
The most significant discovery was not necessarily inside npm itself. It was inside the project’s publishing workflow.
According to Socket, the repository had a GitHub Actions release workflow triggered by an issue_comment event. The workflow reacted to a comment containing npm publish, checked out code associated with the pull request, and then performed a package publication using trusted publishing capabilities.
The problem was the trust boundary.
The workflow did not sufficiently restrict who could trigger the publishing action. Socket found that an untrusted GitHub account could comment on a pull request and cause code from a fork to be processed by the privileged release workflow.
That meant the attacker did not necessarily need to steal the maintainer’s npm password or obtain a traditional long-lived npm publishing token.
The Attacker Abused Trust Instead of Stealing It
This distinction is crucial.
Traditional supply-chain attacks often involve stolen credentials, compromised maintainer accounts or malicious code inserted directly into a repository. Here, the attack demonstrated another possibility: make the legitimate infrastructure publish malicious code for you.
The attacker-controlled source could enter the trusted workflow, while the workflow itself retained access to the credentials and OIDC identity needed to publish the package.
This transformed the CI/CD system from a security control into an attack mechanism.
Why Valid npm Provenance Was Not Enough
Perhaps the most uncomfortable finding is that all 10 malicious releases had valid npm provenance attestations.
Ordinarily, provenance is supposed to increase confidence in software by providing evidence about the build process and the identity of the publishing workflow. That remains valuable, but this incident demonstrates its limitation.
Socket explains that the provenance records could identify the trusted workflow even though attacker-controlled source had entered that workflow. The attestations therefore verified a legitimate publishing path without proving that every byte of source code processed by that path was trustworthy.
This creates a subtle but critical distinction:
Provenance can tell you who built something. It cannot, by itself, guarantee that the builder was fed trustworthy source code.
Why npm Audit Signatures Could Miss the Problem
The incident also demonstrates why organizations should avoid treating one security signal as an absolute guarantee.
Socket specifically warned that npm audit signatures would not flag these releases because the malicious packages possessed valid provenance attestations.
A package can therefore pass an authenticity-oriented check while still being malicious.
That does not make signatures useless. Instead, it shows that software security needs several independent layers: source review, dependency pinning, build isolation, workflow restrictions, runtime monitoring, credential segmentation and behavioral analysis.
The Attack Goes Beyond npm
The malicious payload was reportedly designed with broader propagation in mind.
Researchers observed functionality associated with the Mini Shai-Hulud campaign that could target package ecosystems and attempt to spread compromised code further. Additional research from Endor Labs reported capabilities involving npm, RubyGems and PyPI, while also describing credential theft and self-replication behavior.
This is where the incident becomes particularly dangerous for organizations with polyglot development environments.
A company may think it has an npm problem because the original infection came from npm. But if stolen credentials can be reused against other package registries, the compromise can cross ecosystem boundaries.
GitHub Actions Secrets Become High-Value Targets
CI/CD environments are attractive targets because they frequently contain credentials with broad privileges.
A compromised developer environment may expose source code. A compromised CI runner can potentially expose the credentials required to build, sign, release and deploy that source code.
That creates a dangerous escalation path:
Package installation → credential theft → CI/CD access → package publishing → secondary infections.
The attacker is no longer attacking one package. The attacker is attempting to turn the victim’s development infrastructure into another distribution mechanism.
AI-Agent Configuration Adds a New Dimension
Socket also identified AI-agent configuration among the targeted information.
This is particularly notable in 2026 because AI coding agents are increasingly integrated into developer environments, repositories and automation pipelines. Configuration files may contain credentials, tool permissions, endpoints, repository information or instructions that give an automated agent access to sensitive systems.
The supply-chain threat model is therefore expanding.
A malicious dependency no longer needs to target only traditional developer secrets. It can potentially hunt for the credentials and configuration used by AI-assisted development systems as well.
The Incident Should Change How Organizations Think About CI/CD
For years, CI/CD security discussions have focused heavily on protecting secrets.
But the deeper question is: Who is allowed to make the workflow use those secrets?
A perfectly protected OIDC credential can still become dangerous if untrusted source code is allowed to execute inside a privileged workflow.
The strongest secret is not enough if the workflow that receives it has an overly broad trust boundary.
Immediate Response for Potentially Affected Organizations
Organizations that installed an affected version should not treat this as a routine dependency upgrade.
Socket recommends isolating machines and CI runners that installed compromised versions and treating those environments as potentially compromised. Rebuilding from known-clean images is preferred where possible. Credentials accessible from affected environments should then be revoked and rotated after containment.
Teams should examine GitHub tokens, npm credentials, cloud credentials, package-registry credentials, CI/CD secrets and other sensitive authentication material that may have been accessible.
They should also inspect package-manager caches, lockfiles, node_modules directories and software bills of materials to identify affected versions.
Known-Good Versions Should Be Pinned
For the affected package, the known-good versions identified by Socket are:
0.5.3
1.6.2
2.2.0
3.0.2
Organizations should avoid assuming that a broad semantic version range automatically protects them. Dependency ranges can pull in a malicious release if the attacker manages to publish a version that satisfies the project’s constraints.
Exact version pinning and reproducible builds can significantly reduce that exposure.
Rebuilding Is Safer Than Simply Removing the Package
One of the most important lessons from this incident is that uninstalling the malicious dependency may not be enough.
If the package executed during installation, the attacker may already have accessed credentials or created persistence before the package was removed.
A clean rebuild provides stronger assurance than attempting to manually identify every possible modification.
The appropriate response depends on the environment, but organizations handling sensitive infrastructure should assume that an affected developer machine or runner may have exposed credentials even if no obvious malicious files remain.
Deep Analysis: The Command-and-Control Problem
The most interesting aspect of this incident is that the malware’s objective was not simply to damage the local machine.
Its value comes from information and access.
A credential-stealing package can quietly transform a single developer workstation into an access point for cloud accounts, GitHub repositories and package registries.
That makes credential rotation one of the most important response actions.
Deep Analysis: The Self-Propagation Problem
Self-propagating malware changes the economics of a supply-chain attack.
Instead of compromising one target at a time, an attacker can attempt to use stolen package credentials to publish additional malicious releases.
This creates a feedback loop in which every newly infected environment could become another distribution point.
That is why package-registry credentials should be treated as especially sensitive after a compromise.
Deep Analysis: The Provenance Paradox
The incident exposes what could be called the provenance paradox.
Security teams are increasingly encouraged to demand signed artifacts and trusted build provenance.
That is absolutely the right direction.
But a trustworthy build pipeline can produce an untrustworthy artifact if untrusted code is allowed into the pipeline.
Therefore, artifact identity and source integrity must be evaluated separately.
Deep Analysis: The Fork Trust Boundary
Pull-request forks are useful because they allow external contributors to propose changes without receiving direct repository access.
The danger begins when code from those forks is executed inside privileged workflows.
A fork can contain arbitrary modifications.
If the privileged workflow checks out that code and grants it access to publishing credentials or OIDC identity, the security boundary has effectively collapsed.
Deep Analysis: The Comment Trigger
A command such as npm publish inside a pull-request comment may appear harmless.
In a privileged automation environment, however, that comment can become a control interface.
If the workflow does not verify the
Security-sensitive workflows should never treat user-controlled text as sufficient authorization.
Deep Analysis: OIDC Is Powerful but Not Magical
OIDC-based trusted publishing is designed to reduce dependence on long-lived credentials.
That is an important security improvement.
But OIDC does not automatically determine whether the software being published is safe.
It authenticates a workload to a destination.
If the workload itself has been tricked into processing attacker-controlled code, OIDC can faithfully authenticate the wrong thing.
The lesson is not to abandon OIDC.
The lesson is to place stronger controls around the workloads allowed to use it.
Deep Analysis: AI Changes the Attack Surface
The targeting of AI-agent configuration deserves special attention.
Modern developers increasingly allow AI systems to interact with repositories, terminals, package managers, cloud environments and deployment tooling.
If a malicious package can discover AI-related credentials or configuration, it could potentially gain access to capabilities that did not exist in traditional development environments.
The software supply chain is therefore becoming part of the AI security problem.
Deep Analysis: Developer Machines Are Production Infrastructure
The old assumption that a developer laptop is separate from production is increasingly inaccurate.
Developer systems can contain production credentials, source-code signing keys, cloud CLI sessions and access to internal repositories.
A successful compromise of one developer workstation can therefore become an enterprise incident.
Organizations should protect development endpoints with the same seriousness applied to other privileged infrastructure.
Deep Analysis: CI Runners Need Ephemeral Design
Persistent CI runners can provide attackers with valuable opportunities.
A compromised runner may retain files, credentials or configuration between jobs.
Ephemeral runners reduce the amount of persistent state available to an attacker.
They do not eliminate the risk, but they can make post-compromise persistence substantially harder.
Deep Analysis: Lockfiles Are Necessary but Not Sufficient
Lockfiles provide valuable protection against unexpected dependency changes.
However, a malicious package can still be installed if the lockfile itself resolves to an affected version.
Therefore, teams should combine lockfiles with trusted package policies, dependency scanning and version allowlists.
Reproducibility is strongest when the entire build chain is controlled.
Deep Analysis: SBOMs Become Incident-Response Tools
Software bills of materials are often discussed as compliance documents.
Incidents like this demonstrate their practical value.
If an organization has an accurate SBOM, responders can quickly identify which applications contain an affected package and which environments require investigation.
An SBOM therefore becomes a searchable map of potential exposure during a supply-chain incident.
Deep Analysis: Package Managers Are Security Boundaries
npm is not simply a convenience tool.
When an organization allows packages to execute installation scripts, the package manager effectively becomes a gateway for arbitrary third-party code.
That means package-management policies should be considered part of endpoint and CI security.
Teams should understand which lifecycle scripts are permitted and where those scripts can execute.
Deep Analysis: Build Isolation Matters
A package installation performed inside an isolated build environment has a smaller blast radius than the same installation performed on a developer workstation containing production credentials.
Build isolation should therefore be treated as a defensive layer.
Even if a dependency becomes malicious, the objective should be to prevent the dependency from reaching valuable credentials.
Deep Analysis: Secrets Should Be Narrowly Scoped
The incident also reinforces the principle of least privilege.
A CI job publishing an npm package should not automatically have access to unrelated cloud accounts, deployment environments and repositories.
Reducing the number of secrets available to each workflow can dramatically reduce the consequences of credential theft.
Deep Analysis: Security Controls Must Be Independent
If provenance, signatures, dependency scanners and CI policies all depend on the same trusted workflow, they may fail together.
Defense in depth requires controls that make different assumptions.
Source integrity, artifact analysis, runtime monitoring and workflow authorization should not all rely on one trust signal.
Deep Analysis: Attackers Are Targeting Automation
Attackers increasingly understand that automation is valuable.
A human maintainer may be difficult to trick repeatedly.
An automation workflow can perform the same privileged action every time its trigger conditions are satisfied.
This makes CI/CD configuration itself an increasingly attractive attack surface.
Deep Analysis: Supply-Chain Attacks Are Becoming More Surgical
The attacker did not need to destroy the package or make it obviously malicious.
The malicious versions were designed to resemble legitimate releases and passed provenance verification.
That suggests a broader evolution toward stealthier supply-chain attacks where attackers focus on bypassing trust mechanisms rather than defeating them directly.
Deep Analysis: Package Popularity Amplifies Risk
Approximately 150,000 weekly downloads makes this package significant enough to attract attention, but the larger lesson is that package popularity is not the only factor that matters.
A small package installed inside a major
Security teams should therefore measure privilege and reach, not downloads alone.
Deep Analysis: The Registry Is Only the First Layer
Once malicious code enters a package registry, defenders often focus on removing the package.
But the registry is only the beginning.
The real investigation must determine what happened after installation.
Were GitHub tokens accessible?
Were cloud credentials exposed?
Were npm tokens present?
Could the machine access internal repositories?
Were package publication permissions available?
Those questions determine the true scope of the incident.
Deep Analysis: Credential Rotation Must Follow Containment
Rotating credentials too early can sometimes leave an attacker with continued access if persistence remains active.
Containment, investigation and rebuilding should therefore be coordinated carefully.
The important principle is that credentials potentially exposed to malware should eventually be considered untrusted.
Deep Analysis: The Workflow Should Be Audited
Organizations should review workflows that publish packages, Docker images, releases and deployments.
Particular attention should be given to workflows triggered by pull-request comments, issues, external events or other user-controlled inputs.
Every privileged workflow should have a clearly defined trust boundary.
Deep Analysis: Authorization Must Be Explicit
A workflow should not assume that because someone can comment on a pull request, that person should be able to trigger a release.
Authorization should be explicit.
The workflow should know who requested the action, what source is being published, what branch it came from and whether the requester has permission to release it.
Deep Analysis: Source and Artifact Must Be Correlated
A robust release process should establish an unambiguous relationship between reviewed source and published artifact.
If a workflow can publish code from a fork while claiming provenance associated with the main repository, that relationship becomes misleading.
The source being published must be the same source that was reviewed and approved.
Deep Analysis: Trusted Publishing Needs Trusted Inputs
The phrase “trusted publishing” can create a false sense of security.
Trusted publishing is only as strong as the inputs supplied to the publishing workflow.
If untrusted source code can enter that workflow, the trust is misplaced.
The publishing system should therefore verify both identity and source integrity.
Deep Analysis: Mini Shai-Hulud Represents a Broader Trend
The incident fits a wider pattern in which package ecosystems are being used as distribution networks for credential-stealing malware.
Mini Shai-Hulud is particularly concerning because propagation can turn individual developer compromises into additional supply-chain events.
Researchers from JFrog and Endor Labs independently analyzed this campaign and reported similarities involving cross-ecosystem propagation and credential theft.
Deep Analysis: The Biggest Lesson Is Architectural
The most important takeaway is not that one npm package was compromised.
It is that the software industry has built enormous trust around automated systems.
Repositories, package registries, OIDC providers, CI runners and developer machines are increasingly connected.
When one component is misconfigured, attackers may be able to move through that chain without ever stealing a traditional password.
What Undercode Say:
A New Kind of Supply-Chain Warning
This incident should concern every organization that relies on open-source dependencies, regardless of whether it directly uses this particular package.
The attack demonstrates how a normal development workflow can become a distribution mechanism for malicious software.
Trust Can Be Weaponized
The attackers reportedly did not need to defeat the entire security model.
They found a legitimate path through it.
That is often more dangerous because defensive systems may interpret the resulting activity as normal.
Provenance Is Valuable but Incomplete
Provenance should remain part of modern software security.
However, organizations must stop treating provenance as a complete guarantee of source integrity.
A valid attestation can coexist with malicious code when the trusted workflow processes an untrusted source.
CI/CD Has Become Critical Infrastructure
Development pipelines now possess credentials capable of changing production systems and publishing software consumed by thousands of organizations.
They should therefore be protected like critical infrastructure rather than ordinary automation.
Pull Requests Need Strong Isolation
External pull requests should never be casually executed inside workflows possessing publishing privileges.
Any workflow that handles fork-controlled code deserves particularly aggressive scrutiny.
Comment-Based Automation Is Dangerous
User-controlled comments can be useful automation triggers, but they should never serve as the only authorization mechanism for sensitive operations.
A comment is input.
It is not identity verification.
Credentials Are the Real Prize
The malicious package is only the initial foothold.
The bigger prize is the collection of credentials surrounding the developer environment.
Once attackers obtain those credentials, the original package may become almost irrelevant.
AI Creates Another Secret Store
AI-agent configuration introduces another category of sensitive data that defenders need to inventory.
Organizations should know what AI tools can access and what credentials their configurations contain.
Supply-Chain Security Must Become Behavioral
Checking package names and signatures is no longer enough.
Security systems need to understand what a package does during installation and what resources it attempts to access.
The Blast Radius Can Be Enormous
A developer package can sit at the intersection of source code, cloud infrastructure and CI/CD systems.
That makes seemingly ordinary development dependencies potentially high-value attack targets.
Rebuilding Should Be Normal After High-Risk Exposure
When malware has executed inside a privileged environment, defenders should avoid assuming that deleting the malicious package solved the problem.
A known-clean rebuild provides stronger assurance.
Least Privilege Remains One of the Best Defenses
If every CI job has broad access, a single compromised dependency can become an enterprise-wide incident.
Narrow permissions can prevent that escalation.
Security Teams Should Audit Release Workflows
Package publishing workflows deserve regular security reviews.
They should be treated as production deployment systems with strict authentication and authorization requirements.
Developers Need Better Dependency Visibility
Teams cannot respond to a supply-chain incident quickly if they do not know which packages are installed where.
SBOMs, lockfiles and centralized dependency inventories can dramatically reduce response time.
The Human Element Still Matters
Even highly automated attacks often begin with a simple workflow design decision.
Security failures are frequently architectural before they are technical.
The Industry Is Learning a Difficult Lesson
The modern software ecosystem was designed around speed and collaboration.
Attackers are learning how to turn those same advantages into weapons.
The Next Attack May Look Legitimate
That may be the most important warning from this incident.
The next malicious package may carry valid signatures, trusted provenance and an apparently legitimate publishing history.
Defenders must therefore look beyond authenticity and examine behavior and source integrity.
Supply-Chain Defense Needs Multiple Layers
No individual control can stop every attack.
The strongest architecture combines restricted workflows, source verification, provenance, dependency pinning, isolated builds, least-privilege credentials and runtime detection.
Security Must Follow the Entire Software Lifecycle
Protection cannot stop at the package registry.
It must cover development, pull requests, CI/CD, publishing, deployment and credential management.
This Incident Is a Wake-Up Call
The compromise of @7nohe/openapi-react-query-codegen is a reminder that the most dangerous attacks may not break through the front door.
Sometimes they convince the
✅ Confirmed: Socket reported 10 malicious versions of @7nohe/openapi-react-query-codegen published on August 28, 2026, affecting every maintained release line and carrying valid npm provenance attestations.
✅ Confirmed: Socket identified a comment-triggered GitHub Actions publishing workflow as the mechanism that allowed untrusted pull-request code to reach the trusted publishing process.
✅ Confirmed: The affected versions included 0.5.4, 0.5.5, 1.6.3, 1.6.4, 2.2.1, 2.2.2, 3.0.3, 3.0.4 and two malicious 0.0.0 prereleases; the known-good versions were 0.5.3, 1.6.2, 2.2.0 and 3.0.2.
❌ Not established: The available research does not prove that every one of the package’s approximately 150,000 weekly downloads resulted in a successful compromise. Download volume indicates potential exposure, not confirmed infection.
❌ Not established: The research does not establish with certainty that one specific threat actor was responsible for the entire Mini Shai-Hulud campaign. Attribution remains an area of investigation.
Prediction
(-1) More npm supply-chain attacks are likely to target CI/CD workflows rather than developer credentials directly. The economics are attractive because abusing trusted automation can provide attackers with legitimate publishing capabilities.
(-1) Provenance-only security checks will increasingly be challenged. Organizations will likely move toward combining provenance with stronger source-to-artifact verification and workflow authorization.
(-1) AI development environments will become increasingly attractive targets. As coding agents gain access to repositories, terminals and credentials, malware authors have more reasons to search for AI-related configuration and secrets.
(-1) Package ecosystems will continue to experience cross-platform propagation attempts. Once attackers obtain registry credentials, spreading through multiple ecosystems can increase the value of a single successful infection.
(+1) CI/CD security practices will improve as organizations recognize publishing workflows as critical infrastructure. Stronger restrictions on fork-based execution, comment-triggered workflows and OIDC permissions can substantially reduce this class of attack.
(+1) Ephemeral runners, short-lived credentials and least-privilege automation will become more common. These controls reduce the amount of valuable information available if a dependency executes malicious code during a build.
(+1) Software supply-chain defense will increasingly shift from simple authenticity checks toward continuous behavioral analysis. The central question will no longer be only “Was this artifact published legitimately?” but also “Was legitimate infrastructure used to publish untrusted code?”
Final Takeaway
The compromise of @7nohe/openapi-react-query-codegen is a powerful warning for the modern software industry.
The attackers reportedly did not need to steal the maintainer’s identity in the conventional sense. Instead, they found a path through a trusted automation system and used that system to distribute attacker-controlled code.
That distinction matters enormously.
The future of supply-chain security cannot depend solely on signatures, provenance or the reputation of a package. Those mechanisms must be combined with strict workflow authorization, source verification, isolated builds, dependency controls, credential segmentation and aggressive incident response.
The most dangerous software may not arrive looking suspicious.
It may arrive carrying the right signature, through the right workflow, from infrastructure that everyone already trusts.
And that is precisely why this incident deserves attention far beyond one npm package.
Add a concise emergency response checklist
Reduce repeated analysis headings
▶️ 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: x.com
Extra Source Hub (Possible Sources for article):
https://www.medium.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
