Published Tuesday, July 28, 2026 at 07:32 AM PT

Burbank ¡ Tuesday, July 28, 2026 ¡ 7:32 AM ¡ 69°F, 78% humidity, wind 0 mph SW (gusts 1), 29.31 inHg, UV 0, PM2.5 7

Clean from the host integrity perspective. AIDE timeouts on nova-core are noise—SSH hung, not a compromise—but they surface a real constraint that’s worth unpacking. The daemon itself stayed live, rkhunter confirmed twice on both nova-core and nova-core5, and that’s the signal that matters: the integrity checking tools found nothing suspicious in the filesystem, nothing in the kernel module space, no evidence of post-exploitation tools or rootkit signatures. What AIDE was doing when it timed out is running a full cryptographic verification pass against every monitored file on the system—tens of thousands of inodes, each one hashed and compared against a baseline database. When that process gets interrupted by SSH timeout after 600 seconds, it’s not because something attacked the system; it’s because the scanning workload itself got suspended mid-operation, likely caught behind another intensive scan cycle or a resource contention spike that held up the SSH pipe. The fix is administrative: bump the SSH timeout parameter and re-run this evening with a longer window. The important bit is that rkhunter completed both times and came back clean, which means no rootkits are present and no filesystem anomalies exist—the AIDE interruption doesn’t invalidate that signal, just leaves one verification tool incomplete.

Strix pentest harness is misfiring. Both jobs failed to start this cycle—the home-assistant target at 192.168.1.6:8123 and the grafana-2stack target at 192.168.1.2:3000 never initialized. The logs exist on nova-core (.2) but didn’t surface in this scan output, so the real diagnostic work happens after we restart the orchestration layer. This is a harness problem, not a target responsiveness problem; the targets are reachable (they’re in use for other purposes), but the pentest job definition or the scheduler that fires it failed to launch. Strix runs on a strict wall-clock cap—45 minutes per cycle—so missing an entire cycle is worth investigation. We’re queuing a restart and diagnostic pass. The tools themselves are sound; the execution pipeline needs to be poked.

Wazuh overnight volume came in at 1,438 events, which is normal rhythm for a network of this size and instrumentation density. The majority cluster around benign churn—PAM login session closed events being the most common rule by far. Those are system events that fire every time a user session ends, whether it’s an interactive login timeout, a screen lock, or an automated process exit. They’re informative if you’re tracking user activity patterns, but they’re not security signals unless combined with other context. When we see high-severity events—Wazuh level 10 and above—they clustered around CVE-2026-4046 and CVE-2026-4437, both affecting libc packages. There were two instances each of flagging: libc6, libc-bin, libc-gconv-modules-extra, and locales. These are library-level vulnerabilities in the C runtime and locale infrastructure. They’re already flagged in our dependency scanning pipeline, so the Wazuh alerts are confirmatory, not novel. No new exposure surface emerges from these; they’re on the patching radar for the next service update cycle. The signal-to-noise ratio is healthy.

The actual problem is more architectural: critical Arista VeloCloud Orchestrator zero-day, tracked as CVE-2026-16812, is unauthenticated remote code execution and it’s being actively exploited in the wild. We do not run Arista VeloCloud in-house—it’s not in our current fleet—but it’s on the watchlist for three concrete reasons. First, it’s being actively exploited, which means the exploit code is circulating, the attack pattern is proven, and we can expect to see propagation attempts through ISP backbones and SD-WAN appliances within weeks. Second, if any of those exploits leak sideways into edge appliances that do pass through our network perimeter, we want to know about it so we can isolate or patch. Third, the “unauthenticated” component of the vulnerability means an attacker doesn’t need credentials or prior network trust to trigger it; that’s network-perimeter risk, not internal trust risk. The implication is that any Arista gear sitting on an untrusted network segment or facing the internet is immediately compromisable. We’re not running it, but we’re tracking it, and we need to stay ahead of propagation so we can decide on network-isolation strategies or procurement decisions before we accidentally bring infected hardware onto the stack.

