Explore top 10 tips to secure your open-source projects now. Read More

×
Alerts This Week
Warning Icon 1 606
Alerts This Week
Warning Icon 1 606

Stay Ahead With Linux Security News

Filter%20icon Refine news
X Clear Filters
X Clear Filters
View More

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?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/157-should-linux-servers-automatically-install-security-updates?task=poll.vote&format=json
157
radio
0
[{"id":506,"title":"Yes \u2014 critical security patches should install automatically.","votes":0,"type":"x","order":1,"pct":0,"resources":[]},{"id":507,"title":"No \u2014 every update should be tested before deployment.","votes":0,"type":"x","order":2,"pct":0,"resources":[]},{"id":508,"title":"Only critical vulnerabilities should auto-install.","votes":0,"type":"x","order":3,"pct":0,"resources":[]},{"id":509,"title":"I patch when Reddit starts panicking.","votes":0,"type":"x","order":4,"pct":0,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200
Loading...

Explore Latest Linux Security news

We found 111 articles for you...
210

GhostLock Exposes an Uncomfortable Truth About Open Source Security

When researchers announced GhostLock, many people focused on the exploit. What stood out to me wasn't just what the vulnerability could do, but how long it had remained hidden. The flaw had lived in the Linux kernel for roughly 15 years before it was publicly identified by researchers. That means the flaw survived hundreds of kernel releases and years of upstream development before it was publicly documented. It raises an uncomfortable question about one of open source's oldest assumptions. One of the enduring arguments in favor of open source is that transparency improves security. If anyone can inspect the code, vulnerabilities should be easier to discover and fix. GhostLock doesn't disprove that idea, but it does force us to ask how well it scales when the Linux kernel contains tens of millions of lines of code. . Why the GhostLock Linux Kernel Vulnerability Is Different The Linux kernel vulnerability CVE-2026-43499 , or "GhostLock," was identified by Nebula Security Research in their ionstack analysis . Because the flaw originated in upstream code, it potentially affected numerous Linux distributions that incorporated the vulnerable kernel code until it was patched in the upstream Linux kernel in April 2026 . GhostLock stood out for several reasons: Legacy Impact: The bug existed since kernel 2.6.39, illustrating that even mature, stable code can harbor deep-seated flaws for years. High-Stakes Exploitation: Researchers demonstrated local privilege escalation to root and a container escape, making the vulnerability particularly significant for cloud and containerized environments. Professional Interest: The vulnerability was identified through Google’s kernelCTF program, earning a $92,337 bounty. The payout also reflects how difficult kernel memory-safety bugs have become to identify, even for experienced researchers. The real question isn't whether Linux is secure. It is whether the traditional "many eyes" argument still reflects how securityactually works in a codebase of this magnitude. When "Many Eyes" Meets Modern Reality One of the best-known ideas in open source security is the "many eyes" principle , often associated with Eric S. Raymond's Linus's Law : "Given enough eyeballs, all bugs are shallow." The idea is straightforward. Because the source code is publicly available, developers, researchers, and users can inspect it, increasing the likelihood that vulnerabilities will be identified and fixed more quickly than they might be in closed-source software. In practice, however, transparency makes review possible; it does not guarantee that every line of code will actually be examined by someone with the time, expertise, or reason to look at it. That distinction becomes increasingly important in a project as large and complex as the Linux kernel, where millions of lines of code are maintained by thousands of contributors across hundreds of subsystems. Several practical realities shape how security review works today: The Scale Problem: The Linux kernel receives thousands of changes during every development cycle. No single human can review the entire codebase. Subsystem Silos: Most reviewers specialize in one subsystem. If a vulnerability exists in an obscure or legacy corner of the kernel, it may sit outside the field of view of those most qualified to audit it. The "Old Code" Reality: Legacy code often changes less frequently than actively developed subsystems. That stability is valuable, but it can also mean certain execution paths receive less ongoing scrutiny than newer code undergoing active development. How Linux Kernel Security Research Has Changed GhostLock wasn't discovered because someone finally decided to manually audit that specific line of code. It was discovered because the methodology of Linux security research has fundamentally changed. Historically, kernel security depended largely on expert review and targeted testing. Today, that work is increasingly complemented bycoverage-guided fuzzing, sanitizers, and large-scale automated testing. Tools like syzkaller/syzbot and KASAN act as force multipliers, systematically probing kernel state transitions that would be impossible for a human to track mentally. Automated testing now routinely finds combinations of events that humans would never naturally think to test. Programs like kernelCTF have further professionalized this research, bringing top-tier talent to bear on the kernel’s deepest subsystems. GhostLock is a testament to the fact that modern security is no longer just about "eyes"—it’s about the sophistication of the tooling and the bounty programs that reward deep, specialized research. The Reboot Gap For administrators, GhostLock is a stark reminder of the "reboot gap." Most organizations have well-defined maintenance windows for web servers, databases, and application software. Kernel updates are different because they frequently require reboots, coordinated maintenance windows, or live-patching infrastructure that many organizations simply don't have. It's not uncommon for organizations to schedule kernel updates quarterly while patching user-space software weekly. GhostLock shows why that gap deserves another look. In a containerized world, many assume the host is "just plumbing." A container escape vulnerability proves that the host kernel is the single point of failure for everything running on top of it. Local privilege escalation vulnerabilities become especially important in these environments because the kernel remains the shared trust boundary. When a vulnerability allows for container escape, the kernel is effectively an application-level concern and must be treated with the same urgency as a critical web server flaw. Security Priorities Have Changed GhostLock also highlights how Linux kernel security priorities have shifted over the last decade. Memory safety is now one of the community's primary areas of investment. Maintainers continue to strengthen the kernel through hardeningfeatures, sanitizers, memory-safety improvements, Rust for new kernel components, and continuous automated testing. Rather than suggesting the ecosystem is stagnant, GhostLock illustrates why those investments have become increasingly important as the kernel continues to grow in size and complexity. GhostLock also demonstrates one of open source's greatest strengths. Once the vulnerability was publicly identified, researchers could independently analyze the root cause, distributions could verify the fix, and administrators had complete visibility into the patch itself. That level of transparency is difficult to match in proprietary software, where the source code and development process are generally not available for independent review. What GhostLock Says About the Future of Open Source Security If GhostLock could stay under the radar for 15 years, it makes you wonder: how many other bugs are still waiting to be found? We don't know for sure. But GhostLock also proves that the ecosystem for finding those bugs is much tougher today than it was ten years ago. Between continuous fuzzing, memory sanitizers, coordinated disclosure, and mature bug bounty programs, we are finding whole classes of vulnerabilities that would have been totally invisible in the past. GhostLock doesn't prove that open source security has failed; it proves that transparency alone isn't enough. The Linux kernel has outgrown the point where it can rely solely on volunteer code review to find every critical flaw. Today's security depends just as much on dedicated security teams, automated testing, and bounty programs that reward that deep, specialized research. This reminds us that those strengths still matter, but the scale of modern projects requires more than just visibility. Today's Linux kernel is secured not only by developers reviewing code, but also by continuous automated testing, specialized security researchers, and organizations willing to invest in uncovering vulnerabilities that traditional review alone maynever find. . GhostLock reveals the limitations of open source security, emphasizing the need for advanced tools and methodologies in Linux kernel maintenance.. Linux Kernel GhostLock, Open Source Security Flaws, Automated Security Testing. . MaK Ulac

Calendar%202 Jul 14, 2026 User Avatar MaK Ulac Security Vulnerabilities
209

Trojanized GitHub PoC Repositories Deliver ChocoPoC Malware to Security Researchers

GitHub has become the latest delivery mechanism for malware aimed at security researchers. . YesWeHack and Sekoia identified a campaign that hid a Python-based remote access trojan (RAT) called ChocoPoC inside repositories presented as proof-of-concept exploits for recently disclosed vulnerabilities. Someone looking for a working exploit could clone the project, execute the code, and unknowingly launch a second payload that established remote access. Nothing about the campaign specifically targets Linux. The workflow does. Linux remains a common platform for exploit development, reverse engineering, malware analysis, and penetration testing, so it's also a common place to download and test public PoCs. That makes research workstations an appealing target when attackers decide the easiest way to reach an organization is through the people analyzing its vulnerabilities. How Trojanized GitHub PoC Repositories Delivered ChocoPoC Malware The campaign centers on the deployment of trojanized repositories that mimic legitimate exploit research. When a researcher clones and executes the code to validate a vulnerability, the malicious payload executes alongside the advertised exploit. Once the malicious script is triggered, it can establish remote access, allowing attackers to execute commands remotely on the compromised system. The repositories were designed to resemble legitimate security research projects, allowing the embedded malicious code to blend into routine research workflows. The Campaign Highlights a Common Workflow Risk The campaign highlights a standard practice among vulnerability researchers: downloading public proof-of-concept code to validate newly disclosed vulnerabilities. Linux is widely used for these tasks because of its native development tools, scripting ecosystem, and established penetration-testing distributions. Because researchers frequently execute public exploit code during vulnerability validation, Linux research environments can become attractive targets forcampaigns that abuse trusted repositories. Trust Abuse in Open Source Research Workflows ChocoPoC isn't remarkable because of the malware itself. Security researchers have seen Python backdoors before. What stands out is where it was hidden. Public proof-of-concept repositories have become a routine part of vulnerability research, and attackers are now using that expectation against the people who depend on them. This incident is part of a wider pattern of trust abuse on public code-sharing platforms. Academic research presented at USENIX WOOT 2025 in the paper SecurePoC: A Helping Hand to Identify Malicious CVE Proof of Concept Exploits in GitHub demonstrates that malicious and misleading proof-of-concept repositories have become a significant enough problem to warrant dedicated detection research ( USENIX WOOT 2025, el-Yadmani et al. ; Zenodo Artifact ). The researchers identified numerous cloned and modified repositories containing malicious additions, highlighting how public code-sharing platforms have become an attractive distribution channel for malicious proof-of-concept repositories. Why Linux Users Should Pay Attention ChocoPoC is not a Linux-specific threat. The malicious repositories described by YesWeHack and Sekoia could affect researchers working on Windows, macOS, or Linux. What makes the campaign relevant to Linux users is how many security professionals perform vulnerability research. Linux is widely used for penetration testing, exploit development, reverse engineering, and malware analysis. As a result, Linux workstations, virtual machines, and lab environments are common places to clone and execute public proof-of-concept code. The campaign exploits that research workflow, not the operating system itself. For Linux users who regularly test exploits from public repositories, it serves as a reminder that the repository deserves the same level of scrutiny as the vulnerability being investigated. Reducing Risk When Testing Public Exploit Code As public exploitrepositories become a more frequent source of opportunistic attacks, the security of the researcher’s workstation must be prioritized. Researchers should begin by performing a thorough source inspection, reviewing PoC code for obfuscated commands, unexpected network calls, or hardcoded IPs before any execution. Beyond manual review, consider using disposable virtual machines or isolated container environments when validating exploit code to ensure that malicious payloads cannot reach your host filesystem or network. For those working in Windows-based environments, Microsoft has recently launched a public preview of WSL Containers (WSLC), which allows for the creation of native, isolated Linux container environments ( Microsoft Dev Blog ; Microsoft Learn ; WSL API Reference ; Phoronix ). Furthermore, researchers should perform due diligence by assessing repository reputation, commit history, and the author's track record rather than relying on the code’s presence alone. Finally, monitoring outbound network connections during the testing phase is a practical way to identify and block any unexpected traffic generated by a script. Conclusion ChocoPoC serves as a critical reminder that the security industry’s own workflows are now firmly in the crosshairs of threat actors. As public exploit repositories continue to grow in volume, the ability to validate the integrity of the code we download is becoming just as essential as the ability to validate the vulnerabilities the code aims to address. Security professionals must treat unverified PoC code with the same scrutiny as any other untrusted software. . ChocoPoC malware highlights a serious risk in GitHub PoC repositories, impacting security researchers across platforms.. malware delivery techniques, security researcher risks, public code repositories, ChocoPoC attacks. . MaK Ulac

Calendar%202 Jul 02, 2026 User Avatar MaK Ulac Security Trends
210

Open-Source Screen Recorders: Documenting Malware and Exploits

For information security researchers, there is a continuous effort to improve methods of detecting and documenting vulnerabilities. One of the main tools in that direction is open-source screen recorders . Screen recorders simplify recording the vulnerability exploitation process, tracking malware activity, and publishing Proof of Concepts (PoCs) to the world, which is used to improve the overall level of cybersecurity . . Applications of Screen Recorders for Security Research Currently, several screen recording programs are available. When you choose a proper screen recorder , consider some essential aspects, which we'll list below. However, before doing that, let's examine the security research process in more detail. Documenting Vulnerabilities and Exploits Screen recording applications allow you to create a step-by-step video report that captures all the steps of the process in real-time. For example, when dealing with vulnerabilities such as buffer overflow, you can document the preparation of the test environment, the setup of the virtual machine, and the exploitation phase itself. The high quality of the recording and the ability to add annotations allow viewers to not only watch what is happening on the screen but also understand why the researcher is performing each action. Recording Malware Behavior During Analysis If you execute a suspicious executable within a sandbox, you can monitor all the changes, from new processes being visible to modifications in system files and registry settings. Not only can you document the behavior of Linux backdoor malware , but also comparative analysis of attacks . Synchronizing the recording with analysis tools such as Wireshark or Process Monitor also enables you to correlate visual data with technical data. Capturing and Sharing Proof of Concepts (PoCs) with the Community Creating and demonstrating Proof of Concepts (PoCs) using screen recording software allows you to showcase a vulnerability in action, demonstrate potentialrisks, and suggest ways to mitigate them. But first, you need to: Select an appropriate open-source screen recorder: OBS Studio, SimpleScreenRecorder, Kazam, or VLC Media Player; Configure settings: Adjust the recording settings to ensure high-quality captures (all screen/specific windows, framerate, fps, etc.); Set up a test environment: Ensure you have an isolated and controlled environment for documenting vulnerabilities and exploits or recording malware behavior. After editing the video material (trimming unnecessary fragments and adding comments), the PoC can be published on specialized platforms such as YouTube or Vimeo or shared in professional forums and communities. Comparative Analysis of Popular Open-Source Screen Recorders for Researchers When selecting an instrument, consider the specifics of your research and the operating system's functionality. These are the key features of some of the most popular software products: OBS Studio SimpleScreenRecorder XVidCap Supported OS Windows , macOS , Linux Linux Linux (X Window System) Interface Complex but multifunctional A simple but little customization Minimalistic but outdated System load High Low Low Main advantages Advanced scene handling, annotation support (via plugins), multiple audio/video sources; great for demonstrating complex exploits and vulnerabilities High-quality recording, flexible output settings; simplicity allows you to stay focused on settings during testing Basic recording features: suitable for quick demos but does not support annotation and multithreaded sources Output formats Various formats, including MP4, MKV, FLV, and others MKV, MP4, WebM, OGG Mostly AVI (limited format support) Techniques and Tips for EffectiveScreen Recording in Research To make screen recording as effective as possible, follow these rules: #1. Optimize Recording Settings Select high resolution and high frame rate to be able to capture detailed information, which is particularly crucial when showing intricate processes. It is also crucial to think about video encoding parameters that depend on the eventual audience and platform where the video will be published. For instance, MP4 is best for streaming online and publishing on YouTube, while MKV could be used for lab usage internally. #2. Organize and Label Your Recordings Organize recordings by project, date, and research type. Instead of using generic names such as "recording1," use descriptive names that reflect the nature of the recording, e.g., "buffer_overflow_demo_2026-07-21." Also, remember to add text annotations or graphics overlays. This makes the content more understandable and makes it easier to remember research details in the long run. #3. Ensure Data Privacy and Security When sharing recordings with colleagues, make sure the videos do not record sensitive data such as IP addresses, logins, passwords, or other identifying data. Encrypt and use protection from access when sharing recordings in closed networks, utilizing industry-standard encryption methods such as AES-256 or TLS to secure transmissions. Additionally, role-based access control (RBAC) and multi-factor authentication (MFA) should be implemented to ensure that only authorized personnel can view sensitive recordings. Always adhere to legal norms to prevent violating laws or corporate security guidelines. Bottom Line The use of open-source screen recording software opens up new opportunities for cybersecurity researchers . Ultimately, integrating visual documentation into security procedures is not just a convenient luxury but an actual necessity for modern researchers. Thus, every researcher can contribute to creating a safer digital world. . Delve into key open-source screencapturing tools vital for cybersecurity research, chronicling malware analysis, and disseminating knowledge.. screen recording software, malware documentation, security tools. . MaK Ulac

Calendar%202 Feb 27, 2025 User Avatar MaK Ulac Security Vulnerabilities
83

Discover Supershell: Open Source Botnet for SSH Access and Docker

The digital age offers opportunities but also increases the importance of cybersecurity as threats grow in complexity and sophistication, making preparedness a top priority. . Open-source botnets are now a hot topic in cybersecurity due to their accessibility and rapid adaptability against security measures. Cybersecurity researchers at SOCRadar recently reported about an open-source botnet, Supershell, that obtains SSH shell access. Supershell is an open-source botnet that offers rapid one-click Docker-based deployment with integrated reverse SSH for team collaboration and interactive control. The link for this article located at CyberSecurity News is no longer available. . Discover Supershell, a collaborative open-source botnet featuring SSH connectivity and Docker-based deployment designed for seamless team interaction.. open source botnet, SSH access, Docker deployment. . LinuxSecurity.com Team

Calendar%202 Oct 06, 2023 User Avatar LinuxSecurity.com Team Hacks/Cracks
78

5 Essential Kali Linux Tools For Penetration Testing and Security Research

Kali Linux is a specialized Linux distribution developed by Offensive Security, designed for experienced Linux users who need a customized platform for penetration testing. . Kali Linux also comes with several hundred specialized tools for carrying out penetration testing, security research, computer forensics, reverse engineering, vulnerability management, and red team testing. Here are 5 you should learn how to use. . Delve into vital Kali Linux utilities for security assessments and ethical hacking to sharpen your proficiency and effectiveness.. Kali Linux Tools, Penetration Testing Skills, Security Research Techniques. . LinuxSecurity.com Team

Calendar%202 Nov 26, 2022 User Avatar LinuxSecurity.com Team Vendors/Products
83

LockBit Code Exposed: Ransomware Breach Impacting Security Research

Given that two people—or maybe the same person—leaked the LockBit 3.0 compiler on Twitter, it appears that LockBit has had a breach. . A newly registered Twitter account by the name of “Ali Qushji” claims that their team broke into LockBits’ servers and discovered a compiler of the LockBit 3.0 ransomware encryptor, according to security researcher 3xp0rt. VX-Underground reported that they were approached on September 10th by a person going by the handle “protonleaks,” who also supplied a copy of the builder, after security expert 3xp0rt tweeted about the hacked LockBit 3.0 builder. The public face of the LockBit business, LockBitSupp, asserts that they were not hacked and that a frustrated developer instead exposed the secret ransomware compiler. . A fresh Twitter profile asserts that a group hacked into the servers of LockBit, exposing their ransomware programming. Continue for details.. LockBit Code Leak,Cybersecurity Research,Ransomware Threats. . LinuxSecurity.com Team

Calendar%202 Sep 30, 2022 User Avatar LinuxSecurity.com Team Hacks/Cracks
83

Chaos Malware Alert: Cross-Platform Threat to Linux and Windows Devices

Researchers have revealed a never-before-seen piece of cross-platform malware that has infected a wide range of Linux and Windows devices, including small office routers, FreeBSD boxes, and large enterprise servers. . Black Lotus Labs, the research arm of security firm Lumen, is calling the malware Chaos, a word that repeatedly appears in function names, certificates, and file names it uses. Chaos emerged no later than April 16, when the first cluster of control servers went live in the wild. From June through mid-July, researchers found hundreds of unique IP addresses representing compromised Chaos devices. Staging servers used to infect new devices have mushroomed in recent months, growing from 39 in May to 93 in August. As of Tuesday, the number reached 111. Black Lotus has observed interactions with these staging servers from both embedded Linux devices as well as enterprise servers, including one in Europe that was hosting an instance of GitLab. There are more than 100 unique samples in the wild. . Dark Rose Labs uncovers Phantom malware compromising both Linux and Windows systems, affecting home gateways and corporate servers.. Chaos Malware, Cross-Platform Threat, Linux Device Security, Windows Device Infection. . LinuxSecurity.com Team

Calendar%202 Sep 30, 2022 User Avatar LinuxSecurity.com Team Hacks/Cracks
210

Dirty Cred Exploit Exposed at Black Hat Conference's Insights

A new Linux kernel exploitation called Dirty Cred was revealed at last week’s Black Hat security conference. . Zhenpeng Lin, a PhD student, and a team of researchers worked on an alternative approach to the infamous Dirty Pipe vulnerability that affected Linux kernel versions 8 and later. Dity Pipe is a major flaw that allows attackers to elevate least-privileged accounts to the maximum level (root) by exploiting the way the kernel uses pipes to pass data. Attackers can use it to modify system files and inject arbitrary code that gets executed as root on vulnerable machines. . Investigating the Dirty Cred vulnerability showcased at Black Hat, researchers shed light on its ramifications for Linux kernel security.. Linux Exploit, Dirty Cred, Kernel Security, Black Hat Insights. . Brittany Day

Calendar%202 Aug 18, 2022 User Avatar Brittany Day Security Vulnerabilities
News Add Esm H340

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?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/157-should-linux-servers-automatically-install-security-updates?task=poll.vote&format=json
157
radio
0
[{"id":506,"title":"Yes \u2014 critical security patches should install automatically.","votes":0,"type":"x","order":1,"pct":0,"resources":[]},{"id":507,"title":"No \u2014 every update should be tested before deployment.","votes":0,"type":"x","order":2,"pct":0,"resources":[]},{"id":508,"title":"Only critical vulnerabilities should auto-install.","votes":0,"type":"x","order":3,"pct":0,"resources":[]},{"id":509,"title":"I patch when Reddit starts panicking.","votes":0,"type":"x","order":4,"pct":0,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200