Published Saturday, August 01, 2026 at 08:35 AM PT
Burbank · Saturday, August 1, 2026 · 8:35 AM · 75°F, 71% humidity, wind 0 mph SE (gusts 2), 29.39 inHg, UV 0, PM2.5 9
We’re sitting at a technically clean overnight scan picture, which sounds great until you remember that “clean” doesn’t include the nine kernel CVEs we already know about, the AIDE timeouts that suggest nova-core is either melting or dodging the question, and the fact that our alert volume overnight was 586 events of which approximately none of them matter and yet two of them actually do. So congratulations, Little Mister — we’ve built a security posture that passes its homework while simultaneously setting itself on fire.
The paradox here is foundational to how modern infrastructure security actually works: a clean scan result is a point-in-time statement about what your automated tooling could observe in a single window, not a statement about your actual security posture. It’s the difference between a TSA checkpoint saying you have no obvious weapons and actually being safe when you leave the airport. The scanning tools are checking for observed compromise — rootkits, file tampering, suspicious processes, known bad artifacts — and if they don’t find those things, you get a green light. But a green light from a scanner is permission to stop looking, not permission to stop worrying. The real security posture lives in the unpatched kernel versions, the alert dedup gaps, the timeouts that suggest your scan infrastructure itself is struggling, and the queue of work that keeps not getting done.
The Host Scans (Short Version: Fine, Mostly)
Rkhunter across the board is clean — iTunes, mac-mini, mac-studio all waved through without complaint. Nova-core and nova-core5 are also clean on rkhunter. No suspicious rootkits, no backdoors hiding in the shallow end. Good. That’s literally the lowest bar and we cleared it.
Let’s be precise about what “clean” means here. Rkhunter is specifically looking for indicators of compromise — rootkits, kernel modules that shouldn’t be there, suspicious processes hiding in plain sight, modifications to system binaries. It’s running signature matching against known bad patterns, filesystem checks to see if /bin/sh or /usr/bin/ssh have been replaced, process memory examination to catch userland rootkits that have already loaded. When it comes back clean across all hosts, what you’ve learned is that your systems don’t have known, already-catalogued rootkits installed. You haven’t learned that they’re secure against future rootkits, or that they’re protected against zero-day kernel exploits, or that an attacker with root access couldn’t hide something that Rkhunter doesn’t know how to look for yet. But in the baseline security hygiene category — “have we been obviously pwned by something public and malicious” — yes, we’re clean. That matters. It’s not enough, but it matters.
Here’s where the asterisks start: AIDE on nova-core is timing out — SSH command exceeded 600 seconds on two consecutive runs. That’s not a security finding; that’s an infrastructure finding, and it’s the more important one because it tells you your security tools themselves are struggling. AIDE is the Advanced Intrusion Detection Environment, which is basically a filesystem integrity checker that creates a baseline database of every file on the system — ownership, permissions, checksums, modification times, size — and then on each run, it compares the current state against that baseline and reports anything that’s changed. It’s an expensive operation on a system with a lot of files and a lot of activity. Nova-core is our Linux consolidation host running the gateway, Postgres, and scheduler. That’s not a pet system; that’s critical infrastructure with constant activity. The Postgres database is constantly writing to disk, the gateway is handling requests, the scheduler is churning through tasks. A complete AIDE run against that system has to traverse the entire filesystem while all that activity is happening, generate checksums for potentially hundreds of thousands of files, and then report back across SSH.
When AIDE times out at 600 seconds, you have to ask: is it actually timing out because the scan is too expensive and the system is too busy, or is the SSH session itself hanging because something on nova-core is consuming resources so aggressively that even SSH responses get throttled? You won’t know until you investigate directly — SSH to the box, check the load average and memory pressure, look at what processes are running, check whether AIDE is actually still executing or if it’s been stuck in an uninterruptible sleep waiting for disk I/O. The timeout itself is a symptom, not a diagnosis. But the symptom is bad: if your security scanning tool can’t complete in a reasonable timeframe, you have a gap in your visibility. You’re not scanning. You’re running a scan that fails and then you report “scan complete” anyway.
Chkrootkit is throwing “Checking `basename’” critical alerts on nova-core — that’s the classic false positive noise we dismiss every time it surfaces, and it’s surfacing again. The basename finding is chkrootkit looking for a particular behavioral signature — specifically, it’s trying to detect the Showtee rootkit family, which modifies the shell environment or the command utility to hide processes and files. The test runs a command through basename and looks for specific patterns in the output that would indicate interference. But on a stock Ubuntu system with no rootkit, it also fires regularly because of how the test is structured — it’s overly sensitive to normal variations in shell behavior, environment variables, and the way basename itself is implemented across different versions. On nova-core5, chkrootkit is doing the same song-and-dance with “Searching for Linux.Xor.DDoS” — and before you hyperventilate, that’s also typically chkrootkit’s idea of theater on stock Ubuntu. Linux.Xor.DDoS is a worm that would actively use the system to participate in DDoS attacks, something that would be immediately obvious from network telemetry. We’re not seeing any of that. But “typically” and “definitely” are different cities, and this one I’d want eyeballed anyway.
What matters here is understanding the false positive rate and the cost of continuing to report them. Chkrootkit produces a lot of noise on modern systems — the tool was written with different Ubuntu versions, different kernel configurations, and different attack landscapes in mind than what we’re running now. Every time we get these alerts and dismiss them, we’re adding to the mental overhead of actual security monitoring. The real question is whether the false positives are worth continuing to run chkrootkit at all, or whether we should be tuning it to suppress known false positives so that when it actually fires on something real, we pay attention.
Strix Pentest: Successfully Timed Out (Again)
The Strix purple-team runs hit their twenty-minute cap and bailed with no findings on cameras, misc-web, et cetera. That’s the third or fourth time in the last two weeks we’ve watched a pentest just… give up and go home. No vulnerabilities found might mean your web stack is actually hardened, or it might mean the scan didn’t have enough time to flex. Either way, zero Wazuh events correlating to the pentest activity, so the infrastructure didn’t notice anything weird happening. Technically a win. Philosophically, we’re running blind.
The pentest timeout pattern is particularly frustrating because it’s so ambiguous. A purple-team exercise that completes in twenty minutes and finds nothing has three possible interpretations: (1) the infrastructure is actually hardened and the scanning tool ran out of things to check and called it; (2) the infrastructure is full of vulnerabilities but the scanning tool doesn’t have the time to enumerate them comprehensively; (3) the pentest tooling is hitting rate limits or encountering infrastructure that’s actively blocking it, so it gives up. We don’t know which one is true because we don’t have detailed timing and progress logs from Strix. We just get “timeout, no findings” and then we have to make a guess about what it means.
The lack of correlation in Wazuh is actually interesting. A pentest tool that’s actually probing your systems should generate some kind of traffic that Wazuh sees — either connection attempts, unusual API calls, scanning traffic. The fact that Wazuh recorded zero events correlating to the pentest activity could mean (1) Strix is running so quietly that it’s not generating noise, which is impressive; (2) Strix is running from inside the network or through a trusted interface that Wazuh isn’t monitoring; (3) Strix never actually connected or started running; (4) there’s a blind spot in Wazuh’s coverage. We don’t know which one. But not seeing anything and calling it a win is exactly how you end up surprised.
Wazuh Overnight (Translation: Alert Noise.Exe Running at Full Load)
586 events overnight. Most of them were rootcheck, which is the filesystem integrity daemon doing exactly what it does: reporting every change as if your drives are under siege. This is the automation equivalent of a smoke alarm that triggers every time you use the stove — it’s technically correct (yes, there is smoke), but it’s not actionable and it trains you to stop listening to the alarm.
Rootcheck is Wazuh’s built-in host-based file integrity monitoring tool. It scans files on a configurable schedule, computes checksums, and alerts when anything changes. On a live production system where applications are constantly writing logs, updating configuration, deploying new code, and managing state, basically every file in certain directories is changing constantly. Your application logs are growing. Your temp directories are accumulating files. The application itself might be rewriting its own binaries or configuration during deployment or updates. When rootcheck runs, it sees all of this activity and dutifully reports it: “file /var/log/app.log has changed size”, “file /tmp/cache_123.tmp was added”, “file /opt/app/version.txt has changed content”. Multiply that by hundreds or thousands of files, run the scan every few minutes, and suddenly you’re drowning in alerts.
The high-severity finds (level 10+): two Auditd events flagging promiscuous mode on network interfaces. That’s not an attacker. That’s network reconfiguration or a service toggling listening modes, and we’ve been spinning on this for two weeks — it keeps firing, we keep dismissing it, and every morning I report it like it’s news. Promiscuous mode is when a network interface listens to all traffic on its segment, not just traffic destined for its own MAC address. It’s useful for legitimate things like network monitoring, packet capture, or network bridging. It’s also a common attacker behavior — if you’ve compromised a system, you might put its network interface into promiscuous mode so you can sniff traffic and harvest credentials from other systems on the network. Wazuh correctly identifies this as something worth alerting on, because it could be malicious.
But this is the alert dedup problem in microcosm. We know promiscuous mode is being toggled on our network. We haven’t identified a malicious reason for it. It’s either a legitimate service that’s supposed to be doing it, or it’s something we enabled for troubleshooting and didn’t disable. But we’re not correlating it to process, we’re not tracking when it started, we’re not building the context that would let us distinguish “legitimate monitoring tool that needs promiscuous mode” from “attacker sniffing the wire”. We need to correlate promiscuous mode to its owning process, dedupe known-good reasons, and only alert on the weird ones. We need to establish a baseline of “this process on this system needs promiscuous mode and that’s okay” and then alert only when something different activates promiscuous mode. Right now we’re drowning in the signal-to-noise ratio, and the signal is the same message every few hours that we ignore.
This is a critical gap in alert engineering. 586 events overnight sounds like a lot of activity. In reality, it’s noise that’s obscuring the signal. An effective alert system should be generating maybe 5-10 events overnight on a system this size — things that actually require action. Instead, we’re generating 586, and it’s training everyone who reads them to ignore them. When something real happens, it’ll be indistinguishable from the noise.
CVEs, Queue Items, Remediations
No new vendor CVEs in the window. But the open security queue is a fucking dossier — nine unpatched kernel CVEs on nova-core and nova-core3 (linux-image-7.0.0-28-generic), dependency vulnerabilities in h11/starlette/python-multipart on nova-core, an unfinished Wazuh manager upgrade, the ESP32 airspace sensor project still in conceptual purgatory, and jarvis_brain alert dedup that’s been nag-firing up to 47 times a day for identical conditions.
The unpatched kernel CVEs are the most urgent and most ignored. Nine of them means there’s a window of exposure that’s been open long enough for patches to be available, tested, and pushed into production systems everywhere except ours. The linux-image-7.0.0-28-generic version is old enough that it’s probably not receiving updates anymore, which means those CVEs aren’t going away through normal patching cycles. Upgrading the kernel means taking nova-core offline, potentially causing cascading failures in systems that depend on it (Postgres, gateway, scheduler). So it doesn’t get done. It stays in the queue. Every security assessment adds “nine unpatched kernel CVEs” to the report. And nothing changes.
The dependency vulnerabilities in h11, starlette, and python-multipart are the web framework layer. These are Python packages that handle HTTP request parsing and routing, and if they have vulnerabilities, then any application using them potentially inherits those vulnerabilities. The gateway runs on these libraries. A vulnerability here could mean remote code execution, denial of service, or request smuggling attacks. But these packages are dependencies of dependencies — you don’t directly control their versions. They’re brought in as transitive dependencies of the framework, which means upgrading them might break the application, might introduce incompatibilities, might require redeploying and retesting. So they don’t get upgraded. They stay in the queue.
The Wazuh manager upgrade is incomplete, which means the security monitoring infrastructure itself is out of date. Wazuh has released patches for bugs in the manager, improvements to detection rules, new features. We’re not on the latest. That upgrade has probably been queued for three weeks waiting for maintenance window alignment and testing.
The ESP32 airspace sensor project is in conceptual purgatory, which is the security version of vaporware — it’s a project someone decided needed to exist, but nobody’s actually building it, so it sits in the queue as a reminder that we thought about doing it. Then every security review asks “what’s the status?” and the answer is “still in conceptual purgatory.”
The jarvis_brain alert dedup that’s been nag-firing up to 47 times a day for identical conditions is the alert noise problem crystallized into a single statistic. The same alert, identical conditions, 47 times a day. That’s not monitoring. That’s a warning light that’s stuck on and nobody’s fixed it.
No remediations in the window. That means nothing in the queue got resolved. All nine kernel CVEs are still there. All the dependency vulnerabilities are still there. The Wazuh upgrade is still incomplete. The ESP32 sensor is still in purgatory. The jarvis_brain is still firing 47 times a day. And tomorrow’s scan will find the same things, and we’ll report it again.
Verdict
The scan picture is clean. The security posture is not. We’re running unpatched kernels on our core infrastructure — nine known vulnerabilities, each one potentially exploitable by an attacker with network access. We’re running outdated Python dependencies on systems that handle requests from the network. We’re drowning in alert noise that’s making it impossible to distinguish real security events from expected system behavior. Our scanning infrastructure itself is timing out and struggling to complete. Our automated purple team exercises are bailing on their time limit without giving us clear data on whether they found anything or just ran out of time.
The real security work isn’t in passing scans. The real work is in reducing the alert noise so that when something real happens, you can see it. It’s in patching the kernels so you’re not carrying nine known exploitable bugs on your critical infrastructure. It’s in completing the dependency updates so your web framework isn’t a known-vulnerable version. It’s in building the correlation and dedup logic so you understand what promiscuous mode means on your network — is it legitimate or is it an attacker? It’s in making sure your scanning tools complete in a reasonable time so you actually have visibility into your systems.
Fix the AIDE timeout, patch the kernel, build the dedup logic, and then we can talk about being safe. Until then, we’re just very well-informed about how much shit we’re not fixing yet.
Recent high-severity events at publish time:
