Orthogonal Thinking

Category: Security

Cybersecurity and secure coding practices

  • GitOps vs GitHub Actions: Security-First in Production

    GitOps vs GitHub Actions: Security-First in Production

    Last month I migrated two production clusters from GitHub Actions-only deployments to a hybrid GitOps setup with ArgoCD. The trigger? A misconfigured workflow secret that exposed an AWS key for 11 minutes before our scanner caught it. Nothing happened — this time. But it made me rethink how we handle the boundary between CI and CD.

    TL;DR: GitOps (ArgoCD/Flux) and GitHub Actions serve different roles in production. GitHub Actions excels at CI — building, testing, scanning. GitOps excels at CD — declarative deployments with drift detection and automatic rollback. The security-first approach: use GitHub Actions for CI, GitOps for CD, and never store deployment credentials in CI pipelines. This hybrid model reduces secret exposure and gives you audit-grade deployment history.

    Here’s what I learned about running both tools securely in production, and when each one actually makes sense.

    GitOps: Let Git Be the Only Way In

    GitOps treats Git as the single source of truth for your cluster state. You define what should exist in a repo, and an agent like ArgoCD or Flux continuously reconciles reality to match. No one SSHs into production. No one runs kubectl apply by hand.

    The security model here is simple: the cluster pulls config from Git. The agent runs inside the cluster with the minimum permissions needed to apply manifests. Your developers never need direct cluster access — they open a PR, it gets reviewed, merged, and the agent picks it up.

    This is a massive reduction in attack surface. In a traditional CI/CD model, your pipeline needs credentials to push to the cluster. With GitOps, those credentials stay inside the cluster.

    Here’s a basic ArgoCD Application manifest:

    apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  source:
    repoURL: https://github.com/my-org/my-app-config
    targetRevision: HEAD
    path: .
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app-namespace
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

    The selfHeal: true setting is important — if someone does manage to modify a resource directly in the cluster, ArgoCD will revert it to match Git. That’s drift detection for free.

    One gotcha: make sure you enforce branch protection on your GitOps repos. I’ve seen teams set up ArgoCD perfectly, then leave the main branch unprotected. Anyone with repo write access can then deploy anything. Always require reviews and status checks.

    GitHub Actions: Powerful but Exposed

    GitHub Actions is a different animal. It’s event-driven — push code, open a PR, hit a schedule, and workflows fire. That flexibility is exactly what makes it harder to secure.

    Every GitHub Actions workflow that deploys to production needs some form of credential. Even with OIDC federation (which you should absolutely be using — see my guide on securing GitHub Actions with OIDC), there are still risks. Third-party actions can be compromised. Workflow files can be modified in feature branches. Secrets can leak through step outputs if you’re not careful.

    Here’s a typical deployment workflow:

    name: Deploy to Kubernetes
on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Configure kubectl
        uses: azure/setup-kubectl@v3
      - name: Deploy application
        run: kubectl apply -f k8s/deployment.yaml

    Notice the environment: production — that enables environment protection rules, so deployments require manual approval. Without it, any push to main goes straight to prod. I always set this up, even on small projects.

    The bigger issue is that GitHub Actions workflows are imperative. You’re writing step-by-step instructions that execute on a runner with network access. Compare that to GitOps where you declare “this is what should exist” and an agent figures out the rest. The imperative model has more moving parts, and more places for things to go wrong.

    Where Each One Wins on Security

    After running both in production, here’s how I’d break it down:

    Access control — GitOps wins. The agent pulls from Git, so your CI system never needs cluster credentials. With GitHub Actions, your workflow needs some path to the cluster, whether that’s a kubeconfig, OIDC token, or service account. That’s another secret to manage.

    Secret handling — GitOps is cleaner. You pair it with something like External Secrets Operator or Sealed Secrets and your Git repo never contains actual credentials. GitHub Actions has encrypted secrets, but they’re injected into the runner environment at build time — a compromise of the runner means a compromise of those secrets.

    Audit trail — GitOps. Every change is a Git commit with an author, timestamp, and review trail. GitHub Actions logs exist, but they expire and they’re harder to query when you need to answer “who deployed what, and when?” during an incident.

    Flexibility — GitHub Actions. Not everything fits the GitOps model. Running test suites, building container images, scanning for vulnerabilities, sending notifications — these are CI tasks, and GitHub Actions handles them well. Trying to force these into a GitOps workflow is pain.

    Speed of setup — GitHub Actions. You can go from zero to deployed in an afternoon. GitOps requires more upfront investment: installing the agent, structuring your config repos, setting up GitOps security patterns.

    The Hybrid Approach (What Actually Works)

    Most teams I’ve worked with end up running both, and honestly it’s the right call. Use GitHub Actions for CI — build, test, scan, push images. Use GitOps for CD — let ArgoCD or Flux handle what’s running in the cluster.

    The boundary is important: GitHub Actions should never directly kubectl apply to production. Instead, it updates the image tag in your GitOps repo (via a PR or direct commit to a deploy branch), and the GitOps agent picks it up.

    This gives you:

    • Full Git audit trail for all production changes
    • No cluster credentials in your CI system
    • Automatic drift detection and self-healing
    • The flexibility of GitHub Actions for everything that isn’t deployment

    One thing to watch: make sure your GitHub Actions workflow doesn’t have permissions to modify the GitOps repo directly without review. Use a bot account with limited scope, and still require PR approval for production changes.

    Adding Security Scanning to the Pipeline

    Whether you use GitOps, GitHub Actions, or both, you need automated security checks. I run Trivy on every image build and OPA/Gatekeeper for policy enforcement in the cluster.

    Here’s how I integrate Trivy into a GitHub Actions workflow:

    name: Security Scan
