Listen to this Post
A Quiet Git Feature Has Become a Dangerous Attack Path
Self-hosted development platforms are built on a simple promise: organizations keep control of their source code, repositories, credentials, and development infrastructure instead of placing everything in a public cloud. But that control comes with a responsibility that is easy to underestimate—every exposed server becomes part of the organization’s security perimeter.
That reality is now being tested by a critical vulnerability in Gitea, the popular self-hosted Git service. Tracked as CVE-2026-60004, the flaw can allow attackers to move from repository-level access to arbitrary command execution on the underlying server. Even more concerning, Gitea’s default open-registration configuration can make the attack path reachable without an attacker possessing a previously authorized account.
The situation became serious enough for the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add CVE-2026-60004 to its Known Exploited Vulnerabilities (KEV) Catalog, citing evidence of exploitation. Federal Civilian Executive Branch agencies have been given a three-day remediation window under the applicable CISA directive.
For organizations running Gitea on the public internet, this is no longer a vulnerability that belongs quietly on a backlog. It is an incident-response priority.
The Short Version: What Happened?
CVE-2026-60004 is a critical remote-code-execution vulnerability affecting vulnerable Gitea releases from 1.17 through 1.27.0. Gitea fixed the problem in version 1.27.1, released on July 27, 2026.
The weakness involves
Once that happens, commands can execute with the privileges of the Gitea service account.
That distinction matters. The attacker does not necessarily become root immediately, but control of the Gitea process can still provide access to source code, repository secrets, configuration files, credentials, CI/CD infrastructure, tokens, and other internal resources depending on how the server is configured.
Why This Vulnerability Is So Dangerous
The most worrying part of CVE-2026-60004 is not simply that it permits code execution. It is the combination of remote exposure, a critical severity rating, repository functionality, and potentially open registration.
Gitea is frequently deployed by organizations that want a private alternative to cloud-hosted Git services. Development servers can therefore contain extremely valuable information: proprietary source code, deployment credentials, API keys, SSH keys, build configurations, package credentials, internal documentation, and automation secrets.
An attacker who gains execution on that infrastructure may not need to attack the company’s production servers directly. The development environment can become the bridge.
The Technical Root Cause
The vulnerability resides in the processing of patches through Gitea’s diffpatch functionality. According to Gitea’s security advisory, the endpoint can be abused to install and execute a Git hook using repository-controlled content.
The problem becomes particularly interesting when
A bare Git repository does not have a conventional working tree. Its repository data effectively lives directly in the Git directory. That architectural detail matters because Git hooks are also stored within that internal structure.
Research into the vulnerability describes a sequence in which specially crafted patch operations can trigger Git’s three-way merge behavior and cause an attacker-controlled hook to be written into the repository’s hooks directory.
The resulting hook can then execute commands under the identity of the Gitea service account.
The Open Registration Problem
Under a tightly controlled Gitea installation, an attacker would generally need repository write privileges before reaching the vulnerable functionality.
That is already a serious concern, but it becomes considerably worse when an internet-facing Gitea instance permits users to register accounts and create repositories.
In that configuration, the attacker may be able to follow a chain resembling this:
Internet exposure → account registration → repository creation → repository write access → vulnerable patch processing → Git hook execution → command execution.
The Gitea advisory explicitly warns that default open registration can allow an unauthenticated visitor to obtain the repository access needed to reach the vulnerable functionality.
This is why administrators should not look only at whether their Gitea server has “authentication enabled.” Authentication alone does not necessarily provide meaningful protection if anyone on the internet can create an account.
CISA Raises the Alarm
The most important development is
CISA says the KEV addition is based on evidence of active exploitation, making the issue materially different from an ordinary newly disclosed vulnerability that defenders can schedule for later remediation.
The agency also emphasized that vulnerabilities in the KEV Catalog represent a significant risk to federal environments and encouraged organizations beyond the federal government to prioritize them through risk-based vulnerability management.
For U.S. Federal Civilian Executive Branch agencies, the remediation deadline is August 28, 2026.
Nearly 5,000 Exposed Instances: Why Internet Visibility Matters
Internet-wide scanning data has also highlighted the scale of the problem. Shadowserver tracks thousands of publicly reachable Gitea installations, although the precise number of systems actually vulnerable to CVE-2026-60004 cannot be inferred simply from the number of exposed Gitea interfaces.
An exposed Gitea installation may already be patched, protected by authentication controls, restricted through network policy, or otherwise configured differently from the vulnerable default.
That distinction is important.
Internet exposure does not automatically equal compromise.
But it does increase the opportunity for automated reconnaissance, vulnerability scanning, credential attacks, exploitation attempts, and follow-on intrusion.
The Cryptocurrency-Mining Angle
Reports surrounding exploitation indicate that compromised Gitea servers have been used to deploy cryptocurrency-mining malware.
This is a familiar pattern in mass exploitation campaigns.
Attackers frequently do not need sophisticated espionage objectives when they can automatically identify vulnerable servers, execute a payload, consume their CPU resources, and move on to the next target.
For defenders, however, cryptomining should not be treated as a harmless nuisance.
A mining payload demonstrates that arbitrary code execution has already been achieved. Once an attacker can execute commands on the server, the final objective can change quickly—from mining to credential theft, ransomware deployment, lateral movement, source-code theft, or persistence.
A Gitea Server Is More Valuable Than It Looks
A development server can become a treasure chest for an attacker.
Repositories may contain proprietary intellectual property, internal infrastructure definitions, deployment scripts, test credentials, configuration files, package metadata, CI/CD workflows, container definitions, cloud credentials, and accidentally committed secrets.
Even if passwords are not directly stored in Git, configuration files can reveal enough information to make further attacks easier.
This is why an RCE vulnerability in a development platform should be treated as a potential supply-chain security issue rather than merely another server-side bug.
The Supply-Chain Risk
The modern software-development pipeline is deeply interconnected.
A developer commits code.
A CI system builds it.
A package manager retrieves dependencies.
A container pipeline creates an image.
An automation platform deploys the result.
If an attacker compromises the Git server at the beginning of that chain, the attacker may gain opportunities to influence everything downstream.
This does not mean every CVE-2026-60004 compromise automatically becomes a supply-chain attack. It means the potential blast radius is much larger than the compromised Gitea process itself.
That distinction is critical when determining incident-response priorities.
Gitea 1.27.1 Is the Fix
Gitea released 1.27.1 on July 27, 2026, and the security advisory identifies that release as the patched version. Versions from 1.17 through 1.27.0 are listed as affected.
Administrators should therefore treat 1.27.1 or later as the minimum target when addressing CVE-2026-60004.
Simply restarting the service is not a mitigation.
Changing the exposed port is not a complete mitigation.
Deleting an obviously suspicious repository is not sufficient if the server has already been compromised.
The correct response is to patch, investigate, and assess whether credentials or downstream systems may have been exposed.
Immediate Defensive Actions
1. Upgrade Gitea
The first priority is straightforward: upgrade affected installations to Gitea 1.27.1 or later.
Before upgrading, administrators should follow their normal backup and rollback procedures.
After upgrading, verify the actual running version rather than assuming the package manager completed the update.
2. Disable Open Registration
If public registration is not required, disable it.
A configuration approach commonly recommended for Gitea deployments is:
[service]
DISABLE_REGISTRATION = true
The exact configuration method can differ depending on the installation and deployment model, so administrators should validate the setting against their Gitea configuration and version.
Disabling registration does not patch CVE-2026-60004, but it can remove one particularly dangerous route by which an unauthenticated visitor could obtain repository access.
3. Restrict Internet Exposure
If Gitea does not need to be publicly accessible, place it behind a VPN, private network, access gateway, or restrictive firewall policy.
A development platform does not necessarily need to be exposed directly to the entire internet simply because developers need remote access.
Reducing attack surface is one of the oldest security principles—and it remains remarkably effective.
4. Review Newly Created Accounts
Investigate accounts created shortly before suspicious activity.
Pay particular attention to:
New account
↓
Immediate repository creation
↓
Unusual repository activity
↓
Repeated patch operations
↓
Unexpected child processes
This sequence is not proof of exploitation, but it can be a valuable investigative signal.
5. Review Gitea Logs
Defenders should examine Gitea application and reverse-proxy logs for unusual activity involving patch-related API requests.
For example, a defensive search can begin with:
grep -Ei 'diffpatch|patch|repo.create|user.create' /var/log/gitea/gitea.log
If logs are stored elsewhere, adapt the path accordingly.
The objective is not to blindly search for one magic string. Investigators should correlate timestamps, accounts, source IP addresses, repository names, and subsequent process activity.
6. Look for Suspicious Processes
Because successful exploitation can result in command execution as the Gitea service account, defenders should examine process telemetry.
Useful Linux commands include:
ps aux --forest
and:
pgrep -a -u git
If Gitea runs under a different service account, substitute that account accordingly.
Unexpected shells, download utilities, miners, persistence mechanisms, or processes launched by the Gitea service deserve immediate investigation.
7. Search for Suspicious Git Hooks
Git hooks are legitimate functionality, but unexpected executable hooks can be a warning sign.
Defenders can inventory hook files with:
find /var/lib/gitea -type f -path '/hooks/' -ls 2>/dev/null
The correct storage path depends on the Gitea deployment, so administrators should adjust this command to their environment.
The goal is to identify unusual hook files and compare them against known-good repository state.
Deep Analysis: Understanding the Attack Surface Without Exploiting It
The Vulnerable API
The vulnerable functionality is associated with the diffpatch API endpoint:
POST /api/v1/repos/{owner}/{repo}/diffpatch
The endpoint exists to provide legitimate repository-management functionality.
The security problem arises because attacker-controlled patch data can interact with Git’s repository and hook mechanisms in an unsafe way.
The Bare Repository Problem
Conceptually, the dangerous sequence looks like this:
Attacker-controlled patch
↓
Gitea diffpatch processing
↓
Temporary bare Git repository
↓
Git patch / merge behavior ↓
Repository-controlled hook
↓
Hook execution
↓
Gitea service account
The critical lesson is architectural.
A feature can appear to manipulate “only Git data” while unintentionally crossing the boundary into executable server-side content.
Why Git Hooks Matter
Git hooks are not merely text files.
They are executable automation mechanisms that can be triggered by Git operations.
That means an application that allows untrusted users to manipulate repository structures must treat hook locations as security-sensitive.
The Gitea advisory specifically identifies Git hook installation as the mechanism behind CVE-2026-60004.
Why the Patch Mechanism Became Dangerous
Security researchers analyzing the flaw have described how Git’s three-way merge behavior can undermine assumptions about the –cached patch operation when combined with a bare repository.
This is a good example of why security boundaries cannot be evaluated by looking at one command-line flag in isolation.
A developer may believe that an operation is restricted to an index.
The underlying toolchain may have fallback behavior.
That fallback behavior may interact with the repository layout.
And suddenly, attacker-controlled content can cross from “data” into “executable infrastructure.”
The Importance of Version Verification
Do not rely on a package label alone.
Verify the running Gitea version:
gitea –version
If Gitea runs inside a container, verify the actual image and running process:
docker ps docker exec <container> gitea --version
For Kubernetes deployments, administrators should verify the image tag and running pod rather than checking only the Helm values.
Defensive API Monitoring
Security monitoring should look for unusual use of sensitive repository APIs.
A generic reverse-proxy rule can be used to flag requests containing:
/api/v1/repos/ /diffpatch
This should initially be treated as a monitoring signal rather than an automatic block because legitimate Gitea workflows may use repository APIs.
The stronger signal comes from combining API activity with account creation, repository creation, unusual source addresses, and suspicious server-side processes.
CVE-2026-60004 Is Not
The timing is also important.
Gitea has faced multiple security issues in 2026, including other access-control and repository-related weaknesses. Gitea’s published security advisories list several vulnerabilities disclosed during July, including critical and high-severity issues.
The broader message is uncomfortable but valuable:
Self-hosted does not mean inherently secure.
It means the organization owns more of the security responsibility.
That includes patching, authentication, network segmentation, logging, backup security, secrets management, monitoring, and incident response.
Another Gitea Authentication Bypass Adds Context
The original report also points to CVE-2026-20896, another Gitea vulnerability that was reportedly exploited against instances using reverse-proxy authentication headers.
That incident reinforces a larger pattern: authentication integrations and reverse proxies can create unexpected security boundaries when the application trusts headers supplied by infrastructure in front of it.
Organizations running Gitea behind authentication proxies should therefore review not only application versions but also the trust model between the proxy and Gitea.
What Happens If You Patch Too Late?
Scenario One: The Server Was Never Exploited
The best-case scenario is simple.
You upgrade to 1.27.1 or later.
You disable unnecessary registration.
You restrict external access.
You review the logs.
Nothing suspicious appears.
The incident ends as a vulnerability-remediation event.
Scenario Two: Someone Tested the Vulnerability
A more concerning situation occurs when logs reveal suspicious patch activity but no evidence of persistence.
In that case, preserve logs, investigate the associated account and repository, inspect process activity, review filesystem changes, and determine whether secrets were accessible.
Scenario Three: Full Server Compromise
The most serious scenario is evidence that arbitrary commands were successfully executed.
At that point, do not assume upgrading Gitea alone cleans the system.
Treat the host as potentially compromised.
Depending on the environment, this can mean isolating the system, preserving forensic evidence, rotating credentials, reviewing SSH keys, checking CI/CD secrets, rebuilding the host from a trusted image, and examining connected infrastructure.
Why Credential Rotation Matters
A Gitea compromise can expose much more than repository files.
Configuration files may contain database credentials, OAuth information, SMTP credentials, signing secrets, application configuration, or integration credentials depending on how the instance was deployed.
If compromise is confirmed, credentials should be rotated according to their risk and scope.
The most important principle is simple:
Do not rotate only the password used to access Gitea.
Investigate what the compromised service could access.
The CI/CD Connection
Modern repositories rarely exist in isolation.
A commit may trigger GitHub-style automation, Jenkins pipelines, GitLab runners, Drone, Woodpecker, Kubernetes deployments, cloud builds, package publishing, container builds, or custom internal automation.
If the Gitea server can communicate with those systems, attackers may attempt lateral movement.
That makes network segmentation particularly valuable.
The Gitea server should not automatically have unrestricted access to every internal production service simply because developers need to push code to it.
What Security Teams Should Learn From This
Development Infrastructure Is Production Infrastructure
A common organizational mistake is treating source-code servers as “internal developer tools.”
That mindset is outdated.
Source repositories increasingly contain the instructions that build and deploy production systems.
Compromise the source environment, and an attacker may gain influence over the production environment.
Defaults Matter
Open registration is convenient.
It is also dangerous on an internet-facing development platform when a vulnerability requires only ordinary repository privileges.
Security teams should periodically review application defaults rather than assuming that “default” means “safe.”
Patch Priority Should Follow Exploitation
A vulnerability can have a spectacular CVSS score without being actively exploited.
CVE-2026-60004 has an additional warning sign: CISA has placed it in the KEV Catalog based on evidence of exploitation.
That changes the operational priority.
The question is no longer:
Can we patch this next maintenance cycle?
The better question is:
“What can we do today to determine whether we are exposed?”
What Undercode Say:
The Real Danger Is the Combination
CVE-2026-60004 is dangerous because several individually manageable conditions can combine into a serious attack path.
Self-Hosted Means Self-Responsible
Gitea gives organizations control over their Git infrastructure, but that control comes with operational responsibility.
Open Registration Changes Everything
An RCE requiring repository write access sounds more restrictive than a completely unauthenticated vulnerability.
Open registration can erase much of that distinction.
The Repository Is an Attack Surface
Developers naturally think about repositories as collections of source files.
Security teams must also think about repository operations, hooks, APIs, automation, and server-side Git behavior.
Git Is More Than Version Control
Git can execute hooks, invoke external processes, interact with credentials, and participate in deployment automation.
It therefore deserves the same security scrutiny as other execution-capable infrastructure.
The Gitea Process Is Valuable
Even without root privileges, the Gitea service account can potentially access information that attackers find extremely valuable.
Source Code Is Intellectual Property
For many companies, source code is one of their most important assets.
A vulnerability that exposes repository infrastructure can therefore become a direct business risk.
Secrets Are Often Nearby
Repositories, CI configurations, environment files, deployment scripts, and application configuration can expose secrets even when developers believe credentials are stored elsewhere.
CISA’s KEV Listing Is a Major Signal
CISA does not add vulnerabilities to the KEV Catalog merely because they have high CVSS scores.
The
Three Days Is a Warning
The federal remediation deadline illustrates how seriously actively exploited vulnerabilities are treated.
Private Servers Can Still Be Exposed
Organizations sometimes assume that self-hosted means private.
A public IP address, reverse proxy, cloud load balancer, or exposed management interface can make the distinction meaningless.
Attackers Scan Continuously
Once a vulnerability becomes publicly known, defenders should expect automated scanning to increase.
Exploit Availability Accelerates Risk
Public technical research and proof-of-concept material can reduce the barrier for less sophisticated attackers.
That makes patching increasingly important as time passes.
Logs Become Evidence
The difference between “vulnerable” and “compromised” often comes down to telemetry.
Without useful logs, organizations may never know whether an attacker entered through the vulnerable endpoint.
Account Creation Is an Important Signal
On systems with open registration, unexpected new accounts deserve additional scrutiny.
Repository Creation Is Another Signal
A newly created account followed rapidly by repository creation and unusual API activity can form a valuable investigation pattern.
Child Processes Matter
A Git service spawning unexpected shells, downloaders, miners, or scripting interpreters should attract attention.
Persistence Is the Bigger Threat
Attackers who obtain execution may attempt to establish persistence rather than immediately reveal themselves.
Cryptomining Can Be a Smoke Screen
A miner may be the visible payload while credential theft or lateral movement remains the more serious underlying objective.
Development Servers Deserve EDR
Endpoint detection and response should not stop at employee laptops.
Development servers are increasingly high-value targets.
Network Segmentation Can Limit Damage
Even a successful Gitea compromise becomes harder to weaponize when the server cannot freely communicate with critical production systems.
Secrets Should Be Short-Lived
Long-lived credentials increase the consequences of a server compromise.
CI Tokens Deserve Special Attention
If Gitea can interact with build infrastructure, CI credentials should be reviewed after a confirmed compromise.
Backups Need Protection
An attacker who compromises the development server should not automatically gain the ability to destroy recovery backups.
Patch Management Needs Context
A vulnerability marked “critical” should not necessarily receive the same priority as one that is actively exploited.
CVE-2026-60004 has both signals.
Gitea Administrators Should Verify, Not Assume
A successful package update is not proof that every running process has been upgraded.
Container Users Have a Different Failure Mode
A patched image does not protect an old container that is still running.
Kubernetes Adds Another Layer
Operators should verify the actual running pod image and rollout status.
Reverse Proxies Need Review
Authentication headers and trusted proxy configurations can become security boundaries of their own.
Security Is a Chain
Gitea security, operating-system security, network security, identity security, and CI/CD security are interconnected.
The Vulnerability Is a Lesson in Complexity
The flaw demonstrates how a seemingly legitimate Git operation can interact with lower-level behavior in an unexpected way.
Small Implementation Details Can Have Huge Consequences
A repository-processing decision can ultimately become arbitrary command execution.
Public Exposure Raises the Stakes
An internal development service exposed to the internet deserves the same seriousness as other internet-facing infrastructure.
Patch First, Investigate Second—but Do Both
Organizations should remove the vulnerability quickly while simultaneously determining whether exploitation has already occurred.
Do Not Wait for a Perfect IOC
The absence of a known malicious file does not prove that exploitation did not happen.
Incident Response Should Follow the Blast Radius
If command execution is confirmed, investigate connected credentials and systems rather than stopping at the Gitea server.
Gitea Is Only One Example
The same security philosophy applies to GitLab, Jenkins, CI servers, artifact repositories, package registries, and other development infrastructure.
The Bigger Story Is DevSecOps
Modern software infrastructure is an attractive target because one compromised development system can potentially influence many downstream systems.
The Final Warning
CVE-2026-60004 should not be viewed as simply another Git vulnerability.
It is a reminder that the infrastructure used to create software can itself become a weapon against the organizations creating that software.
✅ CVE-2026-60004 Is a Critical Gitea Vulnerability
Confirmed.
✅ Gitea 1.27.1 Fixes the Vulnerability
Confirmed. Gitea’s advisory lists versions below 1.27.1 as affected and 1.27.1 as the patched release. The project’s changelog also records the 1.27.1 release on July 27, 2026.
✅ Open Registration Can Create an Unauthenticated Attack Path
Confirmed. Gitea explicitly states that with default open registration, an unauthenticated visitor can register, create a repository, obtain write access, and reach the vulnerable functionality.
✅ CISA Added CVE-2026-60004 to KEV
Confirmed. CISA announced the addition on August 25, 2026, and stated that the catalog addition was based on evidence of active exploitation.
✅ Federal Agencies Face an August 28 Deadline
Confirmed in the supplied report and consistent with CISA’s current KEV-driven remediation posture. The three-day deadline is tied to the federal vulnerability-remediation requirements described in the report. CISA’s alert confirms the KEV action and active-exploitation basis.
⚠️ The “Nearly 5,000 Exposed Gitea Instances” Figure Needs Context
Partially confirmed. Shadowserver publicly tracks vulnerable and exposed internet services, but the existence of thousands of exposed Gitea interfaces does not establish that all of those systems are vulnerable to CVE-2026-60004. Some may already be patched or differently configured.
⚠️ Cryptocurrency Mining Should Be Treated as an Exploitation Report, Not a Universal Outcome
Important distinction. Exploitation can lead to cryptomining, but CVE-2026-60004 itself does not mean every vulnerable server will be infected with a miner. Organizations should investigate for multiple possible post-exploitation objectives.
Prediction
(+1) Patching Will Rapidly Reduce the Most Obvious Attack Surface
The strongest positive prediction is that organizations running actively maintained Gitea infrastructure will move quickly toward 1.27.1 or later now that CISA has added CVE-2026-60004 to KEV.
As awareness spreads, security teams will increasingly treat public-facing Git infrastructure as a high-priority asset rather than an ordinary internal application.
(+1) More Organizations Will Disable Open Registration
The incident is likely to push administrators toward stricter account-creation policies.
Where public registration is not genuinely required, disabling it provides a useful additional security layer by preventing anonymous visitors from automatically obtaining repository-creation privileges.
(+1) Development Infrastructure Will Receive More Security Monitoring
The attack demonstrates why EDR, centralized logging, network segmentation, and anomaly detection should cover Git servers and CI/CD systems.
Organizations that previously focused monitoring primarily on endpoints may begin treating development infrastructure as part of the production security boundary.
(-1) Unpatched Internet-Facing Servers Will Remain Attractive Targets
The negative prediction is straightforward: vulnerable Gitea installations that remain online will likely continue attracting automated scanning and exploitation attempts.
The combination of public technical details, internet exposure, and CISA KEV status creates a strong incentive for attackers to search for remaining vulnerable systems.
(-1) Some Victims May Discover the Problem Only After Secondary Activity
A compromised Gitea server may initially appear normal.
Attackers can potentially use access for reconnaissance, credential collection, persistence, or lateral movement before deploying an obvious payload.
That means some organizations may discover exploitation only after seeing unusual outbound traffic, suspicious processes, stolen credentials, or activity elsewhere in their environment.
The Bottom Line
CVE-2026-60004 is a serious warning for anyone operating Gitea on their own infrastructure.
The technical flaw is complicated, but the defensive decision is not.
Upgrade to Gitea 1.27.1 or later.
Disable open registration if it is unnecessary.
Restrict public exposure.
Review logs and newly created accounts.
Investigate suspicious processes and Git hooks.
Rotate credentials if compromise is suspected or confirmed.
Most importantly, do not assume that a development server is less important than a production server.
In today’s software ecosystem, the development environment can be the road into everything else.
CVE-2026-60004 is therefore more than another critical CVE. It is a reminder that the systems used to write, store, build, and deploy software have become some of the most strategically valuable infrastructure inside modern organizations—and attackers know it.
🕵️📝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.bleepingcomputer.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
