Undisclosed hardware fingerprint telemetry with no opt-out

[Lafunamor]

The panel collects a persistent hardware fingerprint and reports it, together with feature-usage data, to www.aapanel.com on a schedule. I could not find any way to turn this off, and I could not find it disclosed in the README or license.txt. Filing as a transparency/privacy request rather than as a security bug.

What is collected

class/public/common.py:5111 — fetch_env_info(), verified at v8.21.0:

def fetch_env_info():
    try:
        return {
            'ip': GetLocalIp(),
            'is_ipv6': 0,
            'os': get_platform(),
            'mac': get_mac_address(),      # MAC address
            'hdid': fetch_disk_SN(),       # disk serial number
            'ramid': get_memory(),
            'cpuid': fetch_cpu_ID(),       # CPU ID
            'server_name': get_hostname(),
            'install_code': get_server_id()
        }
    except:
        return {}

Where it goes

BTTask/task_script.py:374 — submit_module_call_statistics():

cloudUrl = '{}/api/panel/submit_feature_invoked_bulk'.format(public.OfficialApiBase())
...
pdata['environment_info'] = json.dumps(public.fetch_env_info())
pdata['data'] = data_submit
requests.post(cloudUrl, json=pdata, headers=url_headers)

Registered as a recurring task in BTTask/task.py:1384 (interval: 3600, throttled to roughly once a day by an internal date marker). The same environment_info payload is also attached to licence, plugin and store requests from class/panelAuth.py (107, 247, 325, 364, 378, 401) and class/panelPlugin.py (470, 2744).

The installer additionally beacons before any consent is given — install_6.0_en.sh:135 fires api/setupCount/setupPanelInstalling at the start of the run.

Why this is worth changing

To be fair about what this is: I traced the payloads and no site content, credentials, or database contents are transmitted. This is licence binding plus product analytics, which is a legitimate thing for commercial software to do — I am not suggesting anything is being smuggled out.

The concerns are narrower:

1. It is a hardware-level identifier. MAC address, disk serial and CPU ID survive OS reinstalls and IP changes. That is a durable cross-installation identity, not an anonymous usage counter.
2. There is no opt-out. I searched the tree for a telemetry/reporting toggle and found none — this appears unconditional for every installation.
3. It is not disclosed. Neither the README nor license.txt mentions that this data is collected or transmitted.
4. For EU/UK operators this has legal weight. A persistent hardware identifier tied to an identifiable server is likely personal data under GDPR, and collecting it without notice or a lawful basis is a real compliance problem for anyone running aaPanel commercially in that jurisdiction. Users cannot assess this today because it is undocumented.

Suggested fix

Any one of these would be a meaningful improvement, in rough order of value:

1. Document it — a short section in the README or a PRIVACY.md stating what is collected, why, how often, and how long it is retained.
2. Provide an opt-out — a settings toggle, or a sentinel file such as data/no_telemetry.pl, honoured by submit_module_call_statistics().
3. Ask on first run — surface the choice during initial setup rather than defaulting to on.
4. Reduce what is sent — if the goal is counting distinct installations, a random per-install UUID generated at setup achieves that without collecting MAC, disk serial and CPU ID at all.

Point 4 is worth emphasising: install_code (get_server_id()) already exists as a derived identifier, so the raw hardware values may be redundant for the actual purpose.

---

Disclosure: this was an AI-assisted security review. Findings were produced with Claude (Anthropic) analysing the published source, then manually verified against this repository at v8.21.0 before filing. All line references above were checked against current HEAD and are reproducible with grep -n.