on:
  pull_request:
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t my-app:${{ github.sha }} .
      - name: Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: my-app:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: 1

    The exit-code: 1 means the workflow fails if critical or high vulnerabilities are found. No exceptions. I’ve had developers complain about this blocking their PRs, but it’s caught real issues — including a supply chain problem in a base image that would have made it to prod otherwise.

    What I’d Do Starting Fresh

    If I were setting up a new production Kubernetes environment today:

    1. ArgoCD for all cluster deployments, with strict branch protection and required reviews on the config repo
    2. GitHub Actions for CI only — build, test, scan, push to registry
    3. External Secrets Operator for credentials, never stored in Git
    4. OPA Gatekeeper for policy enforcement (no privileged containers, required resource limits, etc.)
    5. Trivy in CI, plus periodic scanning of running images

    The investment in GitOps pays off fast once you’re past the initial setup. The first time you need to answer “what changed?” during a 2 AM incident and the answer is right there in the Git log, you’ll be glad you did it.

    🛠️ Recommended Resources:

    Get daily AI-powered market intelligence. Join Alpha Signal — free market briefs, security alerts, and dev tool recommendations.
    📋 Disclosure: Some links in this article are affiliate links. If you purchase through these links, I earn a small commission at no extra cost to you. I only recommend products I’ve personally used or thoroughly evaluated. This helps support orthogonal.info and keeps the content free.

    FAQ

    Can I use GitHub Actions and ArgoCD together?

    Yes, and this is the recommended production pattern. GitHub Actions handles CI (build, test, scan, push images), then updates a GitOps manifest repo. ArgoCD watches that repo and handles the actual deployment. This separation means your CI system never needs cluster credentials.

    Is GitOps more secure than traditional CI/CD?

    Generally yes. GitOps eliminates the need to store cluster credentials in CI pipelines — the biggest source of credential leaks. ArgoCD pulls from Git (no inbound access needed), provides drift detection, and creates an immutable audit trail of every deployment. The tradeoff is added complexity in the initial setup.

    What about Flux vs ArgoCD?

    Flux is lighter, more composable, and integrates tightly with the Kubernetes API. ArgoCD has a better UI, supports multi-cluster out of the box, and has a larger ecosystem. For security-focused teams, both are excellent — Flux edges ahead for GitOps-native workflows, ArgoCD for teams that want visual deployment management.

    References

  • OAuth vs JWT: Choosing the Right Tool for Developers

    OAuth vs JWT: Choosing the Right Tool for Developers

    I’ve implemented both OAuth and JWT in production systems across my career—from enterprise SSO rollouts to lightweight API auth for side projects. The single most common mistake I see? Treating OAuth and JWT as the same thing, or worse, picking one when you needed the other. They solve different problems, and confusing them leads to real vulnerabilities.

    Here’s what each actually does, when to pick which, and how to avoid the traps I’ve seen burn teams in production.

    OAuth and JWT Are Not the Same Thing

    🔧 From my experience: The worst auth bugs I’ve triaged all came from teams using JWT as a session token without a revocation strategy. When a compromised token has a 24-hour expiry and no blacklist, you’re stuck watching an attacker operate for hours. Always pair JWTs with a server-side revocation check for anything security-critical.

    📌 TL;DR: OAuth and JWT are distinct tools serving different purposes: OAuth is a protocol for delegated authorization, while JWT is a compact, signed data format for carrying claims. OAuth is ideal for third-party integrations requiring secure delegation, whereas JWT excels in lightweight, stateless authentication within microservices.
    🎯 Quick Answer: OAuth is an authorization protocol that delegates access without sharing passwords; JWT is a signed token format for carrying identity claims. Use OAuth for third-party login flows and JWT for stateless API authentication—they solve different problems and are often used together.

    OAuth is a protocol for delegated authorization. It defines how tokens get issued, exchanged, and revoked when one service needs to act on behalf of a user. Think “Log in with Google” — the user never gives their Google password to your app. OAuth handles the handshake.

    JWT (JSON Web Token) is a data format. It’s a signed, self-contained blob of JSON that carries claims — who the user is, what they can do, when the token expires. OAuth can use JWT as its token format, but JWT exists independently of OAuth.

    The valet key analogy works: OAuth is the process of getting the valet key from the car owner. JWT is the key itself — compact, verifiable, and self-contained.

    Here’s what a JWT payload looks like:

    {
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

    The sub field identifies the user, admin is a permission claim, and iat is the issue timestamp. The whole thing is signed — tamper with any field and validation fails.

    The Real Differences That Matter

    Here’s where the confusion gets dangerous:

    • Validation model: OAuth tokens are typically validated by calling the authorization server (network round-trip). JWTs are validated locally using the token’s cryptographic signature. This makes JWT validation faster — critical in microservices where every millisecond counts.
    • Statefulness: OAuth maintains state on the authorization server (it knows which tokens are active). JWT is stateless — the server doesn’t store anything. This is a strength and a weakness (more on revocation below).
    • Scope: OAuth defines the entire authorization flow — redirect URIs, scopes, grant types. JWT just structures and signs data. You can use JWT for things that have nothing to do with OAuth.

    In practice, many systems use both: OAuth for the authorization flow, JWT as the token format. But you can also use JWT standalone for stateless session management between your own services.

    const jwt = require('jsonwebtoken');
const publicKey = process.env.PUBLIC_KEY;

try {
    const decoded = jwt.verify(token, publicKey);
    console.log('Token is valid:', decoded);
} catch (err) {
    console.error('Invalid token:', err.message);
}

    When to Use Which

    Pick OAuth when: Third parties are involved. If users need to grant access to external services — social logins, API integrations, “Connect your Slack account” — OAuth provides the framework for safe delegation. You’re not sharing passwords; you’re issuing scoped, revocable tokens.

    Pick JWT when: You need lightweight, stateless authentication between your own services. In a microservices setup, passing a signed JWT between services beats hitting a central auth server on every request. It’s faster and removes a single point of failure.

    Use both when: You want OAuth for the auth flow but JWT for the actual token. This is the most common production pattern I see — OAuth issues a JWT, and downstream services validate it locally without talking to the auth server.

    For example: an e-commerce platform where OAuth authenticates users at the gateway, then JWTs carry user claims to the cart, inventory, and payment services. Each service validates the JWT signature independently. No shared session store needed.

    Security Practices That Actually Matter

    I’ve seen every one of these mistakes in production code:

    Don’t store tokens in localStorage. It’s wide open to XSS attacks. Use secure, HTTP-only cookies. If a script can read it, an attacker’s script can too.

    Set short expiration times. A JWT that lives forever is a JWT waiting to be stolen. I default to 15 minutes for access tokens, paired with refresh tokens for extended sessions.

    Rotate signing keys. If your signing key is compromised and you’ve been using the same one for two years, every token you’ve ever issued is compromised. Rotate regularly and publish your public keys via a JWKS endpoint.

    Don’t put sensitive data in JWT claims. JWTs are signed, not encrypted (by default). Anyone can decode the payload — they just can’t modify it. Never put passwords, credit card numbers, or PII in claims.

    ⚠️ Security Note: Avoid hardcoding secrets in your codebase. Use environment variables or a proper secrets management system.

    Use established libraries. passport.js for OAuth, jsonwebtoken for JWT. These have been battle-tested by thousands of projects. Rolling your own auth is how security vulnerabilities happen.

    The JWT Revocation Problem (and How to Solve It)

    This is the one thing that trips people up. JWTs are stateless — once issued, the server has no way to “take them back.” If a user logs out or their account is compromised, that JWT is still valid until it expires.

    Two approaches that work:

    • Token blacklist: Maintain a list of revoked token IDs (jti claim) in Redis or similar. Check against it during validation. Yes, this adds state — but only for revoked tokens, not all active ones.
    • Short-lived tokens + refresh tokens: Keep access tokens short (5-15 min). Use long-lived refresh tokens (stored in HTTP-only cookies) to get new access tokens. When you need to revoke, kill the refresh token. The access token dies naturally within minutes.

    I prefer the second approach. It keeps the system mostly stateless while giving you a revocation mechanism that works in practice. The refresh token lives server-side (or in a secure cookie), and revoking it is as simple as deleting it from your store.

    💡 Quick rule of thumb: If you’re building a single app with one backend, you probably just need JWT. If third parties need access to your users’ data, you need OAuth. If you’re running microservices, you likely want both.
    🛠️ Recommended Resources:

    Tools and books I’ve actually used or referenced while working on auth systems:

    Get daily AI-powered market intelligence. Join Alpha Signal — free market briefs, security alerts, and dev tool recommendations.

    Frequently Asked Questions

    What is the main difference between OAuth and JWT?

    OAuth is a protocol for delegated authorization, managing token issuance and revocation, while JWT is a signed, self-contained data format used to carry claims and validate them locally.

    Can OAuth use JWT as its token format?

    Yes, OAuth can use JWT as its token format, but JWT also exists independently and can be used standalone for stateless session management.

    When should developers use OAuth?

    Developers should use OAuth when third-party services are involved, such as social logins or API integrations, as it provides a secure framework for delegating access without sharing passwords.

    Why is JWT preferred in microservices architectures?

    JWT is preferred in microservices because it enables lightweight, stateless authentication, allowing tokens to be validated locally without requiring network round-trips to an authorization server.

    References

    1. RFC Editor — “The OAuth 2.0 Authorization Framework (RFC 6749)”
    2. RFC Editor — “JSON Web Token (JWT) (RFC 7519)”
    3. OWASP — “JSON Web Token (JWT) Cheat Sheet”
    4. NIST — “Digital Identity Guidelines: Authentication and Lifecycle Management (SP 800-63B)”
    5. Auth0 — “OAuth 2.0 and OpenID Connect: An Overview”
    📋 Disclosure: Some links above are affiliate links. If you purchase through these links, I earn a small commission at no extra cost to you. I only recommend products I’ve personally used or thoroughly evaluated. This helps support orthogonal.info and keeps the content free.

    References

    1. IETF RFC 6749 — The OAuth 2.0 Authorization Framework
    2. IETF RFC 7519 — JSON Web Token (JWT)
    3. OWASP — Web Security Testing Guide
    4. OWASP — Authentication Cheat Sheet
    5. GitHub Docs — Authentication
  • PassForge: Building a Password Workstation Beyond One Slider

    PassForge: Building a Password Workstation Beyond One Slider

    I was setting up a new server last week and needed twelve unique passwords for different services. I opened three tabs — LastPass’s generator, Bitwarden’s generator, and 1Password’s online tool. Every single one gave me a barebones interface: one slider for length, a few checkboxes, and a single output. Copy, switch tabs, paste, repeat. Twelve times.

    That’s when I decided to build PassForge — a password workstation that handles everything in one place: random passwords, memorable passphrases, strength testing, and bulk generation. All running in your browser with zero data leaving your machine.

    What makes PassForge different

    📌 TL;DR: PassForge is a browser-based password workstation that offers advanced features like random password generation, memorable passphrase creation, strength testing, and bulk generation. It prioritizes cryptographic randomness, operates entirely offline, and is built as a lightweight, single HTML file with no external dependencies.
    🎯 Quick Answer: PassForge is a free, browser-based password workstation that combines random password generation, passphrase creation, strength testing, and bulk generation in one tool—all processing happens locally with zero server uploads.

    Most password generators solve one narrow problem: they spit out a random string. PassForge treats passwords as a workflow with four distinct modes.

    Password Generator handles the classic use case — random character strings with fine-grained control. You pick a length from 4 to 128 characters, toggle character sets (uppercase, lowercase, digits, symbols), and optionally exclude ambiguous characters like O/0 and l/1/I. Every generated password pulls from crypto.getRandomValues(), not Math.random(), so you get real cryptographic randomness.

    Passphrase Generator is where things get interesting. Instead of random characters, it builds multi-word phrases from a curated 1,296-word dictionary (based on the EFF short wordlist). A 5-word passphrase like “Bold-Crane-Melt-Surf-Knot” carries about 52 bits of entropy — comparable to a random 10-character password — but you can actually remember it. You can pick separator style (dash, dot, underscore, space), capitalize words, and optionally append a number or symbol for sites with strict requirements.

    Strength Tester lets you paste any existing password and get an honest assessment. It calculates entropy, estimates crack time assuming a 10-billion-guesses-per-second GPU cluster, and runs pattern analysis for repeated characters, sequential sequences, and character diversity. The visibility toggle lets you inspect the password without exposing it to shoulder surfers by default.

    Bulk Generator solves my original problem — generating many passwords at once. Slider from 2 to 50, choice between random passwords and passphrases, click any row to copy it, or hit “Copy All” to get the entire batch on your clipboard separated by newlines.

    How it actually works under the hood

    The entire app is a single HTML file — 40KB total, zero external dependencies. No frameworks, no CDN requests, no analytics pixels. When you open it, you get first paint in under 100ms because there’s nothing to fetch.

    Cryptographic randomness

    Every random value in PassForge comes from the Web Crypto API. The cryptoRandInt(max) function creates a Uint32Array, fills it with crypto-grade random bytes, and takes the modulus. For shuffling (ensuring character set distribution), I use the Fisher-Yates algorithm with crypto random indices.

    function cryptoRandInt(max) {
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return arr[0] % max;
}

    The password generator guarantees at least one character from each active set, then fills the remaining length from the combined pool, then shuffles the entire result. This prevents the “first 4 chars are always one-from-each-set” pattern that weaker generators produce.

    Entropy calculation

    Entropy is calculated as length × log₂(poolSize), where pool size is determined by which character classes appear in the password. For passphrases, it’s wordCount × log₂(dictionarySize) — with our 1,296-word list, each word adds about 10.34 bits.

    The crack time estimate assumes a high-end adversary: 10 billion guesses per second, which is what a multi-GPU rig running Hashcat can achieve against fast hashes like MD5. Against bcrypt or Argon2, actual crack times would be orders of magnitude longer. I chose the aggressive estimate because your password should be strong even against the worst-case scenario.

    The strength tester’s pattern analysis

    Beyond raw entropy, the tester checks for real weaknesses:

    • Repeated characters — catches “aaa” or “111” runs (regex: /(.){2,}/)
    • Sequential characters — detects keyboard walks like “abc”, “123”, or “qwerty” substrings
    • Character diversity — unique characters as a percentage of total length; below 50% is a red flag
    • Missing character classes — flags when uppercase, lowercase, digits, or symbols are absent

    Each check produces a clear pass/fail with a specific tip for improvement, not just a vague “make it stronger” message.

    Design decisions I’m opinionated about

    Dark mode is automatic. PassForge reads prefers-color-scheme and switches themes without any toggle button. If your OS says dark, you get dark. No cookie banners, no preference dialogs.

    Every output is one-click copy. Click the password box, click a bulk list row, click the passphrase — they all copy to clipboard with a 2-second toast confirmation. No separate copy button hunting.

    Touch targets are 44px minimum. Every interactive element — tabs, checkboxes, sliders, buttons — meets Apple’s Human Interface Guidelines for minimum touch target size. This matters when you’re generating a password on your phone in a coffee shop.

    Keyboard navigation works throughout. Tabs use arrow keys. Checkboxes respond to Space and Enter. Ctrl+G generates a new password regardless of which tab you’re on. Focus states are visible.

    PWA-installable. PassForge includes a service worker and web manifest, so you can “Add to Home Screen” on mobile or install it as a desktop app. It works offline after the first load — your password generator should never depend on an internet connection.

    When you’d actually use each mode

    Password mode — database credentials, API keys, service accounts, anything a machine reads. Max length, all character sets, exclude ambiguous.

    Passphrase mode — your primary email, password manager master password, full-disk encryption. Anything you type by hand and need to remember.

    Strength tester — auditing existing passwords. Paste your current bank password and find out if it’s actually as strong as you assumed.

    Bulk mode — provisioning new infrastructure, creating test accounts, rotating credentials across services.

    Privacy is structural, not promised

    PassForge doesn’t have analytics. It doesn’t make network requests after loading. There’s no server-side component to hack, no database to breach, no logs to subpoena. Open your browser’s network tab while using it — you’ll see exactly zero requests. Your passwords exist in your browser’s memory and nowhere else.

    This isn’t a privacy policy I wrote to sound good. It’s a consequence of the architecture: single HTML file, no backend, no external scripts.

    Try it

    PassForge is free and ready to use right now. If you find it useful, I’d appreciate a .

    If you work with passwords daily — sysadmin, developer, IT support — bookmark it. It’s built to be the one password tool you keep open.

    Related tools and reads:

    • HashForge — generate and verify MD5/SHA/HMAC hashes, all in your browser
    • DiffLab — compare text diffs without uploading anything
    • RegexLab — test regex patterns with a multi-case runner
    • YubiKey SSH Authentication — pair PassForge with hardware security keys for real protection
    • Browser Fingerprinting — why strong passwords alone aren’t enough for online privacy

    Equip your setup with reliable gear: a YubiKey 5C NFC for hardware-backed 2FA, a mechanical keyboard for comfortable password entry, and a privacy screen protector to keep shoulder surfers away.

    References

    1. Mozilla Developer Network — “Window.crypto.getRandomValues()”
    2. OWASP — “Password Storage Cheat Sheet”
    3. NIST — “Digital Identity Guidelines: Authentication and Lifecycle Management (SP 800-63B)”
    4. GitHub — “PassForge Repository”
    5. Bitwarden — “Password Generator Documentation”

    Frequently Asked Questions

    What makes PassForge different from other password generators?

    PassForge treats passwords as a workflow, offering multiple modes including random password generation, memorable passphrases, strength testing, and bulk generation. It uses cryptographic randomness and operates entirely offline for enhanced security.

    How does PassForge ensure security during password generation?

    PassForge uses the Web Crypto API for cryptographic randomness, ensuring high-quality random values. Since it runs entirely in the browser without external dependencies, no data leaves your machine.

    Can PassForge generate memorable passphrases?

    Yes, PassForge can generate multi-word passphrases using a curated dictionary. These passphrases are designed to be both secure and easy to remember, with customizable separators and optional symbols or numbers.

    Does PassForge support bulk password generation?

    Yes, PassForge includes a Bulk Generator mode that can create up to 50 passwords or passphrases at once. You can copy individual entries or export the entire batch to your clipboard.

  • YubiKey SSH Authentication: Stop Trusting Key Files on Disk

    YubiKey SSH Authentication: Stop Trusting Key Files on Disk

    I stopped using SSH passwords three years ago. Switched to ed25519 keys, felt pretty good about it. Then my laptop got stolen from a coffee shop — lid open, session unlocked. My private key was sitting right there in ~/.ssh/, passphrase cached in the agent.

    That’s when I bought my first YubiKey.

    Why a Hardware Key Beats a Private Key File

    📌 TL;DR: YubiKey provides secure SSH authentication by storing private keys on hardware, preventing extraction or misuse even if a device is stolen or compromised. Unlike disk-stored keys, YubiKey requires physical touch for authentication, adding an extra layer of security. It supports FIDO2/resident keys and works across devices with USB-C or NFC options.
    🎯 Quick Answer: YubiKey SSH authentication stores your private key on tamper-resistant hardware so it cannot be copied or extracted, even if your machine is compromised. Configure it via ssh-keygen -t ed25519-sk to bind SSH keys to the physical device.

    Your SSH private key lives on disk. Even if it’s passphrase-protected, once the agent unlocks it, it’s in memory. Malware can dump it. A stolen laptop might still have an active agent session. Your key file can be copied without you knowing.

    A YubiKey stores the private key on the hardware. It never leaves the device. Every authentication requires a physical touch. No touch, no auth. Someone steals your laptop? They still need the physical key plugged in and your finger on it.

    That’s the difference between “my key is encrypted” and “my key literally cannot be extracted.”

    Which YubiKey to Get

    For SSH, you want a YubiKey that supports FIDO2/resident keys. Here’s what I’d recommend:

    YubiKey 5C NFC — my top pick. USB-C fits modern laptops, and the NFC means you can tap it on your phone for GitHub/Google auth too. Around $55, and I genuinely think it’s the best value if you work across multiple devices. (Full disclosure: affiliate link)

    If you’re on a tighter budget, the YubiKey 5 NFC (USB-A) does the same thing for about $50, just with the older port. Still a good option if your machines have USB-A.

    One important note: buy two. Register both with every service. Keep one on your keychain, one locked in a drawer. If you lose your primary, you’re not locked out of everything. I learned this the hard way with a 2FA lockout that took three days to resolve.

    Setting Up SSH with FIDO2 Resident Keys

    You need OpenSSH 8.2+ (check with ssh -V). Most modern distros ship with this. If you’re on macOS, the built-in OpenSSH works fine since Ventura.

    First, generate a resident key stored directly on the YubiKey:

    ssh-keygen -t ed25519-sk -O resident -O verify-required -C "yubikey-primary"

    Breaking this down:

    • -t ed25519-sk — uses the ed25519 algorithm backed by a security key (sk = security key)
    • -O resident — stores the key on the YubiKey, not just a reference to it
    • -O verify-required — requires PIN + touch every time (not just touch)
    • -C "yubikey-primary" — label it so you know which key this is

    It’ll ask you to set a PIN if you haven’t already. Pick something decent — this is your second factor alongside the physical touch.

    You’ll end up with two files: id_ed25519_sk and id_ed25519_sk.pub. The private file is actually just a handle — the real private key material lives on the YubiKey. Even if someone gets this file, it’s useless without the physical hardware.

    Adding the Key to Remote Servers

    Same as any SSH key:

    ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@your-server

    Or manually append the public key to ~/.ssh/authorized_keys on the target machine.

    When you SSH in, you’ll see:

    Confirm user presence for key ED25519-SK SHA256:...
User presence confirmed

    That “confirm user presence” line means it’s waiting for you to physically tap the YubiKey. No tap within ~15 seconds? Connection refused. I love this — it’s impossible to accidentally leave a session auto-connecting in the background.

    The Resident Key Trick: Any Machine, No Key Files

    This is the feature that sold me. Because the key is resident (stored on the YubiKey itself), you can pull it onto any machine:

    ssh-keygen -K

    That’s it. Plug in your YubiKey, run that command, and it downloads the key handles to your current machine. Now you can SSH from a fresh laptop, a coworker’s machine, or a server — as long as you have the YubiKey plugged in.

    No more syncing ~/.ssh folders across machines. No more “I need to get my key from my other laptop.” The YubiKey is the key.

    Hardening sshd for Key-Only Auth

    Once your YubiKey is working, lock down the server. In /etc/ssh/sshd_config:

    PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

    Reload sshd (systemctl reload sshd) and test with a new terminal before closing your current session. I’ve locked myself out exactly once by reloading before testing. Don’t be me.

    If you want to go further, you can restrict to only FIDO2 keys by requiring the sk key types in your authorized_keys entries. But for most setups, just disabling passwords is the big win.

    What About Git and GitHub?

    GitHub has supported security keys for SSH since late 2021. Add your id_ed25519_sk.pub in Settings → SSH Keys, same as any other key.

    Every git push and git pull now requires a physical touch. It adds maybe half a second to each operation. I was worried this would be annoying — it’s actually reassuring. Every push is a conscious decision.

    For your Git config, make sure you’re using the SSH URL format:

    git remote set-url origin [email protected]:username/repo.git

    Gotchas I Hit

    Agent forwarding doesn’t work with FIDO2 keys. The touch requirement is local — you can’t forward it through an SSH jump host. If you rely on agent forwarding, you’ll need to either set up ProxyJump or keep a regular ed25519 key for jump scenarios.

    macOS Sonoma has a quirk where the built-in SSH agent sometimes doesn’t prompt for the touch correctly. Fix: add SecurityKeyProvider internal to your ~/.ssh/config.

    WSL2 can’t see USB devices by default. You’ll need usbipd-win to pass the YubiKey through. It works fine once set up, but the initial config is a 10-minute detour.

    VMs need USB passthrough configured. In VirtualBox, add a USB filter for “Yubico YubiKey.” In QEMU/libvirt, use hostdev passthrough. This catches people off guard when they SSH from inside a VM and wonder why the key isn’t detected.

    My Setup

    I carry a YubiKey 5C NFC on my keychain and keep a backup YubiKey 5 Nano in my desk. The Nano stays semi-permanently in my desktop’s USB port — it’s tiny enough that it doesn’t stick out. (Full disclosure: affiliate links)

    Both keys are registered on every server, GitHub, and every service that supports FIDO2. If I lose my keychain, I walk to my desk and keep working.

    Total cost: about $80 for two keys. For context, that’s less than a month of most password manager premium plans, and it protects against a class of attacks that passwords simply can’t.

    Should You Bother?

    If you SSH into anything regularly — servers, homelabs, CI runners — yes. The setup takes 15 minutes, and the daily friction is a light tap on a USB device. The protection you get (key material that physically can’t be stolen remotely) is worth way more than the cost.

    If you’re already running a homelab with TrueNAS or managing Docker containers, this is a natural next step in locking things down. Hardware keys fill the gap between “I use SSH keys” and “my infrastructure is actually secure.”

    Start with one key, test it for a week, then buy the backup. You won’t go back.

    Join Alpha Signal for free market intelligence — daily briefings on tech, AI, and the markets that drive them.

    📚 Related Reading

    References

    1. Yubico — “Using Your YubiKey with SSH”
    2. OWASP — “Authentication Cheat Sheet”
    3. GitHub — “YubiKey-SSH Configuration Guide”
    4. NIST — “Digital Identity Guidelines”
    5. RFC Editor — “RFC 4253: The Secure Shell (SSH) Transport Layer Protocol”

    Frequently Asked Questions

    Why is YubiKey more secure than storing SSH keys on disk?

    YubiKey stores the private key on hardware, ensuring it cannot be extracted or copied. Authentication requires physical touch, preventing unauthorized access even if a device is stolen or compromised.

    What type of YubiKey is recommended for SSH authentication?

    The YubiKey 5C NFC is recommended for its USB-C compatibility and NFC functionality, making it versatile for both laptops and phones. The YubiKey 5 NFC (USB-A) is a budget-friendly alternative for older devices.

    How do you set up SSH authentication with a YubiKey?

    You need OpenSSH 8.2+ to generate a resident key stored on the YubiKey using `ssh-keygen`. The key requires PIN and physical touch for authentication, and the public key can be added to remote servers for access.

    What precautions should be taken when using YubiKey for SSH?

    It’s recommended to buy two YubiKeys: one for daily use and one as a backup. Register both with all services to avoid lockouts in case of loss or damage.

  • Browser Fingerprinting: Identify You Without Cookies

    Browser Fingerprinting: Identify You Without Cookies

    Last month I was debugging a tracking issue for a client and realized something uncomfortable: even after clearing all cookies and using a fresh incognito window, a third-party analytics script was still identifying the same user session. No cookies, no localStorage, no URL parameters. Just JavaScript reading properties that every browser willingly exposes.

    Browser fingerprinting isn’t new, but most developers I talk to still underestimate how effective it is. The EFF’s Cover Your Tracks project found that 83.6% of browsers have a unique fingerprint. Not “somewhat unique” — unique. One in a million. And that number climbs to over 94% if you include Flash or Java metadata (though those are mostly dead now).

    I spent a weekend building a fingerprinting test page to understand exactly what data points create this uniqueness. Here’s what I found.

    The Canvas API: Your GPU’s Signature

    📌 TL;DR: Browser fingerprinting allows websites to uniquely identify users without cookies by leveraging browser-exposed properties like Canvas and Audio APIs. These techniques exploit hardware and software variations to generate unique identifiers, making privacy protection more challenging. Studies show that over 83% of browsers have unique fingerprints, highlighting its effectiveness.
    🎯 Quick Answer: Browser fingerprinting uniquely identifies users without cookies by combining Canvas rendering, AudioContext output, WebGL parameters, and installed fonts into a hash. Studies show this technique can uniquely identify over 90% of browsers.

    This is the technique that surprised me most. The HTML5 Canvas API renders text and shapes slightly differently depending on your GPU, driver version, OS font rendering engine, and anti-aliasing settings. The differences are invisible to the eye but consistent across page loads.

    Here’s a minimal Canvas fingerprint in 12 lines:

    function getCanvasFingerprint() {
  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');
  ctx.textBaseline = 'top';
  ctx.font = '14px Arial';
  ctx.fillStyle = '#f60';
  ctx.fillRect(125, 1, 62, 20);
  ctx.fillStyle = '#069';
  ctx.fillText('Browser fingerprint', 2, 15);
  ctx.fillStyle = 'rgba(102, 204, 0, 0.7)';
  ctx.fillText('Browser fingerprint', 4, 17);
  return canvas.toDataURL();
}

    That toDataURL() call returns a base64 string representing the rendered pixels. On my M2 MacBook running Chrome 124, this produces a hash that differs from the same code on Chrome 124 on my Intel Linux box. Same browser version, same text, different pixel output.

    Why? The font rasterizer (FreeType vs Core Text vs DirectWrite), sub-pixel rendering settings, and GPU shader behavior all introduce tiny variations. A 2016 Princeton study tested this across 1 million browsers and found Canvas fingerprinting alone could identify about 50% of users — no cookies needed.

    AudioContext: Your Sound Card Leaks Too

    This one is less well-known. The Web Audio API processes audio signals with slight floating-point variations depending on the hardware and driver stack. You don’t even need to play a sound:

    async function getAudioFingerprint() {
  const ctx = new (window.OfflineAudioContext ||
    window.webkitOfflineAudioContext)(1, 44100, 44100);
  const oscillator = ctx.createOscillator();
  oscillator.type = 'triangle';
  oscillator.frequency.setValueAtTime(10000, ctx.currentTime);

  const compressor = ctx.createDynamicsCompressor();
  compressor.threshold.setValueAtTime(-50, ctx.currentTime);
  compressor.knee.setValueAtTime(40, ctx.currentTime);
  compressor.ratio.setValueAtTime(12, ctx.currentTime);

  oscillator.connect(compressor);
  compressor.connect(ctx.destination);
  oscillator.start(0);
  
  const buffer = await ctx.startRendering();
  const data = buffer.getChannelData(0);
  // Hash the first 4500 samples
  return data.slice(0, 4500).reduce((a, b) => a + Math.abs(b), 0);
}

    The resulting float sum varies by sound card and audio driver. Combined with Canvas, you’re looking at roughly 70-80% unique identification rates. I tested this on three machines in my homelab — all running Debian 12, all with different audio chipsets — and got three distinct values.

    WebGL: GPU Model Exposed

    WebGL goes further than Canvas. It exposes your GPU vendor, renderer string, and supported extensions. Most browsers serve this up without hesitation:

    function getWebGLInfo() {
  const canvas = document.createElement('canvas');
  const gl = canvas.getContext('webgl');
  const debugInfo = gl.getExtension('WEBGL_debug_renderer_info');
  return {
    vendor: gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL),
    renderer: gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL),
    extensions: gl.getSupportedExtensions().length
  };
}

    On my machine this returns Apple / Apple M2 / 47 extensions. That renderer string alone narrows the pool considerably. Combine it with the exact list of supported extensions (which varies by driver version) and you’ve got another high-entropy signal.

    The Full Fingerprint Stack

    A real fingerprinting library like FingerprintJS (now Fingerprint.com) combines 30+ signals. Here are the ones that contribute the most entropy, based on my testing:

    Signal Entropy (bits) How It Works
    User-Agent string ~10 OS + browser + version
    Canvas hash ~8-10 GPU + font rendering
    WebGL renderer ~7 GPU model + driver
    Installed fonts ~6-8 Font enumeration via CSS
    Screen resolution + DPR ~5 Monitor + scaling
    AudioContext ~5-6 Audio processing differences
    Timezone + locale ~4 Intl API
    WebGL extensions ~4 Supported GL features
    Navigator properties ~3 hardwareConcurrency, deviceMemory
    Color depth + touch support ~2 display.colorDepth, maxTouchPoints

    Add those up and you’re at roughly 54-63 bits of entropy. You need about 33 bits to uniquely identify someone in a pool of 8 billion. We’re at nearly double that.

    What Actually Defends Against This

    I tested four approaches on my fingerprinting test page. Here’s my honest assessment:

    Brave Browser — Best out-of-the-box protection. Brave randomizes Canvas and WebGL output on every session (adds noise to the rendered pixels). AudioContext gets similar treatment. In my tests, Brave generated a different fingerprint hash on every page load. The tradeoff: some sites that rely on Canvas for legitimate purposes (online editors, games) may behave slightly differently. I haven’t hit real issues with this in daily use.

    Firefox with privacy.resistFingerprinting — Setting privacy.resistFingerprinting = true in about:config spoofs many signals: timezone reports UTC, screen resolution reports the CSS viewport size, user-agent becomes generic. It’s effective but aggressive — it broke two web apps I use daily (a video editor and a mapping tool) because they relied on accurate screen dimensions.

    Tor Browser — The gold standard. Every Tor user presents an identical fingerprint by design. Canvas, WebGL, fonts, screen size — all normalized. But you’re trading performance (Tor routing adds 2-5x latency) and compatibility (many sites block Tor exit nodes).

    Browser extensions (Canvas Blocker, etc.) — Ironically, these can make you more unique. If 0.1% of users run Canvas Blocker, and it alters your fingerprint in a detectable way (which it does — the blocking itself is a signal), you’ve just moved from “one in a million” to “one in a thousand who runs this specific extension.” I stopped recommending these after seeing the data.

    A Practical Test You Can Run Right Now

    Visit Cover Your Tracks (EFF) — it runs a fingerprinting test and shows exactly how unique your browser is. Then visit BrowserLeaks.com for a more detailed breakdown of each signal.

    When I ran both tests in Chrome, my fingerprint was unique among their entire dataset. In Brave, it was shared with “a large number of users.” That difference matters.

    What Developers Should Do

    If you’re building analytics or auth systems, understand that fingerprinting exists in a gray area. The GDPR considers device fingerprints personal data (Article 29 Working Party Opinion 9/2014 explicitly says so). California’s CCPA covers “unique identifiers” which includes fingerprints.

    My recommendation for developers:

    • Don’t roll your own fingerprinting for tracking. If you need fraud detection, use a service like Fingerprint.com that handles consent and compliance.
    • Test your own sites with the Canvas fingerprint code above. If you’re embedding third-party scripts, check what data they’re collecting. I found three tracking scripts on a client’s site that were fingerprinting users without disclosure.
    • For your own browsing, switch to Brave. It’s Chromium-based so everything works, and the fingerprint randomization is on by default. I moved my daily driver six months ago and haven’t looked back.

    If you’re working from a home office or homelab and want to take your privacy setup further, a dedicated mini PC running a DNS-level blocker like Pi-hole or AdGuard Home catches a lot of the fingerprinting scripts at the network level before they even reach your browser. I run one on my TrueNAS box and it blocks about 30% of tracking domains across my whole network. If you are building a privacy-conscious homelab, my guide to EXIF data removal covers another vector where personal information leaks without your knowledge. Full disclosure: affiliate link.

    If you want to test what your browser reveals, I built a set of privacy-focused browser tools that run entirely client-side — no data ever leaves your machine. The PixelStrip EXIF remover handles EXIF/metadata stripping, and the DiffLab diff checker compares text without uploading to a server.

    The uncomfortable truth is that cookies were the easy privacy problem. The browser itself — its GPU, its fonts, its audio stack — is the harder one. And most people don’t even know they’re being identified.

    📡 Join Alpha Signal for free market intelligence — I share daily analysis on tech sector moves and trading signals.

    References

    1. Electronic Frontier Foundation (EFF) — “Cover Your Tracks”
    2. OWASP — “Browser Fingerprinting”
    3. ACM Digital Library — “The Web Never Forgets: Persistent Tracking Mechanisms in the Wild”
    4. developer.mozilla.org — “Canvas API”
    5. NIST — “Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) (SP 800-122)”

    Frequently Asked Questions

    What is browser fingerprinting?

    Browser fingerprinting is a technique used to uniquely identify users by analyzing properties exposed by their browser, such as rendering behavior or hardware-specific variations, without relying on cookies or other storage mechanisms.

    How does the Canvas API contribute to fingerprinting?

    The Canvas API generates unique identifiers by rendering text and shapes, which vary slightly based on GPU, driver, OS font rendering, and anti-aliasing settings. These subtle differences create consistent, unique hashes across sessions.

    Can browser fingerprinting identify users across devices?

    Browser fingerprinting primarily identifies users based on device-specific properties, so it is less effective across different devices. However, it can reliably distinguish users on the same device even in incognito mode or after clearing cookies.

    How can users protect themselves from browser fingerprinting?

    Users can reduce fingerprinting risks by using privacy-focused browsers, disabling JavaScript, or employing anti-fingerprinting tools like browser extensions. However, complete protection is difficult due to the inherent nature of exposed browser properties.

    🛠️ Recommended Resources:

    Tools for privacy-conscious developers:

    Full disclosure: affiliate links.

  • CVE-2025-53521: F5 BIG-IP APM RCE — CISA Deadline 3/30

    CVE-2025-53521: F5 BIG-IP APM RCE — CISA Deadline 3/30

    I triaged this CVE for my own perimeter the moment it hit the KEV catalog. If you’re running F5 BIG-IP with APM, here’s what you need to know and do—fast.

    CVE-2025-53521 dropped into CISA’s Known Exploited Vulnerabilities catalog on March 27, and the remediation deadline is March 30. If you’re running F5 BIG-IP with Access Policy Manager (APM), this needs your attention right now.

    Here’s what makes this one ugly: F5 originally classified CVE-2025-53521 as a denial-of-service issue. That classification has since been upgraded to remote code execution (CVSS 9.3) after active exploitation was confirmed in the wild. A vulnerability that many teams deprioritized as “just a DoS” is actually giving attackers code execution on BIG-IP appliances. If your patching decision was based on the original advisory, your risk assessment is wrong.

    The Reclassification: From DoS to Full RCE

    📌 TL;DR: CVE-2025-53521 dropped into CISA’s Known Exploited Vulnerabilities catalog on March 27, and the remediation deadline is March 30 . If you’re running F5 BIG-IP with Access Policy Manager (APM), this needs your attention right now.
    🎯 Quick Answer
    CVE-2025-53521 dropped into CISA’s Known Exploited Vulnerabilities catalog on March 27, and the remediation deadline is March 30 . If you’re running F5 BIG-IP with Access Policy Manager (APM), this needs your attention right now.

    When F5 first published advisory K000156741, CVE-2025-53521 was described as a denial-of-service condition in BIG-IP APM. The attack vector was clear enough — a crafted request to the APM authentication endpoint could crash the Traffic Management Microkernel (TMM). Annoying, but many shops treated it as a lower-priority patch.

    That assessment turned out to be incomplete. Subsequent analysis revealed that the same attack primitive — the malformed request that triggers the TMM crash — can be chained with a memory corruption condition to achieve arbitrary code execution. F5 updated the advisory to reflect this, bumping the CVSS score to 9.3 and reclassifying the impact from availability-only to full confidentiality/integrity/availability compromise.

    The timing here matters. Organizations that triaged this as a medium-severity DoS during the initial disclosure window may have scheduled it for their next maintenance cycle. With active exploitation now confirmed and CISA setting a 3-day remediation deadline, “next maintenance cycle” is too late.

    What We Know About Active Exploitation

    CISA doesn’t add vulnerabilities to the KEV catalog on a whim. The KEV listing confirms that CVE-2025-53521 is being actively exploited in the wild. F5 has published indicators of compromise alongside the updated advisory.

    Based on the available intelligence, here’s what the attack chain looks like:

    1. Initial Access: Attacker sends a specially crafted request to the BIG-IP APM authentication endpoint (typically /my.policy or /f5-w-68747470733a2f2f... APM webtop URLs).
    2. Memory Corruption: The malformed input triggers a buffer handling error in TMM’s APM module, corrupting adjacent memory structures.
    3. Code Execution: The corruption is exploited to redirect execution flow, achieving arbitrary code execution in the TMM process context — which runs as root.
    4. Post-Exploitation: With root-level access on the BIG-IP, the attacker can intercept traffic, extract credentials from APM session tables, modify iRules, or pivot deeper into the network.

    The root-level execution context is what elevates this from bad to critical. TMM handles all data plane traffic on BIG-IP. Owning TMM means owning every connection flowing through the appliance — SSL termination keys, session cookies, authentication tokens, everything.

    Affected Versions and Configurations

    CVE-2025-53521 affects BIG-IP systems running Access Policy Manager. The key conditions:

    • BIG-IP APM must be provisioned and active (if you’re only running LTM without APM, you’re not directly affected)
    • The APM virtual server must be accessible to the attacker — which in most deployments means internet-facing
    • All BIG-IP software versions prior to the patched releases listed in K000156741 are vulnerable

    Check whether APM is provisioned on your BIG-IP:

    # Check APM provisioning status
