CVE-2026-73749Patch(hpe / aruba_cx_10000-48y6c_\(r8p13a\))

CVE-2026-73749, a critical HPE AOS-CX vulnerability, enables unauthenticated remote code execution at CVSS 9.8. HPE patched 31 flaws across its switches. #HPE #Aruba #AOSCX #RCE #NetworkSecurity #Switches #InfoSec #PatchNow https://securityonline.info/hpe-aos-cx-cve-2026-73749-rce/ https://t.co/Y2BILewNdK

HPE Patches Critical RCE Vulnerabilities in AOS-CX (CVE-2026-73749) https://www.securityweek.com/hpe-patches-critical-rce-vulnerabilities-in-aos-cx-2/

🔥 CyberForge CVE of the Day #045 🚨 CVE-2026-73749 — HPE Aruba Networking AOS-CX Unauthenticated Elevated-Privilege RCE One reachable service. No account. No helpful click. Elevated code execution on infrastructure trusted to enforce the network’s boundaries. Multiple flaws in an HPE Aruba Networking AOS-CX daemon can improperly process malformed input. A remote attacker with network reachability can send crafted packets and potentially execute code with elevated privileges—without authentication or user interaction. The CVSS v3.1 score is 9.8 Critical. Internet exposure is not required, but reachability from any untrusted network creates a formidable path into privileged infrastructure. The vulnerable daemon, protocol and destination port have not been named publicly. That disclosure boundary matters: ⚠️ CVE-2026-73749 is confirmed unauthenticated, network-reachable elevated-privilege RCE—but public information is not sufficient to invent a reliable port scan, packet signature or exploit request. 🔑 Key details ⭐ Severity: Critical 📊 CVSS v3.1: 9.8 🧮 Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` 🧠 CVE metadata: CWE-284 — Improper Access Control 🧬 Public technical characterisation: Multiple buffer-overflow flaws / malformed-input processing 🎯 Target: HPE Aruba Networking switches running affected AOS-CX releases 🧩 Component: A publicly unnamed AOS-CX daemon 🌐 Attack vector: Network ⚙️ Attack complexity: Low 🔓 Privileges required: None 👆 User interaction: None 👑 Successful privilege level: Elevated privileges ⚔️ Confirmed impact: Remote code execution 💥 CVSS impact: High confidentiality, integrity and availability impact 🛡️ Fix: Upgrade to the applicable fixed AOS-CX release 🧱 Exposure reduction: Dedicated management segment/VLAN plus Layer 3-or-higher firewall policy 🚫 Active exploitation: None publicly confirmed by HPE at review time 🧪 Public PoC: No credible functional exploit verified 📋 CISA KEV: Not listed when checked 7 September 2026 📉 EPSS: Approximately 0.49%, around the 40th percentile at review time 🗓️ Published: 1 September 2026 📜 HPE advisory: HPESBNW05134 rev.1 🔬 Discovery: HPE Networking internal security research 🧬 What actually went wrong? AOS-CX is the operating system used across numerous HPE Aruba Networking enterprise switch families. One of its daemons processes network input. HPE states that multiple vulnerabilities in this daemon may cause malformed input to be handled improperly. An unauthenticated attacker can send specially crafted packets to the affected service. If the vulnerable processing is successfully controlled, the result may be remote code execution with elevated privileges. That description establishes four essential facts: 1️⃣ The attacker-controlled input arrives over a network path. 2️⃣ The vulnerable component is a daemon running on the switch. 3️⃣ Authentication and user interaction are not required. 4️⃣ The successful outcome is privileged code execution rather than merely information disclosure or a harmless error. Public coverage of the HPE bulletin describes the underlying issues as buffer overflows. The CVE ecosystem also associates the record with CWE-284, Improper Access Control. Those labels do not align perfectly. CyberForge will not turn that metadata disagreement into imaginary exploit mechanics. The public evidence does not identify: 🔹 A stack or heap overwrite primitive 🔹 A particular allocation or object layout 🔹 An instruction-pointer offset 🔹 A named protocol parser 🔹 The vulnerable service port 🔹 A reliable crash signature 🔹 A weaponised packet sequence The defensible technical statement is narrower and stronger: > An AOS-CX daemon improperly processes attacker-supplied malformed packets, and successful exploitation can produce unauthenticated remote code execution with elevated privileges. That is already enough to demand rapid remediation. 🧩 One CVE, multiple underlying defects CVE-2026-73749 is an umbrella identifier. HPE says “multiple vulnerabilities,” while public reporting describes nearly two dozen related defects beneath this one CVE. A narrow homemade workaround aimed at one guessed field or packet type may cover only an assumption. Apply the complete fixed release, and do not infer that every underlying issue uses the same corruption primitive. ⚔️ The practical attack chain 1️⃣ An attacker identifies an HPE Aruba Networking switch running an affected AOS-CX release. 2️⃣ They obtain a routed or directly connected network path to a switch-owned address exposing the affected service. 3️⃣ The attacker sends specially crafted packets without authenticating. 4️⃣ The unnamed AOS-CX daemon receives the traffic. 5️⃣ One or more vulnerable input-processing paths mishandle the malformed data. 6️⃣ Successful exploitation changes the daemon’s execution in an attacker-controlled manner. 7️⃣ Attacker-supplied code executes with elevated privileges on the device. 8️⃣ The compromised switch may then place configuration, network integrity and connected services at risk. The public HPE description confirms steps one through seven at a high level. Step eight represents the defensive consequences of privileged compromise—not activity HPE reports observing in a real CVE-2026-73749 intrusion. No packet structure, payload bytes or end-to-end exploit sequence have been published by HPE. 🧱 Why “network reachable” needs careful interpretation The CVSS vector assigns `AV:N`. That does not automatically mean “internet exposed,” and it certainly does not mean every affected switch can be attacked from anywhere. The attacker still requires a path to the affected service. That path might originate from: 🔹 A publicly routed switch address 🔹 An internet-adjacent management network 🔹 A user or guest VLAN 🔹 A compromised server in a data-centre segment 🔹 A breached administrator workstation 🔹 A remote-access VPN with excessive reach 🔹 A customer or partner connection 🔹 A wireless network with weak segmentation 🔹 An obsolete firewall exception 🔹 Another compromised router, firewall or switch An infrastructure device can be invisible to an external scanner and still be reachable from thousands of internal endpoints. The correct exposure question is not merely: “Is the web interface on the internet?” It is: “Which trust zones can reach switch-owned addresses, and which AOS-CX services will accept traffic from those zones?” Because HPE has not identified the daemon or port publicly, that question must be answered through configuration, routing, ACL, firewall and vendor evidence—not through a made-up CVE-specific scan. 🌐 Why elevated code execution on a switch matters An enterprise switch is a privileged control point, not a disposable endpoint. Depending upon its role, it may connect users, servers, storage, wireless infrastructure, management systems, hypervisors, data-centre services or other network devices. Elevated code execution could plausibly allow an attacker to attempt: 🔹 Configuration theft or manipulation 🔹 Collection of locally accessible secrets 🔹 Creation or alteration of administrator accounts 🔹 Changes to VLAN, VRF, ACL or routing policy 🔹 Weakening of segmentation boundaries 🔹 Traffic redirection or interception 🔹 Suppression or redirection of logs and telemetry 🔹 Use of the switch as an internal pivot 🔹 Access to management-plane services 🔹 Disruption of forwarding or connected applications 🔹 Attempts to establish persistence These are risk implications of privileged switch compromise. They are not claims that HPE observed these behaviours, that every affected platform exposes identical post-exploitation capability, or that a public exploit currently provides them. The actual blast radius depends upon the switch model, process context, operating-system protections, network topology, redundancy, secrets present on the device and privileges granted to the vulnerable daemon. 🧩 Affected switch families Public reporting on HPESBNW05134 identifies the following HPE Aruba Networking families: 🔴 Aruba CX 4100i Switch Series 🔴 Aruba CX 6000 Switch Series 🔴 Aruba CX 6100 Switch Series 🔴 Aruba CX 6200F Switch Series 🔴 Aruba CX 6300 Switch Series 🔴 Aruba CX 6400 Switch Series 🔴 Aruba CX 8320 Switch Series 🔴 Aruba CX 8325 Switch Series 🔴 Aruba CX 8360 Switch Series 🔴 Aruba CX 8400 Switch Series 🔴 Aruba CX 9300 Switch Series 🔴 Aruba CX 10000 Switch Series Product-family identity alone is not enough to close or approve a vulnerability ticket. Administrators must combine: 🔹 Exact model 🔹 Running AOS-CX release 🔹 Support lifecycle 🔹 Device role 🔹 Address and VRF configuration 🔹 Network reachability 🔹 Current HPE advisory guidance CMDB entries saying only “Aruba switch” are insufficient for this investigation. 🛡️ Affected and fixed AOS-CX releases HPE published the following minimum fixed versions: 🔴 10.10 branch Affected: up to and including 10.10.1180 Fixed: 10.10.1181 or later within the branch 🔴 10.13 branch Affected: 10.13.0000 through 10.13.1180 Fixed: 10.13.1190 or later 🔴 10.16 branch Affected: 10.16.0000 through 10.16.1051 Fixed: 10.16.1060 or later 🔴 10.17 branch Affected: 10.17.0000 through 10.17.1021 Fixed: 10.17.1030 or later 🔴 10.18 branch Affected release identified in public advisory data: 10.18.0001 Fixed: 10.18.1002 or later The earliest fixed build is not always the best long-term destination. Use the HPE Networking Support Portal and the current advisory to select a vendor-recommended supported release compatible with the exact hardware and feature set. Validate upgrade paths, redundant-pair behaviour, configuration compatibility, required intermediate versions, storage capacity, maintenance windows and rollback procedures before deployment. 🕰️ The End-of-Maintenance trap Public coverage states that 10.10.1181 is an End-of-Maintenance release containing only critical internally discovered fixes. It can address this CVE without becoming a maintained long-term destination. HPE presumes End-of-Maintenance software affected unless explicitly excluded; End-of-Support deployments may be unassessed and should be treated as potentially impacted. Absence from a scanner is not proof of safety. Isolate legacy systems and establish a dated migration or replacement plan. 🚫 Is CVE-2026-73749 being exploited? At the time of the CyberForge review: 🔹 HPE reported no awareness of active exploitation 🔹 HPE was not aware of a public proof of concept at publication 🔹 No credible functional public exploit was verified by CyberForge 🔹 GitHub’s advisory record identified no known public source code 🔹 CVE-2026-73749 was not present in CISA’s Known Exploited Vulnerabilities catalogue 🔹 EPSS was approximately 0.49%, around the 40th percentile EPSS is dynamic. Live aggregators displayed small differences and rounding around the review window. That does not create a contradiction. EPSS estimates the probability of exploitation in the next 30 days. CVSS describes potential technical severity. CISA KEV records vulnerabilities with evidence of exploitation in the wild. Each answers a different question. For CVE-2026-73749, the current intelligence says: “No malicious exploitation is publicly confirmed.” The technical assessment says: “An unauthenticated network attacker may execute code with elevated privileges on affected switches.” Use the first statement to prioritise calmly. Use the second to avoid complacency. The vulnerability was only published on 1 September 2026. Public silence during the first week is not proof that exploitation is impossible or that private research has not begun. 🧪 A word on public PoCs Fresh CVEs quickly acquire GitHub search results, automated landing pages, copied advisory text and repositories claiming to collect every exploit released during the year. A filename containing `CVE-2026-73749` is not a proof of concept. A credible claim needs the actual service, reproducible interaction with affected hardware, technical substance beyond copied advisory text and evidence of controlled execution or an attributable failure. No public implementation meeting that standard was verified during this review. Do not execute untrusted “PoC” files against production switches. Malware authors routinely exploit interest in newly disclosed CVEs by publishing credential stealers, backdoors or destructive scripts under attractive filenames. 🛠️ What HPE has provided HPE has provided the most important permanent control: fixed AOS-CX software for each affected supported branch. The advisory also recommends management-plane hardening: ✅ Restrict command-line and web-management access ✅ Place management interfaces on a dedicated Layer 2 segment or VLAN ✅ Enforce Layer 3-or-higher firewall policy ✅ Use accounting controls so administrator activity is attributable ✅ Upgrade to a supported fixed release The upgrade removes the vendor-defined vulnerable paths. Segmentation limits opportunity while maintenance is arranged and may reveal broader reachability weaknesses that survive after this CVE is fixed. 🧱 The management-segmentation caveat HPE’s recommendation is sound defence in depth, but the vulnerable daemon and port remain unnamed publicly. Restricting only SSH and HTTPS is therefore not a proven CVE-specific workaround. A mature interim control should consider all traffic to switch-owned management and control-plane addresses, then allow only what is operationally required from defined management sources. Before changing policy: 1️⃣ Identify every in-band and out-of-band management path. 2️⃣ Record approved jump hosts, controllers, monitoring systems, AAA servers and automation platforms. 3️⃣ Review routes and VRFs that provide access from user, guest, server, partner and VPN networks. 4️⃣ Remove obsolete broad rules and temporary vendor exceptions. 5️⃣ Preserve emergency access and a tested rollback route. 6️⃣ Validate legitimate management, monitoring and high-availability functions after enforcement. 7️⃣ Review counters and central logs for denied or unexpected access attempts. Segmentation is a bridge and a lasting hardening improvement. It is not a substitute for the fixed AOS-CX image. 👁️ The detection reality No authoritative universal packet signature was identified in the sources reviewed. That is unsurprising: HPE has not published the daemon name, protocol grammar, port, malformed field or exploit bytes. A rule claiming to detect “malformed AOS-CX packets” without those details should be treated cautiously. The strongest current detection layers are: 🔹 Accurate asset and version inventory 🔹 Network reachability analysis 🔹 Central switch logging 🔹 AAA and administrator-session monitoring 🔹 Configuration integrity 🔹 Control-plane health and restart telemetry 🔹 Flow and firewall correlation around suspicious events Detection content may improve if HPE or trusted security vendors release validated signatures. Until then, do not pretend that a generic IDS rule closes the visibility gap. 🔎 Defender hunting guide 1️⃣ Build the AOS-CX inventory Search the CMDB, network source of truth, procurement records, support contracts, controller data, configuration backups and vulnerability-management platform. For every device, record: 🔍 Hostname and management addresses 🔍 Exact switch model and family 🔍 Running and configured boot images 🔍 AOS-CX version 🔍 Support lifecycle 🔍 Site and network role 🔍 Redundancy peer or stack membership 🔍 Business services dependent upon it Include isolated devices, lab equipment, powered-off spares and switches absent from ordinary endpoint scanners. 2️⃣ Map reachability Identify which source networks can communicate with every switch-owned address. Include: 🔍 Internet and externally routed paths 🔍 User, guest and wireless VLANs 🔍 Server and virtualisation networks 🔍 Partner and customer connections 🔍 Remote-access VPN pools 🔍 Jump hosts and management platforms 🔍 Out-of-band management 🔍 Other infrastructure devices Review configurations and approved low-impact connectivity evidence. Do not send malformed payloads or attempt exploitation. Because the vulnerable port is not public, a successful test against SSH or HTTPS cannot prove that the vulnerable service is unreachable. 3️⃣ Review device health Search central logs and monitoring data for: 🔍 Unexplained daemon crashes or restarts 🔍 Watchdog events 🔍 Unexpected switch reboots 🔍 Sudden control-plane CPU or memory anomalies 🔍 Loss of telemetry 🔍 Routing or adjacency flaps 🔍 Redundancy transitions 🔍 Interface-state changes without an approved cause 🔍 Repeated faults correlated with traffic from one source These events have many ordinary causes. Correlation with vulnerable version state, new network sources and unauthorised configuration activity determines their significance. 4️⃣ Review network telemetry Search firewall, NetFlow/IPFIX and packet-broker data for new or unusual traffic directed at switch-owned addresses. Prioritise: 🔍 Sources outside approved management networks 🔍 First-seen internal or external sources 🔍 Repeated short sessions 🔍 Scanning across multiple infrastructure addresses 🔍 Traffic immediately preceding a daemon fault or reboot 🔍 Coordinated access to redundant peers 🔍 Unexpected outbound sessions initiated by a switch Traffic to a switch is not proof of exploitation. Preserve and correlate it rather than applying a CVE label without protocol evidence. 5️⃣ Check configuration integrity Compare current configurations with a protected known-good baseline. Review changes to: 🔍 Local users, roles and privilege levels 🔍 AAA, TACACS+ and RADIUS settings 🔍 SSH keys and management access 🔍 VLANs, VRFs and routed interfaces 🔍 ACLs and control-plane policy 🔍 SPAN, mirroring or traffic-copy features 🔍 Logging and telemetry destinations 🔍 DNS, NTP and external service settings 🔍 Software images and boot variables 🔍 Scheduled or automated operations An unexplained change following suspicious access should be escalated even if the device has since been patched. 6️⃣ Preserve evidence If compromise is plausible, preserve: 🔍 Central syslog, monitoring and AAA records 🔍 Running/startup configurations and image details 🔍 Uptime, process health and crash records 🔍 Firewall, flow and available packet evidence 🔍 Change-management history Coordinate collection carefully. Network infrastructure is operationally sensitive, and an impulsive reload or upgrade may destroy volatile evidence or enlarge an outage. Engage HPE support and the organisation’s incident-response process where privileged execution cannot be ruled out. 🚑 Defensive action ✅ Inventory every device running AOS-CX ✅ Confirm the exact model, running image and support status ✅ Compare each release with HPESBNW05134 ✅ Identify End-of-Maintenance and End-of-Support deployments ✅ Map reachability to all switch-owned addresses ✅ Remove access from internet, user, guest and unnecessary server networks ✅ Restrict management to dedicated segments and approved jump hosts ✅ Schedule the applicable vendor-recommended fixed release ✅ Validate upgrade paths, redundancy and rollback requirements ✅ Confirm every stack member, supervisor and standby component after upgrading ✅ Review historical daemon failures, watchdog events and reboots ✅ Hunt unusual flow, AAA and configuration activity ✅ Preserve evidence and escalate where compromise is plausible ✅ Recheck HPE, CISA KEV, EPSS and credible exploit reporting Prioritise the remediation queue in this order: 1️⃣ Affected switches reachable from the internet or untrusted external networks. 2️⃣ Affected switches reachable from user, guest, wireless, partner, server or broad VPN segments. 3️⃣ Core, aggregation and data-centre switches whose compromise or outage would have a large business impact. 4️⃣ Affected switches reachable only through a verified restricted management network. 5️⃣ Isolated laboratory systems and powered-off spares. Every affected device should still be upgraded. Reachability determines sequence—not permission to remain vulnerable. 🧾 Evidence separation Confirmed by HPE: multiple vulnerabilities exist in an AOS-CX daemon that can improperly process malformed input; an unauthenticated remote attacker can send specially crafted packets to the affected service; successful exploitation may result in remote code execution with elevated privileges; fixed AOS-CX releases are available. Confirmed by the CVSS assessment: the attack is network based, low complexity, requires no privileges or user interaction, retains scope and carries High confidentiality, integrity and availability impact. Confirmed by public advisory data: affected branches include 10.10 through 10.18 with minimum fixed builds 10.10.1181, 10.13.1190, 10.16.1060, 10.17.1030 and 10.18.1002 as applicable. Confirmed exploitation status: HPE reported no known active exploitation at publication. No credible functional public PoC was verified during the CyberForge review, and CISA KEV did not list the CVE when checked. CyberForge interpretation: elevated execution on a trusted switch could enable configuration manipulation, secret theft, weakened segmentation, traffic disruption, persistence attempts or lateral movement. Process instability is a credible concern for malformed-input flaws, but no CVE-specific crash signature was published in the material reviewed. Not established: the daemon name, protocol, service port, exact corruption primitive, a universal exploit packet, a public weaponised PoC, active exploitation, a named threat actor, a victim set, a campaign, guaranteed persistence or a CVE-specific network signature. 🔥 CyberForge verdict CVE-2026-73749 is the sort of vulnerability that makes quiet threat intelligence deceptively comforting. No public campaign is confirmed. No credible weaponised PoC was verified. EPSS is still modest, and the CVE has not entered CISA KEV. The technical condition remains formidable. An unauthenticated attacker can deliver crafted network packets to an affected AOS-CX daemon. Attack complexity is scored Low. No user interaction is required. Successful exploitation may execute code with elevated privileges on a switch trusted to enforce organisational network boundaries. HPE has not disclosed the daemon or port, so defenders cannot depend upon one neat firewall rule or signature. They can still act decisively. The affected release branches are known. The minimum fixed versions are known. Management segmentation is valuable. Device health, network flow, AAA and configuration integrity provide hunting opportunities. The permanent destination is a supported fixed AOS-CX release. The sensible response is neither panic nor delay: 1️⃣ Discover every AOS-CX device. 2️⃣ Confirm the exact release and support state. 3️⃣ Prove which networks can reach switch-owned addresses. 4️⃣ Restrict those paths to approved management sources. 5️⃣ Hunt unexplained failures, traffic and configuration changes. 6️⃣ Upgrade to fixed software. 7️⃣ Verify the running image and protection after deployment. The one-sentence CyberForge verdict: > When malformed packets need neither credentials nor a click to become elevated code execution on an enterprise switch, a quiet threat feed is a patching window— not permission to leave the network boundary exposed. 🔗 Rapid7 vulnerability record: https://www.rapid7.com/db/vulnerabilities/cve-2026-73749/ 🔗 HPE security advisory: https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw05134en_us&docLocale=en_US 🔗 GitHub Advisory Database: https://github.com/advisories/GHSA-q898-2qwx-466h 🔗 Independent security coverage: https://www.bleepingcomputer.com/news/security/hpe-patches-critical-arubaos-cx-remote-code-execution-flaw/ 🔗 Full vulnerability details: https://nvd.nist.gov/vuln/detail/CVE-2026-73749 #CyberSecurity #CVE #HPE #ArubaNetworks #AOSCX #ArubaCX #RemoteCodeExecution #UnauthenticatedRCE #NetworkSecurity #SwitchSecurity #FirmwareSecurity #VulnerabilityManagement #ThreatHunting #BlueTeam #SecOps #CyberForge

