AI-era readiness
13 articles with this tag
Linux kernel CVE-2026-98432: a network-triggered TCP use-after-free (CVSS 9.8); install the fixed kernel, reboot, and check MPTCP
CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP code, published on October 15, 2026. The kernel project's CNA scores it CVSS v3.1 9.8 (network, no privileges, no user interaction). Researchers at an AI company reportedly demonstrated, in a lab and by their own report, remote code execution as root against a server with a Multipath TCP (MPTCP) listener. BleepingComputer says remote code execution on plain TCP servers has not been shown publicly and no exploitation in the wild has been confirmed, and this site did not find the CVE in CISA's KEV catalog on November 1. Upstream fixes are in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10 and later. As of November 1, Debian has fixed kernels, SUSE has some, and Ubuntu and Red Hat list fixes as in progress. Disabling MPTCP alone is not a full fix. This site's conclusion: update internet-facing Linux servers as fixes land, reboot, and use a vendor stop-gap only until then.
Security for the AI era: the basics to lock down now (priority checklist)
AI mostly amplifies attacks on EXISTING weaknesses (unpatched CVEs, reused passwords, exposed secrets) rather than inventing new ones — found automatically, fast, at scale. So the best preparation is locking down the basics in the right order: CVE patching + dependency monitoring, stop password reuse + MFA, remove exposed secrets, least privilege, shrink the public surface, logs/IOCs, backups.
AI-era security measures that work and ones that don't: why small sites get targeted too
Four AI-era misconceptions corrected: (1) too small to be targeted → automated attacks don't need a human to pick a target; (2) needs a special new control → the basics still work best; (3) a product makes you safe → prevention design before detection; (4) AI code is fast so it's safe → it can ship with vulnerabilities, so review before publishing. What works is the boring basics in the right order.
Email spoofing your own domain: how to tell it from a breach, and how SPF, DKIM and DMARC stop it
A suspicious email that appears to come from your own domain is usually not a breach — it's a forged From, because SMTP lets anyone write the From line. Reading the headers (Authentication-Results, Received, Reply-To) tells a breach from a forgery. The main reason it reaches your inbox is a missing DMARC policy. Fix it with SPF → DKIM → DMARC (p=none → reject).
Backup essentials: the 3-2-1 rule and a recovery plan that survives ransomware
'I have a backup' isn't enough — only a backup you've verified you can restore is useful. The basics: the 3-2-1 rule (three copies, two media types, one offsite). For ransomware you also need at least one 'offline or immutable' copy — an always-connected backup gets encrypted along with the original. Cloud sync is not a backup (it replicates deletions and encryption too). Versioning and a periodic restore test complete the practice.
Choosing MFA the right way: what 'phishing-resistant' means, and why SMS is weak
MFA uses different factor categories. Manually entered codes can be relayed through phishing; SMS also depends on control of the phone number. Prefer phishing-resistant methods such as passkeys or FIDO2 security keys for important accounts, check user-verification requirements, and protect recovery methods too.
Fixing dependency CVEs for real: scan, fix, isolate, and keep watching
Vulnerability work isn't done when you 'fix it.' Done = 1) scan, 2) fix, 3) isolate/hand off, 4) monitor. Until monitoring (daily change-detection) is in place, it's incomplete — dependencies turn vulnerable again tomorrow. A perfect fix that the next deploy overwrites is worth zero. Small teams stay safe with two disciplines: automated change-detection and 'local→push→deploy.'
Installing and using osv-scanner: find CVEs in your dependencies automatically
osv-scanner scans lockfiles and containers to surface CVEs in your dependencies, free. This walks through install, run, and CI integration, plus when to use it vs npm/pnpm audit vs Dependabot. This site's view: which tool fits depends on your setup. Use osv-scanner on multi-ecosystem or GitHub-free projects, and the bundled pnpm audit for a single npm tree.
Are password managers safe? How they work, cloud vs local, and how to choose
A password manager helps you use a strong, unique password for each service. Zero-knowledge encryption is designed to protect contents even if encrypted data leaks from the provider, but safety also depends on master password strength, encryption settings, and device security. Use MFA to prevent unauthorized logins, and choose cloud or local by use.
Did you leave a secret file in a public directory? Audit your webroot
Anything in your webroot is fetchable by URL by anyone. A leftover token/credential JSON, .env, or backup means instant exposure — and if it came from a shared template, every site has the same file. Fix: put only publicly-shareable things in the public dir, keep secrets outside the webroot at perms 600, and once you find one, audit every site and host.
The security baseline for indie devs and small operators: standard controls in priority order
The baseline isn't 'all equally important.' This site's priority order: 1) admin accounts, domain and email (MFA), 2) secrets and code, 3) the app itself, 4) patch, detect, recover. With finite time, fill it top-down. Most serious breaches come not from novel attacks but from a gap in these basic controls.
SSH key least privilege: keep production root keys off ephemeral environments that can be compromised
Registering a root key into production from an ephemeral, compromisable environment (GPU pod, CI runner, throwaway VM) means that the moment the environment is compromised, an attacker gets root on production. Fix: no root keys on ephemeral environments; remove keys when unused; if needed again, use a non-root user plus a command-restricted key that limits the key to one operation. Treat a reused key as your most critical asset, and never build a setup where one leaked key opens every server.
An API key leaked from AI-written code and was used for fraudulent charges: the cause was an unpatched CVSS 10.0 vulnerability
The bill spike was a symptom. The cause was an unpatched, published CVSS 10.0 RCE. An anonymized case, distilled into defensive lessons.