LubeLogger CVE-2026-62279

Requires an authenticated LubeLogger account (any user who can edit at least one destination vehicle) on a version prior to 1.6.8, plus a multi-user or household-shared deployment where other users' records exist to be stolen - a single-user instance has no cross-user victim. The attacker supplies caller-controlled source recordIds belonging to another user to the DuplicateRecordsToOtherVehicles endpoint while naming a destination vehicleId they control; no special non-default configuration, no user interaction, and no admin/root role are needed. Limiting factors: valid credentials on the instance, knowledge or enumeration of victim recordIds, and the presence of other users' vehicle records.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N = 7.1 High) is internally consistent with the described flaw: a network-reachable, low-complexity IDOR requiring only a low-privileged authenticated account and no user interaction. The real-world risk is materially lower than the 7.1 headline for two reasons. First, exploitation requires an authenticated account on the same LubeLogger instance AND the presence of other users' records worth stealing - this only matters on multi-user / household-shared deployments; a single-user self-hosted instance has no cross-user victim. Second, the primary impact is confidentiality (C:H - copying another user's record contents and attachment paths into an attacker-controlled vehicle) plus a weak integrity effect (I:L - it creates persistent copies in the attacker's own vehicle, it does not corrupt the victim's data), with no availability impact. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so this is 'no public exploit identified at time of analysis' - there is no evidence of active or automated exploitation. One data-quality conflict to flag: the CWE (CWE-639, Authorization Bypass Through User-Controlled Key) and the source-code fix (added UserCanEditVehicle checks per record) clearly identify this as broken object-level authorization / IDOR, yet the input Tag 'Authentication Bypass' mislabels it - this is an authorization defect, not an authentication bypass. Overall: a legitimate authenticated IDOR worth patching, but a low-urgency issue absent active-exploitation signals and given the niche product footprint.

A registered low-privileged user on a shared/household LubeLogger instance calls the DuplicateRecordsToOtherVehicles endpoint, supplying recordIds that belong to another user's vehicle while naming a destination vehicleId they legitimately control. Because the endpoint authorized only the destination vehicles and never checked UserCanEditVehicle on each source record's VehicleId, the victim's service, fuel, tax, odometer, inspection and other records - including attachment paths - are copied into the attacker's vehicle, exposing their contents. No public exploit code was identified at time of analysis.