🚨 ALERTĂ | Vulnerabilitate critică în HPE Aruba Networking AOS-CX ⚠️ CVE-2026-73749 (CVSS 9.8) poate permite unui atacator neautentificat execuția de cod de la distanță, cu privilegii ridicate. 🛡️ Actualizați cu prioritate! 👉 Detalii: https://www.dnsc.ro/citeste/alerta-vulnerabilitati-critice-identificate-in-hpe-aruba-networking-aos-cx #DNSC #cyber https://t.co/jVYH6X1JcB

HPE patches critical unauthenticated RCE in ArubaOS-CX switches https://anavem.com/news/hpe-patches-arubaos-cx-rce-cve-2026-73749

🚨 Critical vulnerability alert — 2 CVEs, both CVSS 9.8 CVE-2026-20212 (Cisco Nexus 9000) → Unauthenticated root-level RCE → Hits Nexus 9000 w/ Silicon One, via TCP 43210/43211 → Can crash S1HAL & reload switch CVE-2026-73749 (HPE ArubaOS-CX) → Unauthenticated RCE w/ elevated privileges → Triggered by crafted network packets → Hits multiple AOS-CX branches No known active exploitation on either, patch now. Learn more:https://hubs.la/Q04wKV8F0 #Cisco #HPE #RCE #CyberSecurity