tmsh list sys provision apm

# If you see "level nominal" or "level dedicated", APM is active
# If you see "level none", APM is not provisioned — you're not affected by this specific CVE

    Check your current BIG-IP version:

    # Show running software version
tmsh show sys version

# Show all installed software images
tmsh show sys software status

    Immediate Detection: Are You Already Compromised?

    Given that exploitation is active and the vulnerability existed before many orgs patched it, assume-breach is the right posture. For a structured approach, see our incident response playbook guide. Here’s what to look for.

    Check TMM Core Files

    Exploitation of this vulnerability typically produces TMM crash artifacts. If your BIG-IP has been restarting TMM unexpectedly, that’s a red flag:

    # Check for recent TMM core dumps
ls -la /var/core/
ls -la /shared/core/

# Review TMM restart history
tmsh show sys tmm-info | grep -i restart

# Check system logs for TMM crashes
grep -i "tmm.*core\|tmm.*crash\|tmm.*restart" /var/log/ltm /var/log/apm | tail -50

    Audit APM Session Logs

    Look for anomalous APM authentication patterns — particularly failed authentications with unusual payload sizes or malformed usernames:

    # Review APM logs for the past 72 hours
grep -E "ERR|CRIT|WARNING" /var/log/apm | tail -100

# Look for unusual APM access patterns
awk '/access_policy/ && /ERR/' /var/log/apm

# Check for oversized requests hitting APM endpoints
grep -i "request.*too.*large\|oversized\|malform" /var/log/ltm /var/log/apm

    Inspect iRules and Configuration Changes

    Post-exploitation activity often involves modifying iRules to maintain persistence or intercept credentials:

    # List all iRules and their modification timestamps
tmsh list ltm rule recursive | grep -E "^ltm rule|last-modified"

# Check for recently modified iRules (compare against your change management records)
find /config -name "*.tcl" -mtime -7 -ls

# Look for suspicious iRule content (credential harvesting patterns)
tmsh list ltm rule recursive | grep -iE "HTTP::header|HTTP::cookie|HTTP::password|b64encode|log local0"

    Review Network-Level IOCs

    F5’s updated advisory K000156741 includes specific network indicators. Cross-reference your firewall and IDS logs against the published IOCs. At minimum, check for:

    # On your perimeter firewall or SIEM, search for:
# - Unusual POST requests to /my.policy endpoints with oversized payloads
# - Connections from your BIG-IP management interface to unexpected external IPs
# - DNS queries from BIG-IP to domains not in your known-good list

# On the BIG-IP itself, check outbound connections:
netstat -an | grep ESTABLISHED | grep -v "$(tmsh list net self all | grep address | awk '{print $2}' | cut -d/ -f1 | tr '
' '\|' | sed 's/|$//')"

    If your network assessment methodology needs updating, Chris McNab’s Network Security Assessment remains the standard reference for systematically auditing network infrastructure — including load balancers and application delivery controllers like BIG-IP. Full disclosure: affiliate link.

    Mitigation: What to Do Right Now

    Priority 1: Patch

    Apply the fixed version from F5’s advisory. This is the only complete remediation. For BIG-IP, the upgrade process:

    # Download the hotfix ISO from downloads.f5.com
# Upload to BIG-IP:
scp BIGIP-*.iso admin@<bigip-mgmt>:/shared/images/

# Install the hotfix (from BIG-IP CLI):
tmsh install sys software hotfix BIGIP-*.iso volume HD1.2

# Verify installation
tmsh show sys software status

# Reboot to the patched volume
tmsh reboot volume HD1.2

    Critical note: If you’re running an HA pair, follow F5’s documented rolling upgrade procedure. Don’t just reboot both units simultaneously.

    Priority 2: If You Can’t Patch Immediately

    If a maintenance window isn’t available in the next 24 hours, apply these compensating controls:

    Restrict APM endpoint access via iRule:

    # Create an iRule to restrict APM access to known IP ranges
# Apply this to your APM virtual server

when HTTP_REQUEST {
    # Only allow APM access from trusted networks
    if { [IP::client_addr] starts_with "10.0.0." ||
         [IP::client_addr] starts_with "192.168.1." ||
         [IP::client_addr] starts_with "172.16.0." } {
        # Allow — trusted internal range
    } else {
        # Log and reject
        log local0. "Blocked APM access from [IP::client_addr] to [HTTP::uri]"
        HTTP::respond 403 content "Access Denied"
    }
}

    Enable APM request size limits (if not already configured):

    # Set maximum header/request sizes to limit exploitation surface
tmsh modify sys httpd max-clients 10
tmsh modify ltm profile http <your-http-profile> enforcement max-header-count 64 max-header-size 32768

    Monitor TMM health aggressively:

    # Set up a cron job to alert on TMM crashes
echo '*/5 * * * * root test -f /var/core/tmm.*.core.gz && logger -p local0.crit "TMM CORE DUMP DETECTED"' >> /etc/cron.d/tmm-monitor

    Priority 3: Harden Your BIG-IP Management Plane

    This vulnerability is a reminder that BIG-IP appliances are high-value targets. Whether or not you’re affected by CVE-2025-53521 specifically, your BIG-IP management interfaces should be locked down:

    • Management port access: Restrict the management interface (typically port 443 on the MGMT interface) to a dedicated management VLAN with strict ACLs. Never expose it to the internet.
    • Self IP lockdown: Use tmsh modify net self <self-ip> allow-service none on self IPs that don’t need management access.
    • Strong authentication: Enforce MFA for all administrative access. YubiKey 5C NFC hardware keys paired with BIG-IP’s RADIUS or TACACS+ integration provide phishing-resistant MFA that doesn’t depend on SMS or TOTP apps. Full disclosure: affiliate link.
    • Audit logging: Send all BIG-IP logs to an external SIEM. If an attacker compromises the appliance, local logs can’t be trusted.

    The Bigger Picture: Why Reclassifications Catch Teams Off Guard

    🔧 From my experience: Severity reclassifications like this one—from DoS to RCE—are more common than people realize. I always patch for the worst plausible impact, not the vendor’s initial assessment. If a bug can read out-of-bounds memory, assume code execution is one creative exploit away.

    CVE-2025-53521 follows a pattern I’ve seen too many times. A vulnerability gets an initial severity rating, teams make patching decisions based on that rating, and then the severity gets bumped weeks later when exploitation research reveals worse impact than originally assessed. By then, the patching priority has been set and budgets have moved on.

    This is the same pattern we saw with CVE-2026-20131 in Cisco FMC — where the exploitation window stretched for 37 days before a patch landed. The Interlock ransomware group used that window to compromise firewall management planes across multiple organizations.

    If you’re a compliance officer or security lead, here’s what this means for your process:

    • Don’t rely solely on initial CVSS scores for patching prioritization. Track advisories for updates and reclassifications.
    • Treat “DoS” vulnerabilities in network appliances seriously. A DoS on your BIG-IP is already a high-impact event. If it gets reclassified to RCE, you’ve lost your remediation window.
    • Subscribe to vendor security advisory feeds directly — don’t wait for your vulnerability scanner to pick up the update in its next database sync.
    • Maintain an inventory of internet-facing appliances and their software versions. You need to know within hours — not days — when a critical advisory drops for something in your perimeter.

    For teams building out their vulnerability management and cloud security programs, Chris Dotson’s Practical Cloud Security covers the operational frameworks for handling exactly this kind of situation — tracking advisories across hybrid infrastructure, building escalation processes, and maintaining asset inventories that actually stay current. Full disclosure: affiliate link.

    Setting Up Proactive Detection

    Beyond the immediate response to CVE-2025-53521, this is a good opportunity to set up detection that will catch the next BIG-IP zero-day (and there will be a next one).

    Suricata/Snort Rules

    If you’re running a network IDS, add rules to monitor APM endpoints for exploitation patterns:

    # Example Suricata rule for anomalous APM requests
