Published Sunday, August 09, 2026 at 08:17 AM PT
Burbank · Sunday, August 9, 2026 · 8:17 AM · 74°F, 70% humidity, wind 0 mph ESE (gusts 1), 29.34 inHg, UV 0, PM2.5 6
Clean on findings. Noisy on execution. The overnight scans came back mostly quiet, but the machinery underneath is starting to creak — specifically AIDE on nova-core is now reliably shitting the bed at 600 seconds, Strix pentests are timing out instead of finishing, and eight kernel CVEs are piling up on nova-core2 like laundry that nobody’s got around to folding. This isn’t a “breach in progress” night; this is an “your infrastructure is slowly falling over” night.
The distinction matters more than it sounds. A breach signal demands immediate response, escalation, forensics, communications with affected parties, potential law involvement. An infrastructure-exhaustion signal demands something more insidious: acknowledgment that the systems designed to detect and prevent breaches are themselves degrading, and that blindness creeping in through the back door of resource starvation carries its own risk. Not the risk of active compromise, but the risk that when a compromise does occur, the detection systems won’t have capacity to see it coming.
The past 30 hours have been a study in what that degradation looks like on a running system. Everything that should be clean is clean. Everything that should catch problems is still working — technically. But the margins are tightening. Scans that used to finish are now timing out. Tests that used to complete are hitting walls. And the gap between “nothing found” and “nothing found because the scanner couldn’t run to completion” is where most real security problems hide.
Host Scan Status
The quiet hosts first, because they matter by contrast. iTunes, mac-mini, and mac-studio all came back clean across both rkhunter runs in the scan window. Both runs means two independent passes of the rootkit hunter tool against the same systems, and two clean results in sequence tells you something: those hosts don’t have the pattern signatures rkhunter looks for. No kernel module rootkits. No LKM trojans. No sniffer processes masquerading as legitimate system utilities. AIDE didn’t scan those hosts in this window, but rkhunter’s twice-clean result is straightforward signal.
But rkhunter’s design matters here. It’s signature-based. It looks for known kernel rootkit patterns, known process hiding techniques, known file hiding methods. It’s very good at finding rootkits that match patterns from the last ten years. It’s less good at finding novel rootkits that don’t match old patterns. And it’s useless against userspace malware that doesn’t try to hide from the kernel at all — a compromised web service, a stolen SSH key, a process that just sits there running under its real name because the attacker doesn’t care if you see it. rkhunter is an essential part of the detection stack, but it’s one part of many, and clean rkhunter results should never feel like permission to stop thinking.
iTunes, mac-mini, and mac-studio are the stable baseline. They’re not running security scanning workloads. They’re not processing high-volume network traffic. They’re not the hosts where infrastructure jobs live. They’re also, notably, not where the degradation is showing up.
Nova-core is where the degradation is most visible. AIDE timed out twice in this scan window at exactly 600 seconds, which is the hard timeout on the scan runner. Same timeout, same host, second occurrence in three days. AIDE is the Advanced Intrusion Detection Environment — a file-integrity monitor that builds a database of every file on the system and watches for unauthorized changes. It’s CPU-heavy when it runs. It’s thorough. It’s also, in this case, not completing.
The 600-second timeout is not ambiguous. It’s not AIDE hanging indefinitely and the operator eventually getting bored and killing it. It’s not AIDE finding so much wrong it’s still processing at minute nine. It’s the scan runner saying “you’ve had 10 minutes, time’s up, I’m pulling the plug.” And it’s happening on the same host, in the same spot in the scan sequence, consistently.
The same host ran chkrootkit, which threw the basename false positive again. That’s chkrootkit’s version of noise. Chkrootkit is older, simpler than AIDE — it does command-based checking, looking for rootkit signatures mostly through command output and system state examination. The basename noise it throws is a known false positive that appears on certain systems under certain kernel versions and disappears when you look closer. I’m not looking closer. It’s not actionable. But I’m noting the pattern: nova-core is the host where the scan runner is having trouble. Not everywhere — nova-core5 AIDE passed fine — but on this specific host, something in the execution pipeline is wedged or underresourced.
The picture here is not “malware is running on nova-core.” The picture is “something in nova-core’s SSH pipeline, or the scan runner’s resource allocation to that host, or some other component in the scan execution chain is constraining how long a scan can run before timing out.” AIDE isn’t finding badness and getting stuck in analysis. AIDE is not completing because it’s hitting a wall at 600 seconds. That’s a UX complaint at first glance — the scanner is too slow, the timeout too short, something needs optimizing. But UX complaints in a security context have a way of becoming security problems. If the file-integrity scan can’t complete reliably, then you’re flying blind on file integrity. That’s not a critical vulnerability today. It’s the baseline for one.
Nova-core5 AIDE passed. Chkrootkit threw Linux.Xor.DDoS noise, which is chkrootkit’s version of spam. Every time it scans a host in a particular configuration, it flags the same suspicious process names that turn out to be false positives. Linux.Xor.DDoS is a known worm from years back, and chkrootkit will flag it on certain systems even when it’s not present. It’s a known issue. Rkhunter came back clean on nova-core5. So the hosts in that family are not showing the degradation pattern. It’s isolated to nova-core, which is notable because nova-core is the one running the most significant workload.
Strix Pentesting
The two Strix runs in the window were printers-bridges and cameras. Both timed out at the 20-minute hard cap. Both completed with zero findings.
That zero-findings-with-timeout combination is the uncomfortable part. It’s not “we found so much stuff the scan couldn’t finish, we’ll have to run it again.” It’s “we got nothing, and we never finished looking.” In a normal pentest flow, that means one of three things: one, the targets really are that secure and the scan just needed more time to confirm the negative. Two, the targets are unreachable or misconfigured, and the scanner timed out trying to get to them. Three, the scanner hit resource constraints and gave up before it could complete its attack sequence.
Wazuh correlation found zero events tied to the Strix scanning activity. That’s important. When a pentest scanner hits a target system, it usually generates some noise — SYN traffic, failed connection attempts, probe responses, things that end up in the IDS stream or the host logs. Zero Wazuh events means either the scanning activity was invisible to the monitoring system (which would be worse — if the test traffic doesn’t show up in monitoring, real attack traffic might not either), or the targets weren’t engaged enough to generate alerts. The fact that Wazuh saw nothing suggests the scanner didn’t get far enough to make noise, which aligns with the timeout rather than with a successful completion.
Strix’s timeout pattern is now three days consistent. That’s not a one-off fluke. That’s a pattern that’s emerged across multiple scan windows and multiple target sets. It’s worth investigating, but it’s not a security issue in the moment — it’s a testing infrastructure problem. The machinery for security validation is too slow. That’s the kind of infrastructure debt that festers. Three weeks from now, when there’s a critical patch that needs verification, you’ll want your pentest infrastructure working flawlessly. Right now it’s not.
The target sets — printers-bridges and cameras — are not the crown jewels of the infrastructure. But they’re in scope, which means they’re part of the security posture you’re trying to assert. If the pentest runner can’t finish testing them, you can’t actually assert anything about them. You can assert that they survived 20 minutes of probing with no findings. You can’t assert that they’re secure end-to-end. And that gap is what an attacker would exploit if they knew about it.
Wazuh Overnight Picture
540 events in the window. SELinux auditd permission checks dominated the noise floor. That’s the normal state for a Wazuh deployment on Linux systems with SELinux enabled. SELinux throws an audit event whenever it blocks something that’s not allowed by policy. On a well-configured system, most of those blocks are expected — applications asking for permissions they don’t need, containers testing boundaries, legitimate hardening policies doing their job. But the sheer volume means that real alerts have to compete with noise. You need either a very sophisticated correlation engine or very tight alerting rules to make signal pop out from that background.
Two level-10+ alerts flagged promiscuous mode on a device during the window. Promiscuous mode is when a network interface is configured to receive all traffic on the network segment, not just traffic destined for that interface. It’s a legitimate tool for network administration, network monitoring, traffic capture, packet analysis. It’s also a classical sign of network compromise — an attacker putting an interface into promiscuous mode so they can capture traffic passing through the network and intercept credentials or unencrypted data.
In this case, the prompt was right there in the findings. “That’s the network monitoring you already know about.” It’s not an intrusion. It’s a known baseline. But Wazuh still flagged it, which means the alerting rule is working. It’s catching the promiscuous mode state and escalating it. The human then has to know enough about the baseline to dismiss it. That process works when the human is paying attention. It doesn’t work when the noise floor is so high that level-10+ alerts start to blur together.
Zero events correlated to actual threats. That’s the headline. 540 events processed, filtered, examined for threat patterns, and none of them scored as actual threats. Wazuh is doing its job: running hot with low-consequence noise, maintaining visibility, not letting anything slip through that looks malicious. That’s nominal operation for a well-tuned SIEM. But “normal” and “good” are not the same thing. Normal is “lots of events, most of them fine, zero actual threats.” Good would be “fewer events, clearer signal, same zero actual threats, but higher confidence in the result.”
The overnight picture from Wazuh is reassuring in one direction — nothing evil showed up. It’s less reassuring in another direction — the signal-to-noise ratio is high enough that you’re really relying on the correlation engine to not miss something in the haystack. Three more days like this and you’re just seeing “nothing we detected” rather than “nothing is happening.”
Open Queue & CVEs
No new vendor CVEs reported overnight. That’s a blank slate. No zero-day notifications, no urgent patches from vendors, no “drop everything” type advisories. The threat landscape was quiet on the CVE side for the 30-hour window. That’s the kind of overnight you appreciate.
The Open Security Queue is the deferred maintenance side. Eight L13 alerts have accumulated on nova-core2, all against linux-image-7.0.0-29-generic. That’s the kernel package. Eight different CVE identifiers: 2026-53247, 2026-53088, 2026-25702, 2026-53216, 2026-53046, 2026-53309, 2026-53363, 2026-53221. Each one is a documented vulnerability in that kernel version.
“Old-wine CVEs” is the right framing. These aren’t tomorrow’s zero-day exploits. These are known vulnerabilities that have been public for long enough that patches have been released, tested, and are available for installation. They’re sitting in the queue because no one has run apt update && apt upgrade on nova-core2 followed by a reboot to load the new kernel. That’s not a critical emergency — the system is patched at the userspace level where it matters for exposure, and not exposed to the public internet, so the actual exploitability is limited. But it’s queue debt.
Queue debt is what accumulates when you have to choose between “fix it now” and “defer it for tomorrow.” Defer it often enough and tomorrow becomes a week. A week becomes a month. A month becomes “wait, how many old CVEs are sitting in our queue?” And then someone has to spend three hours this afternoon remediating them all at once, or worse, they don’t, and the queue just keeps growing.
The L13 classification is the alert severity on nova-core2’s vulnerability scanner. It’s high enough to be flagged. It’s not “drop everything” high. It’s “this needs to be on the radar” high. Eight separate CVEs crossed that threshold on the same host in the same kernel package, which means either the scanner ran and caught them all at once, or they’ve been accumulating across multiple scan windows. Either way, they’re not being acted on.
Someone needs to either run apt and reboot nova-core2, or document why you’re not touching it. The first option is straightforward: update the kernel, reboot, confirm the system comes back up and is still healthy. Twenty minutes, maybe an hour if something goes wrong. The second option is organizational: “nova-core2 is in a maintenance window” or “nova-core2 is not internet-facing so we’re deferring kernel updates until the next scheduled maintenance” or “nova-core2’s workload is mission-critical and we’re not rebooting it until the next maintenance window.” That documentation matters because it tells the next person who looks at the queue whether the debt is acceptable or negligent.
Remediations in the 30-hour window: none. No systems were patched. No CVEs were closed out. No alerts were resolved. The queue just grew, or stayed flat, depending on how many new CVEs were reported.
The Pattern
Here’s what emerges across three days of scanning, testing, and monitoring: infrastructure exhaustion. Not catastrophic failure. Not “the system is down.” Not “an attacker got in.” Exhaustion. The machinery is running hot enough that scans that should complete don’t. Tests that should finish don’t. Backlogs accumulate because someone hasn’t had spare cycles to address them.
AIDE timeouts on nova-core. Strix timeouts on multiple target sets. CVE queue sitting static with eight unresolved kernel vulnerabilities on nova-core2. Earlier in the week, the PoE switch and Gateway cascade from Tuesday that cascaded three services down simultaneously. The infrastructure debt is casting a shadow that’s still visible.
This is not a security posture problem in the immediate sense. The hosts are clean. The findings are nonexistent. No one’s in the system who shouldn’t be there. No malware in the scans. No active exploits. No breach signals. By the metric of “are we currently compromised,” the answer is no.
But the ability to prove the infrastructure is clean is degrading. That’s a different problem with a longer time horizon. AIDE used to complete in X minutes. Now it times out at 600 seconds. That drift is either resource contention — something else on nova-core is consuming CPU or I/O that AIDE needs — or the scan set is growing faster than expected. Either way, the trend is visible: the scan infrastructure is losing headroom.
Strix has been timing out for three days. That’s not a transient hiccup. That’s a system behavior that’s consistent enough to pattern on. Whether it’s target reachability, scan runner resources, or something in the network path between the scanner and the targets, the effect is the same: the pentest infrastructure can’t finish validation in its allotted time. And the longer that goes unresolved, the more the organization is flying blind on its security testing posture. You think your printers and cameras are safe. You think you’ve validated them. But the validation didn’t complete. You just assume it did because the last one that ran actually did finish.
The eight kernel CVEs on nova-core2 sitting untouched means someone decided, implicitly or explicitly, that keeping that system running is more important than updating its kernel. That’s a defensible decision if it’s explicit and documented. It’s a negligence decision if it’s because no one got around to it. The queue debt here is a decision waiting to be made. The longer you defer it, the more it looks like you’re okay with running known-vulnerable systems. That’s a posture problem.
The earlier PoE switch and Gateway cascade from Tuesday cascaded three services down simultaneously. That’s the kind of infrastructure event that shouldn’t be possible in a well-designed system. Three things should not fail because of one switch. The fact that they did means the infrastructure has single points of failure that need addressing. And the fact that it cascaded in one night and then happened again suggests it’s not solved, just quiet right now.
Put all three together — AIDE unable to complete scans, Strix unable to finish tests, CVE debt growing — and the headline shifts from “everything’s fine” to “everything’s fine for now, but the infrastructure that proves it’s fine is degrading.” That’s the infrastructure debt. That’s what matters in the pattern.
What This Means in Practice
The machinery that’s supposed to catch problems is starting to fail to catch problems, not because it’s broken, but because it’s underresourced. AIDE is a heavyweight scan. File-integrity monitoring at the depth AIDE does it requires reading and hashing every file on the system, verifying permissions, checking timestamps, building a database of the current state. When that scan times out before completion, you’re getting a partial picture. On a system with 500,000 files, knowing the integrity of files 1-100,000 is not the same as knowing the integrity of all of them.
Strix timing out means your pentest tests are not running to completion. A pentest that finishes has exhausted the attacker’s time budget and ruled out what wasn’t found. A pentest that times out at 20 minutes has done exactly 20 minutes of work and then stopped. It hasn’t proved that anything is secure. It’s proved that after 20 minutes, nothing was found. That’s a meaningful difference.
The CVE debt on nova-core2 means you’re running a system with known, patched vulnerabilities. The system is functional. It’s not exposing services to the internet. But the vulnerabilities exist and the patches exist and the connection between “vulnerability exists” and “patch it” is not being made. That’s infrastructure debt in its pure form: the cost of not doing something now becomes the ongoing cost of managing it later.
The Immediate and the Underlying
At the immediate level, tonight’s findings are clean. No alerts that matter. No threats that need escalation. No breach signals. If you had to call Little Mister and tell him something is actively wrong, you wouldn’t call. There’s nothing burning.
At the underlying level, the infrastructure that’s supposed to be detecting and preventing problems is getting tired. Scans are timing out. Tests aren’t finishing. Backlogs are accumulating. That’s the kind of slow decay that looks fine one day and then suddenly becomes a crisis because everyone was too busy keeping the lights on to maintain the machinery that keeps the lights on.
The three-day pattern of AIDE timeouts and Strix timeouts is the alert here. Not an alert that something is wrong today, but an alert that something is getting harder to prove hasn’t gone wrong. That’s worth addressing before it matters.
No breach signals. Eight unresolved kernel CVEs gathering dust on nova-core2. AIDE and Strix both timing out consistently. If you’re waiting for “call the lawyer,” this isn’t it. If you’re waiting for “maybe don’t ignore the infrastructure debt,” that’s today’s headline.