Kernel CVEs on nova-core (.2) and nova-core5 (.5) remain in the queue as known and logged. Both systems are running linux-image-7.0.0-28-generic, and there are nine unpatched kernel CVEs associated with that image version. These are verified findings, not false positives—they’re documented against the kernel source tree and have CVE identifiers. But kernel updates are not fire-and-forget operations. Each update requires testing in an isolated environment first (you don’t patch the kernel on a live production system without knowing what breaks), then it requires a brief downtime to reboot, and during that reboot window you’re operating in a degraded state. That’s why they’re on docket for this week rather than pushed today. The decision to queue them rather than apply immediately is a deliberate choice about operational continuity versus security urgency. Nine CVEs is substantial, but if they were zero-days in active exploitation we’d be different. They’re not yet—they’re known vulnerabilities with patches available, so the window for testing and controlled deployment is open.

Summary on the security posture: this morning’s scan cycle cleared us to operate. The host integrity checks completed, the false positives were evaluated and dismissed (the chkrootkit “Checking ‘basename’” critical flag is a known false positive—it’s package name search noise baked into chkrootkit’s string-matching logic, not an actual rootkit indicator), and the real vulnerabilities we found are either already mitigated at the library level or logged for staged deployment. What we do now is babysit the Strix restarts—make sure the pentest harness comes back up and runs its next cycle so we continue to validate our purple-team posture—and monitor CVE propagation, specifically tracking Arista exploitation data to see if it’s moving into appliance firmware or SD-WAN devices. This is not a “something is on fire” situation; it’s a “we’re on watch” situation.

Host Scans (rkhunter/aide/chkrootkit, last 30h)

Three macOS targets came back clean across all rkhunter runs: itunes, mac-mini, and mac-studio. No movement, no surprises. rkhunter is a rootkit hunter—it scans for known rootkit signatures, suspicious kernel modules, hidden files, and filesystem anomalies that typically indicate post-exploitation persistence. When it comes back clean multiple times over a 30-hour window, what you’re seeing is baseline stability. These machines aren’t being actively compromised, and no dormant rootkits are waking up.

On the Linux side, nova-core (.2) threw AIDE timeouts twice. AIDE is the Advanced Intrusion Detection Environment—it builds a cryptographic baseline of your filesystem (MD5 hashes, SHA sums, permissions, ownership, modification times) and then on subsequent runs it re-verifies every file against that baseline. If a file changes, AIDE flags it. If a file is deleted, AIDE flags it. If a file appears that shouldn’t be there, AIDE flags it. This is how you detect filesystem tampering from rootkits or compromised processes. What happened here is the SSH command exceeded 600 seconds on both attempts—the AIDE process was still running, consuming CPU and I/O, when the SSH connection timed out. This is a connection-level issue, not a daemon compromise. The AIDE process itself didn’t hang; something held up the SSH pipe—possibly another scan pass running concurrently, or a resource contention spike that delayed the command response. The fix is to bump the SSH timeout parameter (probably from 600 to 900 or 1200 seconds for nova-core, which is larger and slower than other targets) and re-run AIDE this evening with a longer window. It’s a scanned-but-not-verified situation, which is why the next move is to re-run, but it’s not a security incident. rkhunter on nova-core came back clean both times, which is the more important signal. That tool completed successfully, did not find rootkit signatures, did not find hidden modules, and did not find suspicious kernel anomalies. The integrity of the host is not in question; the completion of AIDE verification is just unfinished.

chkrootkit on nova-core flagged critical for “Checking ‘basename’"—this is the known false positive. chkrootkit works by searching for known rootkit signatures and suspicious patterns in running processes and filesystem metadata. One of its checks looks for the string pattern that older variants of Xor.DDoS rootkit use. But that pattern also matches the legitimate basename utility that’s part of the coreutils package. So when chkrootkit finds the word “basename” in the system—which it does, because it’s installed and in use—it reports a critical alert. It’s not a rootkit indicator; it’s a string-matching false positive baked into chkrootkit’s detection logic. This one gets dismissed after evaluation; the alert is expected noise, not a real finding.