# Adjust $EXTERNAL_NET and $BIGIP_APM to match your environment

alert http $EXTERNAL_NET any -> $BIGIP_APM any (
    msg:"POSSIBLE F5 BIG-IP APM Exploitation Attempt - Oversized POST";
    flow:established,to_server;
    http.method; content:"POST";
    http.uri; content:"/my.policy";
    http.request_body; content:"|00|"; depth:1024;
    dsize:>8192;
    classtype:attempted-admin;
    sid:2025535210; rev:1;
)

    SIEM Correlation

    Create correlation rules that tie BIG-IP TMM events to network anomalies:

    # Pseudocode for SIEM correlation
IF (source = "bigip" AND message CONTAINS "tmm" AND severity >= "error")
  AND (within 5 minutes)
  (source = "firewall" AND destination = bigip_mgmt_ip AND direction = "outbound")
THEN
  ALERT "Possible BIG-IP compromise — TMM error followed by outbound connection"
  PRIORITY: CRITICAL

    Understanding the attacker’s perspective is critical for building effective detection. Stuart McClure’s Hacking Exposed 7 walks through network appliance exploitation techniques in detail — knowing how attackers approach these devices helps you build detection that catches real attacks instead of generating noise. Full disclosure: affiliate link.

    What You Should Do Today

    Stop reading and do these, in order:

    1. Check if APM is provisioned on your BIG-IP fleet: tmsh list sys provision apm. If it’s not, you’re not directly affected — but still check K000156741 for related advisories.
    2. Verify your BIG-IP version against the fixed versions in F5 advisory K000156741. If you’re running a vulnerable version, escalate immediately.
    3. Run the detection commands above to check for signs of prior compromise. Pay special attention to TMM core dumps and iRule modifications.
    4. Cross-reference the IOCs from F5’s advisory against your perimeter logs and SIEM data for the past 30 days.
    5. Patch or apply compensating controls before the March 30 CISA deadline. If you’re a federal agency or contractor, BOD 22-01 makes this mandatory. If you’re private sector, treat the deadline as a strong recommendation — CISA set it at 3 days for a reason.
    6. Document your response for your compliance records. Whether you’re SOC 2, PCI DSS, or CMMC, you’ll want evidence that you responded to a KEV-listed vulnerability within the required timeframe.
    7. Review your network appliance patching policy. Consider building a threat model for your perimeter infrastructure. If your current process can’t turn around a critical patch in under 72 hours for perimeter devices, this incident is your evidence for getting that changed.

    The CISA KEV deadline isn’t arbitrary. Active exploitation means somebody is actively scanning for and compromising vulnerable BIG-IP instances right now. Every hour you wait is an hour an attacker might find your unpatched APM endpoint.

    Get it patched. If you want to validate your defenses after patching, our penetration testing guide covers the fundamentals. Then fix the process that let a reclassified RCE sit unpatched in your perimeter.

    References

    1. CISA — “Known Exploited Vulnerabilities Catalog”
    2. F5 Networks — “K000156741: BIG-IP APM Vulnerability CVE-2025-53521 Advisory”
    3. MITRE — “CVE-2025-53521”
    4. NIST — “National Vulnerability Database Entry for CVE-2025-53521”
    5. OWASP — “Remote Code Execution (RCE) Overview”

    Frequently Asked Questions

    What is CVE-2025-53521: F5 BIG-IP APM RCE — CISA Deadline 3/30 about?

    CVE-2025-53521 dropped into CISA’s Known Exploited Vulnerabilities catalog on March 27, and the remediation deadline is March 30 . If you’re running F5 BIG-IP with Access Policy Manager (APM), this ne

    Who should read this article about CVE-2025-53521: F5 BIG-IP APM RCE — CISA Deadline 3/30?

    Anyone interested in learning about CVE-2025-53521: F5 BIG-IP APM RCE — CISA Deadline 3/30 and related topics will find this article useful.

    What are the key takeaways from CVE-2025-53521: F5 BIG-IP APM RCE — CISA Deadline 3/30?

    Here’s what makes this one ugly: F5 originally classified CVE-2025-53521 as a denial-of-service issue. That classification has since been upgraded to remote code execution (CVSS 9.3) after active expl

  • CVE-2026-3055: Citrix NetScaler Token Theft — Patch Now

    CVE-2026-3055: Citrix NetScaler Token Theft — Patch Now

    Last Wednesday I woke

    🔧 From my experience: After CitrixBleed, I started running automated config diffs against known-good baselines on a daily cron. It’s a 10-line bash script that’s caught unauthorized changes twice. Don’t wait for the next CVE to build that habit.

    up to three Slack messages from different clients, all asking the same thing: “Is our NetScaler safe?” A new Citrix vulnerability had dropped — CVE-2026-3055 — and by Saturday, CISA had already added it to the Known Exploited Vulnerabilities catalog. That’s a 7-day turnaround from disclosure to confirmed in-the-wild exploitation. If you’re running NetScaler ADC or NetScaler Gateway with SAML configured, stop what you’re doing and patch.

    What CVE-2026-3055 Actually Does

    📌 TL;DR: Last Wednesday I woke up to three Slack messages from different clients, all asking the same thing: “Is our NetScaler safe?” A new Citrix vulnerability had dropped — CVE-2026-3055 — and by Saturday, CISA had already added it to the Known Exploited Vulnerabilities catalog.
    🎯 Quick Answer: CVE-2026-3055 is a critical Citrix NetScaler vulnerability actively exploited in the wild. Patch immediately to the latest NetScaler firmware; if patching is delayed, block external access to the management interface and monitor for indicators of compromise.

    CVE-2026-3055 is an out-of-bounds memory read in Citrix NetScaler ADC and NetScaler Gateway. CVSS 9.3. An unauthenticated attacker sends a crafted request to your SAML endpoint, and your appliance responds by dumping chunks of its memory — including admin session tokens.

    If that sounds familiar, it should. This is the same class of bug that plagued CitrixBleed (CVE-2023-4966) — one of the most exploited vulnerabilities of 2023. The security community is already calling this one “CitrixBleed 3.0,” and I think that’s fair.

    The researchers at watchTowr Labs found that CVE-2026-3055 actually covers two separate memory overread bugs, not one:

    • /saml/login — Attackers send a SAMLRequest payload that omits the AssertionConsumerServiceURL field. The appliance leaks memory contents via the NSC_TASS cookie.
    • /wsfed/passive — A request with a wctx query parameter present but without a value (no = sign) causes the appliance to read from dead memory. The data comes back Base64-encoded in the same NSC_TASS cookie, but without the size limits of the SAML variant.

    In both cases, the leaked memory can contain authenticated session IDs. Grab one of those, and you’ve got full admin access to the appliance. No credentials needed.

    The Timeline Is Ugly

    • March 23, 2026 — Citrix publishes security bulletin CTX696300 disclosing the flaw. They describe it as an internal security review finding.
    • March 27 — watchTowr’s honeypot network detects active exploitation from known threat actor IPs. Defused Cyber observes attackers probing /cgi/GetAuthMethods to fingerprint which appliances have SAML enabled.
    • March 29 — watchTowr publishes a full technical analysis and releases a Python detection script.
    • March 30 — CISA adds CVE-2026-3055 to the KEV catalog. Rapid7 releases a Metasploit module.
    • April 2 — CISA’s deadline for federal agencies to patch or discontinue use. That’s today.

    Four days from disclosure to active exploitation. Six days to a public Metasploit module. This is about as bad as the timeline gets.

    Are You Vulnerable?

    You’re affected if you run on-premise NetScaler ADC or NetScaler Gateway with SAML Identity Provider configured. Cloud-managed instances (Citrix-hosted) are not affected.

    Check your NetScaler config for this string:

    add authentication samlIdPProfile

    If that line exists in your config, you need to patch. If you use SAML SSO through your NetScaler — and plenty of enterprises do — assume you’re in scope.

    Affected versions:

    • NetScaler ADC and Gateway 14.1 before 14.1-66.59
    • NetScaler ADC and Gateway 13.1 before 13.1-62.23
    • NetScaler ADC 13.1-FIPS before 13.1-37.262
    • NetScaler ADC 13.1-NDcPP before 13.1-37.262

    The Exposure Numbers

    The Shadowserver Foundation counted roughly 29,000 NetScaler ADC instances and 2,250 Gateway instances visible on the internet as of March 28. Not all of those are necessarily running SAML, but the attackers already have an automated way to check — that /cgi/GetAuthMethods fingerprinting technique Defused Cyber spotted.

    A quick Shodan check shows the US, Germany, and the UK have the highest exposure counts. If you’re running NetScaler in any of those regions, you’re likely already being probed.

    What watchTowr Calls “Disingenuous”

    This is the part that bothers me. Citrix’s original security bulletin didn’t mention that the flaw was being actively exploited. It described CVE-2026-3055 as a single vulnerability found through “ongoing security reviews.” watchTowr’s analysis showed it was actually two distinct bugs bundled under one CVE, and the disclosure was incomplete about the attack surface.

    watchTowr explicitly called the disclosure “disingenuous.” I tend to agree. When your customers are running edge appliances that handle authentication for their entire organization, underplaying the severity of a memory leak bug — especially one with clear echoes of CitrixBleed — isn’t great.

    Patch Now — Here Are the Fixed Versions

    Upgrade to these versions or later:

    ProductFixed Version
    NetScaler ADC & Gateway 14.114.1-66.59
    NetScaler ADC & Gateway 13.113.1-62.23
    NetScaler ADC 13.1-FIPS13.1-37.262
    NetScaler ADC 13.1-NDcPP13.1-37.262

    If you can’t patch immediately, at minimum disable the SAML IDP profile until you can. But really — patch. Disabling SAML probably breaks your SSO, and your users will notice. Patching and rebooting during a maintenance window is the better path.

    Post-Patch: Check for Compromise

    Patching alone isn’t enough if attackers already hit your appliance. Here’s what I’d check:

    1. Review session logs — Look for unusual admin sessions, especially from IP ranges that don’t match your admin team.
    2. Rotate admin credentials — If session tokens leaked, changing passwords invalidates stolen sessions.
    3. Check for persistence — Past CitrixBleed campaigns dropped web shells and created backdoor accounts. Run a full config diff against a known-good backup.
    4. Inspect NSC_TASS cookies in access logs — Unusually large Base64 values in this cookie are a red flag.
    5. Use watchTowr’s detection script — They published a Python tool specifically for identifying vulnerable instances. Run it against your fleet.

    Why This Pattern Keeps Repeating

    This is the third major Citrix memory leak vulnerability in three years (CitrixBleed in 2023, CitrixBleed2 in 2025, now CVE-2026-3055 in 2026). Each time, the exploitation timeline gets shorter. CitrixBleed took weeks before widespread exploitation. This one took four days.

    The problem is structural: NetScaler sits at the network edge, handles authentication, and touches sensitive data by design. A memory leak in an edge appliance is categorically worse than one in an internal service because the attack surface is the public internet. If you’re running edge appliances from any vendor, you need a patching process that can turn around critical updates in under 48 hours. Not weeks. Not “the next maintenance window.”

    Resources

    Here are the reference books I keep on my desk for situations exactly like this:

    • Network Security Assessment by Chris McNab — the go-to for understanding how attackers probe network appliances. The chapter on SAML/SSO attack surfaces is worth reading right now. (Full disclosure: affiliate link)
    • Hacking Exposed 7 by McClure, Scambray, Kurtz — if you want to understand the attacker’s perspective on edge infrastructure exploitation, this is the classic. (Affiliate link)
    • Practical Cloud Security by Chris Dotson — good coverage of identity federation and why SAML misconfigurations create exploitable gaps. (Affiliate link)

    For hardware-level defense, I’m a fan of YubiKey 5C NFC for hardening admin access. Even if an attacker steals a session token, hardware-backed MFA on your admin accounts adds a second layer they can’t bypass remotely. (Affiliate link)

    What I’d Do This Week

    1. Patch every NetScaler instance. Today, not Friday.
    2. Rotate all admin credentials on patched appliances.
    3. Run the watchTowr detection script against your fleet.
    4. Review your edge appliance patching SLA — if it’s longer than 48 hours for CVSS 9+ flaws, that’s your real vulnerability.
    5. Check whether your SIEM is alerting on anomalous NSC_TASS cookie sizes. If not, add that rule.

    The CISA deadline for federal agencies is today (April 2, 2026). Even if you’re not a federal agency, treat that deadline as yours. The attackers certainly aren’t waiting.

    Related posts:

    Join https://t.me/alphasignal822 for free market intelligence.

    References

    1. CVE Details — “CVE-2026-3055 Details”
    2. Citrix — “Citrix Security Bulletin for CVE-2026-3055”
    3. CISA — “CISA Adds CVE-2026-3055 to Known Exploited Vulnerabilities Catalog”
    4. OWASP — “OWASP Top 10: Insecure Design and Memory Vulnerabilities”
    5. NIST — “NVD Vulnerability Metrics for CVE-2026-3055”

    Frequently Asked Questions

    What is Citrix NetScaler CVE-2026-3055 Exploited: What to Do Now about?

    Last Wednesday I woke up to three Slack messages from different clients, all asking the same thing: “Is our NetScaler safe?” A new Citrix vulnerability had dropped — CVE-2026-3055 — and by Saturday, C

    Who should read this article about Citrix NetScaler CVE-2026-3055 Exploited: What to Do Now?

    Anyone interested in learning about Citrix NetScaler CVE-2026-3055 Exploited: What to Do Now and related topics will find this article useful.

    What are the key takeaways from Citrix NetScaler CVE-2026-3055 Exploited: What to Do Now?

    If you’re running NetScaler ADC or NetScaler Gateway with SAML configured, stop what you’re doing and patch. What CVE-2026-3055 Actually Does CVE-2026-3055 is an out-of-bounds memory read in Citrix Ne

  • Zero Trust for Developers: Simplifying Security

    Zero Trust for Developers: Simplifying Security

    Most Zero Trust guides are theoretical whitepapers that never touch a real network. I’ve actually implemented Zero Trust on my home network — OPNsense firewall with micro-segmented VLANs, mTLS between services, and identity-based access for every endpoint. Here’s how I translate those same principles into developer-friendly patterns that work in production.

    Introduction to Zero Trust

    📌 TL;DR: Learn how to implement Zero Trust principles in a way that empowers developers to build secure systems without relying solely on security teams. Introduction to Zero Trust Everyone talks about Zero Trust like it’s the silver bullet for cybersecurity.
    🎯 Quick Answer
    Learn how to implement Zero Trust principles in a way that empowers developers to build secure systems without relying solely on security teams. Introduction to Zero Trust Everyone talks about Zero Trust like it’s the silver bullet for cybersecurity.

    Everyone talks about Zero Trust like it’s the silver bullet for cybersecurity. But let’s be honest—most explanations are so abstract they might as well be written in hieroglyphics. “Never trust, always verify” is catchy, but what does it actually mean for developers writing code or deploying applications? Here’s the truth: Zero Trust isn’t just a security team’s responsibility—it’s a major change that developers need to embrace.

    Traditional security models relied on perimeter defenses: firewalls, VPNs, and the assumption that anything inside the network was safe. That worked fine in the days of monolithic applications hosted on-premises. But today? With microservices, cloud-native architectures, and remote work, the perimeter is gone. Attackers don’t care about your firewall—they’re targeting your APIs, your CI/CD pipelines, and your developers.

    Zero Trust flips the script. Instead of assuming trust based on location or network, it demands verification at every step. Identity, access, and data flow are scrutinized continuously. For developers, this means building systems where security isn’t bolted on—it’s baked in. And yes, that sounds overwhelming, but stick with me. By the end of this article, you’ll see how Zero Trust can help developers rather than frustrate them.

    Zero Trust is also a response to the evolving threat landscape. Attackers are increasingly sophisticated, Using techniques like phishing, supply chain attacks, and credential stuffing. These threats bypass traditional defenses, making a Zero Trust approach essential. For developers, this means designing systems that assume breaches will happen and mitigate their impact.

    Consider a real-world scenario: a developer deploys a microservice that communicates with other services via APIs. Without Zero Trust, an attacker who compromises one service could potentially access all others. With Zero Trust, each API call is authenticated and authorized, limiting the blast radius of a breach.

    💡 Pro Tip: Think of Zero Trust as a mindset rather than a checklist. It’s about questioning assumptions and continuously verifying trust at every layer of your architecture.

    To get started, developers should familiarize themselves with foundational Zero Trust concepts like least privilege access, identity verification, and continuous monitoring. These principles will guide the practical steps discussed later .

    Why Developers Are Key to Zero Trust Success

    Let’s get one thing straight: Zero Trust isn’t just a security team’s problem. If you’re a developer, you’re on the front lines. Every line of code you write, every API you expose, every container you deploy—these are potential attack vectors. The good news? Developers are uniquely positioned to make Zero Trust work because they control the systems attackers are targeting.

    Here’s the reality: security teams can’t scale. They’re often outnumbered by developers 10 to 1, and their tools are reactive by nature. Developers, on the other hand, are proactive. By integrating security into the development lifecycle, you can catch vulnerabilities before they ever reach production. This isn’t just theory—it’s the essence of DevSecOps.

    Helping developers aligns perfectly with Zero Trust principles. When developers adopt practices like least privilege access, secure coding patterns, and automated security checks, they’re actively reducing the attack surface. It’s not about turning developers into security experts—it’s about giving them the tools and knowledge to make secure decisions without slowing down innovation.

    Take the example of API development. APIs are a common target for attackers because they often expose sensitive data or functionality. By implementing Zero Trust principles like strong authentication and authorization, developers can ensure that only legitimate requests are processed. This proactive approach prevents attackers from exploiting vulnerabilities.

    ⚠️ Common Pitfall: Developers sometimes assume that internal APIs are safe from external threats. In reality, attackers often exploit internal systems once they gain a foothold. Treat all APIs as untrusted.

    Another area where developers play a crucial role is container security. Containers are lightweight and portable, but they can also introduce risks if not properly secured. By using tools like Docker Content Trust and Kubernetes Pod Security Standards, developers can ensure that containers are both functional and secure.

    Practical Steps for Developers to Implement Zero Trust

    Zero Trust sounds great in theory, but how do you actually implement it as a developer? Let’s break it down into actionable steps:

    1. Enforce Least Privilege Access

    ⚠️ Tradeoff: Strict least-privilege RBAC means developers can’t just kubectl exec into any pod to debug. This slows down incident response if you’re not prepared. I solve this with time-boxed elevated access via a simple approval workflow — developers get temporary admin for 30 minutes, fully audited.

    Start by ensuring every service, user, and application has the minimum permissions necessary to perform its tasks. This isn’t just a security best practice—it’s a core principle of Zero Trust.

    
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: read-only-role
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "list"]

    In Kubernetes, for example, you can use RBAC (Role-Based Access Control) to define granular permissions like the example above. Notice how the role only allows read operations on pods—nothing more.

    ⚠️ Security Note: Avoid using wildcard permissions (e.g., “*”). They’re convenient but dangerous in production.

    Least privilege access also applies to database connections. For instance, a service accessing a database should only have permissions to execute specific queries it needs. This limits the damage an attacker can do if the service is compromised.

    2. Implement Strong Identity Verification

    Identity is the cornerstone of Zero Trust. Every request should be authenticated and authorized, whether it’s coming from a user or a service. Use tools like OAuth2, OpenID Connect, or mutual TLS for service-to-service authentication.

    
