Latest Linux Security News & Information

security advisoryimportantCisco

When Security Tools Become a Risk: Cisco Snort 3 Flaws & Network Security Threats

Snort 3 flaws don’t matter because they are unusual. They matter because they are predictable. . Recent disclosures showed that crafted network traffic can crash the Snort 3 inspection engine, force restarts, or degrade analysis without always raising clear alarms. In some cases, memory data can be exposed. None of this requires authentication. For Linux admins running Snort sensors, this means inspection can fail under exactly the conditions it is meant to handle: hostile input at scale. That failure mode is the real issue. Network inspection tools are still widely treated as passive observers, not as software that can be targeted and destabilized. When inspection breaks quietly, visibility disappears first, not connectivity. Traffic looks clean. Alerts dry up. Monitoring dashboards stay green. This is a broader trend Linux admins rarely plan for. As inspection engines grow more complex, they also become part of the attack surface. If you assume detection is working because the service is running, you are already behind. These recently discovered Snort 3 flaws are a reminder that inspection itself needs monitoring, policy, and explicit risk ownership, or it quietly becomes the weakest link in the network. What Do the Cisco Snort 3 Security Flaws Actually Change in Network Inspection? This is not about one bad bug or an exotic edge case. It’s about how the inspection engine behaves when traffic is intentionally shaped to stress it. How the Snort 3 Engine Fails Under Crafted Traffic Snort 3 inspects packets by parsing them deeply, protocol by protocol, field by field. That parsing happens on untrusted input, and some of the recent flaws sit directly in that path. Crafted packets can trigger crashes or force the engine to restart. In some cases, inspection does not stop cleanly. It degrades, skipping analysis while the process recovers. The important detail is how little access is required. These failures can be triggered remotely and without authentication. An attacker doesnot need a foothold inside the network. They only need to reach the sensor with traffic that exercises the vulnerable code paths. From the outside, this looks like normal network noise. From the inside, inspection may already be compromised. Data Exposure and Inspection Blind Spots Not all of the issues are about availability. Some flaws allow limited memory disclosure, leaking data from the inspection process itself. That exposure is subtle, but it matters because it confirms something defenders often overlook. The inspection engine is handling a sensitive state while processing traffic, and bugs there can spill more than just alerts. More damaging, though, are the blind spots. Inspection gaps are not always logged or escalated. A sensor can miss traffic while still appearing healthy in dashboards that only track uptime or alert counts. Quiet failure is the core risk here. The system does not always tell you it has stopped seeing clearly. Affected Products and Linux Deployments These issues are not confined to a single appliance or niche setup. Open-source Snort 3 deployments are affected, as are Cisco Secure Firewall products that embed the Snort engine. Many of those sensors run on Linux, either as dedicated hosts or as part of a larger security stack. That matters for teams relying on network intrusion detection as a control. The same engine, the same failure modes, and often the same monitoring assumptions apply across environments. When Network Intrusion Detection Tools Become Part of the Attack Surface It helps to stop thinking of an IDS as a passive observer. The engine is not just watching traffic. It is actively parsing it, normalizing it, and making decisions based on structures an attacker fully controls. That makes the detection layer a place where mistakes can be triggered on purpose, not just stumbled into. IDS engines process untrusted input continuously, often at line rate. Parsing bugs get easier to hit as traffic volume increases. Attackers can probedetection logic the same way defenders test rules. A crashed or degraded sensor does not raise alarms. It just goes quiet. This is why the risk is easy to underestimate. When an application server crashes, users complain. When an inspection engine fails, the network can look clean. For admins, that means responsibility shifts. Threat models have to include inspection engines as attackable components, not trusted referees standing outside the game. Linux Admin Reality Check: Why Snort 3 Failures Are Easy to Miss Most Snort failures don’t announce themselves as failures. They show up as normal-looking systems doing less work than you think. Why “Service Running” Is Not a Security Signal On a Linux host, the first check is usually simple. Is the service running? systemd says yes, so everyone moves on. That works for many daemons. It breaks down for inspection engines. Snort can crash and restart on its own. It can enter short crash loops and recover without ever tripping a pager. During those windows, packet inspection may stop or partially resume, and nothing in basic service monitoring tells you that coverage slipped. Where IDS Visibility Usually Stops Most IDS monitoring is built around detections. Alerts fired. Signatures matched. Packets dropped. What often goes untracked are decode errors and parser exceptions, the signals that tell you the engine is struggling to make sense of what it is seeing. Those events may be logged locally, if at all. They rarely escalate. Dashboards stay quiet because they are watching outcomes, not engine health. The result is a blind spot that only shows up after you need the data that never got inspected. Early Indicators Admins Tend to Ignore There are usually hints, but they look like noise. A slight drop in inspected traffic. CPU spikes that line up with bursts of malformed packets. A sensor that feels “off” but not broken enough to justify digging. You start to see the trend once you’ve chased it a few times. Inspectiondegrades before it fails, and that degradation is easy to rationalize away as load or background churn. Policy and Monitoring Changes That Reduce Network Inspection Risk Once you accept that inspection can fail quietly, policy has to follow. Network intrusion detection cannot be treated as a static control that is either on or off. It becomes a system whose health needs to be measured, reviewed, and explained, especially in environments where detection is cited as a compensating control. That starts with watching the engine itself, not just the alerts it produces. Signal What It Indicates Why It Matters Snort restarts Engine instability Inspection may drop without notice Decode failures Parsing stress Early sign of hostile or malformed traffic Rule reload errors Broken detection logic Coverage exists on paper, not in practice These signals are not exotic. Most of them already exist in logs or metrics streams. They are just rarely elevated to the level of security monitoring. A few minimum changes usually make the difference: Treat IDS health events as security-relevant, not operational noise. Alert on restarts, crash loops, and repeated decode errors, even if detections stay low. Correlate inspection errors with traffic spikes instead of looking at them in isolation. None of this requires rewriting your entire monitoring stack . It does require changing what you consider evidence that detection is working. Patch, Compensate, or Re-Architect: Security Decisions After Snort 3 Flaws Once the flaws are understood, the hard part starts. This is where teams tend to stall, because patching feels obvious and everything else feels optional. In reality, each choice changes risk in a different way, and pretending there is only one answer is how blind spots stick around. Option What It Fixes What ItDoesn’t Patch Snort Known flaws in current versions Future parser bugs and unknown failure modes Add redundancy Single-sensor failure Operational complexity and tuning drift External monitoring Visibility gaps Alert fatigue and correlation work Patching is necessary. It closes the specific holes that have been documented. It does not change the fact that inspection engines will keep parsing hostile input tomorrow and next year. That is where compensating controls come in. Redundant sensors limit how much visibility you lose when one engine stumbles. External monitoring helps you notice when inspection quality drops instead of assuming clean traffic. The last option is the one people rarely name. Doing nothing. That is still a decision, and it carries risk just like the others. The difference is that it is usually undocumented and therefore hard to defend later. Why Network Security Threats Now Include the Tools You Rely On Network security threats are no longer limited to the traffic crossing the wire. They also live inside the tools built to inspect that traffic. As detection engines grow more complex, they accumulate their own failure modes, many of them subtle. Inspection logic ages. Parsers expand. Edge cases multiply. Over time, the attack surface grows even if the network itself does not. What makes this harder to manage is how these failures present. Inspection engines tend to fail quietly. Alerts stop. Coverage thins. Everything looks calm unless you are watching the right signals. Long-term security strategies have to assume these gaps will happen and plan for how to detect and explain them. FAQ: Cisco Snort 3 and Network Intrusion Detection Risks Can Snort 3 fail without generating alerts? Yes. Snort can crash, restart, or partially degrade while producing few or no alerts. If monitoring is focused on detections rather than engine health, inspection gaps can gounnoticed. How do I detect inspection failure on Linux sensors? You have to look past service status. Track restarts, decode errors, parser exceptions, and sudden drops in inspected traffic, then correlate those signals with traffic patterns and system load. Are passive IDS deployments safer than inline ones? They reduce the risk of blocking traffic, but they do not remove inspection risk. A passive sensor that fails quietly still creates a visibility gap, which can be just as damaging during an investigation. Does patching eliminate inspection risk? No. Patching fixes known flaws, not the underlying reality that inspection engines parse hostile input. New bugs and new failure modes will appear over time, even in well-maintained systems. What metrics indicate IDS health issues? Repeated restarts, rising decode failures, rule reload errors, and unexplained CPU spikes are common indicators. None of them is definitive alone, but together they show when inspection quality is slipping. . Explore recent Cisco Snort 3 flaws affecting network inspection, highlighting the risk of silent failures and data leaks.. Cisco Snort 3, network security tools, Linux intrusion detection, security monitoring, network inspection flaws. . Brittany Day