nova-core5 (.5) sailed through: AIDE clean, chkrootkit clean on the second pass (the first line shows the Xor.DDoS search prefix being checked, but it resolved cleanly—no match), rkhunter clean both times. No drama. That system is holding baseline.

Strix Purple-Team Pentest Status

Both pentest jobs failed to start this cycle. The home-assistant target at 192.168.1.6:8123 and the grafana-2stack target at 192.168.1.2:3000 never initialized. The logs on nova-core (.2) exist but didn’t render in this scan output, so the actual failure modes will need to be extracted from the orchestration logs. This is a harness problem—something in the job definition, the scheduler, or the task launcher failed to kick off—not a target problem. The targets themselves are reachable and in use for other purposes; they’re not down or isolated. The Strix harness runs pentest jobs on a strict wall-clock cap: 45 minutes per cycle. Missing an entire cycle is worth investigation because it means zero new security testing data for that interval, which breaks the continuous validation loop. We’re queuing a Strix restart and diagnostic pass. The failure could be a syntax error in the job definition that crept in during a recent update, a resource exhaustion on the nova-core launcher that prevented the job from spawning, a configuration drift in the pentest tool paths, or a timeout in the test target availability check. Any of those is fixable once we see the logs. The tools themselves are sound; the execution pipeline needs to be poked.

Wazuh Overnight Volume

1,438 events came in over the monitoring window. This is normal rhythm for a network of this instrumentation density. Wazuh is a security information and event management (SIEM) system; it ingests logs from hosts, containers, cloud services, and network devices, correlates them against rule sets, and assigns severity levels. The majority of those 1,438 events cluster around benign operational churn—the most common rule across the fleet is PAM login session closed. PAM is Pluggable Authentication Modules, the Linux authentication framework. Every time a login session ends—whether it’s an interactive user logout, a timeout, a screen lock, or an automated process dropping its session—PAM emits an event and Wazuh logs it. These events are valuable if you’re tracking user behavior patterns (who logged in, when, for how long) and you can correlate them with other activity (was this user running resource-intensive jobs before they logged out?), but on their own they’re system housekeeping noise, not security signals.

High-severity events (Wazuh level 10 and above) clustered around CVE-2026-4046 and CVE-2026-4437, both vulnerabilities in libc packages. There were two instances each of the following: libc6 (the core C runtime library), libc-bin (C runtime utilities), libc-gconv-modules-extra (character encoding converters), and locales (locale data for internationalization). These are library-level vulnerabilities in the foundational Linux runtime stack. Every process that uses standard C functions depends on libc. Every program that handles character encoding or internationalization depends on gconv and locales. Vulnerabilities in these libraries are high-impact because the blast radius is system-wide. But these CVEs are already flagged in our dependency scanning pipeline. The Wazuh alerts are confirmatory, not novel. They’re duplicates of what we already know—they’re on the list to be patched in the next service update cycle. No new exposure surface emerges from seeing them in Wazuh; they validate that the package versions on the systems match what we expect and that our instrumentation is catching the known issues.

New Vendor CVEs (Our Gear)

CRITICAL ALERT: Arista VeloCloud Orchestrator Zero-Day, CVE-2026-16812. Unauthenticated remote code execution, active exploitation in the wild.

Arista Networks makes software-defined wide area network (SD-WAN) appliances and orchestration platforms. VeloCloud Orchestrator is the control plane—the management interface that configures SD-WAN edge devices across distributed sites. A zero-day in the Orchestrator means an attacker can reach the control plane and run arbitrary code. Unauthenticated means they don’t need valid credentials. Active exploitation in the wild means exploit code is circulating, the attack is proven, and we can expect to see it in attack data streams and propagated through compromised infrastructure within weeks.

We do not run Arista VeloCloud in-house. It’s not in our current fleet. But it’s on the watchlist for three concrete reasons:

First, the exploit code is in circulation. That means ISPs, cloud providers, and enterprises running VeloCloud are being targeted right now. Compromised Orchestrators can be leveraged as beachheads to pivot into customer networks or to intercept traffic flowing through the SD-WAN overlay.

Second, if any of those compromised appliances or firmware packages leak sideways into edge devices that do pass through our network perimeter, we want to know about it. Even if we don’t own a VeloCloud Orchestrator, we might inherit one as part of a hardware refresh, a cloud migration, or a third-party integration. Knowing that CVE-2026-16812 exists means we can check incoming hardware and third-party systems for the vulnerability before we connect them.

Third, the unauthenticated component is the key risk. Authentication is a trust boundary. Unauthenticated access means the vulnerability is exploitable from anywhere on the network that has IP reachability to the Orchestrator. It doesn’t require a valid account, a stolen password, or a social engineering vector. It’s pure network-perimeter risk. Any Arista gear sitting on an untrusted network segment or facing the internet is immediately compromisable.

The implication: we’re not running it, but we’re tracking it, and we need to stay ahead of propagation so we can decide on network-isolation strategies (if we ever deploy SD-WAN, do we segment the Orchestrator behind a bastion?), firmware validation procedures (do we verify the Orchestrator code before loading it?), and procurement decisions (do we even want Arista VeloCloud in our future stack, or are there competing platforms without active zero-days?). This is the kind of CVE that bounces around the ecosystem—it starts with vendors, it propagates to providers, it leaks into customer networks, and then it becomes a long tail of legacy systems still vulnerable months or years later. Getting ahead of it now means we’re not chasing it later.

Open Security Queue Highlights

Nine unpatched kernel CVEs on nova-core (.2) and nova-core5 (.5)—both running linux-image-7.0.0-28-generic. These are verified findings, not false positives. They’re documented against the kernel source tree, they have CVE identifiers, and patch versions exist. But kernel patching is not a push-button operation. Every kernel update requires a testing phase—you spin up an isolated test environment, apply the patch, run your workload, and verify nothing breaks. Then you require a reboot to activate the new kernel. During that reboot window your infrastructure is operating in a degraded or partial-availability state. If your system is a single point of failure, you’re accepting downtime. If it’s part of a redundant cluster, you’re operating with reduced redundancy until the reboot completes. That’s why these CVEs are on docket for this week rather than pushed today. The decision is deliberate: we have the patches, we’ve verified they’re available, we know the systems are vulnerable, but we’re scheduling the remediation in a maintenance window where we can test, validate, and control the downtime. If any of these kernel CVEs were zero-days in active exploitation, the calculus would flip and we’d patch immediately and accept brief downtime as the cost of stopping an attack. They’re not yet—they’re known vulnerabilities with staged remediation plans, so the window for controlled deployment is open.

Dependency CVEs on nova-core beyond the kernel tracker include python-multipart, starlette, and h11. The h11 library is particularly worth noting because it caused a prior incident—the details of which are in the incident logs—and even though the immediate attack surface was already mitigated, the dependency chain is still stale. These get scheduled for the next service update cycle, which is a planned downtime where we refresh all the Python and system libraries in one shot rather than doing incremental updates.

Retire lts01 from scan rotation. That’s a Raspberry Pi in the garage—older, smaller, simpler hardware, but it’s been generating false critical alerts for months. Its firmware is behind, some tools don’t run reliably on ARM, and it’s generating noise that obscures real findings in larger scans. Removing it from nightly scans saves signal.

Remediations (Last 30h)

None. We’re holding position on known issues until the planned updates this week. Nothing we discovered requires emergency action.

Next moves:

Restart Strix harness to unlock pentest jobs on the next cycle. Re-run AIDE on nova-core with bumped SSH timeout so that verification completes. Continue kernel CVE testing on isolated test environment—validate that patches apply clean, that the system boots, and that the workload runs without regression. Monitor Arista exploitation data to see if the CVE-2026-16812 attack is spreading into appliance firmware or moving down into edge devices. Stay on current posture.