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×
Desktop Security
security advisory vulnerability
security advisory vulnerability GNOME is officially shortening its standard vulnerability disclosure window from 90 days to 30 days, a change that impacts upstream maintainers, downstream Linux distributions, and system administrators in how they handle software vulnerabilities. The policy shift, announced by long-time security coordinator Michael Catanzaro , addresses modern software patching realities and a growing influx of automated submissions. . Because GNOME is the default desktop environment on several major Linux...
Jul 21, 2026
Security Vulnerabilities security advisory moderate
security advisory moderate For organizations that run a self-hosted Git platform, it’s no longer just about hosting static code repositories. Today, Git servers are responsible for deployment pipelines, API tokens, SSH keys, package repositories, and the automation scripts that push code directly. Confirm that the upgrade addresses known vulnerabilities but also provides production environments. . That makes them trusted systems within the development environment and attractive targets for attackers looking to move...
Jul 20, 2026
Server Securitydata privacy automation
data privacy automation Every system admin has lived through the same Monday morning ritual. A queue of forty tickets, half of them password resets, permission errors, or disk space warnings that any experienced technician could resolve in under two minutes. The other half require actual judgment. For years, automation promised that software would eventually sort the two apart on its own. That promise is now being tested in production Linux environments. . Early results are reshaping how IT teams think about tier-1...
Jul 17, 2026
Privacydata collection automation
data collection automation You're running a web scraping project to collect pricing data from e-commerce sites. You set up a pool of datacenter proxies, launch your scripts, and within minutes — banned . CAPTCHAs everywhere. Your data pipeline stops before it really begins. . It's a frustrating scenario that plays out daily in ad verification, market research, and multi-account management. The website doesn't know you're doing legitimate research or monitoring. It just sees traffic coming from IP ranges it recognizes as...
Jul 17, 2026
Security Trends security advisory social engineering
security advisory social engineering Business Email Compromise used to be a numbers game — mass-blasted emails, broken English, an obvious "URGENT WIRE TRANSFER" subject line. That era is over. Generative AI has turned BEC into a tailored, low-noise operation that mimics writing style, voice, and even video presence. This piece looks at what's actually changed under the hood, what defenders are testing in response, and why so many organizations are still structurally unprepared for it. . The Infrastructure Problem Nobody Wants to...
Jul 17, 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
Should Linux servers automatically install security updates?
Trending News
Loading...
Explore Latest Linux Security news
We found -1 articles for you...
77
security advisoryprivilege escalationimportantOpenStack Keystone Flaws Expose Multiple Paths to Cloud Privilege Escalation
The recent Keystone advisory is unusual because the vulnerabilities are scattered across several features but keep affecting the same class of security controls. Application credentials, trusts, RBAC enforcement, project ownership validation, token expiration. Different code paths. Similar failures. . Most require authentication already. The concern is what happens after access exists. Several of the disclosed vulnerabilities affect how Keystone validates identity, ownership, delegation, and authorization. For environments running OpenStack, that puts the focus on privilege expansion rather than initial compromise. What Is OpenStack Keystone? Most OpenStack services do not evaluate identity independently. A user authenticates to Keystone, receives a token, and presents that token to other services. Nova uses Keystone identities when processing compute requests. Neutron relies on the Keystone project and role information when handling network operations. Horizon uses Keystone during authentication and authorization workflows. Similar trust relationships exist throughout the platform. Keystone also manages application credentials, trusts, federation, project membership, and role assignments. Those functions appear repeatedly throughout the advisory because they are the mechanisms responsible for determining who an identity represents and what actions that identity can perform. That position gives Keystone an unusual amount of influence over the OpenStack security posture. A bug in Nova typically affects compute operations. A bug in Keystone can affect how identities, permissions, projects, and delegated access are interpreted across multiple services at the same time. The vulnerabilities disclosed in this advisory target several of those mechanisms directly. Do These Attacks Require Authentication? In most cases, yes. The advisory does not describe a collection of unauthenticated remote code execution vulnerabilities. Attackers generally need some form of existing access before thesecloud security vulnerabilities become relevant. These vulnerabilities start becoming relevant once an identity already exists inside Keystone. That might be a service account used by automation, an application credential tied to a deployment pipeline, or a federated account brought in through an external identity provider. None of those identities necessarily begin with administrative access. The interesting part is what happens after authentication succeeds. Several of the disclosed flaws affect the checks Keystone performs when validating ownership, evaluating permissions, creating delegated access, or issuing new credentials. Those identities often start with limited permissions. The next challenge is finding a way to extend access, bypass restrictions, or operate outside the boundaries originally assigned to the account. Several of the Keystone vulnerabilities affect exactly those controls. Why These Vulnerabilities Are Related At first glance, the advisory reads like a collection of unrelated implementation bugs. One issue affects application credentials. Another involves trust relationships. Others target OpenStack RBAC , policy enforcement, project ownership validation , LDAP integration, or token handling. The code paths are different, but the failures keep landing in the same place. Keystone is responsible for validating identity, ownership, authorization, delegation, and access scope. The disclosed vulnerabilities challenge one or more of those decisions. That shared theme is what makes the advisory interesting. Rather than exposing a single weakness, the bugs reveal multiple ways identity and authorization controls can become unreliable under specific conditions. How the Vulnerabilities Could Be Exploited Looking at the vulnerabilities through attack scenarios provides a clearer picture than reviewing each CVE in isolation. Impersonating Another User (CVE-2026-42998) This issue involved application credential authentication . Keystone failed to verify that the usersupplied during authentication actually owned the application credential being presented. Under normal conditions, an application credential should remain tied to the identity that created it. Ownership is part of the trust decision. The vulnerability weakened that relationship. The immediate concern is not simply access; activity can become associated with the wrong user. Audit trails become harder to trust, and administrative actions may appear to originate from an account that never performed them. Combining Trust Relationships and Privilege Escalation (CVE-2026-43000) Trust relationships exist to support delegated access. A user authorizes another identity or service to act on their behalf within defined limits. The trust functionality is not unusual. Large OpenStack deployments depend on it for delegated access. What stands out here is how it interacts with the impersonation flaw. Once Keystone accepts the wrong identity, the trust system starts operating on that decision. The result is not a single authorization failure. New trust relationships can be created with privileges the original account never possessed . Weakening RBAC Enforcement (CVE-2026-42999) OpenStack RBAC is one of the primary mechanisms OpenStack uses to separate users, operators, auditors, service accounts, and administrators. The vulnerability involved Keystone incorporating untrusted JSON request data into policy evaluation decisions . Authorization systems depend on trusted inputs. Once policy evaluation begins consuming attacker-controlled attributes, permission decisions become harder to predict and harder to trust. Crossing Project Boundaries (CVE-2026-43001) Project isolation sits at the center of OpenStack's multi-tenant model. Researchers found that Keystone did not correctly validate project ownership during EC2 credential creation. Under certain conditions, users could create credentials associated with projects they did not own . Organizations depend on project boundaries to separate departments,customers, workloads, and environments. When credential ownership and project ownership become disconnected, those boundaries become less reliable. Access That Refuses to Expire (CVE-2026-44394) Token expiration is intended to limit how long compromised access remains useful. The advisory describes a situation where federated token rescoping did not preserve original expiration restrictions. A user could repeatedly obtain newly scoped tokens with fresh lifetimes . During incident response, token expiration often serves as a containment mechanism. Additional Keystone Vulnerabilities Restricted Application Credentials ( CVE-2026-33551 ): This vulnerability allowed restricted credentials to create EC2 credentials despite intended permission boundaries. LDAP Account State Validation ( CVE-2026-40683 ): Researchers found conditions where Keystone improperly handled LDAP user-enabled status values, creating a gap between how an account appears in the directory and how Keystone interprets it. What OpenStack Administrators Should Do Applying vendor patches should be the immediate priority. Administrators should also review how application credentials are used, examine existing trust relationships, validate RBAC assignments, and review federated identity deployments. Historical activity deserves attention as well. Because these vulnerabilities involve privilege escalation, successful exploitation may look like legitimate user activity. Keystone logs are the most valuable starting point for auditing: Application credential creation activity Unexpected EC2 credential generation Cross-project credential creation attempts New trust relationship creation Role assignment changes Token rescoping activity Conclusion The Keystone advisory is best understood as a collection of failures affecting identity and authorization controls. Keystone is making decisions about identity and authority that other OpenStack services rely on without question. For organizations operatingLinux-based OpenStack environments, that makes Keystone one of the highest-value services to patch and review. When trust decisions fail at the identity layer, the effects rarely stay confined to the identity service itself. Want more Linux security news, vulnerability analysis, and software supply chain updates? Subscribe to the LinuxSecurity Newsletter and get the latest threats, advisories, and expert insights delivered directly to your inbox. Related Reading Linux Privilege Escalation Patterns and Mitigation Strategies Privilege Escalation Risks: Controls for Linux Security Securing Linux Cloud Workloads: Key Practices for Safety . OpenStack Keystone vulnerabilities threaten identity controls, leading to privilege escalation risks and unauthorized actions.. OpenStack Security Flaws, Cloud Privilege Escalation, Identity Abuse, Keystone Vulnerabilities. . MaK Ulac
Jun 19, 2026
•
Server Security
212
linuxinfrastructureopenstackBenefits of Linux, OpenStack, and Kubernetes in Cloud Infrastructure
The LOKI stack is a powerful infrastructure that combines Linux, OpenStack, and Kubernetes in the ever-changing landscape of cloud infrastructure . OpenStack reports that Kubernetes was now used on more than 85% of OpenStack installations, indicating how these technologies are becoming increasingly integrated, as opposed to the idea of either-or choices. . Let's have a look at the benefits of integrating Linux, OpenStack, and Kubernetes infrastructure. Linux: The Solid Foundation Linux is the foundation of the LOKI stack, allowing for a unified management experience across physical and virtual devices. Linux is an open-source operating system that is a crucial layer between hardware and software. It is the de facto operating system standard. OpenStack: Orchestrating Cloud Resources OpenStack, which was created in 2010 by Rackspace and NASA as a joint effort, has now become the open-source cloud standard. OpenStack, written in Python, constantly evolves and has regular releases every six months (like Bobcat or the upcoming Caracal). It manages servers, whether they are physical or virtual, and plays a crucial role in LOKI’s infrastructure. OpenStack is a cloud-based operating system that runs on top of Linux to create the space needed for the application layer. Kubernetes: Container Orchestration Excellence Google handed Kubernetes over to the Cloud Native Computing Foundation in 2014. Kubernetes' latest version, 1.28, enables the re-architecting and scaling of containerized applications, as well as automating deployment. Kubernetes was once thought to be a replacement for OpenStack, but it actually requires something similar to OpenStack to provide the infrastructure abstraction required by Kubernetes to run. Integrating LOKI Components Integrating OpenStack and Kubernetes into the LOKI stack offers a multifaceted solution to increase agility, security, and flexibility. Here are three ways that they work together: OpenStack Container OpenStack-Helm enablesthe containerization of the OpenStack Control Plane, simplifying the deployment, maintenance, and upgrading of individual OpenStack Services. This allows for flexibility when managing complex environments. OpenStack Helm can be used to orchestrate LOKI's stack. OpenStack Helm is closely associated with this project. However, there are many other open-source solutions that are being developed in the same space. Kubernetes Containers on OpenStack Kubernetes is able to run in an OpenStack cloud using OpenStack Magnum and the Kubernetes Cluster API. This approach allows for multi-tenant separation between Kubernetes Clusters and offers a robust solution to deploy container frameworks. Cloud Provider OpenStack Plugins for Kubernetes OpenStack services such as Cinder and Manila are independent of an OpenStack cloud. They provide storage solutions for containers without having to rely on Nova (the compute component within OpenStack). Additional OpenStack service plugins enhance Kubernetes functionality, including auto-healing (Magnum), ingress load balancing (Octavia), and secrets/authentication management (Barbican and Keystone) through the use of cloud provider OpenStack, which is maintained inside the Kubernetes community under SIG Cloud Provider. Our Final Thoughts on the Significance of the LOKI Stack The adoption of LOKI is evident in the statistics--Kubernetes is deployed on over 85% of OpenStack setups, with a notable 21% running production workloads using Magnum for container orchestration. The LOKI stack is a testament to Linux, OpenStack, and Kubernetes' collaborative power. It has been able to create an open-source, end-to-end infrastructure stack that can meet diverse use cases and workloads. Are you using the LOKI stack? We'd love to hear about your experience! Connect with us on X @lnxsec , and let's chat! . Explore how integrating Linux, OpenStack, and Kubernetes creates a powerful cloud infrastructure solution.. stack, powerful, infrastructure, combines, linux,openstack, kubernetes. . Brittany Day
Jan 13, 2024
•
Cloud Security
74
securityprivacyresilienceOpenStack Vendors Remain Vigilant Against NSA Snooping Risks
The Edward Snowden revelations about NSA snooping in the cloud are not having an impact on OpenStack cloud vendors, including Rackspace and Dreamhost.. HONG KONG The link for this article located at eWeek is no longer available. . Investigating the responses of OpenStack providers such as Rackspace to the apprehensions regarding NSA surveillance in cloud environments.. OpenStack Security, Cloud Privacy, Vendor Resilience. . Anthony Pell
Nov 12, 2013
•
Network Security
79
software projectopenstackcloud platformRackspace Launches OpenStack Project For Cloud Innovations
Rackspace announced the OpenStack project today, open sourcing much of the software it uses to run its own cloud. I spoke with Rackspace. This is a big announcement in the cloud world, further widening the technologies that are available to start crafting public and private clouds. The nature of Rackspace as not a software company is also interesting to watch here, as well as what partners do with the project. Transcript Michael Cot. The introduction of OpenStack by Rackspace enhances choices for creating both public and private cloud infrastructures.. OpenStack, Rackspace, Cloud Solutions, Cloud Technology, Software Projects. . LinuxSecurity.com Team
Jul 29, 2010
•
Security Projects
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?
Trending News
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!