#threatreport #LowCompleteness CVE-2026-73749: HPE ArubaOS-CX RCE | 06-09-2026 Source: https://socradar.io/blog/cve-2026-73749-hpe-arubaos-cx-rce/ Key details below ↓ 🎯Victims: Network infrastructure 🔓CVEs: CVE-2026-73749 \[[Vulners](https://vulners.com/cve/CVE-2026-73749)] - CVSS V3.1: *9.8*, - Vulners: Exploitation: Unknown Soft: - hpe arubaos-cx (le10.10.1180, le10.13.1180, le10.16.1051, le10.17.1021, 10.18.0001) #threatreport: CVE-2026-73749 is a critical vulnerability affecting the HPE ArubaOS-CX operating system. Rated CVSS 9.8, the issue involves multiple flaws in an AOS-CX daemon that improperly processes malformed input. An unauthenticated remote attacker may exploit the vulnerability by sending specially crafted packets to the affected service, without requiring valid credentials or prior access to the device. Successful exploitation could enable remote code execution with elevated privileges on the targeted switch. This creates a significant risk to the confidentiality, integrity, and availability of network infrastructure, particularly if the vulnerable service is reachable from untrusted or broadly accessible networks. Administrators should verify the precise AOS-CX software image and build running on each device rather than relying only on the major release branch when determining exposure. AOS-CX version 10.10.1181 has reached End of Maintenance, although HPE indicated that it receives fixes for internally discovered critical issues, including CVE-2026-73749. Organizations should consult HPE’s security advisory for the applicable fixed versions and upgrade guidance. The reviewed HPE bulletin does not provide a validated workaround. If patching cannot be completed immediately, administrators should reduce exposure by restricting switch management and control-plane access to dedicated management networks. Management-plane access control lists, firewall policies, and network segmentation should be used to limit which source networks can reach the affected service. These controls are temporary risk-reduction measures and do not replace applying the appropriate security update.

