← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-49189 · CWE-269 · Disclosed 2026-06-04

Unchecked public access permissions on a core Broadcast Receiver

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Post-compromise local privilege escalation on a niche hotspot, not a fleet-wide fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get a foothold on the hotspot

The attacker first needs a way to run a local software component on the Acer M6E itself. In practice that means a chained exploit, maintenance/debug access, or some form of package or component execution on the device; a likely weaponized path would be a malicious APK or adb-driven activity, not a raw network packet from the internet.
Conditions required:
  • 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.000019 or earlier
Where this breaks in practice:
  • 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
Detection/coverage: Network scanners will not see this step directly. Detection is mainly device hardening review, debug-access audit, and forensic evidence of local package/component execution.
STEP 02

Enumerate the exported receiver

Once on-box, the attacker identifies the vulnerable Broadcast Receiver in the application manifest or package metadata. Commodity Android tooling such as apktool, aapt, or dumpsys package is enough to spot an exported receiver lacking a signature-level permission gate.
Conditions required:
  • Access to firmware image, APK, or on-device package metadata
  • Receiver remains exported or callable without privileged permission
Where this breaks in practice:
  • 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
Detection/coverage: Mobile app SAST, manifest review, and firmware unpacking can catch this. Traditional vulnerability scanners usually miss it unless they key off firmware version.
STEP 03

Send a crafted broadcast

The attacker triggers the receiver using a custom local app or 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.
Conditions required:
  • Receiver is callable by an untrusted local component
  • Required action strings or extras can be discovered or brute-forced
Where this breaks in practice:
  • Some admin operations may require specific extras or internal state
  • SELinux, app sandboxing, or partial permission checks may still limit reachable actions
Detection/coverage: EDR on a standard endpoint will not help much here. Platform logging, logcat, and telemetry for unexpected broadcast invocations would be the best local signals, if available.
STEP 04

Abuse administrative operations

Successful invocation lets the attacker perform whatever admin actions sit behind the receiver: configuration changes, management-state changes, or other privileged operations. On a mobile router, that can translate into network tampering, persistence, service disruption, or setting the stage for follow-on abuse of other management functions.
Conditions required:
  • Receiver maps to meaningful privileged operations
  • Those operations are not independently authorization-checked downstream
Where this breaks in practice:
  • 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
Detection/coverage: Look for configuration drift, unexpected management changes, unexplained connectivity changes, or altered admin settings after local access events.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence reviewed of active exploitation, and not listed in CISA KEV.
Public PoC availabilityNo public PoC or exploit repo located in reviewed sources. That does not make it safe; it only means weaponization is not publicly commoditized yet.
EPSS0.00011 (~0.011% modeled exploitation probability in 30 days). Percentile was not confirmed in authoritative reviewed sources.
KEV statusCISA KEV: No. No KEV date applies.
Affected versionsAcer states affected firmware is M6E_AI_1.00.000019 or earlier on the Acer Connect M6E.
Fixed versionAcer says fixes will arrive in an upcoming OTA bundle, but a specific patched firmware version was not published in the advisory reviewed.
CVSS / vectorNo 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 realityThis 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 date2026-06-04.
Reporter / creditAcer credits Ta-Lun Yen for discovery and reporting.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.6/10)

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.

HIGH Affected product and version range from Acer advisory
MEDIUM Assessment that exploitability is sharply constrained by local-position requirement
LOW Exact blast radius of the hidden administrative operations behind the receiver

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. Inventory affected firmware now — Build a list of every M6E at M6E_AI_1.00.000019 or 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like an edge-RCE fire: start by inventorying every Acer Connect M6E running 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

  1. Acer security advisory for Acer Connect M6E vulnerabilities
  2. Acer Connect M6E product page
  3. Acer Connect M6E user manual PDF
  4. FIRST EPSS API documentation
  5. FIRST EPSS data and report documentation
  6. CISA Known Exploited Vulnerabilities Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.