InfoSec.Watch - Issue #147

SonicWall disclosed two vulnerabilities affecting SMA1000-series appliances, and government advisories say both have been exploited in the wild. CVE-2026-15409 is an unauthenticated server-side request forgery flaw in the Work Place interface. CVE-2026-15410 is an authenticated code-injection flaw requiring administrative access to the Appliance Management Console. The affected products are SMA 6210, SMA 7210, and SMA 8200v systems running specified 12.4.3 and 12.5.0 hotfix releases. SonicWall directs customers to 12.4.3-03453, 12.5.0-02835, or later. CISA added CVE-2026-15409 to its exploited-vulnerability catalog with a July 17 remediation deadline.

The operational mistake would be treating this as a patch-only event. An internet-facing remote-access appliance can sit directly on an identity and access path. Teams should upgrade, preserve relevant logs, inspect administrative changes and unusual outbound requests, and determine whether the appliance was exposed during the exploitation window.

Sources: SonicWall PSIRT  •  CSA Singapore  •  NVD / CISA KEV record

Attackers pushed malicious changes into AsyncAPI repositories and allowed the project’s legitimate GitHub Actions workflows to publish five compromised npm versions: @asyncapi/[email protected], @asyncapi/[email protected], @asyncapi/[email protected], and @asyncapi/[email protected] plus 6.11.2-alpha.1. StepSecurity found that the packages carried valid OIDC provenance because the authorized workflows really did publish them. The malicious code executed when affected modules were loaded rather than during installation, and the versions were later removed from npm.

StepSecurity confirmed from the provenance attestations that no npm token was stolen: the attacker’s push access let the projects’ trusted-publisher workflows sign and publish the malicious commits. Microsoft Threat Intelligence traces that access to a malicious pull request against a misconfigured pull_request_target workflow, while noting the surviving records do not establish exactly how the bot credential was obtained. The delivered Miasma payload’s credential-harvesting modules were present but disabled in this build; its command-and-control and persistence were active. Defenders should search lockfiles and build histories for the five versions, investigate systems that loaded them, rotate credentials from any environment that imported a compromised version, and protect every branch and workflow capable of triggering a release. Provenance established which workflow produced the package, not whether the triggering commit was legitimate.

Sources: StepSecurity analysis  •  Microsoft Threat Intelligence

The Coca-Cola Company disclosed that fairlife identified unauthorized third-party access to part of its environment, including production-related systems, in connection with a ransomware event. The company activated incident-response and business-continuity procedures, notified law enforcement, and temporarily suspended fairlife production in the United States. It said Canadian production was not affected and that product quality and safety were not impacted. The investigation remained underway, and the company said the full scope, nature, impact, and potential materiality were not yet known.

For defenders, the signal is the dependency between cyber recovery and physical output. A continuity plan may identify backup systems and recovery owners without proving that production can operate when identity, scheduling, quality, or plant-support services are unavailable. Security and operations teams should map which digital services can halt production, define clean-room recovery order, and test whether manual or degraded procedures work in practice.

Source: The Coca-Cola Company Form 8-K

Nextgov/FCW reported that DHS personnel twice classified suspicious activity in the Homeland Security Information Network as false positives before attackers installed backdoors and stole credential data. DHS confirmed an incident involving a specific unclassified legacy information-sharing environment, said classified networks were not affected, and said the investigation remained active. Attribution and the full scope remain unknown.

Sources: Nextgov/FCW  •  DHS description of HSIN

Unit 42 detailed three RUGGEDCOM ROX II vulnerabilities—CVE-2025-40947, CVE-2025-40948, and CVE-2025-40949—that can expose files or enable command execution with root privileges after authentication. Siemens lists all affected ROX II models below version 2.17.1 and recommends upgrading to 2.17.1 or later. No active exploitation was reported.

Sources: Unit 42  •  Siemens SSA-078743  •  SSA-973901  •  SSA-081142

CVE-2026-56155 allows an authorized local attacker to elevate privileges in Active Directory Federation Services. Microsoft released July security updates, and CISA added the flaw to its exploited-vulnerability catalog. Because exploitation requires an existing foothold, defenders should treat it as a post-compromise escalation path and prioritize AD FS hosts during patching and threat hunting.

Sources: Microsoft MSRC  •  NVD / CISA record

Cisco’s July RoomOS advisory groups six internally discovered vulnerabilities, with a maximum CVSS score of 8.8. Cisco says all RoomOS configurations are affected, no workaround exists, and it is not aware of malicious use. Fixed releases include 11.32.6.0 for on-premises RoomOS 11 and earlier, 11.39.1.1 for cloud-aware deployments, and the listed RoomOS 26 fixes.

Source: Cisco security advisory

Across SonicWall’s SMA1000 advisory, the AsyncAPI release compromise, fairlife’s production shutdown, and the DHS HSIN account, the failure point was the handoff between a control and the evidence used to trust it. A patched appliance still needs compromise review. A provenance-attested package still depends on protected release inputs. A closed alert still needs defensible validation. A continuity plan still needs tested dependencies for production systems. The defensive shift is from asking whether a control exists to asking what artifact proves it worked: firmware and forensic state, reviewed commits and protected branches, closure evidence, or recovery-test results. Controls without closure evidence become assumptions, and attackers repeatedly find the exceptions.

Action: Reopen and independently validate high-severity alerts closed as false positives during the last 30 days when they involved internet-facing, identity-bearing, CI/CD, or production-connected systems.

Who runs it: The SOC lead and incident-response or detection-engineering lead, with system owners supporting evidence collection.

Check these specifically: Web-server child processes, altered or deleted logs, unexpected scheduled tasks or services, hidden backdoors, credential-file access, CI-runner secret use, remote-access appliance administrative changes, and unusual outbound requests. Prioritize SMA1000 appliances, AD FS servers, CI runners, and systems that can interrupt production.

Evidence you’re done: An exported alert set or query, documented second-review findings, a list of reopened or escalated incidents, tuning changes, assigned remediation owners and dates, and a signed review ticket.

False positives are unavoidable. Treating “false positive” as a permanent conclusion is not. On high-consequence systems, closure should be an evidenced, reversible decision that can be sampled and challenged later. The same principle applies to provenance, patch status, and business-continuity plans: each is a useful summary, but none is proof by itself.

The better operating question is not “Do we have the control?” It is “What evidence would make us trust the result—and what evidence would force us to reopen it?” That small change turns assurance from a label into a process.