🚨 HPE ArubaOS-CX switches are exposed to unauthenticated RCE. CVE-2026-73749 (CVSS 9.8) 🤯 Crafted packets → elevated privileges. No login required. Network gear remains one of the cleanest paths to full environment control. https://www.securityweek.com/hpe-patches-critical-rce-vulnerabilities-in-aos-cx/ #NetworkSecurity #Aruba #ThreatIntel

🔥 CyberForge Weekly CVE Rundown #001 — The Sunday Debrief 🗓️ 6–12 September 2026 Seven days. Seven CVEs. One defender-focused debrief. Our inaugural roundup travelled from hostile network metadata and exposed switch services to poisoned commerce templates, a Windows sandbox escape, unsafe AI-agent replay, a compromised firewall feed and finally GitLab file disclosure. Different products; one recurring lesson: when a trusted boundary processes attacker-controlled input with more authority than it deserves, the quietest-looking data can become the sharpest weapon. 📚 The seven-day rundown 1️⃣ Sunday — Day #044 — CVE-2026-86098 ntop nDPI — Heap Buffer Overflow in JSON Serialisation Network-derived TLS SNI, HTTP-header or DNS data can expand during JSON escaping and overflow a caller-supplied heap buffer in nDPI before 6.0. Heap corruption and crashes are confirmed; reliable RCE was not publicly demonstrated. ⚠️ Why it made the list: A passive DPI sensor can still be reached by hostile traffic, and vulnerable code may hide inside downstream products. 🛡️ Defender move: Upgrade or backport nDPI 6.0, then inventory static, vendored and appliance copies. 📌 Status: No confirmed exploitation or weaponised end-to-end exploit identified as published on 6 September. 🔗 Primary source: https://www.vulncheck.com/advisories/ntop-ndpi-before-6.0-heap-buffer-overflow-via-ndpi-json-string-escape 2️⃣ Monday — Day #045 — CVE-2026-73749 HPE Aruba Networking AOS-CX — Unauthenticated Elevated-Privilege RCE Malformed network packets sent to an affected, publicly unnamed AOS-CX daemon can yield elevated-privilege code execution without credentials or user interaction. HPE scored it CVSS v3.1 9.8. ⚠️ Why it made the list: The target is trusted switching infrastructure, where compromise can threaten segmentation, availability and management-plane integrity. 🛡️ Defender move: Apply the branch-specific fixed AOS-CX release and isolate management access; the minimum fixes begin at 10.10.1181, 10.13.1190, 10.16.1060, 10.17.1030 and 10.18.1002. 📌 Status: HPE knew of no active exploitation; no KEV entry or verified functional public PoC as reviewed on 7 September. 🔗 Primary source: https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw05134en_us&docLocale=en_US 3️⃣ Tuesday — Day #046 — CVE-2026-75650 StyleSmuggler — Adobe Commerce and Magento Pre-Authentication RCE An unauthenticated attacker can poison template data and trigger server-side rendering through a failed-payment notification path. Adobe confirmed active exploitation; Sansec reported evolving implants and web-shell activity from the zero-day window. ⚠️ Why it made the list: The email is a server-side execution trigger—nobody needs to receive or open it. 🛡️ Defender move: Apply hotfix VULN-39341, verify it, hunt for compromise, then rotate the Commerce encryption key and every dependent credential at its source. 📌 Status: Actively exploited as published on 8 September; attacks were publicly reported from late 4 September. 🔗 Primary source: https://helpx.adobe.com/security/products/magento/apsb26-146.html 4️⃣ Wednesday — Day #047 — CVE-2026-85880 Microsoft Windows ALPC — AppContainer Escape to SYSTEM Code already running inside a low-privilege AppContainer can exploit an ALPC heap overflow and uninitialised-resource flaw to escape the sandbox and obtain `NT AUTHORITY\\SYSTEM`. It is not a standalone remote entry point. ⚠️ Why it made the list: This CVSS 7.8 flaw proves that active exploitation and destination privilege can matter more than a score-sorted queue. 🛡️ Defender move: Deploy the September Windows update, verify fixed builds after restart and hunt for the initial foothold plus post-escalation SYSTEM activity. 📌 Status: Microsoft-confirmed exploitation; CISA KEV added 8 September with remediation due 22 September. 🔗 Primary source: https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2026-85880 5️⃣ Thursday — Day #048 — CVE-2026-79696 Google ADK for Python — Saved Agent Replay to Unauthenticated RCE An exposed vulnerable `adk web` environment with `pytest` installed can resolve a malicious YAML code reference missed by an incomplete Python denylist, then dispatch it through saved-session replay. The model need not be prompt-injected or persuaded. ⚠️ Why it made the list: Configuration crossed into executable code, while replay bypassed the model as a decision point entirely. 🛡️ Defender move: Remove untrusted exposure, upgrade `google-adk` to 2.7.0+, rebuild deployed images and review workload IAM and secrets. 📌 Status: CVSS v4.0 10.0; no confirmed exploitation, KEV entry or reliable standalone PoC as reviewed on 10 September. 🔗 Primary source: https://github.com/google/adk-python/releases/tag/v2.7.0 6️⃣ Friday — Day #049 — CVE-2026-65639 ConfigServer Security & Firewall — Trusted Rule Feed to Root Commands If a vulnerable CSF host consumes attacker-controlled content from an administrator-configured remote allow or deny feed, unsafe advanced-rule parsing can execute arbitrary operating-system commands as root. No remote feed is configured by default. ⚠️ Why it made the list: The server initiates the connection, yet its trusted security data becomes the attack primitive. 🛡️ Defender move: Upgrade to CSF 16.30+; verify configured feeds, preserve cached content and investigate suspicious process activity around refreshes. 📌 Status: CVSS v4.0 9.5; no confirmed exploitation, KEV listing or reliable standalone PoC as reviewed on 11 September. 🔗 Primary source: https://support.cpanel.net/hc/en-us/articles/43387923160343-Security-CVE-2026-65639-CSF-Security-Release 7️⃣ Saturday — Day #050 — CVE-2026-85706 GitLab — Unauthenticated Commits-API Path Traversal Under the disclosed conditions, GitLab's repository commits API can escape its repository boundary and read local files available to the application context without authentication. Researchers report that at least one public project is required; direct file write, RCE and automatic root were not established. ⚠️ Why it made the list: One readable secret may carry authority over repositories, runners, pipelines and connected infrastructure. 🛡️ Defender move: Upgrade Self-Managed GitLab to 19.1.8, 19.2.6, 19.3.2 or later; preserve logs, hunt the commits route and investigate exposed trust material. 📌 Status: CVSS v3.1 10.0; CISA KEV added 11 September; public probing reported from 06:00 UTC that day. 🔗 Primary source: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/ 🔄 Since the original posts. As-published recap: These summaries preserve the patch, exploitation, PoC, KEV and EPSS positions recorded in our 6–12 September editions. No additional Sunday status review was completed, so they should not be read as fresh claims that nothing has changed. 🏆 This week's Forge honours. 🚨 Most Severe — Joint honour: CVE-2026-75650, CVE-2026-79696 and CVE-2026-85706 Each received a vendor/CNA maximum score: Days #046 and #050 scored CVSS v3.1 10.0, while Day #048 scored CVSS v4.0 10.0. Their outcomes differ — active Commerce RCE, conditional exposed-ADK RCE and known-exploited GitLab file read — so the scores are not a claim of identical practical risk. 🧩 Most Interesting Attack Chain — CVE-2026-75650, StyleSmuggler. Poisoning stored template data and later triggering server-side rendering through a failed-payment notification made this the week's finest documented chain. The execution occurred while Commerce built the message; the supposed “email attack” required no reader, click or successful delivery. 🛡️ Most Defender-Relevant — CVE-2026-85706, GitLab. A legitimate, commonly exposed repository API, no authentication, rapid probing, KEV status and potential access to CI/CD trust make Day #050 an immediate patch-and-investigate case for Self-Managed estates. 💜 CyberForge Pick of the Week. CVE-2026-85880 — AppContainer Breakout to SYSTEM Day #047 takes our first purple crown, and quite deservedly hehe. A low-privilege process beginning inside Windows' locked-down AppContainer can cross the ALPC boundary and emerge as SYSTEM—with Microsoft-confirmed exploitation already in play. Its grand lesson is pure CyberForge: CVSS 7.8 can outrank a theoretical 10.0 when exploitation evidence, host privilege and operational context enter the room. 🧠 What connected the week. Every selection exposed a misplaced trust boundary. Day #044 trusted network metadata near native memory; #046 trusted stored style data at a template engine; #048 trusted YAML references and replayed tool calls; #049 trusted remote firewall policy as root; and #050 trusted a repository path to stay inside the repository. Days #045 and #047 showed the same principle at switch-daemon and Windows sandbox boundaries. Different vulnerability classes, same defensive habit: Trace un-trusted input until it stops acquiring new authority. 🛡️ The defender's Monday shortlist. 1️⃣ Patch and hunt the operational cases first: StyleSmuggler (#046), exploited Windows ALPC (#047) and KEV-listed GitLab (#050). 2️⃣ Find the hidden exposure: embedded nDPI (#044), reachable AOS-CX services (#045), public `adk web` (#048) and configured CSF feeds (#049). 3️⃣ Verify trust after patching: preserve evidence, review credentials and inspect downstream identity, runner, pipeline and infrastructure activity wherever exposure cannot be bounded. 🔥 CyberForge closing thought. Our first weekly debrief did not produce one universal exploit story. It produced something more useful: seven reminders that vulnerability management begins with a CVE number, but good defence follows the data, permissions and trust relationships all the way to their real consequence. > Patch the flaw, investigate the window, and never let a severity number speak without its attack conditions. #CyberSecurity #CVE #WeeklyRundown #ThreatHunting #BlueTeam #VulnerabilityManagement #IncidentResponse #CyberForge

