Overly broad permissions can turn one compromised account into a much larger security problem. Learn how to reduce unnecessary access, review privileges, and apply least privilege across modern Linux systems. Review Linux Privileges×
Stay Ahead With Linux Security Features
identity management security tactics For years, we secured our Linux infrastructure by building walls: VPCs, security groups, and hardened SSH configurations. We treated the cloud like a virtual data center, assuming that if we kept the "bad guys" out of the network, our workloads were safe. . That model is no longer sufficient. Today, one of the most common paths from an initial compromise to a major cloud breach is the identity assigned to your Linux workload. When an attacker gains code execution on a Linux instance—through a...
Jul 17, 2026
security practices patch management Most of us don't hear about a kernel vulnerability until a CVE lands in our inbox or the vulnerability scanner starts complaining. By then, the patch isn't new anymore. Kernel developers may have been passing it around for review, arguing over the implementation, or revising it for days before anyone outside that community noticed it. None of those discussions are secret. They're sitting in mailing list archives, Git commits, and patch reviews where they've been the whole time. The strange...
Jul 14, 2026
Linux security cyber attacks Every Linux server in your fleet produces thousands of events every minute. From journald logs and auditd records to kernel-level eBPF hooks, your systems are constantly talking. Most of that noise is just the mundane churn of system services, CI/CD runners, or routine administrative automation. But among that noise, an attacker might be establishing a foothold, moving laterally, or setting up persistence. The challenge for any security team is: how do you separate the routine from the...
Jul 13, 2026
open-source infrastructure risk Security scanners flag exposed API keys in public repositories every day. The initial response is usually predictable: delete the commit, revoke the credential, and move on. That’s a mistake. . In a real Linux environment, an API key never stays in one place. By the time it hits a public repo, it’s already everywhere. It’s in the CI/CD pipeline. It’s in your container registry. It’s in the build logs. It’s in the backups. Git makes this worse because the history never dies. Deleting a file in...
Jul 11, 2026
open-source rootkit Most of us think of Linux rootkits as ancient history—the stuff of 90s hacking forums and clunky malware that would crash your system if you looked at it the wrong way. But if you think they’ve gone away, you’re mistaken. They’ve just gotten smarter. . Modern attackers aren't using the noisy tools of the past. Today’s threats are surgical. Many of today’s most advanced Linux rootkits operate at the kernel level or abuse legitimate system features to blend in with normal traffic. They’re...
Jul 09, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Should Linux servers automatically install security updates?
Loading...
Explore Latest Linux Security features
We found 6 articles for you...
102
security advisoryimportantsupply chainCompromised VS Code Extension Puts Linux Development Pipelines at Risk
The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal authorities confirmed the compromise in a public alert covering Nx Console and associated GitHub repositories. According to the CISA advisory, the incident was tracked under CVE-2026-48027 and involved supply-chain activity affecting development environments. The compromise centered on Nx Console, a popular extension used by developers working with Nx-managed projects. Rather than targeting production infrastructure directly, attackers inserted themselves into a trusted part of the software development workflow. That matters because extensions already operate with broad visibility into projects, repositories, and developer activity. Nx maintainers later published an incident timeline in their security update , including affected versions, discovery details, and remediation guidance. Users running impacted releases were instructed to remove affected versions and update immediately. At a high level, the attack followed a pattern security teams have been seeing more often over the last several years. Compromise a trusted component. Collect credentials. Use existing trust relationships to move deeper into the environment. No exploit chain required. Incident Overview Item Details Incident Type Supply-chain compromise Affected Component Nx Console CVE CVE-2026-48027 Primary Target Developer credentials Secondary Risk Repository and CI/CD compromise Potential Impact Source code, secrets, infrastructure access How the Attack Worked Modern development extensions have a surprising amount of visibility. They can read project files, interact with repositories, inspect build processes, and in some cases, access authentication material already present on the system. That trust model exists for convenience. Attackers understand that. Research discussing the broader attack methodology, including credential theft and GitHub-focused abuse techniques, was later examined by Microsoft Threat Intelligence in its security research. The mechanics vary between incidents, but the objective rarely changes. Collect credentials that provide access to systems developers already use every day. GitHub tokens are particularly valuable because they collapse multiple attack stages into one. Instead of breaking into a repository, an attacker authenticates. Instead of probing infrastructure, they inspect deployment workflows and secrets already stored inside the environment. The token becomes the foothold. From there an attacker may be able to: Clone private repositories Review deployment workflows Access package registries Harvest CI/CD secrets Modify build pipelines Publish malicious code updates Establish persistence through automation None of those actions require root access on a Linux workstation. Sometimes they do not require touching the workstation again. Why GitHub Tokens Matter GitHub stopped being just a source code platform years ago. For many organizations, it functions as the operational center of the environment. Infrastructure definitions live there. Deployment workflows live there. Kubernetes manifests, Helm charts, Terraform projects, Ansible playbooks, cloud automation scripts. Same place. The value of a stolen token depends on permissions. The problem is that developers often need extensive permissions to do their jobs. A single account may have access to: Private Repositories: Source code theft GitHub Actions: Pipeline manipulation Package Registries: Malicious Releases Organization Secrets: Credential Exposure Infrastructure Repositories: Cloud and platform visibility Deployment Automation: Unauthorized changes That is why developer accounts keep showing up in modern attack chains. They sit between development and production. Attackers know it. The Linux Security Impact This is not really a VS Code story. It is a Linux infrastructure story that happens to begin inside a development tool. Many affected users run Linux workstations because they manage Linux environments. Ubuntu systems administering Kubernetes clusters. Fedora laptops maintain cloud infrastructure. Debian workstations managing CI/CD pipelines. Different distributions. Similar trust relationships. The workstation becomes the first hop. A compromised developer machine may expose: GitHub tokens SSH keys Cloud credentials Kubernetes configuration files Internal repositories Build automation scripts Not every stolen credential leads directly to production. Enough of them do. Teams often focus heavily on server hardening while developer systems quietly accumulate administrative access across multiple environments. An attacker does not necessarily need local privilege escalation when repository permissions already open the next door. CI/CD Pipelines Build systems represent one of the highest-value targets in a software environment. Once repository access is established, workflow definitions become attractive targets. A modified pipeline can collect secrets, alter builds, inject code into releases, or create long-term persistence that survives workstation cleanup. Those investigations get expensive fast. Containers and Kubernetes Container environments depend heavily on automation. Repositories define what gets built, where it gets pushed, and how it gets deployed. Attackers increasingly target the pipelinerather than the cluster itself. Modifying trusted deployment paths is often easier than breaking through cluster defenses. Infrastructure-as-Code Repositories Terraform and Ansible repositories frequently contain the blueprint for an entire environment. Even when secrets are managed correctly, those repositories reveal architecture, permissions, cloud services, deployment patterns, network layouts, and operational processes. An attacker can learn a great deal before ever launching a second-stage attack. The initial compromise happens on a workstation. The visibility gained afterward can extend across an entire organization. What Linux Developers Should Do Now The immediate priority is determining whether affected extension versions were installed and whether repository credentials may have been exposed. Organizations should review guidance published by Nx, GitHub, and CISA while treating exposed credentials as compromised until proven otherwise. Extension Review Remove affected extension versions Update to verified releases Review installed development extensions Check for unexpected modifications Credential Response Rotate GitHub personal access tokens Revoke unused credentials Review OAuth integrations Replace exposed secrets Repository Audit Review commit activity Inspect branch protections Check workflow modifications Examine the package publication history Investigate unusual logins CI/CD Review Rotate pipeline secrets Audit service accounts Validate deployment workflows Review recent build activity Lessons for Open Source Security Supply-chain attacks keep succeeding because they exploit trust that already exists. Developers trust extensions. Pipelines trust repositories. Production systems trust deployment workflows. Attackers do not need to build those relationships. They inherit them. That shift changes how Linux defenders need to think about risk. The boundary is no longer theserver. It is the entire path that leads to the server. Extension ecosystems, package registries, source repositories, CI/CD platforms, and developer workstations all sit inside the same attack surface now. Treating them as separate problems creates blind spots that attackers are increasingly willing to exploit. Conclusion The most important detail in this incident is what was not exploited. There was no Linux kernel vulnerability. No container escape. No exposed daemon is listening on the internet. The attacker gained leverage through a trusted development tool and moved through existing trust relationships from there. As more infrastructure becomes defined through GitHub repositories, containers, Kubernetes deployments, and infrastructure-as-code projects, developer workstations continue to increase in value. They hold credentials. They control pipelines. They connect directly to the systems organizations depend on every day. That makes them a target. Related Reading GitHub Actions Compromise CI/CD Supply Chain Risks Explored Why CI/CD Pipelines Are Targets in Software Supply Chain Attacks Risks of GitHub Repo Breach on Linux Supply Chain Security Why Linux Supply Chain Attacks Are Becoming a Nightmare for DevOps Teams GitHub Actions Linux Self-Hosted Runners Security Risks Open-Source Supply Chain Attacks Threaten Linux Production Systems . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They neede. compromise, console, shows, infrastructure, behind, single, developer, accoun. . MaK Ulac
Jun 03, 2026
•
102
security advisoryRed HatimportantRed Hat npm Package Compromise Highlights a Growing Supply Chain Problem
Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other secrets were reportedly among the targets. That's not particularly surprising. Development environments tend to end up with access to far more systems than anyone originally planned for, especially once build automation, cloud services, and deployment tooling start getting layered on top of each other. The question usually isn't whether useful credentials exist. It's how many are sitting there and what they can reach. By the time someone starts inventorying what a CI runner can reach, the answer is often more than expected. Red Hat says it has not identified customer or partner impact, and the investigation is still underway. The compromise is notable less because of the malware itself and more because of where it showed up. A package repository sits in a place most organizations have already decided to trust. Once that trust relationship gets involved, the discussion usually shifts away from malware and toward access, validation, and how much confidence teams should place in automated software distribution. A Trusted Namespace Becomes an Attack Vector According to researchers, the compromised packages were distributed through Red Hat's @redhat-cloud-services namespace on npm. That detail matters because software teams often make decisions about risk based on reputation. Packages maintained by a well-known vendor naturally receive more trust than those published by an unknown developer. Compromising a trusted namespace gives malicious code a much better chance of reaching developer workstations, buildservers, and automated deployment environments without raising immediate suspicion. The goal is not necessarily widespread infection. Access to a handful of well-positioned systems can be enough. Investigators believe the campaign affected dozens of package versions across multiple projects. Those packages were primarily frontend libraries rather than customer-facing Red Hat products, but frontend dependencies are routinely pulled into enterprise development workflows. Once a malicious package enters a build process, the attack surface expands quickly. How Miasma Targets Linux-Based Environments Unlike traditional malware campaigns that focus on persistence or disruption, Miasma appears to have been built around credential collection. The malware searched infected Linux systems for the files and environment variables that DevOps teams rely on daily: SSH keys: Stored in ~/.ssh. Registry credentials: Found in files like ~/.npmrc and ~/.docker/config.json. Cloud credentials: Stored locally or exposed through metadata services. Kubernetes configuration files , such as ~/.kube/config. CI/CD secrets: Injected directly into runners through environment variables. For an attacker, these files represent immediate opportunities for lateral movement. A GitHub token may provide access to private repositories. A Kubernetes credential can expose cluster resources. Cloud access keys may unlock storage buckets, deployment pipelines, or administrative functions. Each credential becomes another step deeper into an environment that already trusts the user or service associated with it. That strategy also generates less noise than many conventional attacks. Security teams often have detections for privilege escalation attempts, malware execution, and suspicious binaries. Legitimate credentials present a different challenge. Activity performed with valid authentication frequently blends into normal operations, especially inside busy development environments where automation is alreadyperforming thousands of actions every day. CI/CD Pipelines: The Prime Target for Linux Operators One of the most concerning aspects of this incident involves how the packages were published. Researchers believe the attackers abused GitHub Actions trusted publishing workflows using OIDC rather than stealing a traditional npm authentication token. This highlights a shift in supply chain risk. Security controls designed to eliminate long-lived credentials are becoming the new target. An attacker who gains access to a publishing workflow effectively inherits the permissions of that workflow. Since those workflows are already authorized to push updates to official namespaces, the attacker doesn't need to break into the publishing process. The publishing process becomes the attack path. Trusted publishing has become increasingly popular because it removes long-lived credentials from deployment workflows. Instead of storing permanent tokens, systems establish trust relationships between source repositories, build pipelines, and package registries. The benefit: The model is generally more secure. The risk: Those trust relationships become valuable targets. An attacker who gains access to a publishing workflow may not need the credentials at all; the workflow already possesses the permissions required to publish software. In effect, the trust relationship becomes the credential. Why Linux Teams Should Care Modern software development doesn't just run on Linux. Most of the infrastructure responsible for building, packaging, signing, and deploying software relies on Linux systems. DevOps teams Build runners serve as the bridge between source code and production. If those runners operate with excessive permissions, a single dependency update can expose an entire CI/CD pipeline. Linux administrators The servers responsible for compiling, packaging, and deploying software often contain some of the most valuable credentials in the environment. They deserve the sameattention as production systems. Kubernetes operators Compromised build pipelines can provide a path into clusters through service account tokens or deployment automation. An attacker doesn't need direct access to the cluster if the pipeline already has it. Security teams Traditional perimeter defenses provide little protection when trusted systems begin performing malicious actions using valid credentials. What Linux Organizations Should Review Now Rather than waiting for the next supply chain notification, organizations should use incidents like Miasma as an opportunity to examine their own Linux-based development infrastructure: Audit build runner permissions: Use a least-privilege lens to review what your runners can access (cloud accounts, SSH keys, registries). Focus on runner isolation: Use container isolation, workload separation, and credential scoping to limit how far an attacker can move after gaining a foothold. Apply Linux-native security controls: Use SELinux or AppArmor to restrict process access, seccomp filtering to reduce dangerous system calls, and read-only filesystem configurations to impede unauthorized modifications. Monitor package changes: Many supply chain attacks begin long before code reaches production; dependency monitoring should be as critical as production workload monitoring. Reconsider trust: Trust remains necessary, but it should never replace verification. The Real Lesson The Red Hat compromise wasn't significant because attackers found a new way to steal credentials. Those techniques have existed for years. What makes this incident noteworthy is that the attack leveraged systems and workflows organizations already trusted. Package repositories, CI/CD pipelines, publishing workflows, and automated deployment systems have become attractive targets because compromising them allows attackers to inherit existing trust relationships rather than create new ones. The Linux supply chain is deeper and moreinterconnected than many organizations realize. Protecting it requires acknowledging that the most dangerous threats may not arrive through an exposed service or an unpatched vulnerability. They may arrive through the same trusted mechanisms used to deliver software every day. Related Reading GitHub Actions Compromise CI/CD Supply Chain Risks Explored Why CI/CD Pipelines Are Targets in Software Supply Chain Attacks Linux Supply Chain Attacks Threaten DevOps Teams and Security GitHub Actions Linux Self-Hosted Runners Security Risks . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reporte. researchers, investigating, campaign, tracked, miasma, found, packages. . MaK Ulac
Jun 02, 2026
•
102
security advisoryvulnerabilityimportantLinuxSecurity.com Major Update for Improved Threat Discovery and Research
LinuxSecurity.com has been part of the Linux and open-source security community since the late 1990s. Over the years, the platform has evolved alongside the Linux threat landscape itself — from the early days of mailing lists and isolated vulnerability disclosures to today’s nonstop cycle of advisories, exploit research, malware reporting, supply chain attacks, and infrastructure-focused threat intelligence. . For many readers, LinuxSecurity.com became more than just a news site. It became a long-running research archive used to track vulnerabilities, investigate Linux threats, review hardening guidance, and stay current on operational security risks affecting enterprise systems, cloud environments, and open-source infrastructure. But the way security professionals research information has changed dramatically. Modern Linux security investigations rarely happen inside a single article or isolated advisory feed. Security teams move rapidly between vulnerability disclosures, mitigation guidance, malware analysis, hardening documentation, threat reporting, and historical research while trying to understand exposure and respond quickly. The previous platform no longer reflected that workflow. So we rebuilt LinuxSecurity.com from the ground up with a stronger focus on discoverability, connected research, faster navigation, and operational threat visibility. The new platform was designed to help Linux administrators, security teams, researchers, and open-source professionals move naturally between advisories, HOWTOs, feature analysis, archived research, and emerging threat coverage without constantly fighting disconnected archives or fragmented navigation. The mission itself has not changed. LinuxSecurity.com remains focused on delivering Linux security news, open-source threat intelligence, vulnerability awareness, practical hardening guidance, and security education for the Linux community. The difference is that the platform is now built to support the way modern Linux securityresearch actually happens. A Better Way to Explore Linux Security Topics The updated LinuxSecurity.com platform was redesigned around the realities of modern Linux security research workflows. Instead of forcing readers to manually navigate disconnected archives, static categories, or isolated article feeds, the new structure organizes content around related security topics, operational workflows, and active threat intelligence. Whether readers are researching SSH hardening, privilege escalation, Linux malware, OpenSSL vulnerabilities, cloud exposure, container security, or supply chain threats, the platform now helps surface connected advisories, tutorials, feature analysis, and historical research within a unified experience. The goal is not simply faster navigation. It is to create a faster understanding. Readers can now move more naturally between vulnerability disclosures, mitigation strategies, hardening guidance, malware reporting, and related Linux security coverage during active investigations without losing research continuity or context. The updated structure also improves visibility into ongoing Linux security activity by making advisories, trending topics, distribution-specific vulnerability reporting, featured analyses, and archived research easier to discover directly on the homepage and in topic hubs. LinuxSecurity Features The Features section was redesigned to highlight deeper Linux security analysis, investigative reporting, and long-form technical coverage focused on real-world operational risk. Readers can explore in-depth articles examining vulnerability trends, malware activity, supply chain threats, Linux hardening strategies, cloud security exposure, infrastructure attacks, and broader developments affecting the Linux and open-source security landscape. Rather than focusing solely on breaking disclosures, Features provide additional context on how vulnerabilities are exploited, why operational failures persist, and how organizations can strengthentheir defensive posture across Linux environments. The updated structure also improves discovery of related research, helping readers move between advisories, technical guidance, historical analysis, and current threat reporting during ongoing investigations. LinuxSecurity Advisories Streamlined access to vulnerability reports and security updates. The redesigned Advisories section gives readers direct access to Linux vulnerability disclosures and distribution-specific security updates without forcing them to dig through fragmented archives or disconnected feeds. Advisories are now easier to browse by distribution, topic, and publication date, helping administrators quickly identify patches and exposure affecting their environments. Readers can move between current vulnerability activity, related advisories, and connected Linux security coverage more naturally while tracking emerging threats across Debian, Ubuntu, Fedora, openSUSE, Rocky Linux, Slackware, Gentoo, Oracle Linux, and additional distributions. The updated interface also improves visibility into ongoing advisory activity by surfacing recent searches, trending topics, and newly published security updates directly from the main advisory hub. LinuxSecurity HOWTOs Practical, step-by-step hardening and configuration guidance. The LinuxSecurity HOWTOs section was redesigned to make technical hardening guidance easier to discover and apply during active security investigations. Readers can quickly access step-by-step walkthroughs covering Linux hardening, access control, file integrity monitoring, container security, SSH configuration, CI/CD security, and cloud infrastructure protection. Rather than existing as isolated tutorials, HOWTOs are now more tightly connected to related advisories, malware reporting, and feature analysis, allowing readers to move directly from vulnerability awareness into actionable remediation and defensive implementation guidance. LinuxSecurity News The LinuxSecurity News section wasredesigned to provide faster visibility into ongoing Linux security developments, vulnerability disclosures, malware activity, and emerging open-source threats affecting enterprise and infrastructure environments. Readers can now more quickly monitor active Linux security discussions, follow evolving attack trends, and explore timely reporting covering cloud security, supply chain risk, privilege escalation, ransomware activity, infrastructure compromise, and operational security issues impacting Linux systems. The updated layout also improves access to trending stories, featured reporting, and related security coverage, helping readers stay informed without constantly sorting through fragmented security feeds or disconnected news archives. By surfacing current Linux security developments more effectively, the platform helps administrators, researchers, and security professionals maintain stronger awareness of rapidly evolving threats across the open-source ecosystem. LinuxSecurity Newsletters LinuxSecurity.com newsletters were redesigned to help readers stay informed on meaningful Linux security developments without needing to constantly monitor dozens of separate advisory feeds, threat intelligence sources, and open-source security discussions throughout the week. Subscribers receive curated coverage focused on Linux vulnerability advisories, malware reporting, open-source threat intelligence, hardening guidance, cloud security risks, infrastructure attacks, and newly published HOWTOs and feature analysis. Some weeks focus heavily on patching activity, disclosure tracking, and active vulnerabilities. Other weeks center around operational failures, evolving attacker techniques, Linux malware trends, or recurring security mistakes that continue to expose enterprise infrastructure and cloud environments. The goal is simple: surface the Linux security developments that matter most and make them easier to review quickly during busy operational workflows. For administrators,researchers, and security professionals already using LinuxSecurity.com during vulnerability response and ongoing research, the newsletters provide a steady stream of connected security intelligence tied directly to the platform’s broader advisory and threat coverage. LinuxSecurity Security Dictionary The LinuxSecurity Security Dictionary was expanded to serve as a practical reference resource for Linux administrators, researchers, and security professionals navigating complex security terminology during active investigations and ongoing research. The dictionary provides organized definitions and contextual references covering vulnerability terminology, malware concepts, encryption methods, access control models, authentication technologies, attack techniques, and broader cybersecurity terminology frequently encountered throughout Linux security operations. Rather than functioning as a simple glossary, the Security Dictionary helps readers better understand the technical language surrounding advisories, hardening guidance, threat reporting, and feature analysis published across the platform. The updated structure also improves navigation and discoverability, making it easier to quickly reference unfamiliar terms while researching vulnerabilities, reviewing threat intelligence, or investigating operational security issues. LinuxSecurity Polls LinuxSecurity Polls were redesigned to encourage greater community participation while helping surface real-world perspectives from Linux administrators, security professionals, researchers, and open-source users across the broader Linux ecosystem. Poll topics focus on operational security priorities, Linux adoption, hardening practices, infrastructure management challenges, defensive tooling, and evolving security concerns affecting modern Linux environments. Beyond simple engagement, polling data provides additional visibility into how security professionals are approaching ongoing operational risks, vulnerability management, cloudsecurity, and system hardening across real-world deployments. The updated polling experience also creates more opportunities for readers to participate in broader Linux security discussions happening throughout the platform. About Us The About Us section was redesigned to provide additional context around LinuxSecurity.com’s long-standing role within the Linux and open-source security community. Readers can learn more about the platform’s history, editorial mission, research focus, and ongoing commitment to delivering practical Linux security guidance, vulnerability awareness, open-source threat intelligence, and educational security coverage for the broader Linux ecosystem. The updated section also highlights LinuxSecurity.com’s relationship with Guardian Digital and its continued focus on supporting Linux administrators, developers, researchers, and enterprise security teams with reliable security-focused reporting and operational guidance. As Linux threats continue evolving across enterprise infrastructure, cloud environments, and open-source software ecosystems, the platform remains committed to helping readers stay informed on the vulnerabilities, hardening practices, malware activity, and defensive strategies shaping Linux security today. Distribution-Specific Advisories LinuxSecurity.com now organizes advisories by Linux distribution to help administrators and security teams identify relevant vulnerability disclosures and patch activity faster during active operational workflows. Readers can quickly review advisories affecting Debian, Debian LTS, Fedora, Gentoo, Mageia, Oracle Linux, openSUSE, Rocky Linux, Slackware, SuSE, Ubuntu, and additional Linux distributions without manually filtering through unrelated security updates. This structure improves visibility into distribution-specific exposure while helping organizations track vulnerabilities, package updates, and patching activity affecting their environments more efficiently. By separating advisory coverageby distribution, the platform also makes it easier to monitor recurring vulnerability trends, identify software components that are actively targeted, and track ongoing Linux security developments across the broader open-source ecosystem. AI-Powered Search and Topic Discovery The new AI-powered search and topic discovery system was designed to reduce the amount of manual research required during active Linux security investigations. Instead of forcing readers to navigate disconnected archives, isolated advisories, or fragmented category structures, the updated platform connects related content dynamically across advisories, HOWTOs, feature analysis, malware reporting, historical research, and broader threat intelligence coverage. Readers researching topics such as SSH hardening, OpenSSL vulnerabilities, Linux privilege escalation, systemd abuse, container security, ransomware activity, supply chain attacks, or cloud exposure can now uncover connected tutorials, advisories, and threat analysis within a unified research experience. The updated search experience also includes refined filtering and discovery tools that allow readers to narrow results by: Topics and categories Authors Publication dates HOWTO-specific criteria Related Linux security subjects This connected discovery model helps security professionals move more naturally between vulnerability intelligence, defensive guidance, operational hardening, and historical Linux security research during active investigations. The result is a more continuous research workflow that surfaces both current threat activity and foundational Linux security knowledge that may still remain operationally relevant today. Faster Visibility Into Emerging Linux Threats Our homepage was redesigned to provide faster visibility into ongoing Linux security activity while making active threat coverage easier to follow throughout the platform. Readers can now quickly explore: Weekly vulnerability activity Trending securitytopics Featured Author’s Choice coverage Recent advisories Active Linux security discussions Current threat reporting The previous homepage often made important information difficult to surface consistently, especially during busy vulnerability cycles where new advisories and threat coverage were published rapidly throughout the week. The updated experience makes it easier to identify active security developments quickly while connecting related coverage together more naturally. Readers can now monitor vulnerability activity, malware reporting, trending Linux security discussions, and recent advisories from a single location without constantly digging through disconnected archives or categories. The updated platform was designed to support the way modern security research actually happens, moving quickly between advisories, tutorials, threat analysis, hardening guidance, and related vulnerabilities during the same investigation. Bringing Archived Security Research Back Into View LinuxSecurity.com contains decades of Linux and open-source security coverage, much of which remains highly relevant today. Older hardening guides, technical explainers, and vulnerability research can sometimes be difficult to rediscover over time, even when the information itself remains useful. The new platform structure helps reconnect archived knowledge with current advisories, modern threat reporting, and newer tutorials, making foundational security guidance easier to surface during active research. As a result, older Linux hardening articles can now appear alongside newer vulnerability coverage whenever the topics overlap, allowing readers to discover both historical context and current threat intelligence within the same research flow. Improved Mobile Navigation and Article Experience Linux security research doesn’t always happen from a desktop. The new LinuxSecurity.com experience was also designed to make long-form technical content easier to navigate on mobile devices. Articlesnow include features like “In This Article” navigation, allowing you to quickly jump between sections without scrolling through an entire page. Whether you’re looking for: mitigation steps detection guidance vulnerability details hardening recommendations command examples You can move directly to the information you need faster. We are excited to welcome readers to the new LinuxSecurity.com and look forward to continuing to deliver the Linux security news, research, tutorials, and threat coverage the community relies on every day. Thank You for Supporting LinuxSecurity.com Whether you have been using LinuxSecurity.com for years or are discovering the platform for the first time, we’re glad to have you here. The new LinuxSecurity.com was rebuilt to better support the way today’s Linux administrators, researchers, and security professionals investigate threats, track vulnerabilities, and stay informed on the rapidly evolving open-source security landscape. We look forward to continuing to provide the Linux security news, advisories, hardening guidance, and threat intelligence the community relies on every day. . For many readers, LinuxSecurity.com became more than just a news site. It became a long-running rese. linuxsecurity, linux, open-source, security, community, since, 1990s. . Dave Wreski
May 25, 2026
•
102
security advisorydenial of serviceRed HatWhy Red Hat’s krb5 Update Matters for Linux and Windows Authentication
Red Hat released an Important krb5 security update for Red Hat Enterprise Linux 8 this week, addressing two vulnerabilities tracked as CVE-2026-40355 and CVE-2026-40356. On paper, it looks like another Linux package advisory. . Kerberos sits within the authentication layer that many enterprises use to connect Linux systems, Windows domains, Active Directory, file services, internal applications, and privileged-access workflows. When krb5 needs a security update, the concern is not just the package itself. It is the trust path behind it. The advisory listed in today’s security feed identifies RHSA-2026:16799 as an Important krb5 security update for RHEL 8. The issue is tied to MIT Kerberos 5 and specific NegoEx handling conditions that could allow an unauthenticated remote attacker to crash an affected process. This is not being described as credential theft or a full authentication bypass. That matters. But authentication-layer availability still matters, especially in mixed Linux and Windows environments where Kerberos helps determine who gets access to what. What Red Hat Fixed in the krb5 Update The update fixes two flaws in how MIT Kerberos 5 handles certain NegoEx authentication data. Instead of letting an attacker take over a system, the reported impact is that a specially crafted request could crash an affected process. For Linux teams, that still matters. krb5 often sits close to login flows, service authentication, identity integrations, and access control. A crash in the wrong process can interrupt more than one user session. It can affect file access, application access, administrative workflows, and service-to-service authentication. That is why Linux administrators should not dismiss the update simply because the impact reads like a denial-of-service attack. Why This Is More Than a Routine Package Update A RHEL system may use Kerberos directly. It may use SSSD. It may authenticate users through Active Directory . It may support Samba file shares, internal webapplications, automation systems, or administrative access that depends on Kerberos tickets in the background. In those environments, krb5 is not just another package. It is part of the access path. If that path breaks, the effect is operational first. Users cannot log in. Services fail to authenticate. File shares stop behaving correctly. Admins lose reliable access when they need it most. Logs fill with authentication errors that may obscure other activity. Those are not always breach scenarios, but they are security problems. Availability is part of security when the system being disrupted controls identity. Why Active Directory Environments Should Pay Attention Kerberos is closely tied to Microsoft Active Directory , but Linux systems rely on it too. In many organizations, Linux and Windows infrastructure share the same authentication backbone. A Linux server joined to Active Directory may use Kerberos to validate users, obtain tickets, and participate in domain-based access control. That makes this a Linux update with a Windows-relevant impact area. A Windows-heavy organization may still run Linux database servers, web applications, file services, monitoring platforms, container hosts, developer tooling, and CI/CD runners. If those systems authenticate through Active Directory, krb5 becomes part of the same identity chain. Not in the idea that this is a Windows vulnerability. It is not. The risk is that Linux systems often sit inside Windows-managed identity environments, and authentication flaws on one side can still affect the shared infrastructure on which both sides depend. How Authentication Outages Can Turn Into Security Problems The reported issue is narrower than a full Kerberos compromise. It depends on specific NegoEx handling conditions, and the public impact centers on crashing affected processes. That should keep the story grounded. Still, authentication bugs deserve attention because they sit close to critical workflows. A denial-of-service issue inauthentication can disrupt logins, interrupt access to internal systems, break service authentication, or create pressure during an incident. When users cannot authenticate, teams often move fast. Sometimes too fast. They restart services, bypass controls, delay policy enforcement, or open temporary access paths just to restore operations. Attackers do not always need to steal credentials to create useful disruption. Sometimes, they only need to make the identity unreliable. That is especially true in environments where Linux servers and Windows identity infrastructure are already tightly connected. What Linux Teams Should Check After Patching Linux teams running RHEL 8 should apply the krb5 update through normal security patching, then confirm that dependent services are restarted where needed. The update is rated Important in the feed, and the package sits close enough to authentication that it should not be pushed behind lower-risk maintenance. Admins should also check where Kerberos is actually used. In many environments, that list is longer than expected. Start with Linux systems joined to Active Directory. Review hosts using SSSD , PAM , Samba, LDAP integrations, GSSAPI-enabled applications, and services that depend on Kerberos-backed access. Pay special attention to file servers, administrative jump hosts, internal applications, and systems that support privileged workflows. CI/CD and automation systems are worth checking, too. If they rely on Kerberos-backed access to internal resources, authentication instability can affect builds, deployments, and operational tooling. After patching, monitor authentication logs for unusual failures, repeated crashes, or service restarts. A quiet patch is ideal. A noisy authentication layer usually means something else needs attention. What This Says About Linux and Windows Identity Risk This advisory is a useful reminder that Linux and Windows security are not separate in most enterprise networks. A Linux server may authenticateagainst Active Directory. A Windows user may access a Linux-hosted application. A Linux file server may depend on Kerberos tickets. A security team may need logs from both sides to understand what happened during an incident. The trust layer is shared, even when the operating systems are different. That is why krb5 updates matter. They are not always flashy, and they do not always point to immediate compromise. But they touch the systems that decide whether users, services, and administrators can access what they need. For Linux administrators, the takeaway is simple: authentication infrastructure belongs near the top of the patching queue. Not because every flaw is catastrophic, but because the systems behind login, identity, and service trust are too important to leave exposed. Bottom Line: Patch Authentication Before Trust Breaks The Red Hat krb5 update is not a dramatic vulnerability story. There is no confirmed domain takeover, no stolen credentials campaign, and no Linux privilege escalation chain in the advisory details provided. It still belongs on the radar. Kerberos is one of the places where Linux and Windows security meet. In enterprise environments, that overlap supports login flows, file access, service authentication, and administrative control. When krb5 is affected, the concern is not only the Linux package. It is the identity infrastructure behind it. That is what makes this update worth watching. Linux security is not only about patching exposed services or hardening the kernel. It is also about protecting the authentication paths that connect systems, users, and trust across the network. Stay Ahead of Linux Security & Authentication Risks Interested in more in-depth coverage of Linux security, enterprise authentication, Red Hat security updates, Kerberos risk, Active Directory integration, and infrastructure hardening strategies? Subscribe to the LinuxSecurity newsletter for weekly threat analysis, advisory coverage, and practical guidance for securing Linuxand open-source environments. Related Reading Red Hat Enterprise Linux 8.6 Security Update for Kerberos RedHat: RHSA-2022-8637:01 Important: krb5 security update Critical Linux-PAM Vulnerability Exposes Servers to Local Privilege Escalation RHEL 9.4 Security Enhancements: SELinux, Cryptography, More Comprehensive Linux Security Tools and Hardening Best Practices 2026 . Kerberos sits within the authentication layer that many enterprises use to connect Linux systems, Wi. released, important, security, update, enterprise, linux, address. . MaK Ulac
May 14, 2026
•
102
security advisorylocal privilege escalationexploitUbuntu Dirty Frag Important Local Privilege Escalation Exploit
Just weeks after Linux defenders began responding to Copy Fail , researchers have disclosed another serious privilege escalation vulnerability that can deliver reliable root access on major distributions. . Known as Dirty Frag, the exploit abuses Linux page cache corruption to modify protected files directly in memory without relying on unstable race conditions or crash-prone exploitation methods. Unlike race-condition exploits that rely on timing or unstable behavior, Dirty Frag succeeds consistently. No kernel panic is required. No memory corruption crash window needs to line up perfectly. According to researcher Hyunwoo Kim, the exploit chain works reliably enough to provide immediate root access across a wide range of environments. At the time of disclosure, no CVE had been assigned, and no official patches were broadly available. How the Dirty Frag Exploit Works Dirty Frag is not a single vulnerability. It is a chained local privilege escalation attack built from two separate Linux kernel flaws: xfrm-ESP Page-Cache Write RxRPC Page-Cache Write Both vulnerabilities abuse the Linux kernel’s handling of fragmented socket buffer structures ( sk_buff ) during in-place cryptographic operations. At a high level, the exploit abuses Linux zero-copy networking behavior. Using splice() and related kernel interfaces, attackers can place references to page-cache-backed memory into fragmented socket buffers. Vulnerable cryptographic code paths then perform in-place operations directly against those fragments. That allows protected memory pages to be modified even when the attacker only has read access to the underlying file. In practice, attackers can: patch /usr/bin/su with shellcode alter /etc/passwd bypass authentication launch a root shell All from an otherwise unprivileged local context. What makes Dirty Frag especially dangerous is that the exploit modifies files through the Linux page cache in memory rather than writingdirectly to disk. That breaks long-standing security assumptions around read-only file access and protected cached pages. Why Security Researchers Are Comparing It to Dirty Pipe Dirty Frag belongs to the same vulnerability class as: Dirty Pipe Dirty COW Copy Fail All of them abuse unintended write behavior against cached pages in memory. Dirty Pipe targeted pipe_buffer structures. Dirty Frag instead abuses the frag field inside Linux socket buffers. That difference matters because it opens another path to modifying supposedly protected memory pages during network and cryptographic processing. The exploit effectively turns internal kernel crypto operations into arbitrary write primitives. Two Exploit Paths Cover Each Other’s Weaknesses One reason Dirty Frag is especially concerning is that the two exploit variants compensate for each other. The ESP variant The xfrm-ESP attack path provides a strong arbitrary write primitive, but typically requires: user namespaces CAP_NET_ADMIN within a namespace Some hardened environments restrict unprivileged namespace creation, which can block this path. The RxRPC variant The RxRPC attack path does not require namespace creation and can work entirely from unprivileged APIs. Instead of patching binaries directly, it manipulates /etc/passwd entries to bypass authentication. Its limitation is module availability. Some distributions do not ship rxrpc.ko by default. Together, they broaden exploitability If one path is blocked by policy or configuration, the other may still succeed. That flexibility is exactly why researchers are treating Dirty Frag as more than another isolated Linux kernel bug. Why You Need To Take Dirty Frag Vuln Seriously Several characteristics make Dirty Frag more dangerous than a typical Linux local privilege escalation vulnerability. Reliable Exploitation Changes the Threat Model Many Linux kernel privilege escalation exploits rely on raceconditions, unstable timing windows, or behaviors that frequently crash systems during exploitation attempts. Dirty Frag is different. According to researcher Hyunwoo Kim, the exploit chain works reliably without requiring race conditions or precise timing. The attack also avoids the kernel instability commonly associated with memory corruption exploits, making successful privilege escalation far more practical for real-world attackers. That reliability significantly lowers the barrier to weaponization. Broad Linux Distribution Exposure Increases Risk Researchers confirmed successful exploitation against multiple major Linux distributions, including: Ubuntu Red Hat Enterprise Linux CentOS Stream AlmaLinux Fedora openSUSE Tumbleweed Because the affected functionality exists deep inside common Linux kernel networking and cryptographic subsystems, organizations may find it difficult to quickly determine exposure across large environments. Shared infrastructure, CI/CD systems, developer platforms, and container-heavy deployments may face elevated risk. Public Exploit Code Is Already Available The coordinated disclosure process reportedly broke down after a third party publicly released exploit details ahead of schedule. Once the embargo collapsed, researchers and maintainers released technical writeups and proof-of-concept exploit chains publicly. As a result, attackers already have access to: detailed exploit documentation weaponized proof-of-concept code mitigation bypass techniques practical exploitation examples before many organizations have production-ready patches available. Temporary Mitigation Available Until vendors release patches, researchers recommend disabling the affected modules where possible. sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2> /dev/null; true" Be aware that this mitigation has anoperational impact. Disabling these modules may break: IPsec VPN functionality AFS distributed file systems services relying on RxRPC Some administrators have also noted that if the vulnerable modules are already loaded, a reboot may be necessary after unloading them to fully clear the affected page cache state. SELinux May Reduce Exposure Some early testing suggests that strict SELinux policies can interfere with exploitation. Researchers discussing the flaw noted that SELinux Strict Policy configurations using user_t contexts appeared capable of blocking exploit execution paths associated with Dirty Frag and Copy Fail. Kernel Hardening Still Matters Dirty Frag is another reminder that SELinux , AppArmor , and other hardening layers can still help reduce zero-day impact even before patches arrive. The Bigger Problem Facing Linux Security Dirty Frag arrives only weeks after the Linux ecosystem began responding to Copy Fail, another actively exploited privilege escalation vulnerability. CISA recently added Copy Fail to its Known Exploited Vulnerabilities catalog , warning federal agencies to patch affected systems quickly due to the risk of real-world exploitation. Now, another exploit chain in the same vulnerability family has appeared before many defenders fully addressed the previous one. The trend is difficult to ignore. Researchers are increasingly finding ways to abuse: page cache interactions splice behavior zero-copy networking in-place cryptographic operations inside the Linux kernel. The result is a growing class of high-impact privilege escalation vulnerabilities that can bypass traditional assumptions about file protections and memory isolation. What Linux Administrators Should Do Right Now Organizations running Linux servers should immediately: Determine whether affected modules are loaded Restrict unprivileged user namespace creation where feasible Apply temporary mitigations ifoperationally possible Monitor vendor advisories closely Watch for unusual privilege escalation activity Harden SELinux or AppArmor policies where applicable Prioritize patch deployment once fixes become available Systems with shared-user access, developer workloads, CI/CD infrastructure, or container-heavy environments may face elevated risk. Final Thoughts Dirty Frag does not feel like an isolated kernel mistake. It looks more like another sign that attackers and researchers are getting better at abusing the same weak points inside Linux memory handling and page-cache behavior. Dirty COW exposed it years ago. Dirty Pipe reinforced it. Copy Fail pushed it further. Now Dirty Frag arrives with reliable exploitation, public proof-of-concept code, and multiple paths to root access before many defenders have even finished patching the last round of issues. What stands out here is the consistency. No unstable race conditions. No complicated crash timing. Just predictable abuse of trusted kernel operations that were never expected to become write primitives. That changes the risk calculation for shared systems, developer infrastructure, container hosts, and anywhere unprivileged local access already exists. The bigger problem is that these bugs keep surfacing in different forms while targeting the same underlying assumptions around memory isolation and protected file access. Defenders can patch this specific flaw once updates land, but the pattern itself is becoming harder to dismiss. Stay Ahead of Linux Security Threats Sign up for our newsletter for weekly analysis covering Linux kernel vulnerabilities, privilege escalation exploits, container security risks, and hardening strategies. Dirty Pipe: High Severity Linux Vulnerability Explained DirtyCred: Another Linux Privilege Escalation Threat What Is an RCE Vulnerability in Linux? Linux Risk Management and Exploitation Trends The Evolution of Linux Security Threats . Known as Dirty Frag,the exploit abuses Linux page cache corruption to modify protected files direct. weeks, linux, defenders, began, responding, researchers, disclosed, another. . MaK Ulac
May 08, 2026
•
102
security advisoryUbuntuimportantCrackArmor AppArmor Flaws Put Linux Containers and Snap Sandboxes at Risk
Linux administrators rely on AppArmor to contain compromised applications. If a browser, container, or Snap package is exploited, the profile is supposed to limit what that process can touch on the host. This mechanism is the backbone of Linux container isolation. . The newly disclosed “CrackArmor” vulnerabilities challenge that isolation model directly. Research from Qualys shows that attackers with local code execution may be able to manipulate or disable AppArmor protections entirely, turning a restricted process into a path toward host-level compromise. The Breakdown of Mandatory Access Control Traditional Linux permissions determine which users can access a system. AppArmor adds another layer by restricting what a process can do after execution begins through mandatory access control. Even a root process can still be blocked from accessing sensitive files, loading kernel interfaces, or initiating unauthorized actions if the profile denies it. CrackArmor matters because the AppArmor vulnerabilities target the framework itself rather than a single application or driver. The flaws affect the Linux Security Module (LSM) policy management interfaces and allow an unprivileged local attacker to abuse a confused-deputy condition to load, replace, or remove security profiles. By interacting with pseudo-files under /sys/kernel/security/apparmor/, an attacker may be able to alter enforcement behavior through privileged tooling that was never intended to expose direct profile control to lower-privileged users. This effectively bypasses the Linux sandboxing that administrators rely on for security. Why This Isn’t “Just” a Local Privilege Escalation CrackArmor is not a remote code execution worm by itself. The attacker still needs local code execution first. In practice, though, that initial foothold is often the easy part. A successful exploit of these flaws can result in a Linux privilege escalation. Common entry points include: Malicious scripts executed by users Browser exploit chains Vulnerable applications running inside containers Exposed development tooling or CI runners Once local execution exists, the AppArmor flaws can be chained with other weaknesses to bypass namespace restrictions or weaken Linux container isolation. In a multi-tenant infrastructure, that changes the impact significantly. There is currently no public evidence of widespread in-the-wild exploitation. Still, Linux privilege escalation and container escape paths remain high-value targets because they convert a limited foothold into persistent system access. Some of these flaws have reportedly existed since kernel v4.11, which was released in 2017, leaving a long exposure window across older deployments. Container Isolation Risks A realistic scenario involves a vulnerable web application running inside a Kubernetes security context, specifically a container protected by an AppArmor profile such as docker-default. An attacker exploits the application and gains shell access inside the container. From there, the attacker abuses the AppArmor policy handling flaw to trigger privileged profile operations indirectly, leading to a potential container escape. If the profile is removed or replaced successfully, the container may gain visibility into host resources depending on namespace configuration, mounted filesystems, and granted capabilities. At that point, the attack moves beyond the original container compromise and into host interaction, credential access, network inspection, or lateral movement activity. Effective Kubernetes security depends on these profiles remaining immutable to the processes they restrict. Ubuntu, Azure, and Snap Exposure Ubuntu security is heavily affected because AppArmor is enabled by default across much of the ecosystem. Snap Sandbox The Snap sandbox relies extensively on AppArmor profiles to isolate desktop and server applications from the host system. If these profiles can be manipulated, the core security promise of the Snap sandboxis broken. Azure Kernels Many Azure-focused Ubuntu kernels use AppArmor as part of the default workload isolation model for cloud deployments, making Ubuntu security a top priority for cloud architects. Kuberne tes Kubernetes security clusters frequently assume that AppArmorProfile enforcement inside Pod Security Contexts provides a stable isolation boundary between workloads and the host. AppArmor vulnerabilities that allow profile modification threaten this entire boundary. Remediation and Verification Canonical has released patched kernels under USN-8243-1. Applying updates alone is not enough. The patched kernel does not become active until the system reboots. Maintaining robust Linux sandboxing requires verified, active enforcement. Operational Actions Audit active kernels: uname -r Verify Kubernetes profile attachment: kubectl exec -- cat /proc/1/attr/current The output should show AppArmor profiles operating in (enforce) mode. Monitor for unexpected profile modifications through dmesg or journalctl -k, especially profile unload activity or denied operations involving the Linux Security Module filesystem. Apply updates and reboot affected systems: sudo apt update && sudo apt upgrade For organizations relying on mandatory access control, namespace isolation, or multi-tenant Linux infrastructure, delaying these updates leaves a path open for a container escape from local execution to broader system compromise. Stay Ahead of the Threat: Sign up for our newsletter for weekly deep-dives into Linux security, Kubernetes risks, and container escape threats. Kubernetes Container Security Misconfigurations Leading to Threats What Is a Container Escape Vulnerability? What Is AppArmor? A Practical Look for Linux Admins . The newly disclosed “CrackArmor” vulnerabilities challenge that isolation model directly for Linux containers.. AppArmor Security Flaws, Linux Container Security Risks, Ubuntu Kernel Updates, Local PrivilegeEscalation. . MaK Ulac
May 07, 2026
•
102
security advisorycode executionimportantCI/CD Pipelines Vulnerabilities in Trusted Execution Paths March 2026
Time and time again, Linux systems execute attacker-controlled code during normal operation, and nothing in the system reports it as a failure. Security models still lean on the idea that something has to break first. An exploit fires, a misconfiguration opens a path, a control fails. But in these cases, there is no breakpoint to trace back to, because the commands being used are valid, expected, and fully trusted by the system. The pattern becomes easier to see in automated environments and is a defining trait of modern software supply chain attacks. CI/CD pipelines run these workflows constantly. They assume the inputs they receive are safe by default, which makes them a clear example of how trusted execution paths turn into execution paths for attacker-controlled code. . CI/CD Pipelines Execute Attacker-Controlled Code Through Rewritten Git Tags In March 2026, a widely used security tool called Trivy was compromised during a routine CI/CD workflow . Nothing was exploited or misconfigured; the system ran exactly as designed, yet still executed malicious code. Pipelines automate tasks like pulling code based on version tags (e.g., v0.69.4). These tags are treated as stable references that should always resolve to the same content. How Git Tags Become Mutable Execution References That trust breaks at the reference level. In the Trivy case, attackers reassigned 76 out of 77 tag pointers to malicious commits. Because Git allows tags to be moved, the system accepted this as a valid state. The pipeline resolved the tag at runtime and executed whatever code it pointed to without verifying if the reference had changed. This is the core issue. The execution path is authorized, so whatever flows through it is trusted by default, even when silently altered. Why Trusted Execution Paths Fail to Verify Content What’s missing here isn’t a failed control. It’s how trust is defined in the first place. Most systems validate access, not whether what they execute is still the samething. If a workflow is allowed to run and the command is valid, the result is treated as trusted by default. That assumption only holds if the thing being executed stays the same. In these environments, it doesn’t. A tag can move, a maintainer can change, or a commit can be rewritten, while the execution path remains untouched. The system validates the path, not the content flowing through it, so nothing fails because nothing appears out of place. The result followed naturally. During execution, the pipeline exposed credentials from environment variables like GitHub tokens and AWS keys, because the process still had full access, and no part of the system recognized that the code being executed was no longer what was originally intended. The Fix: Stop trusting tags. Pin to the exact content using a full commit SHA. Because a SHA is tied to the code itself, the reference cannot be silently reassigned. For external binaries, always validate a checksum before execution. npm install Executes Attacker-Controlled Code During Package Installation While the Trivy case involved manipulated references, the npm ecosystem often suffers from identity failures. Here, the reference remains the same, but the identity behind the code is compromised. This has happened repeatedly. In multiple incidents, such as the phishing compromise of a prolific maintainer , attackers hijacked accounts to publish malicious updates. Because these updates come from the expected publisher, they are installed automatically. This is a fundamental trust gap: the system validates the publisher, not the content. On Linux, this leads to immediate execution. npm install does more than pull files; it automatically runs lifecycle scripts as the current user. This allows attacker-controlled code to execute before the application even starts, granting it access to your files, network, and environment variables—all within a "trusted" workflow. The system doesn’t fail; it simply trusts the wrong thing. The Fix: Breakthe link between retrieval and execution by disabling lifecycle scripts during installation: npm config set ignore-scripts true npm install --ignore-scripts This keeps the package on disk without running its code, so execution does not happen until the code is actually reviewed or invoked. git pull Executes Attacker-Controlled Code From Manipulated Repository History In the Trivy case, the system trusted a reference. In the npm case, it trusted a hijacked identity. With Git, the trust failure shifts to the repository history itself. When you run git pull, you likely check git log to see who made changes. What you see looks like a reliable timeline of names and dates. However, a Git commit is simply a stored object containing unverified fields for author name, email, and timestamp. This is not a hack; it is a core feature. Anyone can use the git commit --author command to set any identity they choose. Because Git does not verify these fields by default, an attacker can rewrite history to include malicious code that appears to be authored by a trusted contributor years ago. When this rewritten history is pushed, and you git pull, your system accepts it as valid input. You aren't just trusting the code; you are trusting unverified metadata. The result is consistent: malicious code is merged because it looks like it belongs. The system didn't fail—it trusted a history that was never authenticated. The Fix: Verify the commit, don't just read it. Enable commit signature visibility to shift trust from easily faked names to cryptographic signatures: Bash git config --global log.showSignature true This ensures the author’s identity and the commit’s integrity are cryptographically proven before you merge. Linux Must Enforce Execution Boundaries When Trusted Workflows Execute Untrusted Code By the time the code reaches your system, the critical decisions have often already been made. A reference was resolved, a package was installed, or a repository was pulled—allthrough trusted workflows that failed to verify the content. This leaves only one place where control still exists: the moment of execution. Linux Executes Untrusted Code With Full Permissions By default, Linux tools run with the same permissions as the user who launched them. Attacker-controlled code inherits your access to files, networks, and environment variables without needing to bypass a single security control. To limit this, isolate execution. Use Podman to run tools inside containers with restricted access, ensuring that even if code runs, it cannot exfiltrate data or modify your host: Bash podman run --rm --network=none -v $(pwd):/apps:ro Processes Automatically Expose Credentials Linux processes inherit environment variables from the parent shell. Tokens, API keys, and cloud credentials exported earlier are passed automatically to new processes. Attackers don't need to "find" your secrets; they are handed to them at startup. Reduce this exposure by using scoped execution via systemd-run or temporary subshells, and avoid exporting sensitive variables globally in files like .bashrc. The Point of Execution is the Point of Truth Whether it's a "latest" tag or an unverified binary, the pattern is consistent: the system isn't being bypassed; it is executing exactly what it was given. To address this, verify the code before it touches your CPU. Use sha256sum to confirm a binary matches its expected value and review commit history for inconsistencies. If the origin of code cannot be cryptographically proven, it must be treated as untrusted. When verification fails at the workflow level, the only remaining safety net is the execution boundary you build within the OS. Execution Without Trust Across all three cases, nothing was exploited, and nothing was misconfigured. The system had access, the workflows were valid, and the commands executed exactly as expected, which is why this keeps happening. The risk is not unauthorized access. It is authorizedexecution from unverified sources, where a tag moves, a maintainer changes, or a commit lies, and the system accepts all of it because it trusts what it sees. Stop trusting what can change: Names and labels Tags Authorship Start verifying what cannot: Commit hashes Signatures Checksums Doing this manually does not scale. That is why teams use tools to track and update pinned versions, so the workflow stays usable while the references stay fixed. If the origin of the code cannot be proven, treat it as untrusted before execution. Because at that point, the system will execute it anyway. . CI/CD tools face major risks as trusted code execution paths allow for attacker-controlled code to execute within workflows.. secure coding practices, CI/CD security, software supply chain, code execution integrity, code review processes. . MaK Ulac
Mar 31, 2026
•
102
security advisoryintrusion preventionimportantIntrusion Detection Systems vs Prevention Systems Snort Overview
Intrusion detection and prevention systems are often treated as interchangeable. IPS is often described as IDS with blocking turned on. That sounds simple, but the moment traffic runs inline, mistakes start breaking real connections. IDS watches traffic and reports what looks suspicious, while IPS sits in the path and can block connections as they happen. Let’s walk through that shift using simple Snort examples. The goal is to show what breaks once blocking is enabled and why that changes how you operate the system. . Who Is Responsible for the Impact of IDS vs IPS Decisions? IDS and IPS often run the same detection engine . The same rule fires, the same signature matches, and the system reaches the same conclusion about the traffic. The rule logic stays the same. What changes is what happens when it fires. An IDS, or intrusion detection system , can reuse that detection logic safely because it only observes traffic. When the same rules are used inline, responsibility shifts immediately. You can reuse the same rules in both modes. But once you turn on blocking, someone owns the outages. A simple framing helps clarify the difference. IDS tells you something is wrong. IPS decides whether users feel it. IDS Observes traffic out of band Generates alerts for review Preserves availability when rules are wrong Supports human decisions before action is taken IPS Modifies traffic inline Drops or resets connections automatically Enforces decisions without review Owns the impact when something breaks The operational takeaway is that insight and enforcement are different jobs. IDS can generate alerts that turn out to be harmless. IPS can block legitimate traffic. Many teams make this explicit with a responsibility contract during design reviews. The artifact is simple, but it forces a necessary question before blocking is enabled: Who owns the outcome when detection becomes enforcement? What Happens When an IPS Blocks Traffic Inline? Whenan intrusion prevention system blocks traffic inline, it sits directly in the network path and makes a decision on every packet as it passes through. Traffic is inspected in real time and either allowed, dropped, or reset before it reaches the destination. There is no copy of the traffic and no later review. Whatever decision is made is immediately visible to users. Inline placement is the part that changes everything. A passive IDS watches a mirrored stream and cannot affect delivery. An inline IPS is different. All traffic must pass through it to get anywhere, which means if the rule is wrong, traffic breaks immediately. This is the point where the difference shows up. Inline packet flow looks like this: Client → eth0 → Snort (inspect + decide) → eth1 → Server There is no buffer in that path. No rewind. No second chance to reinterpret the decision. If the IPS misclassifies traffic, the application feels it immediately. Under the hood, every packet follows the same simple loop: Inspect the traffic Decide on a rule match Allow, drop, or reset the connection Both modes inspect traffic and match rules. The difference is whether the packet keeps moving. In detection mode, the outcome is an alert. In prevention mode, the outcome is broken or preserved connectivity. Here is a basic Snort inline configuration: snort -Q \ --daq afpacket \ --daq-mode inline \ -i eth0:eth1 \ -c /etc/snort/snort.conf The -Q flag is the turning point. It puts Snort inline instead of passive . Drop and reject rules only work here because Snort is no longer just watching traffic. It’s deciding whether packets move forward or not. At that point, detection stops being an alerting tool and starts actively controlling traffic. Once traffic is inline, a bad rule affects everyone using that connection. There is no “observe first” safety net. A bad rule doesn’t just generate an alert. It interrupts traffic. For wiring details and DAQ behavior, see the Snort inlinedeployment guide, but the risk is already visible here. Enforcement happens in the packet path, and mistakes affect traffic. Does an IPS Still Work If Systems Aren’t Fully Patched? Most IPS deployments quietly assume you already know what is vulnerable. That assumption rarely holds up for long. Patch data drifts, inventories lag, and services change faster than signatures do. IPS rules assume something about the system they’re protecting. A specific endpoint exists. A bug behaves a certain way. A fix has not been applied yet. When those assumptions are accurate, blocking can be precise. When they are not, the IPS is still forced to act, and enforcement turns into educated guessing. This is where people misunderstand intrusion prevention systems. IPS does not compensate for weak patching. It reflects it. When patch data is accurate, you can scope rules tightly. When it isn’t, you end up blocking more traffic than you intended. Consider a basic drop rule tied to a known vulnerable path: drop tcp $EXTERNAL_NET any -> $HOME_NET 443 ( msg:"IPS DROP - CVE-2023-XXXX exploit attempt"; flow:to_server,established; content:"/vulnerable_path"; http_uri; classtype:attempted-admin; sid:3000001; rev:1; ) From the IPS point of view, this rule is simple. If that request shows up, drop it. The problem is that the rule has no idea whether the target is actually vulnerable. Testing it is trivial: curl -k https://TARGET/vulnerable_path> If the service is fully patched, the request should not succeed anyway. Dropping it does not change real behavior, and nobody notices. This is the best-case scenario for intrusion detection prevention. If the service is unpatched, the IPS genuinely prevents exploitation. The request never reaches the application, and the risk is reduced, at least temporarily. If patch data is stale or wrong, the IPS blocks traffic that is no longer dangerous. Users experience breakage, not protection. From the outside, it looks arbitrary. From theinside, the IPS is doing exactly what it was told. This is where IDS and IPS behave very differently. Detection can live with uncertainty and still be useful. IDS can log something questionable and let you investigate later. IPS has to decide right now, even if it’s not fully sure. The less confidence you have in patch state, the more likely you are to block traffic that doesn’t need to be blocked. Why Do IPS Blocking Rules Fail So Quickly on Encrypted Traffic? They fail because once traffic is encrypted, the IPS can’t see what the request actually is anymore, but it still has to make a decision. TLS hides the URL, the path, the parameters, and any exploit string that would normally trigger a clean match. What’s left is the connection itself. At that point, an intrusion prevention system only sees where the traffic is coming from, where it’s going, and which port it’s using. IDS can live with that and log it. IPS can’t. It’s inline, so every session still has to be allowed, dropped, or reset. When blocking is required, and there’s nothing useful left to inspect, rules get written against the few fields that still exist. That usually means ports and direction, not behavior. You see rules like this show up: drop tcp $EXTERNAL_NET any -> $HOME_NET 443 ( msg:"IPS DROP - blunt port-based enforcement"; sid:3000009; rev:1; ) This rule doesn’t look inside the connection. It can’t. It just drops traffic headed to 443 based on where it’s coming from. Once traffic is encrypted, there isn’t much else to match on. In a lab, this often looks fine. Traffic is controlled. Applications are known. Nothing unexpected crosses the rule. It appears to work. Production environments are different. Almost all traffic is encrypted. Browsers, APIs, agents, background services. A rule this broad starts dropping legitimate sessions. When the IPS can’t see the request but still has to enforce a decision, real traffic gets blocked. Do TCP Resets and Session DropsActually Stop Attacks? They solve different problems. A drop blocks traffic. A reset interrupts a connection. Neither one guarantees prevention. What a drop does Packets are silently discarded The connection hangs until it times out Some clients retry automatically What a reset does A TCP RST is sent back The connection closes immediately Failures show up faster to users A basic Snort reset rule looks like this: reject tcp $EXTERNAL_NET any -> $HOME_NET 80 ( msg:"IPS TCP RESET demo"; flow:to_server,established; content:"test"; sid:3000002; rev:1; ) Resets feel cleaner, but they come with tradeoffs. Under load, attackers can send data before the RST arrives, so some traffic still reaches the application. The practical takeaway is simple. Resets interrupt sessions. Drops block packets. Both can reduce impact, but neither guarantees an attack is fully stopped once traffic volume climbs. Can You Tune an IPS Without Creating Permanent Blind Spots? Every IPS tuning change may create a potential blind spot if not done carefully, but proper methods exist to minimize or avoid that. Tuning usually starts when the IPS flags traffic that turns out to be legitimate. The alerts are technically correct, but they don’t reflect real risk. To stop the interruptions, a rule is added to let that traffic pass without inspection. That is what a bypass rule does in practice: pass tcp $HOME_NET any -> $HOME_NET 8443 ( msg:"BYPASS - internal API traffic"; sid:5000001; rev:1; ) Once this rule is in place, traffic on that port is no longer inspected. It does not generate alerts. It does not get checked by later rules. The IPS simply steps aside and lets it through. There are a few details that matter here. Pass rules are usually evaluated before drop rules. If the pass is broad, inspection is removed entirely for that traffic. If the rule order is wrong, nothing else has a chance to run. Over time, these exclusions tend tostick around. The service changes, the environment changes, but the bypass stays. Attackers don’t need to break the IPS if the IPS has already been told to ignore a path. That’s the trade you make when you start bypassing traffic. Every time you add a bypass rule, you remove inspection from that traffic. For a deeper look at how this plays out as environments grow, see IDS false positives and performance. Why Do IPS Configuration Changes Cause Outages So Easily? Because when an IPS is inline, config changes affect live traffic immediately. You’re not changing a policy in the background. You’re changing how packets are handled right now. If a rule is wrong, traffic starts dropping as soon as the process reloads. If the config is invalid, Snort may not come back up at all. Either way, users feel it before you finish checking logs. The usual workflow looks like this: # Validate config before reload snort -T -c /etc/snort/snort.conf # Restart inline Snort systemctl restart snort If you skip the test step, you’re guessing. A bad config can stop the service or load in a broken state, and because the IPS is inline, that guess turns into a traffic problem immediately. Even when the config is valid, timing matters. Restarting during active traffic means every mistake shows up at full volume. There’s no quiet failure mode. That’s why rollback planning has to come first. There’s very little room for mistakes once it’s inline. If you don’t already know how to bypass or revert the change, you find out the hard way, usually from users, not monitoring. How Is IPS Most Commonly Misused in Production Environments? Most IPS outages are not caused by bugs. They come from how blocking is turned on. The most common mistakes look like this: Using IPS to make up for systems that are not fully patched Treating alerts as final decisions instead of signals Enabling blocking without assigning clear ownership Having no rollback or kill switch when something breaks In production, an inline intrusion prevention system must have a way to step out of the path. Hardware bypass NICs or a software kill switch are recommended for fail-safe operation in production IPS deployments. If the IPS process fails, traffic should continue to flow. If there’s no bypass, one bad rule can take down traffic. When Does an Intrusion Prevention System Work? An intrusion prevention system is not always wrong. It just works in a narrow set of conditions. IPS works best when you know exactly what services are running, and they don’t change much. Services are fully inventoried. Patch status is accurate. Traffic paths are stable and predictable. When those pieces line up, blocking can be targeted instead of disruptive. A few things usually need to be true at the same time: You know which services are exposed and why Patch data reflects reality, not last quarter Traffic flows are consistent Someone owns rollback decisions The team accepts some false positives Turning on blocking doesn’t mean you’re more advanced. It means you’re prepared to deal with traffic being interrupted. If any of these pieces are missing, risk increases immediately. The IPS is still inline, and uncertainty shows up as broken traffic. Is Moving from IDS to IPS a Security Maturity Upgrade? No. IDS does not “graduate” into IPS. They solve different problems and fail in different ways. IDS and IPS carry complementary responsibilities. IDS focuses on visibility and understanding what is happening on the network. IPS focuses on enforcement and stopping traffic in real time. One helps you learn. The other forces you to act. Neither replaces the other. The failure modes are different, too. When IDS is wrong, you get noise. When IPS is wrong, users get blocked. That difference does not disappear as teams get more experienced. IDS remains foundational even in environments that use blocking. You still need visibility, context, and a way to respond withouttouching live traffic. That’s why IDS response and countermeasures matter alongside prevention, not after it. Prevention does not replace visibility. It depends on it. Why IPS Blocking Fails Without Certainty IPS has to decide immediately. It doesn’t get time to double-check whether the rule is perfectly accurate. When that decision is wrong, users notice right away. Detection can log something questionable and let you investigate later. IPS has to act even if it isn’t fully sure. That uncertainty gets enforced inline, and small mistakes turn into dropped traffic instead of alerts. IPS only works if someone validates the assumptions behind each blocking rule and is willing to own the impact. If you’re unsure about your rules, blocking doesn’t fix that. It just pushes the consequences onto live traffic. . Who Is Responsible for the Impact of IDS vs IPS Decisions? IDS and IPS often run the same detection . often, intrusion, detection, prevention, systems, treated, interchangeable, descri. . MaK Ulac
Mar 12, 2026
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Should Linux servers automatically install security updates?
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!