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 0 articles for you...
210
open-sourcedependency managementsecurity threatMalicious Go Modules: Securing Your Linux Build Pipeline
Every Linux developer who works with Go has run the same workflow a thousand times. You find a library that solves your problem, you see a decent star count on GitHub, and you run go get. It is frictionless and efficient. Lately, however, it is becoming one of the most effective ways for an attacker to get code running on your build servers. The recent "Operation Muck and Load" campaign is a perfect example of why this workflow is risky. Researchers uncovered over 200 GitHub repositories distributing malicious Go modules . These were not exploiting a vulnerability in the Go compiler or a bug in a specific package. They were exploiting the assumption that anything hosted on GitHub deserves the benefit of the doubt. . How Attackers Turn GitHub Into a Delivery Platform The attack starts long before any malware is downloaded. Attackers first publish a Go module that looks like something you would genuinely use. The repository has a believable name, a polished README, and enough commit history to suggest an active project. Much of that activity is manufactured through commit farming, giving the impression that multiple developers have been maintaining the code over time. Once a developer imports the module, the real attack begins. Hidden inside the package is obfuscated code that launches PowerShell rather than simply performing its advertised function. Instead of connecting directly to a command-and-control server—which would be easy for security teams to block via firewall rules—the script first checks a public "dead drop" page that stores the current server location. This technique, classified by MITRE as a Dead Drop Resolver , lets the attackers change infrastructure whenever they want without modifying the malware itself. Only after resolving that address does the downloader retrieve the final payload, such as a Remote Access Trojan. Supply chain attacks are difficult to detect because nothing initially looks broken. The build succeeds, the application runs, and developers move on.By the time suspicious behavior appears, the malicious dependency may already be embedded across multiple projects. Why Your Linux Build Pipeline Is at Risk It is easy to look at a Windows-based RAT and assume your Linux servers are safe. Do not be that confident. Shared Infrastructure: If your CI/CD runner is configured to compile artifacts for both Linux and Windows, that runner is now compromised. Trusting the Proxy: Many developers rely on the default GOPROXY . While this protects you from repositories disappearing, it does not verify that the code within those modules is benign. Developer Workstations: Most of us use Linux as our primary workstation. If you import a malicious module, your local GOPATH is exposed, and any environment variables or credentials cached on your machine are fair game. Auditing and Verifying Your Dependencies Go provides several tools to help you keep an eye on your dependencies. If you are not using them, you are flying blind. 1. Start with go mod verify The go mod verify command checks that the dependencies in your local cache have not been modified since they were downloaded. If a local file has been tampered with, this command will immediately flag it. 2. Inspect with go list Before you add a module, see what it’s actually pulling in. Use go list -m all to get a full tree of your project's dependencies. If you are importing a simple logging tool and it suddenly pulls in 50 sub-dependencies you’ve never heard of, that is a massive red flag. 3. Manage your Proxy In enterprise environments, do not just rely on public proxies. Consider using an internal GOPROXY or an artifact repository that caches and scans modules. This gives you a single choke point where you can enforce security policies and conduct vulnerability scans before code ever reaches your build pipeline. 4. Leverage Build-Time Monitoring If your build process is suddenly reaching out to the internet to fetch "resolver" content from randompublic websites, your security team needs to know. Monitor your CI/CD runners for unexpected outbound network traffic during the go build phase. Legitimate builds should talk to known proxies or git servers, not random public dead drops. Don't Let Your Build Process Be Your Weak Link Go's module ecosystem is not broken, but blind trust is. The repositories in Operation Muck and Load did not exploit a flaw in the language; they exploited the assumption that anything hosted on GitHub deserves the benefit of the doubt. Before adding a new dependency, spend a minute looking at who maintains it, how the project history has evolved, and what your build process is actually downloading. Verify your hashes, pin your versions, and keep an eye on your outbound traffic. That is often enough to avoid becoming the next victim of a supply chain attack. . Learn how to secure your Linux build pipeline from malicious Go modules exploiting trust in GitHub repos.. Go modules security, Linux build risks, dependency management, supply chain threats. . MaK Ulac
Jul 10, 2026
•
Security Vulnerabilities
210
security advisoryzero-dayimportantActively Exploited Chromium V8 Zero-Day: What Linux Admins Need to Know
CISA added CVE-2026-11645 to its Known Exploited Vulnerabilities catalog after Google confirmed active exploitation of the flaw. The bug sits in V8, the JavaScript engine behind Chrome and Chromium. . That's where this gets more interesting. Most coverage will focus on Chrome because that's where the patch landed. But the affected component is V8. Chromium relies on it. Electron relies on it. Plenty of desktop software Linux users interact with every day relies on it too, often without much thought given to what is running underneath the interface. V8 has become part of the plumbing. When a vulnerability shows up there, the conversation shifts from a browser update to a dependency problem . Different vendors patch at different speeds. Some applications ship their own Chromium runtimes. Others inherit updates from distribution maintainers. Same vulnerable code. Different timelines. This is the fifth Chrome zero-day reported as exploited in the wild this year. That doesn't automatically mean browser security is getting worse. It does reinforce where attackers continue to spend their time. Browser engines process untrusted content constantly. A successful exploit can provide an initial foothold without touching SSH, bypassing MFA, or finding weak sudo rules on a target system. What Is CVE-2026-11645? CVE-2026-11645 is an out-of-bounds read and write vulnerability in V8. Google released patches after confirming exploitation in the wild , while technical details remain limited. NVD describes the flaw as allowing a remote attacker to execute arbitrary code inside the browser sandbox through a crafted HTML page in Chrome versions before 149.0.7827.103. Why Memory Bugs Matter Out-of-bounds memory bugs are familiar territory. Software reaches beyond the memory region it was supposed to access, and things start breaking in ways developers never intended. Sometimes that means a crash. Sometimes memory corruption. Sometimes the conditions are needed tobuild the next stage of an exploit chain. The location matters as much as the bug class. V8 sits directly in the path of content delivered from websites and web applications. Every page load pushes data through code designed for performance, compatibility, and speed. Large codebases carrying that much complexity tend to attract researchers and attackers for the same reason. Google has not released exploit details, target information, or attribution. That's normal when patches are still rolling out. What defenders know right now is enough. The flaw exists in V8, exploitation has been observed, and one of the most widely deployed open-source components on the internet is carrying the issue. Why the V8 Engine Matters Beyond Chrome V8 is not just a Chrome component . It is the open-source JavaScript and WebAssembly engine used by Chromium, and Chromium sits underneath a long list of browsers and desktop applications. Chrome is the visible patch notice. The dependency graph is bigger than that. Where V8 Lives in Your Environment: Chromium-based browsers: Brave, Vivaldi, and Microsoft Edge . Electron applications: Desktop software that may not look like a browser at all—chat clients, editors, dashboards, wallets, internal tools, and build systems. That creates a practical problem for Linux admins. Updating Chrome does not automatically update every Chromium runtime sitting on a workstation. A Flatpak package may move on one schedule. A Snap package on another. A vendor-supplied AppImage may not get touched by normal package management at all. Quiet exposure. Open source makes this both better and harder. The code is visible, patched, reviewed, and reused at scale. It also means one vulnerable component can travel through a lot of projects before anyone in operations sees a clean inventory line for it. You can patch what you know. The embedded copy is where teams get burned. Active Exploitation Confirmed Google said an exploit for CVE-2026-11645 exists in thewild. CISA then added the flaw to KEV, a catalog used by defenders to prioritize vulnerabilities with evidence of real-world exploitation. That is enough to move this out of routine maintenance and into active triage. Confirmed exploitation is not the same as mass exploitation. Public reporting has not tied CVE-2026-11645 to a named threat actor, spyware vendor, or broad campaign. No clean attribution. No victim profile. No full exploit chain. That uncertainty should not slow patching. Early zero-day reporting is usually incomplete because vendors are trying to close the window before exploit details spread. Attackers already have enough to work with. Defenders do not need a full teardown before pushing patches. The safe read is simple. A V8 flaw was exploited before public patch adoption caught up. That is exactly the window attackers like, especially when the target component is reachable through normal web activity. Why Browser Engines Remain Prime Targets Browser engines take hostile input for a living. JavaScript, WebAssembly, media codecs, PDFs, images, extensions, authentication flows, cloud dashboards. All of it moves through code that has to be fast and forgiving while still holding a security boundary. V8 sits close to the hardest part of that problem. JIT compilation, garbage collection, object handling, optimization paths, and memory management all need to work under pressure. Patch Blind Spots Chrome may update fast, but bundled Chromium runtimes often do not. Check Electron apps, AppImages, Flatpaks, Snaps, and vendor tools that ship their own browser engine. A browser exploit does not need to deliver root access on the first move. A renderer foothold can expose session data, browser storage, tokens, extension behavior, or enough local context to support the next stage. Then the chain keeps moving. This is why browser bugs keep showing up in serious intrusion work. They start from normal user behavior: open a page, follow a link, load an ad, or visit acompromised site. No exposed service required. The Growing Pattern of Chrome Zero-Days in 2026 CVE-2026-11645 is reported as the fifth Chrome zero-day exploited in the wild during 2026. Earlier exploited Chrome flaws this year included CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, and CVE-2026-5281. The count is useful, but the pattern matters more. Attackers keep coming back to browsers because browsers sit where the credentials are: Cloud sessions Admin consoles Developer portals Password managers Internal apps SSO tokens A clean browser foothold can become the first step toward something larger. Linux systems are not outside that model. The post-exploitation path may look different than Windows, but the target value is still there: Developer keys, SSH configs, Git credentials, browser cookies, Kubernetes contexts, cloud CLI tokens. Plenty to steal before anyone talks about root. The mistake is treating browser patching like low-grade desktop hygiene. It belongs in endpoint defense, beside kernel patches, sudo rules, exposed daemons, and privilege escalation bugs. Different surface. Same incident queue. What Linux Users Should Do Now Patch Chrome and Chromium-based browsers first. Then verify the version actually changed. Reports list Chrome versions before 149.0.7827.103 as affected, with Linux update guidance pointing to patched Chrome builds in the 149.0.7827 line. A browser that downloaded an update but never restarted is still running old code. Check Chromium packages from the distribution next. Ubuntu, Debian, Fedora, RHEL, Arch, and downstream repositories do not always ship fixes at the same pace. That is not unusual. It does mean admins should verify package status instead of assuming the update has already landed. Look for Electron applications and bundled runtimes. This is where the open-source dependency issue gets operational. Slack-style clients, IDEs, database tools, internal dashboards, chat apps, and packaged desktop utilitiesmay carry Chromium components outside normal browser inventory. Managed fleets need version reporting, not user confirmation. Pull browser versions from endpoint management, package databases, EDR inventory, or configuration management. Force relaunches where needed. Long-running sessions are boring until they are not. Why This Matters for Open-Source Security The story is not just that Google patched Chrome. The larger issue is that attackers are exploiting a flaw in V8, a shared open-source component used across browsers, desktop applications, and development tooling. That is a different risk shape. Open-source reuse is how modern software gets built. It saves time, improves quality, and gives maintainers a common base to patch. It also concentrates exposure. One bug in the wrong component can touch products that do not share branding, vendors, package managers, or release cycles. V8 is one of those components. Most users never think about it, but they run it constantly—through browsers, through Electron, and through tools that wrap web interfaces inside desktop shells. The dependency is quiet until a zero-day makes it loud. For Linux admins, this pushes asset management down a layer. Knowing that Chrome is installed is not enough. Teams need to know where Chromium and V8 are embedded, which apps bundle their own runtime, and which packages depend on distribution maintainers for fixes. Not elegant work. Necessary work. Conclusion CVE-2026-11645 is an actively exploited V8 vulnerability, but the bigger lesson sits underneath the patch notice. Attackers targeted a browser engine. Defenders are left tracking a dependency that runs across browsers, Electron applications, developer tools, and countless Chromium-based projects. Patch the obvious browsers. Check Chromium packages. Find Electron apps and bundled runtimes. Then treat V8 the way security teams already treat OpenSSL, glibc, sudo, and the Linux kernel when active exploitation is confirmed. The software stack may lookdifferent. The risk model doesn't. Want more Linux security news, vulnerability analysis, and patch guidance delivered straight to your inbox? Subscribe to the LinuxSecurity Newsletter to stay ahead of emerging threats and critical updates. Related Reading Google Chrome Critical 0-Day CVE-2025-6558: Immediate Action Required Critical Security Update Released to Fix Chrome V8 Vulnerability Chrome Zero-Day Flaw Exposes Login Tokens on Linux Mitigating Chromium Security Flaws on Linux with Timely Updates . That's where this gets more interesting. Most coverage will focus on Chrome because that's where the. added, cve-2026-11645, known, exploited, vulnerabilities, catalog, google, confirmed. . MaK Ulac
Jun 10, 2026
•
Security Vulnerabilities
83
security advisorydependency managementLinux administrationUnderstanding Trojans in jQuery: Mitigation Strategies for Linux Admins
Security professionals and system administrators face growing cyber threats in today's digital environment, making defending systems increasingly challenging. A recent discovery by Phylum revealed a sophisticated large-scale operation targeting Node Package Manager (npm) , GitHub repositories, and Content Delivery Networks (CDNs) via trojanized versions of the jQuery JavaSecript library . . To help you secure your dependencies against these attacks, I’ll explain the attack mechanics and potential implications for Linux admins while outlining actions you can take to defend against such sophisticated threats. Understanding Trojanized jQuery Attacks JQuery is a fast, small, feature-rich JavaScript library used widely across web development projects for its simplicity and ease of use. Unfortunately, its widespread adoption makes it an attractive target for cybercriminals who disguise malicious code within legitimate-looking jQuery scripts to sneak it onto websites and applications for further malicious activities, including data exfiltration, deployment of additional malware , or establishing backdoors for access. The attack tactics involve threat actors publishing compromised versions of jQuery packages on npm or infiltrating existing packages and using CDNs for distribution across the web. With GitHub acting as a repository host and CDNs playing such an integral role in distribution across the internet, the scope and scale of this attack are alarming. Malicious code embedded within compromised scripts carefully designed to avoid detection can remain dormant until specific conditions are met or remotely activated by an attacker. What Are the Security Implications for Linux Admins? Linux admins overseeing web servers and development environments face major security threats fr om these attacks, especially from jQuery-powered apps whose widespread usage reassures a false sense of security. The trust placed in package repositories and CDNs creates an illusionary sense of safety forapplication owners and CDNs alike. The effects are profound, from data loss and theft to increased costs due to downtime for maintenance tasks on applications running on Linux systems to downgrades on services rendered vulnerable by these attacks. Repercussions include: Compromise of Web Applications: Malicious jQuery libraries may compromise web applications and expose sensitive user and corporate data. Threatened System Integrity: Compromised libraries may provide entry points for attackers looking to escalate privileges and compromise Linux systems hosting these applications. Damaged Trust: Relying on external resources such as npm, GitHub, and CDNs is often problematic because incidents like these erode trust between essential services and users, further complicating dependency management and code deployment strategies. Practical Defense Strategies Against Trojanized jQuery Attacks Linux administrators need a multi-layered defense strategy focused on vigilance, validation, and integrity to counter current and potential future threats. This strategy should include: Integrity Checks and Code Review: Employ integrity checks on imported libraries and conduct thorough code reviews for critical dependencies like jQuery. This will provide early warning of compromised packages. Secure Dependency Management: Maintain strict control over package sources. Whenever possible, always rely on verified and secure sources when selecting dependencies. Tools like npm audit can assist in identifying known vulnerabilities in packages, and private registries may help maintain approved packages that have already been verified and tested. Continuous Monitoring and Alerting: Implement continuous monitoring for web applications and servers and alarm mechanisms that detect unusual activities, such as outbound connections, that could indicate data exfiltration attempts. Education and Awareness: Educate development teams on the risks associated with external dependencies.Foster a culture that prioritizes scrutinizing third-party code. Disaster Recovery and Response Planning: Establish an incident response and disaster recovery plan. Should an attack compromise services or data, having access to secure backups to restore services or data quickly is critical. Contribute to Security Communities: Join security communities and platforms. Sharing information about potential threats can enable others to bolster their defenses early, contributing to a more robust collective security posture. Our Final Thoughts on Securing Your Dependencies Against Trojanized jQuery Attacks The discovery of trojanized jQuery attacks illustrates the ever-evolving landscape of cyber threats, underscoring the importance of constant vigilance for Linux administrators. In addition to keeping systems and networks secure, their responsibility also encompasses protecting dependencies and third-party code as part of an overall proactive security approach. By employing rigorous security practices, promoting awareness campaigns, and encouraging community collaboration efforts, it is possible to reduce the risk of such sophisticated attacks. . Grasp the methods to safeguard your libraries against malicious jQuery intrusions with essential tactics and knowledge tailored for Linux system administrators.. Trojanized jQuery, Cyber Threat Strategies, Linux Dependency Security. . Brittany Day
Jul 10, 2024
•
Hacks/Cracks
209
cybersecuritydependency managementsecurity challengesUnderstanding Dependency Security Risks in Open-Source Projects
Open-source software and hardware projects are becoming increasingly popular, but their complexity and large supply chains bring new challenges for engineers in terms of cybersecurity. With the growing threat of cyber attacks, it's important to understand the security issues posed by dependencies and how the future of open-source projects can mitigate these risks. . PyTorch, a popular open-source platform for Python, is just one example of the potential benefits and drawbacks of open-source projects at scale. Open-source projects have the potential to provide innovative solutions but also come with risks that must be carefully considered. As technology continues to progress, open-source solutions are becoming increasingly dominant. Agricultural industries that have historically been tied to manufacture-specific solutions that lock out individual developers are being challenged, software companies are shifting their focus to open-source solutions in an attempt to demonstrate security and privacy, and even large businesses (such as IBM) who have garnered success on closed-source solutions are now even joining in the open-source movement. But why exactly has the open-source movement proven to be a modest success? Many would be quick to suggest that the free nature of open-source hardware makes it popular with those looking to save money, and there is undoubtedly some truth in this. However, considering that the vast majority of people continue to use paid solutions (such as MS Office over LibreOffice) provides counter-evidence to this motive. . Engineers must understand the significance of supply chain vulnerabilities in open-source software and take measures to enhance security.. Open-Source Projects, Security Risks, Dependency Management. . Brittany Day
Feb 22, 2023
•
Security Trends
79
dependency managementvulnerability reportlibrary securityGitHub Reports Over Four Million Flaws In JavaScript And Ruby Libraries
GitHub says its security scan for old vulnerabilities in JavaScript and Ruby libraries has turned up over four million bugs and sparked a major clean-up by project owners.. The massive bug find total was reached within a month of the initiative's launch in November when GitHub began scanning for known vulnerabilities in certain popular open-source libraries and notifying project owners that they should be using an updated version. . GitHub identified more than four million vulnerabilities in Java and Python packages, leading to necessary rectifications by developers.. Dependency Management, Library Security, Code Flaws, Security Issues. . LinuxSecurity.com Team
Mar 22, 2018
•
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!