Jan 19, 2026 •

Brittany Day Security Vulnerabilities

security advisorylinuxdata exposure

Linux Security: Mitigating Model Inversion Attack Risks

Machine learning now runs deep inside Linux security workflows, from containerized inference services to open-source model pipelines. These systems look harmless at first glance. You hand them data, they return predictions, and that feels like the end of the transaction. It isn’t. A model can leak far more than teams expect, and that’s where model inversion attacks turn into a real operational problem. . How Model Inversion Attacks Threaten Linux Security A model inversion attack exploits a machine learning model’s outputs to recover details about the data used to train it. The attacker doesn’t need to steal the model. They query it, study the responses, and work backward until patterns start forming. It’s not a perfect reconstruction, but it’s accurate enough to expose people, systems, and internal logic when the model runs inside open-source Linux environments. How Model Inversion Attacks Work on Linux Systems Attackers begin by crafting inputs and collecting outputs, treating the model like a signal source. Two or three rounds of probing give them the early hints they need. Then comes gradient inspection when the model’s weights are public or deployed on a Linux system with loose file permissions. Gradients reveal how each input shift affects the output, which quietly exposes the model’s internal logic. With enough iterations, the attacker generates inputs that match the model’s learned features. It starts rough. But it sharpens fast when combined with auxiliary details like demographics or partial datasets. Open-source ecosystems often publish checkpoints and metadata meant for transparency, and those artifacts speed up the reconstruction process. Why Linux Security Faces Higher Exposure Most ML inference stacks run inside Linux containers , and that environment becomes part of the attack surface. Docker and Kubernetes leave traces everywhere: cache folders, logs, and leftover checkpoints. If someone gains access, even briefly, they can pull fragments thathelp refine the inversion process. Older kernel modules and forgotten libraries widen that path. One misconfigured permission on a mounted volume is all it takes. Many teams push models to production without hardened SELinux or AppArmor policies. It saves time but leaves the model exposed. Linux security controls matter here because inversion attacks don’t need a crash or exploit chain. They just need visibility into how the model behaves. Real-World Examples of Model Inversion Attacks Research has shown how easy it is to turn model outputs back into sensitive data. In 2014, Fredrikson et al. combined a trained model with demographic details to infer private genetic markers. A year later, they reconstructed recognizable faces from a facial recognition model. Those results put regulated industries in a tough spot, especially those under GDPR or HIPAA. Financial models face similar pressure. Credit scoring systems help analysts, yet their outputs can reveal the thresholds used to approve a loan. Once an attacker maps those patterns, internal decision logic becomes an open book. Impact on Open-Source Models in Linux Environments Open-source models make inversion faster. Repos on GitHub, Hugging Face, and TensorFlow Hub often publish architectures, weights, and environment configs. An attacker can clone the repository, deploy it on a Linux box, and iterate until they recover meaningful patterns from gradients. Linux systems also leave footprints: temporary files, stale logs, exposed endpoints. In 2023, researchers extracted portions of training text by hammering a commercial sentiment-analysis API with repeated queries. That kind of leakage scales quickly in containerized environments. Transparency in Linux Ecosystems: Strength and Risk Open-source work depends on transparency. Teams share architectures, weights, and dataset descriptions so others can reproduce results. But those same details help attackers. Model hyperparameters and dataset schemas offer clues. Public APIs and demoservers hosted on Linux give adversaries a stable target for constant probing. Linux Security Mitigation Strategies for Sysadmins and Developers Model inversion attacks hit hardest when the model and its Linux environment leak small details without anyone noticing. The goal isn’t perfection. It’s reducing how much the attacker can see and limiting where they can stand. That starts with treating every model like sensitive infrastructure. 1. Use Differential Privacy During Training During training, a model can quietly memorize exact records. Differential privacy reduces that risk by adding controlled noise to each update so no single user’s data becomes recoverable. The process doesn’t fix sloppy deployments, but it stops the model itself from leaking precise training examples. Tools like TensorFlow Privacy and PyTorch Opacus make this easy to apply. 2. Keep Models From Overfitting Overfitted models cling to details that attackers can extract. Dropout, augmentation, and regularization keep the model general enough that inversion has less to work with. It’s not glamorous. But it’s one of the simplest ways to keep training data from resurfacing in outputs. 3. Limit What the Model Returns Don’t expose raw probability vectors when class labels are enough. Those high‑resolution outputs give attackers the signal they need to reconstruct patterns. Clip, round, or simplify the responses so the model reveals less with every query. 4. Harden the Linux Environment Around the Model Inference containers should run under SELinux or AppArmor with tight profiles. Keep model weights in directories with restrictive read permissions. Avoid mounting hostPath volumes unless absolutely required. And don’t run inference containers with elevated privileges; they don’t need them. Audit logs should capture access patterns so odd spikes in queries get noticed instead of ignored. 5. Secure Container Configurations Container misconfigurations leak more than teams expect. Encrypt sharedvolumes that hold gradients, checkpoints, or temporary artifacts. Prevent containers from writing sensitive files to /tmp or other world‑readable paths. And avoid spreading model directories across multiple containers unless that layout is essential. 6. Manage Artifacts Like Sensitive Data Training leaves behind checkpoints, gradient dumps, notebooks, and half‑finished files. These artifacts become clues for inversion attacks. Rotate them, encrypt them, or purge them automatically. Linux hosts make it easy to forget what gets left in a home directory or workspace. Cleanups matter. 7. Watch for Abnormal Query Behavior Most inversion attacks rely on repeated probing. Track how often a client hits an endpoint and whether their query patterns drift from normal usage. Even basic rate limits and anomaly detection force attackers to slow down. Slowed attacks are easier to spot. 8. Reduce Public Exposure in Open‑Source Deployments Open‑source models don’t need to expose everything. Publish only the artifacts that serve the project. Hold back unnecessary metadata, fine‑tuning notes, or evaluation endpoints. Demo servers should never run without rate limits or authentication. Transparency helps the community, but it doesn’t require giving attackers perfect alignment. The Future of Secure AI Models Model inversion attacks remind us that models running on Linux aren’t private by default. The openness that powers Linux also gives attackers a predictable environment to study, which is why hardened hosts, encrypted gradients, and careful use of AI framework s matter. One weak configuration can reveal more than teams expect. As more workloads rely on Linux for model deployment, security needs to assume that someone will try to pull training data from the system. And once that data leaks, there’s no clean way to take it back. . Model inversion attacks threaten Linux security by leaking sensitive data through machine learning models. Mitigation strategies included.. modelinversion attack, Linux security, machine learning, data exposure, inference models. . MaK Ulac

