Listen to this Post
A New Warning for Security Teams
Network security platforms are supposed to sit between organizations and attackers. But when the centralized system responsible for managing those defenses contains remotely exploitable flaws, the security equation can change dramatically.
A new MS-ISAC advisory dated August 11, 2026, warns of multiple vulnerabilities in SonicWall Global Management System (GMS), including several command-injection and remote-code-execution weaknesses. The most concerning issues can potentially be exploited without authentication, meaning an attacker may not need legitimate credentials before attempting to compromise an exposed GMS installation.
The affected product is SonicWall GMS, a centralized management platform used to administer SonicWall firewalls and other security products from a single console. According to the advisory, GMS Virtual Appliance and Windows deployments running version 9.5.1 and earlier are affected.
The good news is that there are currently no reports of these vulnerabilities being exploited in the wild. The bad news is that the technical characteristics of the flaws make them exactly the kind of vulnerabilities security teams should not leave exposed while waiting to see whether attackers begin using them.
Why SonicWall GMS Matters
SonicWall Global Management System is more than an ordinary web application. It provides centralized administrative control over security infrastructure, allowing organizations to manage firewalls, wireless security, email security, secure remote access and other supported SonicWall technologies through a common management environment.
That centralized role makes GMS particularly sensitive.
If an attacker compromises an ordinary workstation, the immediate impact may be limited to that machine. Compromising a centralized security-management server can be a completely different story.
Depending on the privileges assigned to the affected service account, successful exploitation could allow an attacker to install software, read or modify information, delete data, execute commands or create additional accounts.
The potential impact therefore extends beyond the GMS server itself.
Six Vulnerabilities Create a Larger Attack Surface
The advisory describes six separate vulnerabilities affecting SonicWall GMS. They do not all provide the same attack path, but together they create a concerning collection of weaknesses involving arbitrary file writes, command injection, cross-site scripting, certificate validation and insecure object handling.
The vulnerabilities are identified as CVE-2026-66145, CVE-2026-66146, CVE-2026-66147, CVE-2026-66148, CVE-2026-66154 and CVE-2026-18634.
The most serious concern is not simply the number of CVEs. It is the combination of unauthenticated access, command execution and the privileged role GMS can occupy inside an enterprise.
CVE-2026-66145: Unauthenticated Remote Code Execution
CVE-2026-66145 is described as an unauthenticated remote code execution vulnerability involving arbitrary file writing through a ZIP Slip-style attack.
ZIP Slip vulnerabilities generally occur when an application extracts archive contents without properly validating file paths. A malicious archive can contain paths designed to escape the intended extraction directory and write files somewhere else on the system.
When the vulnerable application processes such content improperly, an attacker may be able to place files in locations they should never be able to access.
In this case, the advisory says the vulnerability can allow a remote attacker to read sensitive information and perform arbitrary file writes without authentication.
That makes this vulnerability particularly important for organizations whose GMS interface is reachable from untrusted networks.
CVE-2026-66146: Cross-Site Scripting
CVE-2026-66146 covers multiple cross-site scripting vulnerabilities.
XSS is sometimes dismissed as less serious than direct remote code execution, but that assumption can be dangerous in an administrative management interface.
An attacker who successfully executes malicious JavaScript in the browser of an administrator may potentially interact with the application using that administrator’s authenticated session.
The real-world impact depends heavily on how the vulnerable functionality is exposed, which privileges the victim has and whether additional protections are present.
In a centralized management console, however, compromising an administrator’s browser session can have consequences far beyond the browser itself.
CVE-2026-66147: Unauthenticated Command Injection
CVE-2026-66147 is another major concern.
According to the advisory, an unauthenticated attacker can potentially achieve remote code execution through specially crafted requests.
Command injection vulnerabilities are particularly dangerous because they can transform an input-validation weakness into operating-system-level command execution.
The fact that this issue is described as unauthenticated increases the urgency.
An attacker does not necessarily have to steal an administrator password first. If the vulnerable endpoint is reachable and exploitation conditions are satisfied, the attacker may be able to send malicious requests directly to the service.
CVE-2026-66148: Privilege Escalation to Root
CVE-2026-66148 follows a different path.
This vulnerability requires authentication, but the advisory states that a low-privileged local user could exploit command injection functionality to execute system commands with root privileges.
This is a classic example of why least privilege matters.
A low-privileged account should not be capable of turning itself into a root-level execution context simply by interacting with an application component in an unexpected way.
Organizations should therefore treat low-privileged GMS accounts as potentially valuable stepping stones for attackers.
CVE-2026-66154: Certificate Validation Weakness
CVE-2026-66154 involves insufficient certificate validation within a privileged communication workflow.
The advisory says exploitation would require a successful man-in-the-middle attack and controlled network conditions.
That makes this vulnerability different from the unauthenticated command-injection issues.
It is not necessarily an internet-wide instant compromise scenario. Instead, it becomes relevant when an attacker can position themselves between communicating systems and manipulate the relevant network traffic.
In environments where management infrastructure crosses less-trusted network segments, this deserves particular attention.
CVE-2026-18634: Insecure Deserialization
CVE-2026-18634 involves insecure handling of serialized objects.
The advisory states that a local attacker capable of interacting with the affected service could exploit the behavior to perform unauthorized actions.
Insecure deserialization has historically been a serious application-security problem because serialized data can sometimes contain instructions or object structures that cause unexpected behavior when processed by a vulnerable application.
Combined with other weaknesses, such a flaw can potentially become part of a larger attack chain.
The Bigger Problem Is the Attack Chain
Looking at these vulnerabilities individually can make the situation appear fragmented.
Looking at them as an attack surface tells a different story.
An attacker may not need one vulnerability to accomplish everything.
They could potentially use an externally reachable weakness for initial access, exploit a file-writing primitive, establish persistence, steal credentials, manipulate application data or move toward privileged execution.
The advisory maps the vulnerabilities to MITRE ATT&CK Initial Access and specifically identifies Exploit Public-Facing Application (T1190) as the relevant technique.
That classification is important because it highlights the fundamental risk: exposed management software is itself an attractive entry point.
No Exploitation Reports — For Now
The MS-ISAC advisory states that there are currently no reports of these vulnerabilities being exploited in the wild.
That is reassuring, but it should not be interpreted as a reason to delay remediation.
The period between vulnerability disclosure and active exploitation can be unpredictable.
Once technical details become public, security researchers, vulnerability analysts and threat actors can all begin studying the same software.
A vulnerability that has not been exploited today can become a practical attack tool tomorrow.
A History of SonicWall Security Problems Adds Context
SonicWall products have repeatedly attracted security researchers because they occupy strategically important positions in enterprise networks.
Older SonicWall GMS vulnerabilities have included serious command-execution and deserialization issues. Public vulnerability records document historical GMS weaknesses that allowed remote attackers to execute commands or Java code under certain conditions.
That history does not mean the current vulnerabilities are being exploited, nor does it establish that the current code shares the same root cause. It does, however, reinforce why centralized security-management software deserves the same patching discipline as internet-facing firewalls and VPN appliances.
SonicWall’s own GMS 9.5.1 release documentation describes the release as a maintenance update containing critical bug fixes and notes that it includes fixes for vulnerability issues reported in previous GMS releases.
Systems Affected
The advisory identifies SonicWall GMS Virtual Appliance and Windows deployments running version 9.5.1 and earlier as affected.
Organizations should therefore inventory both physical and virtual deployments rather than assuming that only one installation type requires attention.
Virtual appliances can sometimes be forgotten because they are managed differently from conventional Windows servers, but from an attacker’s perspective, the distinction is irrelevant if the vulnerable service is reachable.
Why Internet Exposure Matters
A management console that is directly accessible from the internet should always be considered a high-value target.
Security administrators should ask a simple question:
Does GMS actually need to be reachable from the public internet?
In many environments, the answer should be no.
Management interfaces should ideally be accessible only from trusted administrative networks, VPN-protected segments or dedicated management infrastructure.
Reducing exposure does not eliminate the vulnerability, but it can dramatically reduce the number of attackers capable of interacting with it.
Least Privilege Can Reduce the Blast Radius
The advisory strongly recommends applying the principle of least privilege.
This recommendation deserves special attention because remote code execution does not automatically mean complete control of an entire organization.
The final impact depends heavily on what privileges the compromised service possesses.
If a vulnerable service operates with excessive administrative rights, exploitation can become much more damaging.
If the service is restricted to only the permissions it actually requires, the attacker may encounter additional barriers.
Least privilege is therefore not simply an access-control philosophy. It is a damage-containment mechanism.
Network Segmentation Is Another Critical Defense
Security management systems should not live in the same unrestricted network segment as ordinary employee devices.
A segmented architecture can prevent a compromised management server from becoming an easy bridge into sensitive internal systems.
Organizations should consider placing administrative infrastructure in dedicated network zones and restricting communication between those zones and production networks.
The goal is straightforward:
If one system falls, the rest of the organization should not automatically fall with it.
Deep Analysis
Understanding the ZIP Slip Risk
A vulnerable archive extraction process might conceptually perform something similar to:
extract("backup.zip", "/opt/gms/uploads/")
The dangerous part occurs when an archive contains a path such as:
../../../../tmp/malicious-file
If the application blindly trusts the archive path, extraction can escape the intended directory.
A secure application should canonicalize and validate the resulting path before writing anything:
realpath(target_path)
The security principle is simple:
resolved_path must remain inside the intended extraction directory
Administrators should not attempt to exploit the vulnerable service themselves on production systems. Instead, they should use approved vulnerability scanners and vendor-supported remediation procedures.
Checking the Installed GMS Version
On Linux-based GMS deployments, administrators can inspect running processes and installed application information using commands appropriate to their environment, for example:
uname -a
ps aux | grep -i gms
For a Windows installation, administrators can inspect installed software and service information through PowerShell:
Get-Service | Where-Object {$_.DisplayName -match "SonicWall|GMS"}
Installed software can also be reviewed through approved enterprise inventory tooling.
The important objective is not simply identifying the operating system. Security teams need to determine the exact GMS release and build.
Finding Unexpected Network Exposure
Linux administrators can review listening services with:
ss -lntup
Windows administrators can use:
Get-NetTCPConnection -State Listen
Firewall and load-balancer configurations should then be reviewed to determine whether the GMS management interface is accessible from the internet, untrusted VLANs or other unnecessary network segments.
Reviewing Suspicious Authentication Activity
Security teams should also examine authentication and application logs for unusual activity.
Useful indicators can include:
Repeated failed authentication
Unexpected administrator logins
New accounts
Unexpected configuration changes
Unusual file creation
Unexpected process execution
Outbound connections from GMS
Administrative activity outside normal hours
Centralized logging and SIEM correlation can make these patterns easier to identify.
Looking for Command Injection Indicators
Because the advisory identifies command injection vulnerabilities, defenders should pay particular attention to anomalous process activity originating from GMS services.
Potential indicators include unexpected shell processes:
ps aux --forest
or unusual child processes associated with application services.
On Windows systems, defenders can investigate process creation telemetry through:
Get-WinEvent -LogName Security
Organizations should rely on their established EDR, SIEM and forensic tooling rather than using a single command as proof of compromise.
Scanning Without Exploiting
A vulnerability scanner can help determine whether vulnerable versions remain deployed.
A basic network discovery workflow might begin with:
nmap -sV <GMS-IP>
However, version detection alone is not proof that a particular CVE is exploitable.
Authenticated vulnerability assessment is generally more reliable because it can compare installed software and configuration information against known vulnerable versions.
Aggressive exploitation scripts should not be run against production management systems without explicit authorization.
What Administrators Should Do Immediately
Step One: Identify Every GMS Instance
Create an inventory of every SonicWall GMS deployment, including Windows systems and virtual appliances.
Do not assume that there is only one installation.
Large organizations may have separate management servers for different business units, geographic regions or network environments.
Step Two: Confirm the Version
Determine whether each system is running 9.5.1 or earlier.
Record the exact version, build, host, IP address, business owner and network exposure.
This creates a clear remediation map.
Step Three: Apply Vendor Updates
SonicWall recommends keeping supported software current, and organizations should apply the appropriate security updates after testing them against their environment.
The safest approach is to obtain updates directly through SonicWall’s official support and software distribution channels rather than third-party download sites.
SonicWall’s documentation confirms that GMS 9.5.1 is a supported release and describes its upgrade paths from earlier GMS versions.
Step Four: Reduce Internet Exposure
If GMS is publicly accessible, restrict it.
Where practical, place administrative access behind VPN, dedicated management networks, access-control lists, identity-aware proxies or equivalent controls.
Do not treat network restriction as a replacement for patching.
It is an additional defensive layer.
Step Five: Review Service Account Privileges
Determine which operating-system account runs GMS services.
Ask whether that account actually requires administrative privileges.
If not, reduce its permissions according to
The objective is to prevent an application compromise from automatically becoming full operating-system compromise.
Step Six: Inspect Logs
Review authentication, application, system, EDR and network logs for signs of exploitation.
Pay particular attention to:
Unexpected remote requests
Suspicious administrative logins
Newly created accounts
Unexpected configuration changes
Unknown files
Unusual child processes
Unexpected outbound network connections
Attempts to access sensitive files
Step Seven: Rotate Credentials If Compromise Is Suspected
If investigation produces credible evidence that a GMS system was compromised, credentials accessible from that system should be treated as potentially exposed.
Credential rotation should be performed according to the organization’s incident-response procedures.
Why Home Users Face a Different Risk
SonicWall GMS is primarily an enterprise management product, so the risk profile for ordinary home users is substantially lower.
Most home users are unlikely to have GMS deployed.
The main concern is therefore directed toward organizations, government agencies, managed service providers and enterprises operating SonicWall infrastructure.
For those environments, however, GMS should be treated as security-critical infrastructure rather than ordinary management software.
Why Managed Service Providers Should Pay Special Attention
Managed service providers may face a particularly serious scenario because centralized management systems can represent multiple customer environments.
If one GMS installation manages security infrastructure belonging to multiple organizations, compromise could potentially create consequences across several customer environments.
That makes asset inventory, tenant isolation, privileged access management and segmentation especially important for service providers.
A single vulnerable management platform should never become a single point of failure for dozens or hundreds of customers.
The Importance of the Service Account
The advisory makes an important distinction: exploitation occurs in the context of the affected service account.
That phrase can easily be overlooked.
Remote code execution does not automatically provide the attacker with unlimited privileges. The actual outcome depends on what the compromised process is allowed to do.
This is why security teams should evaluate both vulnerability severity and execution context.
A critical vulnerability running as root or administrator is potentially far more dangerous than the same vulnerability operating under a heavily restricted account.
Attackers Are Increasingly Targeting Management Planes
Modern attacks are increasingly focused on management infrastructure.
The reason is simple.
Management systems provide control.
A compromised endpoint might provide access to one employee. A compromised management platform can potentially provide the ability to manipulate many devices.
This pattern has appeared repeatedly across firewalls, VPN gateways, remote-management platforms, virtualization systems, identity infrastructure and cloud control planes.
Security teams therefore need to protect management interfaces with the same intensity they apply to externally facing applications.
The Hidden Danger of Not Exploited Yet
One of the most dangerous phrases in vulnerability management is “no known exploitation.”
It describes the current threat-intelligence picture, not the future.
A vulnerability can move through several stages:
Disclosure
↓
Technical analysis
↓
Proof of concept
↓
Weaponization
↓
Mass scanning
↓
Targeted exploitation
Defenders should try to patch before the vulnerability reaches the final stages.
Once mass scanning begins, defenders lose one of their biggest advantages: time.
What Undercode Say:
Centralized Security Creates Centralized Risk
SonicWall GMS is designed to simplify security administration.
That is its strength.
It is also what makes vulnerabilities in the platform so important.
A system that controls many security devices naturally becomes a high-value target.
Remote Code Execution Changes Everything
The most serious concern in this advisory is the presence of remote code execution.
An attacker who can move from a malformed request to operating-system command execution has crossed a major security boundary.
That boundary should never be underestimated.
Authentication Is a Critical Divider
The unauthenticated vulnerabilities deserve immediate attention because attackers do not need legitimate credentials to begin testing them.
This dramatically lowers the barrier to exploitation.
Public Exposure Multiplies the Risk
An internet-facing GMS server can potentially be discovered by automated scanning.
Attackers do not need to know the organization personally.
They can scan ranges, fingerprint services and identify potential targets automatically.
Security Infrastructure Is Becoming a Prime Target
Attackers increasingly understand that compromising defensive infrastructure can be more valuable than attacking individual endpoints.
If the
Least Privilege Is Not Optional
Running services with excessive privileges transforms application vulnerabilities into infrastructure-level disasters.
Least privilege can create an important containment boundary.
Segmentation Is the Second Wall
Even after successful exploitation, an attacker should encounter another barrier.
Network segmentation provides that barrier.
A compromised GMS system should not have unrestricted access to databases, employee workstations and critical servers.
Administrative Interfaces Should Be Boring
The safest management interface is one that nobody on the public internet can reach.
Administrative systems should be difficult to discover, tightly restricted and heavily monitored.
Convenience should not override security.
Patch Speed Matters
The longer a vulnerable management platform remains unpatched, the larger the opportunity window becomes.
Attackers do not need months.
They sometimes need only days.
Vulnerability Management Must Be Continuous
Organizations should not wait for emergency advisories to discover what software they operate.
Asset inventory should already answer that question.
Version Visibility Is Fundamental
Security teams cannot patch what they cannot identify.
Every GMS instance should have an owner, version, location and exposure status.
Service Accounts Deserve More Attention
Service accounts often live quietly in the background.
That makes them easy to overlook.
They should be inventoried, monitored and reviewed regularly.
Credentials Could Become Secondary Targets
A compromised management platform may expose credentials, configuration information or connection details.
Security teams should consider what secrets are stored or processed by the system.
Logs Become Critical After Disclosure
Once a serious vulnerability is announced, historical logs become more valuable.
Organizations should preserve relevant telemetry before retention windows erase it.
Detection Should Accompany Patching
Patching fixes the vulnerability.
Detection helps determine whether somebody already exploited it.
Both are necessary during high-risk vulnerability events.
No Exploitation Does Not Mean No Risk
The absence of confirmed attacks is encouraging.
It is not a security control.
Security Teams Should Think in Attack Chains
Attackers rarely depend on a single vulnerability when multiple paths are available.
One flaw can provide access.
Another can provide privilege escalation.
A third can provide persistence.
GMS Should Be Treated as Critical Infrastructure
It manages security infrastructure.
That alone should elevate its patching priority.
Managed Service Providers Face Greater Consequences
A centralized GMS deployment supporting multiple customers can concentrate risk.
Isolation between customers becomes essential.
Virtual Appliances Need Equal Attention
Virtualization does not make a vulnerable application safer.
The same vulnerable application logic can remain exploitable regardless of whether it runs on physical or virtual infrastructure.
Network Controls Buy Time
A firewall rule cannot repair vulnerable code.
But it can prevent random internet scanners from reaching the application.
That additional time can be extremely valuable.
EDR Can Reveal the Aftermath
Unexpected shells, scripting engines or system utilities launched by GMS processes should be investigated.
Process telemetry can expose exploitation that application logs fail to capture.
SIEM Correlation Can Reveal Patterns
A single suspicious event might appear harmless.
Multiple events occurring together can tell a very different story.
Administrators Need an Emergency Playbook
Organizations should already know who owns GMS, who can patch it and how to isolate it.
Waiting for an incident to determine those responsibilities wastes valuable time.
Backup Configuration Data
Before major remediation, organizations should ensure they have secure and tested backups of required configurations.
Backups should themselves be protected from unauthorized modification.
Do Not Test Public Exploits Against Production
Security validation should be authorized and controlled.
Production management systems are poor places for uncontrolled exploit experimentation.
Penetration Testing Still Matters
Automated scanners are useful, but complex application vulnerabilities may require manual assessment.
The advisory itself recommends penetration-testing programs and remediation of discovered findings.
Security Architecture Matters More Than One Patch
Patching closes a known hole.
Architecture determines what happens if the next hole appears.
Management Planes Need Isolation
Critical administrative infrastructure should occupy dedicated network zones wherever practical.
Internet Access Should Be Minimized
Management servers generally do not need unrestricted outbound connectivity.
Restricting outbound traffic can also make command-and-control activity harder.
The Current Window Is an Opportunity
There are no reported in-the-wild exploits at the time of the advisory.
That means defenders still have an opportunity to act before exploitation becomes widespread.
The Real Lesson Goes Beyond SonicWall
This is not merely a SonicWall story.
It is a reminder that every centralized management platform represents concentrated power.
The more devices a platform controls, the more attractive it becomes to attackers.
Security Teams Should Act Before the Headlines
Once exploitation becomes widespread, patching becomes a race.
Before exploitation, patching is preparation.
That difference can determine whether an organization experiences a routine maintenance event or a major incident.
✅ The Vulnerability Count and CVE List Match the Advisory
The supplied advisory identifies six vulnerabilities affecting SonicWall GMS and lists CVE-2026-66145, CVE-2026-66146, CVE-2026-66147, CVE-2026-66148, CVE-2026-66154 and CVE-2026-18634.
The technical descriptions provided in the original text distinguish between unauthenticated RCE, XSS, authenticated command injection, certificate validation and insecure serialized-object handling.
✅ GMS 9.5.1 Is a Real SonicWall Release
SonicWall’s official documentation confirms GMS 9.5.1 as a real release and describes it as a maintenance release containing critical bug fixes. SonicWall also documents supported virtual-appliance deployment and upgrade paths to 9.5.1.
✅ The Centralized-Management Description Is Consistent With GMS
SonicWall documentation confirms that GMS is used as a centralized management system for supported SonicWall appliances and security products. The product documentation also describes virtual-appliance deployment and supported managed platforms.
⚠️ No Exploitation Claim Requires Continuous Monitoring
The supplied advisory says there were no reports of exploitation in the wild when it was issued.
That is a time-specific threat-intelligence statement, not a permanent guarantee that exploitation will not occur.
Prediction
(+1) Security Teams Will Prioritize GMS Patching Before Exploitation Becomes Widespread
The strongest positive prediction is that organizations operating SonicWall GMS will accelerate patching and reduce unnecessary exposure before attackers can turn the disclosed vulnerabilities into large-scale campaigns.
Because several issues involve unauthenticated attack paths and command execution, security teams have a strong incentive to treat the advisory as an emergency vulnerability-management event rather than a routine monthly update.
(+1) Network Segmentation Will Reduce the Impact of Successful Exploitation
Organizations that already isolate administrative infrastructure should be better positioned to contain an intrusion.
Even if an attacker manages to compromise GMS, segmentation can prevent immediate access to unrelated production systems.
(-1) Exposed and Unpatched Systems Could Become Attractive Scanning Targets
The negative scenario is straightforward.
If vulnerable GMS deployments remain publicly accessible, attackers may eventually begin automated discovery and exploitation.
The combination of public exposure, unauthenticated vulnerabilities and administrative functionality makes delayed remediation particularly risky.
(-1) Privileged Service Accounts Could Magnify the Damage
If a compromised GMS service operates with excessive privileges, successful exploitation could result in much greater system-level control.
That is why patching and privilege reduction should be treated as complementary defenses.
Final Assessment
A Vulnerability Disclosure That Deserves Immediate Attention
The SonicWall GMS vulnerabilities disclosed in the August 11, 2026 MS-ISAC advisory should be treated as a serious enterprise-security issue.
The most important detail is not simply that six CVEs exist.
It is that several of them affect a centralized management platform, including vulnerabilities described as unauthenticated command injection and remote code execution.
There are currently no reported in-the-wild attacks according to the advisory, giving defenders a valuable window to respond.
Organizations running SonicWall GMS should identify every affected installation, confirm versions, apply the appropriate vendor updates, restrict unnecessary network exposure, review service-account privileges and investigate logs for suspicious activity.
The broader lesson is even more important: the systems responsible for managing security infrastructure must themselves be among the most heavily protected assets in the enterprise.
A firewall can stop an attacker at the network boundary. But if the platform controlling that firewall becomes compromised, the attacker may eventually find a way around the very defenses designed to keep them out.
That is why this advisory should not be treated as just another software update.
It is a warning about the security of the control plane itself.
🕵️📝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.cisecurity.org
Extra Source Hub (Possible Sources for article):
https://www.pinterest.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
