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

×
Alerts This Week
Warning Icon 1 519
Alerts This Week
Warning Icon 1 519

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

Is continuous patching actually viable?

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/156-is-continuous-patching-actually-viable?task=poll.vote&format=json
156
radio
0
[{"id":503,"title":"Delayed updates invite catastrophic breaches.","votes":1,"type":"x","order":1,"pct":50,"resources":[]},{"id":504,"title":"Automated fixes break production environments.","votes":1,"type":"x","order":2,"pct":50,"resources":[]},{"id":505,"title":"Manual approvals cannot keep pace.","votes":0,"type":"x","order":3,"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 13 articles for you...
210

Microsoft Blocks Open Source Dev Accounts, Disrupting Security Pipelines

When developer accounts are blocked, the impact is felt far beyond a single login screen. For many projects, these accounts are the access points for the entire delivery pipeline. If a maintainer is locked out, the flow of security updates stops. In a world where hackers move fast, a stalled pipeline is a massive vulnerability. . Recent account suspensions at Microsoft have affected several major open-source projects. While these events are often seen as small administrative errors, they expose a structural risk: our decentralized, open-source world runs on centralized pipes. When those pipes are cut, the fixes we rely on can no longer reach the systems that need them. Open-Source Dependency on Centralized Infrastructure We often assume open source is independent because the code is public. However, the machinery used to ship that code often relies on services controlled by a single vendor. The Integrity Chain Bottleneck Source: Applied Sciences, MDPI. "A Cross-Chain Solution for Supply Chain Traceability." To maintain software integrity, users need to know that the code they download hasn't been tampered with. This relies on code signing to maintain a verifiable chain of custody for every update. Many cross-platform projects route their release validation through infrastructure linked to Microsoft systems. If a maintainer is locked out of their Microsoft Partner Center account, that chain is broken. They cannot verify new builds, and the package managers you trust cannot receive "official" updates. The Release Pipeline Modern software delivery isn’t just a file transfer; it’s a high-speed pipeline. Code is written, built by automated systems, and distributed to mirrors. Many projects route this flow through GitHub Actions . If the account at the start of that chain is suspended, the machinery snaps. The code might be ready, but it is effectively trapped on a developer’s local machine with no path to production. The Vulnerability Disclosure Cycle Thisinterruption is most dangerous during the vulnerability disclosure process. When a critical bug is found, the fix must move through the pipeline instantly to minimize exposure. If the maintainer’s access is pulled, the patch is paralyzed. This creates a "false sense of security" where the community knows a fix exists, but it cannot be deployed to protected systems. Operational Risks of Pipeline Interruption When a maintainer loses access, the failure isn't a loud crash. It is a quiet drift away from a secure state. Exposure Windows and Version Drift: Attackers scan for bugs the moment they are disclosed. Every hour a maintainer is locked out is an hour that the exploit window stays open. This leads to version drift, where your defense tools are tuned for a version of a package that is now known to be broken. The Synchronization Problem: Linux depends on a healthy software supply chain to ensure that libraries and dependencies are updated in sync. If one key maintainer is blocked, their project stalls while everything around it keeps moving. This creates a gap that hackers use to find a weak link in your stack. Implicit Trust Model Failures: We trust signed packages because we trust the maintainer’s identity. If maintainers are forced to use unsafe workarounds or unsigned builds during a lockout, the entire security model of the repository begins to crumble. The Decentralization Paradox in Modern Security Linux is decentralized by design, which is its greatest strength. However, the delivery of that code has become highly centralized. We rely on a small number of hosting providers to keep the global software supply chain moving. When a provider like Microsoft or GitHub suspends accounts, the "coordination without authority" model of open source is tested. There is no central vendor to provide an SLA or a backup path. This highlights a quiet reliance on centralized services inside a system that is marketed as being independent. If the delivery mechanism is a singlepoint of failure, the "decentralized" nature of the code doesn't actually protect you from a shutdown. Exploit Surface of Administrative Lockouts Imagine a critical vulnerability is found in a core system utility. The developer writes a fix in an hour and prepares to push it to the main repository. But during the upload, they find their account has been suspended for an automated "identity verification" check. The developer cannot sign the new version. They cannot trigger the build system. Meanwhile, a public CVE (Common Vulnerabilities and Exposures) has already notified the world that the bug exists. The lockout itself becomes the security hole. The fix is ready, but because of a centralized administrative error, the enterprise infrastructure and critical systems that run our businesses stay vulnerable to an active threat. Identifying Supply Chain Gaps Because these failures are silent, security teams must look for the "absence" of activity rather than just error messages. Audit Upstream Activity: Watch for a mismatch between code commits and actual releases. If a maintainer is active on GitHub but the package version hasn't changed, the pipeline might be stuck. Verify Repository Integrity: Monitor for broken signing chains or unsigned packages in your mirrors. A sudden change in how a project signs its code is often a sign of an upstream access crisis. Map Dependency Concentration: Use OpenSSF tools to understand which of your core libraries rely on a single build path. If those paths route through one vendor, you have a centralized risk that needs a backup plan. A Fix That Can’t Ship Is No Fix At All The recent account suspensions are a reminder that your security posture must account for the delivery pipes, not just the code. Open source is a chain of trust. If the pipeline stops, the speed at which we write patches doesn't matter. A fix that is trapped behind a login screen is a fix that doesn't exist. To protect the ecosystem, we have to ensure thatour decentralized software isn't entirely dependent on centralized keys that can be turned off without warning. . Recent account suspensions at Microsoft have affected several major open-source projects. While thes. developer, accounts, blocked, impact, beyond, single, login, screen. . MaK Ulac

Calendar%202 Apr 09, 2026 User Avatar MaK Ulac Security Vulnerabilities
78

Windows Dual-Boot: Microsoft Update Causes Critical Boot Failures

For Linux admins, managing dual-boot systems often feels like juggling two worlds that occasionally collide. Imagine you're balancing between your Linux setup and Windows environment when, suddenly, an update throws a wrench in the works. This is exactly what happened with Microsoft's August 2024 security updates , which led to Linux boot failures on systems with Secure Boot enabled. It felt like taming a beast that shouldn't be there in the first place, right? . This headache didn't get sorted until May 2025, leaving us scratching our heads and dealing with downtime we couldn't afford. The frustration was real, and it tested our patience and problem-solving skills. What's important is understanding what went down and extracting the key takeaways. As annoying as it was, this incident carries valuable lessons for anyone putting Linux and Windows side-by-side. So, let’s dive in and dissect what happened, piece by piece. The Root of the Problem: Secure Boot and Microsoft's Updates If you're running a dual-boot system, you already know how intricate Secure Boot can get. It’s intended to improve system security by restricting what code the machine runs during the startup process—a concept designed to prevent loads of malicious bootloaders or unauthorized operating systems. Sounds great, right? There's a problem when systems like this straddle opposing ecosystems like Windows and Linux. Every change to this boot process can potentially ripple across both sides. That happened when Microsoft introduced updates to address vulnerabilities in GRUB2, a popular Linux bootloader integral to Secure Boot. Specifically, the update targeted the exploitation defined by CVE-2022-2601 , which allowed Secure Boot bypasses. While their aim was securing the Windows ecosystem by blocking certain UEFI shim loaders reliant on outdated SBAT versions (Secure Boot Advanced Targeting), the change inadvertently took out these loaders in affected dual-boot setups—even folks who weren’t using the vulnerableversions. Linux systems simply refused to boot. Instead, administrators were greeted by cryptic errors like: "Something has gone seriously wrong SBAT self-check failed Security Policy Violation.” Imagine discovering this after what seemed like a routine update to your Windows partition. Missteps in Detection—and the Domino Effect What makes this issue particularly frustrating for Linux admins is that Microsoft had anticipated dual-boot systems and claimed that these updates wouldn’t be applied there. The idea was straightforward: if Microsoft detected another OS coexisting on Secure Boot-enabled systems, they wouldn’t push the updates blocking vulnerable shim versions. Simple enough, right? But that detection mechanism failed. Some dual-boot systems—especially those with custom configurations or specific distribution setups—slipped through Microsoft’s detection process, and the updates were pushed anyway. This failure led to Linux bootloaders being flagged and blocked by Secure Boot policies, completely locking Linux out of systems where it relied on those mechanisms. For some admins, this felt like a betrayal of trust. The challenge of dual-boot systems is already compounded by the need to manage dependencies between operating systems. To see an assumed safety net fail caused additional chaos, especially on production systems or machines where restoring boot functionality isn’t immediate. Administrators were left with broken workflows and no clear explanation. How Was It Fixed? The fix for this issue wasn’t immediate. Microsoft finally released updated patches as part of its May 2025 Patch Tuesday cycle, resolving the issue for affected systems. But that nine-month gap between discovery and solution wasn’t a trivial wait for administrators charged with maintaining these machines. Many needed answers yesterday, desperate for a roadmap to keep systems functional until Microsoft got it right. When the fix rolled out, it came through updated Secure Boot configurations thathandled the SBAT blocking mechanism more gracefully. Installing the latest Windows updates from May 2025 ensured that Linux bootloaders would no longer be erroneously flagged and blocked. That’s good news, but the pain of waiting exposed a significant difference between how the Windows ecosystem handles problems and how Linux communities might react to something like this. Open-source projects are often praised for their rapid response cycles, where users frequently receive regular updates or fixes to even small issues. Nine months would be an eternity there. Workarounds in the Interim Microsoft offered a workaround during the gap before the proper fix rolled out. If this felt clumsy to Linux admins, there’s a good reason—it involved manually deleting the problematic SBAT updates from the affected systems and running registry commands to opt out of future installations of the offending updates. Diving into the registry might not raise an eyebrow for Windows users struggling with Secure Boot quirks. However, many likely viewed this approach as cumbersome, especially for Linux administrators accustomed to editable configuration files. Editing the registry feels like a step back compared to Linux's straightforward practices for modifying bootloaders or system files. The command itself, aimed at stopping the updates, looked like this: reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD It felt counterintuitive—Windows itself was blocking secure bootloaders used by Linux, and now Linux admins had to disable part of Secure Boot to get their systems operational again. Practical wisdom prevailed, and admins did their best to keep production systems running. But this workaround reinforced the delicate dance of dual-booting. Not all admins are equally comfortable living inside the registry, and this resolution wasn’t ideal for some. The Complexity of Cross-Platform Management This issue highlights what Linux administrators have longunderstood but likely feel anew—dual-boot systems aren’t inherently simple, especially when two distinct ecosystems try to operate under one Secure Boot umbrella. Windows updates don’t happen in isolation. Once Secure Boot policies shift for one OS, they have consequences for the other. Microsoft's misstep in detecting dual-boot systems shows how easily assumptions can fail as ecosystems grow more connected. Linux admins were reminded of one important truth: managing dual systems means knowing your side and the other's updates, implementations, and philosophies. In hindsight, the solution was technically straightforward. Microsoft needed to fix how their updates interacted with UEFI shim loaders in Linux environments. However, the ripple effects exposed broader structural challenges. If one vendor makes an error in bootloader handling, another ecosystem suffers—not because of faults in their code but because of how trust and policies are imposed at the firmware level. For Linux administrators, this episode suggests a need for extra vigilance when systems update policies change. Even Linux distributions held hostage by Secure Boot constraints can fall victim to sudden technical shifts like this. Lessons for Linux Admins Moving Forward There’s a lot to take away from this incident. First, never let your guard down when managing dual-boot systems. It’s not just about keeping Windows security updates in check or making sure your Linux distribution is patched —it’s about anticipating how updates might collide in unforeseen ways. Secure Boot, while deeply valuable for protecting the integrity of modern systems, is still a complicated feature with varying levels of support across Linux distributions. Communication gaps also stood out here. Microsoft attempted to communicate the scope of the fix and the workarounds administrators could use. However, Linux users accustomed to transparent change logs and community-driven forums might have felt lost navigating Microsoft's relativelyformal advisory channels. Dual-boot admins are left to bridge this divide—one foot in Linux documentation and another in Windows advisories. Finally, there’s the question of trust. Multi-boot machines force administrators to trust updates from both sides. When something breaks, trust often takes a hit, whether it’s Microsoft’s failure to detect dual-boot systems correctly or Linux distributors’ inability to preemptively adapt to changes outside their control. Our Final Thoughts on The Road Ahead As Secure Boot continues to evolve, Linux administrators will need to become even savvier about potential risks. Dual-boot systems are manageable but require constant attention and periodic adjustments to stay functional. This incident shows how one ecosystem's security patch can cripple another and how solutions, even when ultimately effective, may not come as quickly as you’d like. For now, the best approach is staying informed. Know what updates are rolling out to both your Windows and Linux systems. Get familiar with how Secure Boot works between the two, and don’t be afraid to question whether certain updates are necessary or safe to install in a dual-boot environment. You might never find yourself reading Windows KB advisories with as much attention as Linux man pages—but in this increasingly interconnected world of firmware policies and Secure Boot compatibility, the admin who understands both sides of the battle wins. . The August 2024 Windows updates led to critical boot failures for Linux admins. Discover the impacts and fixes.. linux, admins, managing, dual-boot, systems, often, feels, juggling, worlds, occasionally. . Brittany Day

Calendar%202 May 15, 2025 User Avatar Brittany Day Vendors/Products
210

November 2022 Microsoft Patches: 64 Fixes Including Six Zero-Days

Microsoft Patch Tuesday updates for November 2022 addressed 64 vulnerabilities, including six actively exploited zero-days. . Microsoft Patch Tuesday updates for November 2022 addressed 64 new vulnerabilities in Microsoft Windows and Windows Components; Azure and Azure Real Time Operating System; Microsoft Dynamics; Exchange Server; Office and Office Components; SysInternals; Visual Studio; SharePoint Server; Network Policy Server (NPS); Windows BitLocker; and Linux Kernel and Open Source Software. The link for this article located at Security Boulevard is no longer available. . In August 2022, Google’s monthly security patches addressed 50 vulnerabilities affecting various Google software and Android systems.. Microsoft Updates, Patch Tuesday, Zero-Day Threats, Cybersecurity. . Brittany Day

Calendar%202 Nov 09, 2022 User Avatar Brittany Day Security Vulnerabilities
78

WSL 0.50.2.0: Microsoft Updates Kernel And Introduces New Icon

Microsoft has released the latest preview version of Windows Subsystem for Linux, bringing with it a lengthy changelog, an updated kernel and a new icon. . With the launch of Windows Subsystem for Linux Pre-release 0.50.2.0, Microsoft has introduced a new icon (featuring, of course, a penguin), but there's far more to this release than just this visual update. The latest version fixes various WSL issues, updates the Linux kernel, and includes numerous other changes and additions. Continuing its embrace of Linux, Microsoft has used the latest version of WSL to make numerous changes to this increasingly invaluable tool. Key changes with this release include updating the tar used for importing and exporting WSL2 distributions, as well as adding new strings and parameters, while updating existing ones. . The newest version of WSL Pre-release 0.50.2.0 from Microsoft showcases a revamped logo along with significant kernel enhancements, boosting efficiency and user experience.. Windows Subsystem For Linux, WSL Update, Microsoft Linux Tool. . LinuxSecurity.com Team

Calendar%202 Nov 17, 2021 User Avatar LinuxSecurity.com Team Vendors/Products
78

Microsoft Linux App Repository Changes: TLS 1.2 Usage Now Mandatory

For obvious reasons, Microsoft is pushing for the migration to TLS 1.2, and the software giant has announced a change concerning its Linux app repository. To download packages, TLS 1.2 will now be mandatory. . Hosted at packages.microsoft.com, the collection of software for Linux will no longer allow TLS 1.0 and TLS 1.1, with the company explaining that beginning with September 24, TLS 1.2 will be mandatory. In other words, clients not using TLS 1.2 will no longer be allowed to download Linux packages from Microsoft, and the firm emphasizes that companies should give up on the older version due to security risks. The link for this article located at Softpedia News is no longer available. . To enhance security measures, Microsoft has officially required TLS 1.2 for its Linux application repository, discontinuing support for previously utilized, less secure versions.. TLS 1.2 Migration, Microsoft Linux Update, Package Repository Changes. . LinuxSecurity.com Team

Calendar%202 Aug 31, 2020 User Avatar LinuxSecurity.com Team Vendors/Products
78

Microsoft Azure Sphere IoT Security Announcement for Embedded Devices

At a small press event in San Francisco, Microsoft today announced the launch of a secure end-to-end IoT product that focuses on microcontroller-based devices — the kind of devices that use tiny and relatively low-powered microcontrollers (MCUs) for basic control or connectivity features.. Typically, these kinds of devices, which could be anything from a toy to a household gadget or an industrial application, don’t often get updated and hence, security often suffers. At the core of Azure Sphere is a new class of certified MCUs. As Microsoft president and chief legal officer Brad Smith stressed in today’s announcement, Microsoft will license these new Azure Sphere chips for free, in hopes to jump-start the Azure Sphere ecosystem. The link for this article located at TechCrunch is no longer available. . Google introduces a privacy-centric IoT solution leveraging a tailored Linux kernel for microprocessor-driven equipment.. IoT Security, Microsoft Linux Kernel, Embedded Devices, Custom IoT Solutions, Azure Sphere Security. . LinuxSecurity.com Team

Calendar%202 Apr 18, 2018 User Avatar LinuxSecurity.com Team Vendors/Products
83

Microsoft Xbox Live Accounts Compromise Advisory: Security Risks Revealed

A number of . The statement from Microsoft reads: We are aware that a group of attackers are using several stringed social engineering techniques to compromise the accounts of a handful of high-profile Xbox Live accounts held by current and former Microsoft employees. We are actively working with law enforcement and other affected companies to disable this current method of attack and prevent its further use. Security is of critical importance to us and we are working every day to bring new forms of protection to our members. Read more at https://venturebeat.com/security/microsoft-xbox-live-hack/ The link for this article located at VentureBeat is no longer available. . The statement from Microsoft reads: We are aware that a group of attackers are using several stringe. number, statement, microsoft, reads, aware, group, attackers, using. . LinuxSecurity.com Team

Calendar%202 Mar 21, 2013 User Avatar LinuxSecurity.com Team Hacks/Cracks
78

Testing Microsoft Windows Security Through Advanced Hacking Scenarios

Over the past few weeks, I've been putting together test hacking scenarios for a customer. They wanted to see copies of the RSA attack, the Google attack, advanced persistent threat (APT) simulations, social engineered Trojans, worms, remote buffer overflows, and more. The objective: to test what they could do to prevent all of those assaults on their predominately Microsoft Windows environment.. I put the customer's environment through its paces, and as expected, it was great fun. It certainly beats filling out paperwork and reading security policies. But something unexpected happened along the way, although I shouldn't have been surprised as I am a full-time principal security architect at Microsoft: I found that Windows 7 and other Microsoft programs were significantly harder to hack than most anyone would believe. It was difficult to perform almost any hack without disabling multiple default defenses and ignoring one or more additional warnings. The link for this article located at InfoWorld is no longer available. . I put the customer's environment through its paces, and as expected, it was great fun. It certainly . weeks, putting, together, hacking, scenarios, customer. . LinuxSecurity.com Team

Calendar%202 Jun 02, 2011 User Avatar LinuxSecurity.com Team Vendors/Products
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

Is continuous patching actually viable?

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/156-is-continuous-patching-actually-viable?task=poll.vote&format=json
156
radio
0
[{"id":503,"title":"Delayed updates invite catastrophic breaches.","votes":1,"type":"x","order":1,"pct":50,"resources":[]},{"id":504,"title":"Automated fixes break production environments.","votes":1,"type":"x","order":2,"pct":50,"resources":[]},{"id":505,"title":"Manual approvals cannot keep pace.","votes":0,"type":"x","order":3,"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