Nov 14, 2025 •

MaK Ulac Security Vulnerabilities

Banner 2 1028x280 1708121730 1 1771599631

security advisoryupdatecritical

Linux Kernel Netfilter Vulnerability: CVE-2024-26925 Critical DoS Threat

A critical vulnerability was discovered in the Linux kernel's netfilter subsystem, specifically within the nf_tables component, posing potential risks to systems worldwide. The vulnerability, CVE-2024-26925 , arises from improperly releasing a mutex within the garbage collection (GC) sequence of nf_tables. It could potentially lead to race conditions and compromise the stability and security of the Linux kernel. . What Is the Impact of This Vulnerability on Linux Security? The technical details of the vulnerability and its impact on the Linux kernel's security should be highlighted. During the critical section, the commit mutex must not be released between nft_gc_seq_begin() and nft_gc_seq_end. The async GC worker could collect expired objects and get the released commit lock within the same GC sequence if this occurs. The implications of this kernel flaw are severe for systems utilizing the nf_tables for network packet filtering. Thus, admins and users should apply the latest updates to safeguard their systems. This proactive patching underscores the Linux community's commitment to security and stability and the importance of staying updated and informed on Linux security patches and best practices. For Linux admins, infosec professionals, internet security enthusiasts, and sysadmins, this vulnerability could have substantial long-term consequences for their systems and networks. It raises questions about the overall security of the Linux kernel and prompts critical analysis of the patching process and its effectiveness. However, the implications of this vulnerability extend beyond the immediate need for patching, elevating the importance of understanding and addressing potential weaknesses in open source and Linux security . This article aims to ensure that users are aware of their risks and equipped to take necessary actions to mitigate potential threats. Our Final Thoughts on This Critical Kernel Bug The critical vulnerability identified in the Linux kernel's netfiltersubsystem underscores the ongoing challenges in maintaining robust security measures for open-source software. The implications of this vulnerability on systems worldwide necessitate a heightened focus on proactive security measures, patching, and ongoing monitoring to ensure the resilience of Linux environments. This article aims to provide valuable insights and takeaways for the global community of Linux admins, infosec professionals, internet security enthusiasts, and sysadmins by emphasizing the impact of this flaw on security practitioners and offering actionable mitigation recommendations. . This critical weakness in the Linux kernel presents considerable dangers, requiring immediate response from system administrators and cybersecurity personnel.. Linux Kernel, Netfilter, Critical Risk, DoS, Security Update. . Brittany Day

