This is a maintenance hatch left unlocked inside the machine, dangerous only after someone already got into the chassis
CVE-2026-49189 affects Acer Connect M6E 5G portable Wi-Fi routers running firmware M6E_AI_1.00.000019 or earlier. Acer describes it as unchecked public access on a core Android-style Broadcast Receiver, which means a local software component on the device can send a broadcast and trigger administrative actions that should have been restricted.
There is no published vendor CVSS baseline here, so this is a first-principles call. In practice this is not an internet-reachable one-shot bug; it is a *post-compromise/local-position* privilege escalation on a relatively narrow device population. That sharply limits urgency, but the impact is still real because administrative operations on a mobile router can alter network behavior, device ownership, and trust settings if an attacker already has code execution on the unit.
4 steps from start to impact.
Get a foothold on the hotspot
adb-driven activity, not a raw network packet from the internet.- Attacker can execute code locally on the M6E device
- Device is reachable for maintenance, debug, or chained exploitation
- Target runs affected firmware
M6E_AI_1.00.000019or earlier
- Dedicated hotspot appliances are not normal app platforms in most enterprises
- This prerequisite already implies the attacker is past the initial-access stage
- Many fleets never expose debug or software-install paths to end users
Enumerate the exported receiver
apktool, aapt, or dumpsys package is enough to spot an exported receiver lacking a signature-level permission gate.- Access to firmware image, APK, or on-device package metadata
- Receiver remains exported or callable without privileged permission
- The exact component name is not public in Acer's advisory
- Attackers still need enough platform familiarity to map the receiver to a useful admin function
Send a crafted broadcast
am broadcast, passing the intent/action and extras needed to reach the privileged code path. If the receiver does not enforce exported=false or a signature permission, the untrusted caller can invoke operations intended for trusted components only.- Receiver is callable by an untrusted local component
- Required action strings or extras can be discovered or brute-forced
- Some admin operations may require specific extras or internal state
- SELinux, app sandboxing, or partial permission checks may still limit reachable actions
logcat, and telemetry for unexpected broadcast invocations would be the best local signals, if available.Abuse administrative operations
- Receiver maps to meaningful privileged operations
- Those operations are not independently authorization-checked downstream
- Acer's public write-up does not show full impact beyond 'administrative operations'
- Blast radius is generally limited to the compromised device, not the whole enterprise by default
The supporting signals.
| In-the-wild status | No evidence reviewed of active exploitation, and not listed in CISA KEV. |
|---|---|
| Public PoC availability | No public PoC or exploit repo located in reviewed sources. That does not make it safe; it only means weaponization is not publicly commoditized yet. |
| EPSS | 0.00011 (~0.011% modeled exploitation probability in 30 days). Percentile was not confirmed in authoritative reviewed sources. |
| KEV status | CISA KEV: No. No KEV date applies. |
| Affected versions | Acer states affected firmware is M6E_AI_1.00.000019 or earlier on the Acer Connect M6E. |
| Fixed version | Acer says fixes will arrive in an upcoming OTA bundle, but a specific patched firmware version was not published in the advisory reviewed. |
| CVSS / vector | No vendor or authority CVSS score/vector is published. Mechanically, this behaves like a local, low-complexity, post-compromise authorization failure, not a remotely reachable internet exploit. |
| Exposure reality | This CVE's attack surface is on-device local component access, not a directly exposed WAN service. Separate Acer issues in the same bulletin cover external exposure; this one does not. |
| Disclosure date | 2026-06-04. |
| Reporter / credit | Acer credits Ta-Lun Yen for discovery and reporting. |
noisgate verdict.
The decisive factor is the attacker position requirement: this bug needs local code execution on the hotspot itself before it becomes useful. That makes it a post-initial-access privilege escalation on a niche device class, which is materially less urgent than a remotely reachable router flaw even though the downstream admin impact can be meaningful on a compromised unit.
Why this verdict
- Major downward pressure: requires local execution on the device. This is not unauthenticated remote and not even ordinary authenticated remote; it assumes the attacker can already run a software component on the hotspot.
- Compounding friction: post-compromise on a narrow platform. A dedicated portable router is a much smaller and less app-friendly target population than Windows, browsers, VPNs, or enterprise web middleware.
- Upward pressure: admin operations on a network device matter. If the receiver can change privileged state, the attacker may tamper with connectivity, trust settings, or management behavior in ways that outlast the initial foothold.
Why not higher?
It is not higher because the attack chain starts from a constrained prerequisite that many real deployments never expose: code execution on the appliance itself. There is no reviewed evidence of KEV listing, active campaigns, or a direct internet-triggerable path for this specific CVE, so scoring it like a remote edge-device takeover would be wrong.
Why not lower?
It is not lower because this is still a privilege boundary failure on a routing device, not cosmetic hardening debt. Once an attacker gets local execution, a publicly callable administrative receiver can become a reliable pivot for persistence, policy tampering, or chaining into higher-value network abuse.
What to do — in priority order.
- Eliminate local maintenance exposure — Disable or tightly gate any debug, servicing, or software-loading path that can place code on the M6E. Because this is a MEDIUM finding there is no mitigation SLA, so do this as normal hardening rather than an emergency change, then complete vendor remediation within the 365-day window once Acer ships the fix.
- Restrict where these hotspots are trusted — Treat M6E units as semi-trusted edge devices: keep them off privileged management segments, avoid using them as implicit trust anchors, and limit what downstream systems they can administer. This reduces blast radius if a local receiver-abuse chain lands on a device.
- Inventory affected firmware now — Build a list of every M6E at
M6E_AI_1.00.000019or earlier, tag business owners, and pre-stage the firmware rollout process. There is no mitigation SLA at MEDIUM, but inventory work should happen during the next normal operations cycle so the eventual patch is not delayed by asset uncertainty. - Monitor for unexplained admin-state changes — Review device settings, management endpoints, VPN profiles, and network behavior for drift that cannot be tied to approved change records. This will not prevent exploitation, but it can surface a compromised unit before the device is reused in a more sensitive environment.
- Perimeter firewalls alone do not solve this, because the vulnerable trigger is a local broadcast receiver, not a normal inbound WAN service.
- Admin password rotation alone does not close the receiver if the vulnerable component can invoke privileged code without going through the login flow.
- External network vulnerability scanning is a weak control here; at best it can fingerprint firmware, but it will not validate whether the receiver is actually exported and callable.
Crowdsourced verification payload.
Run this on an auditor workstation, jump host, or CI job with Python 3; no elevated privileges are required. Invoke it with the firmware version you read from the device screen or Admin Web UI, for example python3 verify_cve_2026_49189.py --version M6E_AI_1.00.000019; if Acer later publishes an exact fixed build, add --fixed-version <build> to allow a definitive PATCHED result.
#!/usr/bin/env python3
# verify_cve_2026_49189.py
# Check Acer Connect M6E firmware exposure for CVE-2026-49189.
#
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / usage error
#
# Usage examples:
# python3 verify_cve_2026_49189.py --version M6E_AI_1.00.000019
# python3 verify_cve_2026_49189.py --version M6E_AI_1.00.000020 --fixed-version M6E_AI_1.00.000020
import argparse
import re
import sys
AFFECTED_MAX = "M6E_AI_1.00.000019"
def normalize(v: str):
m = re.search(r'(\d+)\.(\d+)\.(\d+)', v)
if not m:
return None
return tuple(int(x) for x in m.groups())
def main():
parser = argparse.ArgumentParser(description='Assess Acer Connect M6E exposure to CVE-2026-49189 by firmware version.')
parser.add_argument('--version', required=True, help='Observed device firmware version, e.g. M6E_AI_1.00.000019')
parser.add_argument('--fixed-version', required=False, help='Vendor-published fixed firmware version, if/when Acer discloses it')
args = parser.parse_args()
current = normalize(args.version)
affected = normalize(AFFECTED_MAX)
if current is None:
print('UNKNOWN - could not parse --version value')
sys.exit(2)
if current <= affected:
print(f'VULNERABLE - observed version {args.version} is <= affected maximum {AFFECTED_MAX}')
sys.exit(1)
if args.fixed_version:
fixed = normalize(args.fixed_version)
if fixed is None:
print('UNKNOWN - could not parse --fixed-version value')
sys.exit(2)
if current >= fixed:
print(f'PATCHED - observed version {args.version} is >= fixed version {args.fixed_version}')
sys.exit(0)
print(f'UNKNOWN - observed version {args.version} is above known affected range but below declared fixed version {args.fixed_version}')
sys.exit(2)
print(f'UNKNOWN - observed version {args.version} is above {AFFECTED_MAX}, but Acer has not published a confirmed fixed version in the reviewed advisory')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
M6E_AI_1.00.000019 or earlier, identify any units used in sensitive or privileged network contexts, and review whether your environment exposes maintenance, debug, or software-loading paths that could give an attacker local execution on the device. Because this is MEDIUM with no KEV or active exploitation evidence, there is noisgate mitigation SLA — go straight to the 365-day remediation window; once Acer publishes the fixed OTA build, push it through normal change control and complete deployment within the noisgate remediation SLA of 365 days from fix availability.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.