Meatmeet basestation CVE-2025-65829

Exploitation requires physical possession of the Meatmeet basestation and the ability to reflash its ESP32 firmware; because the SoC ships without Secure Boot enabled, the device performs no authenticity check on the Application Startup Flow, so an unsigned/modified image runs at boot. No authentication, credentials, or user interaction are needed once physical access is obtained (consistent with PR:N/UI:N). The exact flashing interface or trigger mechanism is not described in the available sources beyond 'flash modified firmware.' The decisive limiting factor is the physical-access requirement (AV:P): the flaw cannot be reached remotely or over the network, which sharply narrows realistic attacker populations to those with hands-on device access.

This is a genuine but physically-gated weakness, not a remote-exploitation emergency. The CVSS 3.1 vector (AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base 6.8 Medium) is internally consistent with the description: the attacker needs physical possession of the Meatmeet basestation, but once present requires no authentication and no user interaction, and the impact is full compromise (C:H/I:H/A:H) because missing Secure Boot lets arbitrary firmware run at startup. The supporting signals all point to low real-world urgency: EPSS is 0.32% (25th percentile), the CVE is NOT on CISA KEV (no confirmed active exploitation), and the vuln.today Decision label is 'this_month' rather than act_now/emergency. These signals agree rather than conflict - a low exploitation probability is expected for a flaw that cannot be triggered over a network. The two references are technical write-ups describing the absent Secure Boot, so a public PoC reference exists; it is not verified as working exploit code. Net: real and legitimate to fix within a normal patch cycle, but the physical-access requirement caps mass-exploitation risk; it is not a high-CVSS-but-fake issue, nor a drop-everything priority.

An attacker who gains physical possession of a Meatmeet basestation (e.g. a borrowed, resold, or unattended device) connects to its firmware-flashing interface and writes a modified image. Because Secure Boot is absent, the tampered firmware is not authenticity-checked and executes on the next boot, giving the attacker persistent control of the device. Public write-ups document the missing Secure Boot condition, but no verified working exploit tool is provided.