Apr 30, 2024 •

Brittany Day Security Vulnerabilities

security advisorydebiancritical severity

Debian: DSA-5462-1 Critical: Zenbleed Microcode Info Disclosure

It was discovered that under specific microarchitectural circumstances, a register in "Zen 2" CPUs might not be written to 0 correctly, potentially causing data from another process and/or thread to be stored in the YMM register ( CVE-2023-20593 , also known as Zenbleed). . This vulnerability could result in the exposure of sensitive data. Updated microcode packages that mitigate this flaw are now available for Amd Epyc gen 2 CPUs. Other Zen 2-based CPUs will get their microcode update later when AMD has fixed and validated the microcodes. Given that this bug poses a severe threat to the confidentiality of sensitive information, it is crucial that all impacted users apply the updates issued by Debian , D ebian LTS , Fedora , Mageia , Oracle , Slackware , SUSE and Ubuntu now to prevent potential compromise of their critical data. To stay on top of essential updates released by the open-source programs and applications you use, register as a LinuxSecurity user , subscribe to our Linux Advisory Watch newsletter, and customize your advisories for your distro(s). This will enable you to stay up-to-date on the latest, most significant issues impacting the security of your systems. Follow @LS_Advisories on Twitter for real-time updates on advisories for your distro(s) . . This risk may reveal confidential information. Firmware updates are being deployed promptly to address the concern.. Microcode Update, AMD Security, Zen 2 Threat, Data Exposure, Information Disclosure. . Brittany Day

