A SQL injection does not have to expose a full database dump to become an operational emergency. HPE reports that CVE-2026-79858 lets an unauthenticated network attacker inject SQL through the PAPI protocol on affected AOS-8 systems. The vendor says successful exploitation could expose or modify sensitive information in the underlying database and interrupt the affected service. The CVSS 3.1 score is 9.8, with high confidentiality, integrity, and availability impact.
That combination changes the incident question. Teams should ask not only whether data was read, but whether configuration, operational records, or database content was changed in a way that could affect network behavior later.
What HPE established
HPE's HPESBNW05162 advisory describes the issue as an unauthenticated SQL injection in the PAPI protocol. The attack vector is network-based, privileges are not required, and user interaction is not required. The vendor ties the weakness to AOS-8 versions through 8.13.3.0 and 8.10.0.23. Fixed releases are 8.13.3.1 and 8.10.0.24.
The public advisory does not identify the vulnerable endpoint, the database engine, the exact query structure, or a packet-level exploit sequence. It should not be used to infer those details. The important public facts are the unauthenticated path, the injection class, the affected branches, the patched releases, and the stated impact to confidentiality, integrity, and availability.
A CVE filter search in ZoomEye returned no indexed matches for this CVE during this review. A broader product query for app="ArubaOS" returned 211 matches. Those 211 are product-fingerprint results, not confirmed vulnerable devices. They can support a discovery list, but an operator still needs asset-owner confirmation and version checks.
Why integrity deserves its own workstream
Many SQL injection responses start with a search for signs of bulk extraction. That is useful, but it can miss the longer-lived problem. If an attacker can modify information in a live management system, a later controller restart, configuration synchronization, or automated workflow may carry the altered state forward.
For this CVE, defenders should define which data is operationally sensitive. Examples include controller configuration records, local user or role data, trusted management relationships, service-health information, and any database-backed records that influence device behavior. The exact schema is not public, so the response should start from the organization's own asset and application model.
The response should also preserve evidence before repair. Replacing a configuration or restoring a database may remove the data needed to explain an earlier change. Capture current configuration checksums, administrative logs, backup dates, deployment records, and service exceptions. Record who collected each item and when it was captured.
A defensible triage sequence
First, identify every applicable AOS-8 deployment and verify its current software release. Treat the advertised version with the same care as the actual running version, especially where staged or mixed environments are possible.
Second, determine where PAPI is reachable. A network diagram that only covers web management interfaces is incomplete for this issue. Confirm which routing, firewall, and VLAN boundaries allow PAPI traffic to reach AOS-8 assets.
Third, compare configuration and data records against known-good baselines. This should include changes outside a scheduled window, unexpected trust relationships, unexplained local accounts or permissions, and alerts that coincide with unusual PAPI reachability. These checks are investigative leads, not proof that exploitation occurred.
Fourth, patch to 8.13.3.1, 8.10.0.24, or a later supported release. HPE also recommends restricting command-line and web management interfaces to a dedicated Layer 2 segment or VLAN and controlling them with Layer 3 and higher firewall policy. Accounting controls should track and log user activity and resource use.
The limits of the public record
HPE says it was not aware of public discussion or exploit code when the advisory was released. That does not establish that no exploitation occurred, and it does not make internet-facing PAPI a safe exposure. It also does not justify claiming that any ZoomEye match is compromised.
The practical conclusion is narrower and more useful: treat CVE-2026-79858 as both a data-exposure and data-integrity problem, collect evidence before making changes, verify reachability rather than assuming it, and patch the affected AOS-8 branches. The database question continues after the upgrade, because a repaired device can still reflect altered state that was introduced earlier.