curl -X POST https://auth.example.com/token \
 -H "Content-Type: application/x-www-form-urlencoded" \
 -d "grant_type=client_credentials&client_id=your-client-id&client_secret=your-client-secret"

    In this example, a service requests an OAuth2 token using client credentials. This ensures that only authenticated services can access your APIs.

    💡 Pro Tip: Rotate secrets and tokens regularly. Use tools like HashiCorp Vault or AWS Secrets Manager to automate this process.

    Mutual TLS is another powerful tool for identity verification. It ensures that both the client and server authenticate each other, providing an additional layer of security for service-to-service communication.

    3. Integrate Security into CI/CD Pipelines

    Don’t wait until production to think about security. Automate security checks in your CI/CD pipelines to catch issues early. Tools like Snyk, Trivy, and Checkov can scan your code, containers, and infrastructure for vulnerabilities.

    
# Example: Scanning a Docker image for vulnerabilities
trivy image your-docker-image:latest

    The output will highlight any known vulnerabilities in your image, allowing you to address them before deployment.

    ⚠️ Security Note: Don’t ignore “low” or “medium” severity vulnerabilities. They’re often exploited in chained attacks.

    Another important step is integrating Infrastructure as Code (IaC) security checks. Tools like Terraform and Pulumi can define your infrastructure, and security scanners can ensure that configurations are secure before deployment.

    Overcoming Common Challenges

    🔍 Lesson learned: When I rolled out Zero Trust network policies on my homelab, I accidentally blocked my own monitoring stack from reaching the metrics endpoints. Lesson: always maintain a “break glass” access path and test network changes in a canary segment first. I now keep a dedicated management VLAN that bypasses segmentation rules for emergency access.

    Let’s address the elephant in the room: Zero Trust can feel overwhelming. Developers often worry about added complexity, performance impacts, and friction with security teams. Here’s how to overcome these challenges:

    Complexity: Start small. You don’t need to overhaul your entire architecture overnight. Begin with one application or service, implement least privilege access, and build from there.

    Performance Impacts: Yes, verifying every request adds overhead, but modern tools are optimized for this. For example, mutual TLS is fast and secure, and many identity providers offer caching mechanisms to reduce latency.

    Collaboration: Security isn’t a siloed function. Developers and security teams need to work together. Use shared tools and dashboards to ensure visibility and alignment.

    💡 Pro Tip: Host regular “security hackathons” where developers and security teams collaborate to find and fix vulnerabilities.

    Another challenge is developer resistance to change. Security measures can sometimes feel like roadblocks, but framing them as enablers of innovation can help. For example, secure APIs can unlock new business opportunities by building customer trust.

    Monitoring and Incident Response

    Zero Trust isn’t just about prevention—it’s also about detection and response. Developers should implement monitoring tools to detect suspicious activity and automate incident response workflows.

    Use tools like Prometheus and Grafana to monitor metrics and logs in real time. For example, you can set up alerts for unusual API request patterns or spikes in failed authentication attempts.

    
alert:
 name: "High Failed Login Attempts"
 expr: failed_logins > 100
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: "High number of failed login attempts detected"

    Automating incident response is equally important. Tools like PagerDuty and Opsgenie can notify the right teams and trigger predefined workflows when an incident occurs.

    💡 Pro Tip: Regularly simulate incidents to test your monitoring and response systems. This ensures they’re effective when real threats arise.
    🛠️ Recommended Resources:

    Tools and books mentioned in (or relevant to) this article:

    Conclusion and Next Steps

    I run Zero Trust on my own network because it works — not because a vendor told me to. Start with least-privilege access controls and mutual TLS between services. Those two changes alone eliminate most lateral movement attacks. Don’t try to boil the ocean; pick one service, lock it down, learn from it, and expand.

    Here’s what to remember:

    • Zero Trust is a mindset, not just a set of tools.
    • Developers are key to reducing the attack surface.
    • Start with least privilege access and strong identity verification.
    • Automate security checks in your CI/CD pipelines.
    • Collaborate with security teams to align on goals and practices.
    • Monitor systems continuously and prepare for incidents.

    Want to dive deeper into Zero Trust? Check out resources like the NIST Zero Trust Architecture guidelines or explore tools like Istio for service mesh security. Have questions or tips to share? Drop a comment or reach out on Twitter—I’d love to hear your thoughts.

    Frequently Asked Questions

    What is Zero Trust for Developers: Simplifying Security about?

    Learn how to implement Zero Trust principles in a way that empowers developers to build secure systems without relying solely on security teams. Introduction to Zero Trust Everyone talks about Zero Tr

    Who should read this article about Zero Trust for Developers: Simplifying Security?

    Anyone interested in learning about Zero Trust for Developers: Simplifying Security and related topics will find this article useful.

    What are the key takeaways from Zero Trust for Developers: Simplifying Security?

    But let’s be honest—most explanations are so abstract they might as well be written in hieroglyphics. “Never trust, always verify” is catchy, but what does it actually mean for developers writing code

    References

    1. NIST — “Zero Trust Architecture”
    2. OWASP — “OWASP API Security Top 10”
    3. OPNsense — “OPNsense Documentation”
    4. Kubernetes — “Securing Kubernetes Clusters”
    5. GitHub — “Zero Trust Networking with mTLS”
    📋 Disclosure: Some links are affiliate links. If you purchase through these links, I earn a small commission at no extra cost to you. I only recommend products I’ve personally used or thoroughly evaluated. This helps support orthogonal.info and keeps the content free.
    Get daily AI-powered market intelligence. Join Alpha Signal — free market briefs, security alerts, and dev tool recommendations.

    Disclaimer: This article is for educational purposes. Always test security configurations in a staging environment before production deployment.

  • Docker Compose vs Kubernetes: Secure Homelab Choices

    Docker Compose vs Kubernetes: Secure Homelab Choices

    Last year I moved my homelab from a single Docker Compose stack to a K3s cluster. It took a weekend, broke half my services, and taught me more about container security than any course I’ve taken. Here’s what I learned about when each tool actually makes sense—and the security traps in both.

    The real question: how big is your homelab?

    📌 TL;DR: Last year I moved my homelab from a single Docker Compose stack to a K3s cluster. It took a weekend, broke half my services, and taught me more about container security than any course I’ve taken. Here’s what I learned about when each tool actually makes sense—and the security traps in both.
    🎯 Quick Answer: Use Docker Compose for homelabs with fewer than 10 containers—it’s simpler and has a smaller attack surface. Switch to K3s when you need multi-node scheduling, automatic failover, or network policies for workload isolation.

    I ran Docker Compose for two years. Password manager, Jellyfin, Gitea, a reverse proxy, some monitoring. Maybe 12 containers. It worked fine. The YAML was readable, docker compose up -d got everything running in seconds, and I could debug problems by reading one file.

    Then I hit ~25 containers across three machines. Compose started showing cracks—no built-in way to schedule across nodes, no health-based restarts that actually worked reliably, and secrets management was basically “put it in an .env file and hope nobody reads it.”

    That’s when I looked at Kubernetes seriously. Not because it’s trendy, but because I needed workload isolation, proper RBAC, and network policies that Docker’s bridge networking couldn’t give me.

    Docker Compose security: what most people miss

    Compose is great for getting started, but it has security defaults that will bite you. The biggest one: containers run as root by default. Most people never change this.

    Here’s the minimum I run on every Compose service now:

    version: '3.8'