Aug 03, 2023 •

Brittany Day Security Vulnerabilities

data exposurecloud securityopen source tool

S3crets Scanner: Secure Your Public AWS S3 Buckets Today

A new open-source 'S3crets Scanner' scanner allows researchers and red-teamers to search for 'secrets' mistakenly stored in publicly exposed or company's Amazon AWS S3 storage buckets. . Amazon S3 (Simple Storage Service) is a cloud storage service commonly used by companies to store software, services, and data in containers known as buckets. Unfortunately, companies sometimes fail to properly secure their S3 buckets and thus publicly expose stored data to the Internet. . Dive into the innovative S3crets Scanner, a community-driven application designed to detect sensitive information hidden within publicly accessible AWS S3 repositories.. Open Source Tool,AWS S3 Scanning,Cloud Security Solutions,Data Exposure Prevention. . Brittany Day

Oct 30, 2022 •

Brittany Day Cloud Security

security advisorymoderatesecurity issue

Linux Kernel ARM Threat: CVE-2020-28588 Moderate Data Leak Advisory

An information disclosure vulnerability in the Linux kernel that exposes stack memory (tracked as CVE-2020-28588 ) can be exploited to leak data and act as a springboard for further compromise. . Disclosed by Cisco Talos researchers on Tuesday , the bug is described as an information disclosure vulnerability "that could allow an attacker to view Kernel stack memory." The kernel is a key component of the open source Linux operating system. The vulnerability, tracked as CVE-2020-28588 , was found in the proc/pid/syscall functionality of 32-bit ARM devices running the OS. . Revealed by Microsoft Security, this vulnerability is a privacy breach within the Windows OS that may result in unauthorized data access.. Linux Kernel Security, Data Leak Issues, Information Disclosure. . Brittany Day

Apr 28, 2021 •

Brittany Day Security Vulnerabilities

security advisoryRed Hatred hat

Linux Kernel 5.11.8: Spectre Attack Mitigations Bypass Advisory

