CVE-2026-79858 gives security and network teams a concrete scenario to test: an unauthenticated network attacker reaches the PAPI protocol on an affected AOS-8 system and attempts to read or change database-backed information. The exercise should improve decision speed without pretending that a hypothetical event has occurred.
The public advisory does not disclose the vulnerable endpoint, query construction, packet layout, or database engine. The tabletop should stay at the level the evidence supports. Its purpose is to test ownership, evidence collection, containment, and patch coordination for the conditions HPE describes.
Scenario setup
State clearly that the scenario is fictional. Assume an AOS-8 controller or gateway is running a version within the affected ranges. It has a management role that matters to wireless operations, and a path from a non-management network can reach PAPI. An alert suggests an unexplained configuration change, but the alert alone does not prove exploitation.
The facilitator should provide only information that a real team could reasonably obtain. Avoid handing participants a perfect packet capture or a confirmed database query result. Those details are not public for this CVE and would turn the exercise into a script rather than a decision test.
Round one: establish the facts
Ask the asset owner to confirm the model, role, running release, ownership, and business dependency. Ask the network team to reconstruct which sources can reach PAPI and which rules or routes create that path. Ask security operations which logs are available, where they are retained, and whether the suspected change corresponds to an approved maintenance event.
The output should separate four categories: verified facts, missing evidence, working hypotheses, and decisions. A product match from ZoomEye belongs in the fact category only as a product match. It should not be promoted to a vulnerable or compromised finding without asset-owner verification.
Round two: preserve evidence and contain
Participants should decide what to preserve before making disruptive changes. Reasonable items include current configuration, accounting records, software versions, backup metadata, relevant service logs, and the time range of external reachability.
Next, ask who can narrow access without breaking wireless operations. HPE recommends dedicated Layer 2 segmentation or VLANs for command-line and web management interfaces, Layer 3 and higher firewall policy, and accounting controls. The facilitator should require participants to name the exact traffic path and the person who will validate the change.
A useful answer includes a rollback condition. A poor answer is simply to enable a firewall rule and declare the asset contained without checking that PAPI is no longer reachable from the untrusted source or that management operations still work.
Round three: patch and verify
The patching owner should state the applicable fixed release. HPE lists 8.13.3.1 for the affected 8.13 range and 8.10.0.24 for the affected 8.10 range. The team should identify the approved target for the fictional asset, the maintenance window, the service owners who must participate, and the evidence required after the change.
Verification should include the running version, wireless service health, management connectivity, monitoring, and accounting visibility. If integrity concerns remain, the team should decide who owns the comparison against the preserved baseline and what evidence would close or escalate the case.
Round four: communicate uncertainty
Ask each participant to write a one-sentence status update. The update should avoid saying that 211 public ArubaOS fingerprints were attacked and avoid saying that a zero CVE-filter result proves safety. A strong example is: an affected AOS-8 asset has a reachable PAPI path and a configuration anomaly whose cause is not yet known; containment and evidence preservation are underway.
This exercise is useful because the vulnerability combines unauthenticated access with both data and availability impact. It forces the organization to coordinate teams that often work separately: wireless operations, network security, incident response, change management, and data owners.
Capture improvements
The final output should list concrete changes, not general lessons. Examples include adding AOS-8 version and PAPI reachability fields to the asset inventory, testing management-segment firewall rules before an incident, assigning an owner for accounting logs, and documenting the approved patch and rollback evidence.
CVE-2026-79858 does not require an invented breach narrative to support a serious exercise. The published conditions are enough to test whether the organization can distinguish exposure from exploitation and move from uncertainty to a verified fixed state.