services:
  app:
    image: my-app:latest
    user: "1000:1000"
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '0.5'
    networks:
      - isolated
    logging:
      driver: json-file
      options:
        max-size: "10m"

networks:
  isolated:
    driver: bridge

    The key additions most tutorials skip: read_only: true prevents containers from writing to their filesystem (mount specific writable paths if needed), no-new-privileges blocks privilege escalation, and cap_drop: ALL removes Linux capabilities you almost certainly don’t need.

    Other things I do with Compose that aren’t optional anymore:

    • Network segmentation. Separate Docker networks for databases, frontend services, and monitoring. My Postgres container can’t talk to Traefik directly—it goes through the app layer only.
    • Image scanning. I run Trivy on every image before deploying. One trivy image my-app:latest catches CVEs that would otherwise sit there for months.
    • TLS everywhere. Even internal services get certificates via Let’s Encrypt and Traefik’s ACME resolver.

    Scan your images before they run—it takes 10 seconds and catches the obvious stuff:

    # Quick scan
trivy image my-app:latest

# Fail CI if HIGH/CRITICAL vulns found
trivy image --exit-code 1 --severity HIGH,CRITICAL my-app:latest

    Kubernetes: when the complexity pays off

    I use K3s specifically because full Kubernetes is absurd for a homelab. K3s strips out the cloud-provider bloat and runs the control plane in a single binary. My cluster runs on a TrueNAS box with 32GB RAM—plenty for ~40 pods.

    The security features that actually matter for homelabs:

    RBAC — I can give my partner read-only access to monitoring dashboards without exposing cluster admin. Here’s a minimal read-only role:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: monitoring
  name: dashboard-viewer
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: viewer-binding
  namespace: monitoring
subjects:
- kind: User
  name: reader
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dashboard-viewer
  apiGroup: rbac.authorization.k8s.io

    Network policies — This is the killer feature. In Compose, network isolation is coarse (whole networks). In Kubernetes, I can say “this pod can only talk to that pod on port 5432, nothing else.” If a container gets compromised, lateral movement is blocked.

    Namespaces — I run separate namespaces for media, security tools, monitoring, and databases. Each namespace has its own resource quotas and network policies. A runaway Jellyfin transcode can’t starve my password manager.

    The tradeoff is real though. I spent a full day debugging a network policy that was silently dropping traffic between my app and its database. The YAML looked right. Turned out I had a label mismatch—app: postgres vs app: postgresql. Kubernetes won’t warn you about this. It just drops packets.

    Networking: the part everyone gets wrong

    Whether you’re on Compose or Kubernetes, your reverse proxy config matters more than most security settings. I use Traefik for both setups. Here’s my Compose config for automatic TLS:

    version: '3.8'
services:
  traefik:
    image: traefik:v3.0
    command:
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entryPoint.to=websecure"
      - "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
      - "[email protected]"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    volumes:
      - "./letsencrypt:/letsencrypt"
    ports:
      - "80:80"
      - "443:443"

    Key detail: that HTTP-to-HTTPS redirect on the web entrypoint. Without it, you’ll have services accessible over plain HTTP and not realize it until someone sniffs your traffic.

    For storage, encrypt volumes at rest. If you’re on ZFS (like my TrueNAS setup), native encryption handles this. For Docker volumes specifically:

    # Create a volume backed by encrypted storage
docker volume create --driver local \
  --opt type=none \
  --opt o=bind \
  --opt device=/mnt/encrypted/app-data \
  my_secure_volume

    My Homelab Security Hardening Checklist

    After running both Docker Compose and K3s in production for over a year, I’ve distilled my security hardening into a checklist I apply to every new service. The specifics differ between the two platforms, but the principles are the same: minimize attack surface, enforce least privilege, and assume every container will eventually be compromised.

    Docker Compose hardening — here’s my battle-tested template with every security flag I use. This goes beyond the basics I showed earlier:

    version: '3.8'