Cybersecurity researchers have identified two new vulnerabilities in Linux-based OSes that, if successfully exploited, could enable attackers to bypass mitigations for speculative attacks such as Spectre and obtain sensitive information from kernel memory. . Discovered by Piotr Krysiuk of Symantec's Threat Hunter team, the flaws — tracked as CVE-2020-27170 and CVE-2020-27171 (CVSS scores: 5.5) — impact all Linux kernels prior to 5.11.8. Patches for the security issues were released on March 20, with Ubuntu, Debian, and Red Hat deploying fixes for the vulnerabilities in their respective Linux distributions. While CVE-2020-27170 can be abused to reveal content from any location within the kernel memory, CVE-2020-27171 can be used to retrieve data from a 4GB range of kernel memory. The link for this article located at The Hacker News is no longer available. . Newly discovered weaknesses could enable cybercriminals to circumvent Spectre defenses on Linux platforms, raising issues of data privacy.. Linux Kernel Security,Spectre Attack,Kernel Mitigation Bypass,Red Hat Fix. . Brittany Day

Mar 29, 2021 •

Brittany Day Security Vulnerabilities

security advisorycritical issuemalware threat

Exploring Major Security Threats Affecting IT Systems In The Last Decade

Thank you to Skynats for contributing this article. This past decade has been plagued with security vulnerabilities. Let’s have a look at the top vulnerabilities that have recently crippled the IT world. Badlock: Badock is a crucial security bug affecting Windows computers and Samba servers. It is identified using the following reference: (CVE-2016-0128(Microsoft) CVE-2016-2118(samba). The RPC services allowed an attacker to become a man in the middle to intercept the communication between a client and a server hosting a SAM database to exploit and force the authentication to downgrade, allowing the attackers to access the SAM database. Blueborne: Blueborne is a virus that spreads through the air. Yes, it of course through the Bluetooth on your device. Everything from your smartphone to other devices (TV, Computer, smart cars, laptops) are Bluetooth enabled and active almost all the time, leaving these devices vulnerable to malware attacks that can remotely seize them without user permission. Cloud Bleed: This was another leading cloud-based security vulnerability affecting Cloudflare's reverse proxies which was discovered on February 17, 2017. Most of the busiest websites and the apps rely on Cloudflare's protection. This security bug caused their edge server to run past the end of a buffer and then return the memory which contained private information such as: 1. HTTP cookies 2. Authentication tokens 3. HTTP post bodies 4. Tons of sensitive data and more The worst part was that some of this data was cached by search engines. Dirty Cow: This was another serious security problem discovered in the way the Linux kernel memory handled the copy on write (COW) that affects Linux-based OSes including Android devices that used an older version (before 2018) of the Linux kernel. Dirty Cow is a local privilege escalation vulnerability bug that exploits a rare condition by implementing the copy on write mechanism. Computers and devices that still using an older version of theLinux kernel remain vulnerable, and any user can become root in less than five seconds. The exploitation of this bug doesn't leave any trace in the log, so you can't detect if someone has used this exploit against your server. Foreshadow: This bug (L1TF or foreshadow) affecting Intel/AMD processors will allow attackers unprecedented access to sensitive information that is stored on a personal computers and cloud server. Foreshadow has two versions: the original attack which extracts data from SGX enclaves and the second version (next-generation) which targets virtual machines (VMs), hypervisors (VMM), OS Kernel memory and system management mode (SMM) memory. Foreshadow is similar to the Spectre security bug which affects the Intel and AMD chips, and the Meltdown security bug also affects Intel. Nevertheless, applying software patches may help mitigate some concern, but the users may see some considerable changes in overall PC or server power by doing so. Heartbleed: Heartbleed is a serious vulnerability in the popular open SSL cryptographic software library, used widely in implementation of the transport layer security (TLS) protocol. The Heartbleed vulnerability was publicly disclosed in April of 2014. iSee You: This is an Apple webcam vulnerability which is a silent malware attack. Apple laptops affected are capable of running all sort of operating systems, including macOS, Microsoft Windows and Linux. Researchers have released iSightDefender, a macOS kernel extension to reduce the attack surface under the macOS operating system. KRACK: (Key Reinstallation Attack) is a replay attack (a type of exploitable flaw) on the Wi-Fi protected Access protocol (WPA) used to secure the Wi-Fi connections. It was discovered in 2016 by Belgian researchers. All the major software platforms that use Wi-Fi protected access are affectedincluding Microsoft windows, macOS, iOS, Linux, Andriod and OpenBSD. Lazy: Lazy, which is also referred to as Lazy FP State Restore or LazyFP, is a securityvulnerability affecting Intel CPUs. The vulnerability is caused by a combination of flaws in the speculation execution technology. This vulnerability is used to leak the content of the FPU registers that belongs to another process. Lazy is related to the Spectre and Meltdown vulnerabilities which were publicly disclosed in January of 2018. Linux .encoder: This is considered to be the first ransomware Trojan targeting computers and cloud servers running Linux. There are additional variants of this Trojan that target other UNIX and UNIX-like systems which were discovered on November 5, 2015. Meltdown: Meltdown is a severe security vulnerability in tech media that is found in almost all CPUs used in modern devices. Mobile phones, laptops, systems and internet of things (IoT) devices are vulnerable. Meltdown CPU vulnerabilities and exposures will break the fundamental isolation between the user and the application. This will allows a rogue process to access the memory of other programs and the operating system. The Meltdown vulnerabilities primarily affect Intel microprocessors, but will also affect the ARM Cortex-A75 and IBM's Power microprocessors. It does not affect AMD CPUs. Microarchitectural: The Microarchitectural Data Sampling (MDS) vulnerabilities are a set of weaknesses in Intel x86 microprocessors that use hyper-threading to leak data across the protection boundaries that are architecturally supposed to be secure. After Meltdown, Spectre and Foreshadow, Microarchitectural is considered the most critical vulnerability in modern processors. The attack exploits vulnerabilities have been labeled as Fallout, RIDL (rogue in-flight Data load) and Zombiaload and allows attackers to steal sensitive data and keys. Have another vulnerability that you feel belongs on this list? Please do not hesitate to reach out and let us know! . . Thank you to Skynats for contributing this article. This past decade has been plagued with security . thank, skynats, contributing, article, decade, plagued,security. . Brittany Day

Jan 14, 2021 •

Brittany Day Security Vulnerabilities

Community Poll

More Polls

Should Linux servers automatically install security updates?

Yes — critical security patches should install automatically.
No — every update should be tested before deployment.
Only critical vulnerabilities should auto-install.
I patch when Reddit starts panicking.

Stay Ahead With Linux Security News

Refine news

Get the latest News and Insights

Community Poll

Should Linux servers automatically install security updates?

Trending News

Misuse of Cron Jobs for Long-Term Access in Linux Environments

Risks of GitHub Repo Breach on Linux Supply Chain Security

After Years of Supply Chain Attacks, npm Is Finally Closing the Door on Auto-Scripts

FFmpeg PixelSmash Vulnerability Exposes Linux Media Servers to Remote Code Execution Risk

Explore Latest Linux Security news

When Security Tools Become a Risk: Cisco Snort 3 Flaws & Network Security Threats

Linux Security: Mitigating Model Inversion Attack Risks

Linux Kernel Netfilter Vulnerability: CVE-2024-26925 Critical DoS Threat

Debian: DSA-5462-1 Critical: Zenbleed Microcode Info Disclosure

S3crets Scanner: Secure Your Public AWS S3 Buckets Today

Linux Kernel ARM Threat: CVE-2020-28588 Moderate Data Leak Advisory

Linux Kernel 5.11.8: Spectre Attack Mitigations Bypass Advisory

Exploring Major Security Threats Affecting IT Systems In The Last Decade

Get the latest News and Insights

Community Poll

Should Linux servers automatically install security updates?

Trending News

Misuse of Cron Jobs for Long-Term Access in Linux Environments

Risks of GitHub Repo Breach on Linux Supply Chain Security

After Years of Supply Chain Attacks, npm Is Finally Closing the Door on Auto-Scripts

FFmpeg PixelSmash Vulnerability Exposes Linux Media Servers to Remote Code Execution Risk

Powered By

Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases

QUICK LINKS

subscribe to newsletters!

Stay Ahead With Linux Security News

Refine news

Topics

Category

Authors

Published Date

Get the latest News and Insights

Community Poll

Should Linux servers automatically install security updates?

Trending News

Explore Latest Linux Security news

Get the latest News and Insights

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!