【重要】HPE Aruba AOS-CXにCVSS 9.8、認証不要RCEを修正 https://www.cybernote.click/2026/09/06/hpe-aruba-aos-cx-cve-2026-73749-rce/ #IT #Security #cybersecurity

Aruba AOS-CX kritieke RCE: CCB vraagt firmware-upgrade nu https://www.kmo.partners/2026/09/11/aruba-aos-cx-cve-2026-73749-ccb-patch/ https://www.kmo.partners/wp-content/uploads/2026/09/aruba-cover.jpg #aos-cx #ccb #cve-2026-73749 #cybersecurity #fabricCo https://t.co/jstjJOqPh0

HPE AOS-CX switch RCE bundleHPE patched a pile of AOS-CX bugs tracked together as CVE-2026-73749 (reported CVSS 9.8). Network OS on campus/core switches. Critical RCE class. If the management plane is reachable, treat it like a router 0-day week: patch, then dump config diffs. https://www.securityweek.com/hpe-patches-critical-rce-vulnerabilities-in-aos-cx/ #CVE202673749 #HPE #Networking

HPE patched critical unauth RCE in ArubaOS-CX (CVE-2026-73749) via crafted packets to a daemon, plus a broad CX advisory set. Inventory CX switches; patch mgmt-exposed devices first. No active exploit reported yet. https://www.bleepingcomputer.com/news/security/hpe-patches-critical-arubaos-cx-remote-code-execution-flaw/