services:
  secure-app:
    image: my-app:latest
    user: "1000:1000"
    read_only: true
    security_opt:
      - no-new-privileges:true
      - seccomp:seccomp-profile.json
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE    # Only if binding to ports below 1024
    tmpfs:
      - /tmp:size=64M,noexec,nosuid
      - /run:size=32M,noexec,nosuid
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '0.5'
        reservations:
          memory: 128M
          cpus: '0.1'
    healthcheck:
      test: ["CMD", "wget", "--spider", "-q", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s
    restart: unless-stopped
    networks:
      - app-tier
    volumes:
      - app-data:/data    # Only specific paths are writable
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  app-data:
    driver: local

networks:
  app-tier:
    driver: bridge
    internal: true        # No direct internet access

    The key additions here: seccomp:seccomp-profile.json loads a custom seccomp profile that restricts which syscalls the container can make. The default Docker seccomp profile blocks about 44 syscalls, but you can tighten it further for specific workloads. The tmpfs mounts with noexec prevent anything written to temp directories from being executed—this blocks a whole class of container escape techniques. And internal: true on the network means the container can only reach other containers on the same network, not the internet directly.

    K3s hardening — Kubernetes gives you Pod Security Standards, which replaced the old PodSecurityPolicy. Here’s how I enforce them per-namespace, plus a NetworkPolicy that locks things down:

    # Label the namespace to enforce restricted security standard
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

# NetworkPolicy: only allow specific ingress/egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: strict-app-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: web-frontend
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-system
        - podSelector:
            matchLabels:
              app: traefik
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: api-backend
      ports:
        - protocol: TCP
          port: 3000
    - to:                            # Allow DNS resolution
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

    That NetworkPolicy says: my web frontend can only receive traffic from Traefik on port 8080, can only talk to the API backend on port 3000, and can resolve DNS. Everything else is blocked. If someone compromises the frontend container, they can’t reach the database, can’t reach other namespaces, can’t phone home to an external server.

    For secrets management on K3s, I use SOPS with age encryption. The workflow looks like this:

    # Encrypt a Kubernetes secret with SOPS + age
sops --encrypt --age age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p \
  secret.yaml > secret.enc.yaml

# Decrypt and apply in one step
sops --decrypt secret.enc.yaml | kubectl apply -f -

# In your git repo, .sops.yaml configures which files get encrypted
creation_rules:
  - path_regex: .*\.secret\.yaml$
    age: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

    This means secrets are encrypted at rest in your git repo—no more plaintext passwords in .env files that accidentally get committed. The age key lives only on the nodes that need to decrypt, never in version control.

    Side-by-side comparison:

    • Least privilege: Compose uses cap_drop: ALL + seccomp profiles. K3s uses Pod Security Standards with restricted enforcement.
    • Network isolation: Compose uses internal: true bridge networks. K3s uses NetworkPolicy with explicit allow rules.
    • Secrets: Compose relies on Docker secrets or .env files (weak). K3s uses SOPS-encrypted secrets in git (strong).
    • Resource limits: Both support CPU/memory limits, but K3s adds namespace-level ResourceQuotas for multi-tenant isolation.
    • Runtime protection: Both benefit from Falco, but K3s integrates it as a DaemonSet with richer audit context.

    Monitoring and Incident Response

    I run Prometheus + Grafana on my homelab, and it’s caught three misconfigurations that would have been security holes. One was a container running with --privileged that I’d forgotten to clean up after debugging. Another was a port binding on 0.0.0.0 instead of 127.0.0.1—exposing an admin interface to my entire LAN. The third was a container that had been restarting every 90 seconds for two weeks without anyone noticing.

    Monitoring isn’t just dashboards—it’s your early warning system. Here’s how I set it up differently for Compose vs K3s.

    Docker Compose: healthchecks and restart policies. Every service in my Compose files has a healthcheck. If a service fails its health check three times, Docker restarts it automatically. But I also alert on it, because a service that keeps restarting is usually a symptom of something worse:

    # Prometheus alert rule: container restarting too often
groups:
  - name: container-alerts
    rules:
      - alert: ContainerRestartLoop
        expr: |
          increase(container_restart_count{name!=""}[1h]) > 5
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Container {{ $labels.name }} restarted {{ $value }} times in 1h"
          description: "Possible crash loop or misconfiguration. Check logs with: docker logs {{ $labels.name }}"

      - alert: ContainerHighMemory
        expr: |
          container_memory_usage_bytes / container_spec_memory_limit_bytes > 0.9
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Container {{ $labels.name }} using >90% of memory limit"

      - alert: UnusualOutboundTraffic
        expr: |
          rate(container_network_transmit_bytes_total[5m]) > 10485760
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Container {{ $labels.name }} sending >10MB/s outbound — possible exfiltration"

    That last alert—unusual outbound traffic—has been the most valuable. If a container suddenly starts pushing data out at high volume, something is very wrong. Either it’s been compromised, or there’s a misconfigured backup job hammering your bandwidth.

    Kubernetes: liveness/readiness probes and audit logging. K3s gives you more granular health checks. Liveness probes restart unhealthy pods. Readiness probes remove pods from service endpoints until they’re ready to handle traffic. I also enable the Kubernetes audit log, which records every API call—who did what, when, to which resource:

    # K3s audit policy — log all write operations
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: ""
        resources: ["secrets", "configmaps", "pods"]
  - level: Metadata
    verbs: ["get", "list", "watch"]
  - level: None
    resources:
      - group: ""
        resources: ["events"]

    Log aggregation is the other piece. For Compose, I use Loki with Promtail—it’s lightweight and integrates natively with Grafana. For K3s, I’ve tried both the EFK stack (Elasticsearch, Fluentd, Kibana) and Loki. Honestly, Loki wins for homelabs. EFK is powerful but resource-hungry—Elasticsearch alone wants 2GB+ of RAM. Loki runs on a fraction of that and the LogQL query language is good enough for homelab-scale debugging.

    The key insight: don’t just collect logs, alert on patterns. A container that suddenly starts logging errors at 10x its normal rate is telling you something. Set up Grafana alert rules on log frequency, not just metrics.

    The Migration Path: My Experience

    I started with Docker Compose on a single Synology NAS running 8 containers. Jellyfin, Gitea, Vaultwarden, Traefik, a couple of monitoring tools. Everything lived in one docker-compose.yml, and life was simple. Backups were just ZFS snapshots of the Docker volumes directory.

    Over about 18 months, I added services. A lot of services. By the time I hit 20+ containers, I was running into real problems. The NAS was out of RAM. I added a second machine and tried to coordinate Compose files across both using SSH and a janky deploy script. It sort of worked, but secrets were duplicated in .env files on both machines, there was no service discovery between nodes, and when one machine rebooted, half the stack broke because of hard-coded dependencies.

    That’s when I set up K3s on three nodes: my TrueNAS box as the server node, plus two lightweight worker nodes (old mini PCs I picked up for cheap). The migration took a weekend and broke things in ways I didn’t expect:

    • DNS resolution changed completely. In Compose, container names resolve automatically within the same network. In K3s, you need proper Service definitions and namespace-aware DNS (service.namespace.svc.cluster.local). Half my apps had hardcoded container names.
    • Persistent storage was the biggest pain. Docker volumes “just work” on a single machine. In K3s across nodes, I needed a storage provisioner. I went with Longhorn, which replicates volumes across nodes. The initial sync took hours and I lost one volume because I didn’t set up the StorageClass correctly.
    • Traefik config had to be completely rewritten. Compose labels don’t work in K8s. I had to switch to IngressRoute CRDs. Took me a full evening to get TLS working again.
    • Resource usage went up. K3s itself, plus Longhorn, plus the CoreDNS and metrics-server components—my baseline overhead went from ~200MB to ~1.2GB before running any actual workloads.

    But once it was running, the benefits were immediate. I could drain a node for maintenance and all pods migrated automatically. Secrets were managed centrally with SOPS. Network policies gave me microsegmentation I couldn’t achieve with Compose. And Longhorn meant I had replicated storage—if a disk failed, my data was on two other nodes.

    My current setup is a hybrid approach, and I think this is the pragmatic answer for most homelabbers. Simple, single-purpose services that don’t need HA—like my ad blocker or a local DNS cache—still run on Docker Compose on the TrueNAS host. Anything that needs high availability, multi-node scheduling, or strict network isolation runs on K3s. The K3s cluster handles about 30 pods across the three nodes, while Compose manages another 6-7 lightweight services.

    If I were starting over today, I’d still begin with Compose. The learning curve is gentler, the debugging is easier, and you’ll learn the fundamentals of container networking and security without fighting Kubernetes abstractions. But I’d plan for K3s from day one—keep your configs clean, use environment variables consistently, and document your service dependencies. When you’re ready to migrate, it’ll be a weekend project instead of a week-long ordeal.

    My recommendation: start Compose, graduate to K3s

    If you have fewer than 15 containers on one machine, stick with Docker Compose. Apply the security hardening above, scan your images, segment your networks. You’ll be fine.

    Once you hit multiple nodes, need proper secrets management (not .env files), or want network-policy-level isolation, move to K3s. Not full Kubernetes—K3s. The learning curve is steep for a week, then it clicks.

    I’d also recommend adding Falco for runtime monitoring regardless of which tool you pick. It watches syscalls and alerts on suspicious behavior—like a container suddenly spawning a shell or reading /etc/shadow. Worth the 5 minutes to set up.

    The tools I keep coming back to for this:

    Related posts you might find useful:

    Get daily AI-powered market intelligence. Join Alpha Signal — free market briefs, security alerts, and dev tool recommendations.

    Frequently Asked Questions

    What is Docker Compose vs Kubernetes: Secure Homelab Choices about?

    Last year I moved my homelab from a single Docker Compose stack to a K3s cluster. It took a weekend, broke half my services, and taught me more about container security than any course I’ve taken.

    Who should read this article about Docker Compose vs Kubernetes: Secure Homelab Choices?

    Anyone interested in learning about Docker Compose vs Kubernetes: Secure Homelab Choices and related topics will find this article useful.

    What are the key takeaways from Docker Compose vs Kubernetes: Secure Homelab Choices?

    Here’s what I learned about when each tool actually makes sense—and the security traps in both. The real question: how big is your homelab? I ran Docker Compose for two years.

    References

    1. Docker — “Compose File Reference”
    2. Kubernetes — “K3s Documentation”
    3. OWASP — “Docker Security Cheat Sheet”
    4. NIST — “Application Container Security Guide”
    5. Kubernetes — “Securing a Cluster”
    📦 Disclosure: Some links above are affiliate links. If you buy through them, I earn a small commission at no extra cost to you. I only recommend stuff I actually use. This helps keep orthogonal.info running.
  • CVE-2026-20131: Cisco FMC Zero-Day Exploited by Ransomware

    CVE-2026-20131: Cisco FMC Zero-Day Exploited by Ransomware

    I triaged CVE-2026-20131 for my own network the day it dropped. If you run Cisco FMC anywhere in your environment, this is a stop-what-you’re-doing moment.

    A critical zero-day vulnerability in Cisco Secure Firewall Management Center (FMC) has been actively exploited by the Interlock ransomware group since January 2026 — more than a month before Cisco released a patch. CISA has added CVE-2026-20131 to its Known Exploited Vulnerabilities (KEV) catalog, confirming it is known to be used in ransomware campaigns.

    If your organization runs Cisco FMC or Cisco Security Cloud Control (SCC) for firewall management, this is a patch-now situation. Here’s everything you need to know about the vulnerability, the attack chain, and how to protect your infrastructure.

    What Is CVE-2026-20131?

    📌 TL;DR: A critical zero-day vulnerability in Cisco Secure Firewall Management Center (FMC) has been actively exploited by the Interlock ransomware group since January 2026 — more than a month before Cisco released a patch.

    CVE-2026-20131 is a deserialization of untrusted data vulnerability in the web-based management interface of Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management. According to CISA’s KEV catalog:

    “Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management contain a deserialization of untrusted data vulnerability in the web-based management interface that could allow an unauthenticated, remote attacker to execute arbitrary Java code as root on an affected device.”

    Key details:

    • CVSS Score: 10.0 (Critical — maximum severity)
    • Attack Vector: Network (unauthenticated, remote)
    • Impact: Full root access via arbitrary Java code execution
    • Exploited in the wild: Yes — confirmed ransomware campaigns
    • CISA KEV Added: March 19, 2026
    • CISA Remediation Deadline: March 22, 2026 (already passed)

    The Attack Timeline

    What makes CVE-2026-20131 particularly alarming is the extended zero-day exploitation window:

    Date Event
    ~January 26, 2026 Interlock ransomware begins exploiting the vulnerability as a zero-day
    March 4, 2026 Cisco releases a patch (37 days of zero-day exploitation)
    March 18, 2026 Public disclosure (51 days after first exploitation)
    March 19, 2026 CISA adds to KEV catalog with 3-day remediation deadline

    Amazon Threat Intelligence discovered the exploitation through its MadPot sensor network — a global honeypot infrastructure that monitors attacker behavior. According to reports, an OPSEC blunder by the Interlock attackers (misconfigured infrastructure) exposed their full multi-stage attack toolkit, allowing researchers to map the entire operation.

    Why This Vulnerability Is Especially Dangerous

    Several factors make CVE-2026-20131 a worst-case scenario for network defenders:

    1. No Authentication Required

    Unlike many Cisco vulnerabilities that require valid credentials, this flaw is exploitable by any unauthenticated attacker who can reach the FMC web interface. If your FMC management port is exposed to the internet (or even a poorly segmented internal network), you’re at risk.

    2. Root-Level Code Execution

    The insecure Java deserialization vulnerability grants the attacker root access — the highest privilege level. From there, they can:

    • Modify firewall rules to create persistent backdoors
    • Disable security policies across your entire firewall fleet
    • Exfiltrate firewall configurations (which contain network topology, NAT rules, and VPN configurations)
    • Pivot to connected Firepower Threat Defense (FTD) devices
    • Deploy ransomware across the managed network

    3. Ransomware-Confirmed

    CISA explicitly notes this vulnerability is “Known to be used in ransomware campaigns” — one of the more severe classifications in the KEV catalog. Interlock is a ransomware operation known for targeting enterprise environments, making this a direct threat to business continuity.

    4. Firewall Management = Keys to the Kingdom

    Cisco FMC is the centralized management platform for an organization’s entire firewall infrastructure. Compromising it is equivalent to compromising every firewall it manages. The attacker doesn’t just get one box — they get the command-and-control plane for network security.

    Who Is Affected?

    Organizations running:

    • Cisco Secure Firewall Management Center (FMC) — any version prior to the March 4 patch
    • Cisco Security Cloud Control (SCC) — cloud-managed firewall environments
    • Any deployment where the FMC web management interface is network-accessible

    This includes enterprises, managed security service providers (MSSPs), government agencies, and any organization using Cisco’s enterprise firewall platform.

    Immediate Actions: How to Protect Your Infrastructure

    Step 1: Patch Immediately

    Apply Cisco’s security update released on March 4, 2026. If you haven’t patched yet, you are 8+ days past CISA’s remediation deadline. This should be treated as an emergency change.

    Step 2: Restrict FMC Management Access

    The FMC web interface should never be exposed to the internet. Implement strict network controls:

    • Place FMC management interfaces on a dedicated, isolated management VLAN
    • Use ACLs to restrict access to authorized administrator IPs only
    • Require hardware security keys (YubiKey 5 NFC) for all FMC administrator accounts
    • Consider a jump box or VPN-only access model for FMC management

    Step 3: Hunt for Compromise Indicators

    Given the 37+ day zero-day window, assume-breach and investigate:

    • Review FMC audit logs for unauthorized configuration changes since January 2026
    • Check for unexpected admin accounts or modified access policies
    • Look for anomalous Java process execution on FMC appliances
    • Inspect firewall rules for unauthorized modifications or new NAT/access rules
    • Review VPN configurations for backdoor tunnels

    Step 4: Implement Network Monitoring

    Deploy network security monitoring to detect exploitation attempts:

    • Monitor for unusual HTTP/HTTPS traffic to FMC management ports
    • Alert on Java deserialization payloads in network traffic (tools like Suricata with Java deserialization rules)
    • Use network detection tools — The Practice of Network Security Monitoring by Richard Bejtlich is the definitive guide for building detection capabilities

    Step 5: Review Your Incident Response Plan

    If you don’t have a tested incident response plan for firewall compromise scenarios, now is the time. A compromised FMC means your attacker potentially controls your entire network perimeter. Resources:

    Hardening Your Cisco Firewall Environment

    🔧 From my experience: Firewall management consoles are the keys to the kingdom, yet I routinely see them exposed on flat networks with password-only auth. Isolate your FMC on a dedicated management VLAN, enforce hardware MFA, and treat it like you’d treat your domain controller—because to an attacker, it’s even more valuable.

    Beyond patching CVE-2026-20131, use this incident as a catalyst to strengthen your overall firewall security posture:

    Management Plane Isolation

    • Dedicate a physically or logically separate management network for all security appliances
    • Never co-mingle management traffic with production data traffic
    • Use out-of-band management where possible

    Multi-Factor Authentication

    Enforce MFA for all FMC access. FIDO2 hardware security keys like the YubiKey 5 NFC provide phishing-resistant authentication that’s significantly stronger than SMS or TOTP codes. Every FMC admin account should require a hardware key.

    Configuration Backup and Integrity Monitoring

    • Maintain offline, encrypted backups of all FMC configurations on Kingston IronKey encrypted USB drives
    • Implement configuration integrity monitoring to detect unauthorized changes
    • Store configuration hashes in a separate system that attackers can’t modify from a compromised FMC

    Network Segmentation

    Ensure proper segmentation so that even if FMC is compromised, lateral movement is contained. For smaller environments and homelabs, GL.iNet travel VPN routers provide affordable network segmentation with WireGuard/OpenVPN support.

    The Bigger Picture: Firewall Management as an Attack Surface

    CVE-2026-20131 is a stark reminder that security management infrastructure is itself an attack surface. When attackers target the tools that manage your security — whether it’s a firewall management console, a SIEM, or a security scanner — they can undermine your entire defensive posture in a single stroke.

    This pattern is accelerating in 2026:

    • TeamPCP supply chain attacks compromised security scanners (Trivy, KICS) and AI frameworks (LiteLLM, Telnyx) — tools with broad CI/CD access
    • Langflow CVE-2026-33017 (CISA KEV, actively exploited) targets AI workflow platforms
    • LangChain/LangGraph vulnerabilities (disclosed March 27, 2026) expose filesystem, secrets, and databases in AI frameworks
    • Interlock targeting Cisco FMC — going directly for the firewall management plane

    The lesson: treat your security tools with the same rigor you apply to production systems. Patch them first, isolate their management interfaces, and monitor them for compromise.

    Recommended Reading

    If you’re responsible for network security infrastructure, these resources will help you build a more resilient environment:

    Quick Summary

    1. Patch CVE-2026-20131 immediately — CISA’s remediation deadline has already passed
    2. Assume breach if you were running unpatched FMC since January 2026
    3. Isolate FMC management interfaces from production and internet-facing networks
    4. Deploy hardware MFA for all firewall administrator accounts
    5. Monitor for indicators of compromise — check audit logs, config changes, and new accounts
    6. Treat security management tools as crown jewels — they deserve the highest protection tier

    Stay ahead of critical vulnerabilities and security threats. Subscribe to Alpha Signal Pro for daily actionable security and market intelligence delivered to your inbox.

    Get Weekly Security & DevOps Insights

    Join 500+ engineers getting actionable tutorials on Kubernetes security, homelab builds, and trading automation. No spam, unsubscribe anytime.

    Subscribe Free →

    Delivered every Tuesday. Read by engineers at Google, AWS, and startups.

    References

    1. Cisco — “Cisco Secure Firewall Management Center Deserialization Vulnerability CVE-2026-20131”
    2. CISA — “CVE-2026-20131 Added to Known Exploited Vulnerabilities Catalog”
    3. MITRE — “CVE-2026-20131”
    4. Cisco Talos — “Interlock Ransomware Exploiting Cisco FMC Zero-Day Vulnerability”
    5. NIST — “National Vulnerability Database Entry for CVE-2026-20131”

    Frequently Asked Questions

    What is CVE-2026-20131: Cisco FMC Zero-Day Exploited by Ransomware about?

    A critical zero-day vulnerability in Cisco Secure Firewall Management Center (FMC) has been actively exploited by the Interlock ransomware group since January 2026 — more than a month before Cisco rel

    Who should read this article about CVE-2026-20131: Cisco FMC Zero-Day Exploited by Ransomware?

    Anyone interested in learning about CVE-2026-20131: Cisco FMC Zero-Day Exploited by Ransomware and related topics will find this article useful.

    What are the key takeaways from CVE-2026-20131: Cisco FMC Zero-Day Exploited by Ransomware?

    If your organization runs Cisco FMC or Cisco Security Cloud Control (SCC) for firewall management, this is a patch-now situation. Here’s everything you need to know about the vulnerability, the attack

Home · About · Privacy Policy · Terms of Service
© 2026 Orthogonal Info. All rights reserved.
Also by us: StartCaaS — AI Company OS · Hype2You — AI Tech Trends