Network Security
system security Linux network
system security Linux network The romanticized image of the digital nomad – a laptop on a sun-drenched balcony – rarely accounts for the actual friction of maintaining a professional development environment on the move. . The friction is amplified with Linux. We are looking for a setup that respects our kernel configurations, handles volatile network handovers, and maintains a strict security posture without the hand-holding of a consumer-grade OS – so, put simply, more than just a laptop and a sunny deck. The hardware is...
May 26, 2026
Server Securityopen-source Linux administration
open-source Linux administration Cron has existed in Unix and Linux environments for decades, handling backups, cleanup scripts, patching jobs, log rotation, monitoring tasks, and other maintenance work that administrators do not want to run manually. Most Linux servers rely on it constantly, which is exactly why attackers continue abusing it for persistence after a system has already been compromised. . Persistence through cron is not complicated. Attackers do not need a rootkit or advanced malware framework to maintain...
May 25, 2026
Vendors/Productssecurity breach linux
security breach linux A major internal repository breach at GitHub has exposed a critical and overlooked blind spot in Linux supply chain security. Kernel exploits, exposed SSH services, weak firewall rules, and vulnerable daemons dominated the Linux threat model for years, and in many environments, they still matter. But recent supply-chain incidents involving GitHub ecosystems, npm packages, and malicious developer tooling point somewhere else entirely: the developer workstation. . The breach matters because...
May 21, 2026
Security Trends access control multi-tenant
access control multi-tenant Linux administrators often face an ugly choice in the cloud: prioritize convenience and cost-efficiency by sharing infrastructure, or sacrifice those benefits for the sake of total isolation. Most modern Linux workloads don't live on their own private servers anymore. They live in shared environments like Kubernetes clusters, where multiple teams and services run side-by-side. It sounds efficient, and it usually is. . But cloud isolation isn't as ironclad as it looks on the diagram. If you...
May 21, 2026
Vendors/Productsincident response cloud security
incident response cloud security Managed Extended Detection and Response (MXDR) has become one of the most sought-after security services in the enterprise market — and with good reason. It promises the holy grail: broad visibility across endpoints, network, cloud, email, and identity, combined with the 24/7 human expertise most organizations simply cannot build in-house. . However, the rapid growth of the market has produced a wide range of providers whose capabilities vary considerably beneath the surface. Choosing the...
May 19, 2026
Refine news
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security news
We found -3 articles for you...
210
security advisorySQL InjectionlinuxFortiClient EMS SQL Injection Risk on Linux Systems CVE-2026-21643
One unauthenticated HTTP request is all it takes. From there, attackers can move from the edge straight into your internal network, operating from a system your Linux servers already trust. CVE-2026-21643 in FortiClient EMS isn’t just another SQL injection. It turns a management server into a pivot point, giving attackers the same access paths your administrators rely on. . FortiClient EMS (Endpoint Management Server) sits at the center of that trust. It manages endpoints, pushes configurations, and communicates directly with internal systems, including Linux servers. This matters for Linux because EMS is basically the 'Command & Control' for the whole network, including Linux endpoints. Since our Linux servers are set up to trust the EMS IP for updates and management, an attacker who hits this SQLi can bypass our internal firewalls and pivot directly into our 'safe' Linux zones. It’s basically a skeleton key to the internal network. What Is the FortiClient EMS Vulnerability The issue lies in how FortiClient EMS handles input sent to its backend database (PostgreSQL). User-controlled data is not properly filtered, allowing it to be executed as SQL. Vector: Injection delivered through crafted HTTP requests to the /api/v1/init_consts endpoint. Payload: The exploit is hidden in the Site header. Escalation: Attackers use COPY ... FROM PROGRAM to escalate from database access to system-level command execution. Risk increases in multi-tenant environments. One EMS instance can expose multiple groups at once, not just a single target. Lateral Movement into Linux Security Early reporting shows real attack activity, not just scanning, and roughly a thousand exposed instances have already been identified , which makes this a broad target surface rather than a niche case. The pattern is consistent: attackers hit exposed EMS systems, test for injection, and move quickly if the server responds. The issue lies in how the server handles input. A crafted HTTPrequest carries a SQL injection, which the backend database executes, allowing the attacker to move straight into database access without any prior authentication. From there, it stops looking like a web bug and starts behaving like an internal foothold. That shift is what enables lateral movement. Once the attacker controls the EMS server, they inherit its position inside the network, including access to systems that already trust it. In Linux environments, that often means direct paths to internal services like SSH, databases, and APIs that are restricted to management hosts. The traffic doesn’t come from an external source anymore. It comes from a system that those servers are configured to accept. Why this is a "Skeleton Key" for Linux: This doesn’t stay contained to the EMS server. That’s the part people miss when they hear “ SQL injection ” and think it only impacts a database. FortiClient EMS sits in a management layer, pushing configs from a subnet that other systems already trust. That placement turns it into an entry point, not just another service. Once compromised, the attacker is no longer probing from the outside. They’re operating as a trusted internal host. Here’s what that looks like in practice: Trust Boundary Erosion: Your Linux database server blocks SSH from the internet, but allows it from the management subnet. The Pivot: The attacker now controls the EMS server on that trusted subnet. The "Inside-Out" Attack: They connect directly to the Linux server from that trusted IP. Host-based firewalls (iptables/nftables) allow the traffic because it's coming from a "safe" zone. Credential Theft: The attacker can also pull ZTNA tokens or deployment scripts directly from the EMS database to log in as a legitimate admin. At that point, nothing “external” is happening anymore. The source is trusted, and Linux systems that were never exposed to the web are now wide open. How the FortiClient EMS Exploit Works The path is directand requires little setup if the EMS server is exposed. Attackers identify reachable instances, typically on port 8013, then target a known unauthenticated endpoint, /api/v1/init_consts. The payload is delivered through the Site header. Because that value is passed into a backend query without proper filtering, the database executes it as SQL, giving the attacker immediate query control. From there, escalation is built in. The EMS service account often runs with elevated privileges, allowing functions like COPY ... FROM PROGRAM to execute commands directly on the host. At that point, the attacker is no longer interacting with the database. They’re operating on a trusted system inside the network, with access to the same internal paths used for management. Who Is Affected by the FortiClient EMS Vulnerability The impact starts with FortiClient EMS, specifically versions 7.4.0 through 7.4.4, but the real risk depends on how it’s deployed and what sits behind it. Exposure changes everything. An EMS server open to the internet becomes an entry point, and in multi-tenant or enterprise environments, that system often sits between multiple networks, users, and services. Linux systems are not directly vulnerable to this flaw, but they are part of the environment it exposes. They trust the same management subnet, rely on shared services, and accept connections tied to automation workflows that EMS is already part of. Once that trust is compromised, those systems become reachable in ways that bypass external controls, because they were already accessible from inside. How the FortiClient EMS Flaw Can Be Used in Real Attacks Once the EMS server is compromised, the attacker doesn’t need to force their way deeper. They move through what’s already allowed, and the activity starts to look like normal management traffic coming from inside the network. Linux systems don’t just sit there. They expose services internally by design, SSH for admin access, PostgreSQL or MySQL forapplications, and internal APIs that never face the internet. Once the attacker is on EMS, those services are reachable over the same internal paths, and access attempts blend in with normal admin or application behavior. The value sits in the data as much as the access. The EMS database stores configuration profiles, and in environments using VPN or ZTNA for Linux users, those profiles often include service account tokens, API keys, and deployment scripts. An attacker can pull that directly from PostgreSQL and reuse it, which means they don’t need to break into a Linux server if the credentials and access paths are already stored upstream. In many environments, those profiles tie into automation, deployment scripts, or configuration tools, so access isn’t just possible, it’s already provisioned. How to Reduce Risk Start with patching because everything else depends on it, and if you’re still on a vulnerable version, the exposure remains regardless of controls around it. Move to 7.4.5 or later before anything else . Then deal with exposure, because an EMS server reachable from the internet is an easy target, so access should be limited to trusted networks where you control who can reach it and how. After that, focus on what’s hitting the service and what it’s doing in response. Watch for abnormal HTTP requests, especially unusual or malformed headers Look for patterns that don’t match normal EMS traffic Control what happens after compromise, not just before it. Apply egress filtering on the EMS server Restrict outbound connections to only what is required This matters because it limits what an attacker can do next, and blocking outbound callbacks can stop reverse shells or command-and-control traffic before it fully establishes. If you cannot patch immediately, consider auditing the PostgreSQL service account privileges. While EMS requires high-level access for standard operations, disabling the ability to execute external programs throughthe database can break the exploit chain even if the SQL injection is successful. Detection sits at the database layer, and this is where most teams don’t look until it’s too late. Monitor for pg_sleep usage Watch for long-running or delayed queries Investigate abnormal SQL behavior tied to API requests Don’t guess whether you’ve been hit, check for it directly by searching EMS logs for pg_sleep, and if you see requests to /api/v1/init_consts taking exactly 10 or 20 seconds, that lines up with time-based SQL injection testing, not normal use. On the Linux side, access patterns matter just as much. Internal traffic is usually trusted, so it’s rarely inspected, which means once EMS is compromised, the attacker’s activity blends in with legitimate admin behavior. At that point, the problem isn’t just exposure, it’s visibility. Watch for SSH attempts coming from management hosts that don’t normally initiate them, or bursts of authentication failures that originate from inside the network instead of outside. Tools like fail2ban often focus on external sources, so internal brute-force attempts can slip through if they’re not explicitly monitored. If your access controls rely on subnet trust, tightening that to host-based or identity-based rules reduces the blast radius, because once a management system is compromised, subnet-level trust stops being a control and starts being a path. What This FortiClient EMS Flaw Means for Linux Security This doesn’t start on Linux, but it lands there because of how Linux environments are built. Most systems trust internal IP ranges, management hosts, and automation systems without treating them as hostile, and that works until one of those trusted systems is compromised. Once EMS is under attacker control, that trust is reused. Connections come from a known system, over allowed paths, and Linux hosts accept them without challenge because nothing about the source looks wrong. No exploit is needed at that point.Access comes from trust that was already in place. If a management system at the edge is exposed, everything behind it inherits that risk. Linux systems don’t become vulnerable. And once an attacker is operating from a trusted system, access isn’t forced. It’s already allowed. . SQL injections can turn trusted Linux servers into entry points for attackers. Understand the risks and mitigation steps.. FortiClient EMS, SQL Injection, Linux Security, Internal Access, Lateral Movement. . MaK Ulac
Mar 30, 2026
•
Security Vulnerabilities
83
malwarethreat detectionbotnetPanchan Botnet Lateral Movement in Linux Education Servers
A new peer-to-peer botnet named Panchan appeared in the wild around March 2022, targeting Linux servers in the education sector to mine cryptocurrency. . Panchan is empowered with SSH worm functions like dictionary attacks and SSH key abuse to perform rapid lateral movement to available machines in the compromised network. At the same time, it has powerful detection avoidance capabilities, such as using memory-mapped miners and dynamically detecting process monitoring to stop the mining module immediately. . Panchan leverages SSH vulnerabilities to facilitate lateral propagation and covert cryptocurrency mining on compromised Linux servers within the academic realm.. Panchan Botnet, SSH Exploits for Linux, Cryptomining Threats, Peer-to-Peer Malware. . LinuxSecurity.com Team
Jun 15, 2022
•
Hacks/Cracks
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More