HPE patched a critical unauthenticated RCE flaw (CVE-2026-73749) in ArubaOS-CX, the network OS on its enterprise switches used by large businesses, government agencies, healthcare orgs, and data centers; a buffer overflow lets remote attackers execute code with elevated privileges via crafted packets. The bulletin also covers 23 other vulnerabilities, several rated 8.1 to 8.8.

A critical unauthenticated remote code execution vulnerability in HPE ArubaOS-CX, tracked as CVE-2026-73749, has been patched by the vendor. https://ift.tt/9PIM5Ke

A critical unauthenticated remote code execution vulnerability in HPE ArubaOS-CX, tracked as CVE-2026-73749, has been patched by the vendor. https://ift.tt/9PIM5Ke

【重要】HPE Aruba AOS-CXにCVSS 9.8、認証不要RCEを修正 https://www.cybernote.click/2026/09/06/hpe-aruba-aos-cx-cve-2026-73749-rce/ #IT #Security #cybersecurity

🚨 CRITICAL: CVE-2026-73749 | CVSS 9.8 AOS-CX daemon vulnerabilities allow unauthenticated RCE with elevated privileges via malformed packets. Patch immediately. #CVE #Vulnerability #PatchNow #ThreatIntel #DFIR https://t.co/caF0cF2XIz

HPE patched CVE-2026-73749 in ArubaOS-CX (CVSS 9.8). Unauth remote code execution via crafted packets to a switch daemon. Upgrade now: 10.18.1002+, 10.17.1030+, 10.16.1060+, 10.13.1190+, 10.10.1181+. https://www.bleepingcomputer.com/news/security/hpe-patches-critical-arubaos-cx-remote-code-execution-flaw/

HPE Patches Critical RCE Vulnerabilities in AOS-CX CVE-2026-73749: HPE has patched multiple vulnerabilities in AOS-CX, including critical-severity flaws leading to remote code execution. https://www.securityweek.com/hpe-patches-critical-rce-vulnerabilities-in-aos-cx-2/ https://t.co/z0LD77QfK9