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 136 articles for you...
77
security advisoryUbuntuimportantUbuntu 18.04 EOL: Understanding Security Management and Risks
Linux security depends heavily on whether a system is still inside its support window. When that window closes, the system keeps running, and nothing on the surface changes, but the updates stop immediately. From that point forward, the release no longer tracks the changes happening in the rest of the environment. The gap isn’t evident from uptime or basic monitoring, but it affects how well the system withstands new security pressures. . In a mixed environment, the pattern becomes clear. Systems that still receive updates stay aligned with current fixes, and the ones outside support don’t, so their exposure shifts away from the rest of the fleet. Operations can keep older workloads stable, but stability doesn’t mean the system is protected to the same degree. The kernel introduces another timing layer because it follows its own lifecycle, and that schedule doesn’t always align with the base OS. Ubuntu 18.04 is a straightforward example since its lifecycle is well documented and common in production, making the transitions easy to observe. What follows is a breakdown of how Ubuntu’s lifecycle is structured, what the 18.04 timeline shows in practice, how the kernel’s lifecycle fits into that picture, why these transitions matter for Linux security, and the steps needed to keep systems operating inside supported windows. The systems continue to function normally, but once support ends, they stop receiving updates that keep them aligned with current security needs. Understanding the Ubuntu Linux Support Lifecycle (Standard Support, LTS, ESM, and EOL) Ubuntu’s support lifecycle sets the pace for how long a system can stay aligned with current Linux security expectations. Each LTS release moves through the same sequence of phases: Standard Support, a quieter Maintenance window, Extended Security Maintenance, and finally EOL. The sequence is predictable, and that predictability gives long-lived systems a clear update path as they age. Once a release stops tracking upstreamchanges, its security posture holds still while the rest of the environment keeps moving. The lifecycle policies published by Canonical describe the early stage where full kernel and userland maintenance is still routine. Standard Support brings broad updates, but the rhythm shifts as the release matures and the stream narrows toward security-focused patches. That tightening creates the hinge between Maintenance and ESM, the point where the release moves away from general upkeep and into targeted fixes. Extended Security Maintenance keeps those patches available for Ubuntu Pro users, giving the system a controlled tail period even as the broader ecosystem moves forward. The 18.04 LTS documentation reflects this exact progression, ending in the phase where vendor updates stop entirely and the system holds whatever protections it had at EOL. The OS continues to run without issue, but its defense surface no longer evolves with new threats or upstream corrections. The lifecycle works exactly as designed, and that stable pattern is what makes its support boundaries so important when evaluating long-term security posture. For reference, Ubuntu 18.04’s Standard Support ended on 31 May 2023, and ESM coverage remains available through April 2028 for Ubuntu Pro users. Ubuntu 18.04 Lifecycle Explained: From Standard Support to ESM Ubuntu 18.04 makes a steady case study because its lifecycle was predictable from day one, and the release saw wide use across cloud and enterprise stacks. The transition from Standard Support into ESM followed the schedule exactly as published. That consistency matters, since it shows how a release can operate normally while its support window quietly narrows beneath it. The lifecycle breaks into four clear stages, each with a different security implication: Ubuntu 18.04 Lifecycle Phases Phase What It Included Security Implication Standard Support Full kernel and userland updates System trackscurrent fixes and stays aligned with active development Maintenance Security-focused updates become the primary stream The update surface begins to narrow as broader maintenance winds down. ESM (Ubuntu Pro) Continued security fixes for subscribers Critical patches persist, but only for ESM-enabled systems EOL No further vendor updates System runs, but protection no longer evolves with the environment When Ubuntu 18.04 moved fully to ESM, Ubuntu Pro users continued receiving targeted patches, while non-ESM systems remained operational but no longer gained new protections. That’s the lifecycle principle in plain form: functionality continues, but security alignment halts the moment a release crosses its final support boundary. Linux Kernel LTS Lifecycle and EOL: What Administrators Need to Know The kernel runs on its own support cycle, separate from any distribution, and that cycle determines how long a system can keep gaining new security capabilities. The upstream schedule in the kernel.org LTS table rarely matches a distro’s timeline, which means OS support and kernel support don’t expire at the same time. That split matters because the kernel sets the ceiling for how far its protections can evolve. How the Kernel Lifecycle Works Kernel.org publishes the LTS timeline that decides how long upstream work continues. Each branch receives hardening improvements, mitigation updates, and subsystem refinements until its upstream EOL. Once that date passes, the branch is fixed at its last upstream commit, even if a distribution keeps shipping it. What Changes at Upstream EOL The kernel keeps running, but upstream development stops, so new defenses no longer land. Vendors can still backport CVE fixes, but backports only patch specific issues; they don’t deliver broader changes like stack-hardening updates, memory-isolation improvements, or reworked subsystembehavior. Newer kernel lines continue advancing while the EOL branch stays static, widening the security gap over time. Why This Matters for Long-Lived Releases A release such as Ubuntu 18.04 carries a kernel line whose upstream lifecycle determines which mitigations it can support. Even if the OS remains fully supported, the kernel’s protections stop evolving once its upstream EOL arrives. Both timelines have to be monitored since the distro controls patch flow and the upstream kernel controls the protection ceiling. The Practical Takeaway for Administrators A system can be inside its OS support window while its kernel has already aged out of upstream development, leaving it with a fixed set of defenses. Every distribution inherits this behavior because the upstream kernel sets the boundary, not the vendor. How Lifecycle Boundaries Impact Linux Security Outcomes When a system moves outside its support window, its security posture changes immediately, even though nothing on the surface looks different. The OS keeps running, but it no longer receives the security inputs that matter — advisories, patches, kernel improvements. Supported environments continue to shift with each update cycle, and an unsupported system stays tied to its last known state. What Stops at the Support Boundary New security advisories no longer arrive for that release. Vendor patches stop, leaving exposed systems that continue to be vulnerable. Kernel-level updates end, so no new mitigations or hardening improvements arrive. Vulnerabilities accumulate because the system is no longer part of the active update stream. Components such as systemd, compilers, logging tools, and container runtimes continue to advance across supported stacks, while the unsupported system remains fixed. Ubuntu 18.04 shows this clearly: Standard Support closed on schedule, and from that point forward, only ESM systems continued receiving targeted fixes. Systems running 18.04 without ESM stayedfunctional but could no longer take on the protections needed to match current baselines. Unsupported nodes don’t fall behind all at once; they simply stop moving while everything around them continues to progress. Tracking the latest Linux News makes this visible over time, as supported releases keep gaining updates and older ones drop out of the advisory flow entirely. How to Manage Linux Support Lifecycles (Actionable Steps for Security Teams) Lifecycle timing has a direct impact on Linux security, and the only reliable way to stay aligned is to treat those dates as operational boundaries, not background information. Once the schedule is clear, planning becomes predictable instead of reactive. Track Lifecycle Dates Proactively Use Canonical’s lifecycle pages along with the kernel.org LTS tables so that both support clocks stay in view. One governs distribution updates, the other governs upstream hardening work. Missing either one leads to surprises later. Inventory Systems by Lifecycle Stage Sort machines into Standard Support, Maintenance, ESM, and EOL. It shows which systems still have full coverage and which don’t. Nodes still running Ubuntu 18.04 without ESM usually stand out immediately. This is the point where patch behavior and long-term protection diverge. Apply Updates Before Lifecycle Transitions Apply updates while the release is still in Standard Support, since that’s when the full set of fixes is still available. Once the release moves into later phases, the update stream narrows and coverage drops. Doing the work before that shift avoids the scramble that usually follows. Migrate Workloads Before Deadlines Test on Ubuntu 20.04 or 22.04 early so the move doesn’t collide with other changes. Configuration management tools such as Ansible, Chef, and Puppet drop support for EOL systems, and once that happens, automation degrades quickly. Keeping workloads on supported releases maintains automation. If Ubuntu 18.04 Must Remain Temporarily, ReduceExposure Tighten network access first, keep privileges minimal, and freeze configuration state to avoid drift. These controls reduce the surface while you plan the replacement path. Once CM tools stop supporting Ubuntu 18.04 post-EOL, expect more manual handling for anything not already scripted. Monitor Active Advisories Compare the update activity of supported releases to what your older branches receive. The difference becomes visible fast when unsupported systems fall out of the advisory flow. The Ubuntu advisories page is a practical way to track that gap as it opens. Takeaway: Treat Lifecycle Awareness as a Core Linux Security Practice Lifecycle awareness sits at the center of modern Linux security work because a system’s protection level follows its support stage, not how healthy it appears. Ubuntu 18.04 shows this clearly; it moved through each phase as documented, gaining new defenses while supported and holding steady once that window closed. Supported systems continue to evolve with current protections, and unsupported systems remain fixed at whatever update level they held on the final day. Lifecycle deadlines should be treated as security deadlines. They mark the point where a system can no longer keep pace with the environment around it. Broader operational issues—such as system drift in Linux —often begin from the same condition: a system that stops moving while everything else keeps going. Staying inside defined support windows is the most reliable way to prevent that drift from taking hold. . Understand the implications of Ubuntu 18.04 EOL on security and how to manage risks effectively.. Ubuntu Security, LTS Support, Linux Lifecycle Management, EOL Risks. . MaK Ulac
Nov 20, 2025
•
Server Security
79
security riskpythonsoftware transitionNavigating Legacy Infrastructure Amidst Python 2 Sunset Phase
The Python 2 EOL is coming and will have some serious implications for legacy systems. . If you're a developer, you know that once a language reaches EOL, it won't get any new features or bug fixes. That means if you're using Python 2, there will be no more support from the creators of the language. Plus, plenty of projects still use versions of Python 2 that haven't been updated since 2014—so they're likely vulnerable to hacking and other attacks. But what if your company has legacy code that doesn't support newer languages like Python 3? How can you manage this transition? I found the article linked below helpful in understanding how to deal with this issue, how long it takes to make the switch, how much it costs, and what kinds of things could go wrong during the process. Check it out! If you have additional questions, please connect with me on X @lnxsec - I'd love to help! The link for this article located at Security Boulevard is no longer available. . As Python 2 nears end-of-life, developers face migration challenges and security issues that need addressing effectively.. Python End Of Life, Legacy System Challenges, Software Transition, Code Migration. . LinuxSecurity.com Team
Dec 17, 2023
•
Security Projects
83
security advisoryIntelsecurity riskIntel Alder Lake BIOS Code Leak: Security Risks and Hidden Features
Source code for the BIOS used with Intel's 12th-gen Core processors has been leaked online, possibly including details of undocumented model-specific registers (MSRs) and even the private signing key for Intel's Boot Guard security technology. . The source code was apparently shared via 4chan and GitHub, in a file containing tools and code for generating and optimizing BIOS/UEFI firmware images, plus related documentation. Word quickly spread to Twitter at the weekend, Alder Lake being the code-name for the x86 giant's 12th-gen desktop processors. The source code may reveal exploitable vulnerabilities in the firmware that miscreants could abuse in future on people's PCs. . Uncover the exposed Intel Alder Lake firmware source code, highlighting possible vulnerabilities and hidden functionalities.. Intel BIOS Leak, Alder Lake Security Threats, Firmware Exploits. . LinuxSecurity.com Team
Oct 14, 2022
•
Hacks/Cracks
209
cyber threatssecurity riskattack methodsMalware Delivery Risks in Linux Systems Require Vigilance Against Threats
Linux systems are a popular delivery mechanism for malware. While they’re not the most popular – that distinction goes to HTML and Javascript – don’t think you can ignore them. Linux-based attacks are very much still happening. . When bad actors identify a vulnerability they can exploit, their next move is typically to spread malware to achieve their objectives. When deciding what platforms to employ, hackers have a variety of ways to get malware into systems without attracting attention. This is known as the “hacker’s choice.” And they can also find ways to remain in those systems even longer without being noticed, which is what we’re seeing with advanced persistent crime (APC). Our researchers have observed that over the previous six months, HTML has been the most common method of malware delivery, with a difference of about 10% between it and Javascript. HTML hit a new high in May. . Operating systems like Linux can still pose vulnerabilities for malware infiltration, underscoring the necessity of continuous protective protocols against potential dangers.. Malware Delivery, Linux Systems, Cyber Threat Awareness, Security Practices. . Brittany Day
Sep 30, 2022
•
Security Trends
215
security riskgnomelinux systemsGNOME's New Feature to Alert on Secure Boot Risks in UEFI Systems
GNOME is planning to protect insecure hardware by notifying users more about their firmware security status. . When you install Linux on your UEFI-enabled computer, you have to disable Secure Boot because the live USB will refuse to boot with the option enabled. Some mainstream Linux distributions support Secure Boot, but it is still challenging to set up for many other distributions (and with Nvidia hardware onboard). While things may not have improved over the years, Secure Boot is an essential protection feature in general. . Explore GNOME's initiatives aimed at alerting users about their firmware security conditions in relation to Secure Boot vulnerabilities.. Secure Boot, GNOME Notifications, UEFI Security, Firmware Status, Linux Hardware Risks. . Brittany Day
Aug 02, 2022
•
Desktop Security
83
remote accessmalwaresecurity riskRising Malware Threats in Windows Subsystem for Linux (WSL)
The number of malware strains targeting WSL is growing. . Windows Subsystem for Linux (WSL) is becoming a breeding ground for malware , cybersecurity researchers are saying. While WSL-based malware is not particularly new (spotted as early as September 2021), it’s been rising in popularity among cybercriminals of late. Speaking to BleepingComputer, cybersecurity researchers from Lumen Technologies said they’ve managed to track more than 100 samples since then. The samples vary in complexity, as well as features on offer. While some are relatively simple, others enable threat actors to remotely access devices, run arbitrary code, steal authentication cookies from specific browsers , or download files. . The Windows Subsystem for Linux (WSL) is increasingly viewed as a potential hotspot for malicious software, prompting alarm bells to ring amongst cybersecurity professionals.. Windows Subsystem for Linux, Malware Threats, Cybersecurity Risks, Remote Access Issues. . LinuxSecurity.com Team
Jun 01, 2022
•
Hacks/Cracks
209
patch managementsecurity riskvulnerability managementCritical Linux Patching Delays Lead to Increased Cybersecurity Incidents
Computer security only happens when software is kept up to date. That should be a basic tenet for business users and IT departments. Apparently, it isn’t. At least for some Linux users who ignore installing patches, critical or otherwise. A recent survey sponsored by TuxCare , a vendor-neutral enterprise support system for commercial Linux, shows companies fail to protect themselves against cyberattacks even when patches exist. . Results reveal that some 55 percent of respondents had a cybersecurity incident because an available patch was not applied. In fact, once a critical or high priority vulnerability was found, 56 percent took five weeks to one year on average to patch the vulnerability. The goal of the study was to understand how organizations are managing security and stability in the Linux suite of products. Sponsored by TuxCare, the Ponemon Institute in March surveyed 564 IT staffers and security practitioners in 16 different industries in the United States. . Research indicates that 55% experienced security breaches stemming from outdated software; discover efficient methods for applying updates.. Cybersecurity Incidents, Linux Patching, IT Management, Software Security, Linux Study. . Brittany Day
May 09, 2022
•
Security Trends
78
linux distributionsecurity riskautomationExploring CloudLinux OS Solo: A Budget-Friendly RHEL Solution for WordPress
The new CloudLinux OS Solo commercial Linux distro comes with a high degree of automatization, reducing security risks associated with manual operations. . CloudLinux OS Solo is a new commercial Linux distro based on RHEL built by the creators of the established CloudLinux OS. CloudLinux is also the owner of the community-driven open-source project AlmaLinux , which aims to be 1:1 binary compatible CentOS drop-in replacement . Most businesses do not have access to in-house professional Linux administrators for websites built on the LAMP (Linux, Apache, MySQL, PHP) stack. Where previously the hosting company configured the systems that allowed the website to operate, now the business must manage these processes themselves. . CloudLinux OS Solo is an innovative enterprise-grade Linux distribution derived from RHEL, crafted by the developers of the well-regarded CloudLinux OS.. CloudLinux, Linux Distribution, WordPress Optimization, RHEL Based, Cloud Hosting. . LinuxSecurity.com Team
Jun 04, 2021
•
Vendors/Products
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!
Explore top 10 tips to secure your open-source projects now. Read More