LinuxSecurity.com

Proxies are a standard component of a Linux administrator's toolbox. You can use them to see how services respond in various locations, to run route monitoring checks, and to retrieve public data for internal tooling. However, a proxy is an outbound tunnel with credentials attached, and on a multi-user server, it is a security risk that should be treated with the same caution as SSH or sudo. This post explains the practical measures that prevent a proxy setup from becoming a weak point in an ...

Before the week gets away from you, take a look at what's landed across the Linux ecosystem.  The volume of security advisories hasn't slowed, and while not every update demands an emergency maintenance window, several deserve to move to the top of your patch queue. This week's updates span the kernel, remote desktop infrastructure, VPNs, containers, browsers, and the utilities Linux systems quietly depend on every day.  Individually, these look routine. Together they show how quickly attacke...

Linux systems generate a steady stream of authentication, service, kernel, and application logs. On most systems, those logs never leave the machine that created them. If you're responsible for ten or twenty servers, that means checking each one separately. If one disappears before you can investigate it, its logs may disappear with it. Centralized logging solves that by sending log messages to another server as they're created. Instead of searching every machine, you have one place to review...

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. O...

Most of us don't hear about a kernel vulnerability until a CVE lands in our inbox or the vulnerability scanner starts complaining. By then, the patch isn't new anymore. Kernel developers may have been passing it around for review, arguing over the implementation, or revising it for days before anyone outside that community noticed it. None of those discussions are secret. They're sitting in mailing list archives, Git commits, and patch reviews where they've been the whole time. The strange pa...

Spin up a fresh Linux VPS with default settings and check /var/log/auth.log ninety seconds later. There will already be failed login attempts — not dozens, hundreds, sometimes before the deployment script has even finished running.

Every Linux server in your fleet produces thousands of events every minute. From journald logs and auditd records to kernel-level eBPF hooks, your systems are constantly talking. Most of that noise is just the mundane churn of system services, CI/CD runners, or routine administrative automation. But among that noise, an attacker might be establishing a foothold, moving laterally, or setting up persistence. The challenge for any security team is: how do you separate the routine from the malici...

If you’re running Gitea in a container, stop what you’re doing and check your versioning right now. We’re looking at a critical vulnerability—CVE-2026-20896—shipped directly in Gitea’s official Docker images. It’s a 9.8 CVSS-rated "open door" that lets any unauthenticated attacker stroll in and impersonate any user on your system, admin account included, without needing a password or a token. The reality? This isn't some complex, low-level kernel exploit. It’s a classic "secure-by-default" fa...

There was a time when Linux meant server rooms and hobbyist forums. These days it's on regular laptops, and a big part of that is people getting fed up with commercial operating systems scraping their data, shipping telemetry nobody asked for, and boxing them into hardware ecosystems they can't opt out of.

There's a gap between what Linux systems log by default and what you actually need to detect a compromise. Most environments have logging active, which creates a sense of coverage that doesn't hold up under investigation.

When you’re digging through an incident, your logs are the only thing you can actually trust. The problem is, attackers know that too. If someone gets root on your server, their first move is almost always to delete the evidence and cover their tracks.

Security scanners flag exposed API keys in public repositories every day. The initial response is usually predictable: delete the commit, revoke the credential, and move on. That’s a mistake.

Root access on a Linux system rarely arrives through a zero-day.

When an attacker breaks into a Linux system, their work is rarely done. Usually, the real work starts after the initial exploit: hiding their tracks. If you’re a Linux admin or security analyst, there is nothing worse than logging in, running a few commands, and realizing the logs aren't telling the whole story. When logs are missing or look "off," your primary source of truth is compromised. This guide covers how to handle that situation. We’ll walk through the workflow you need to determine...

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 dist...