CVE-2026-44314
Description
Traccar is an open source GPS tracking system. Prior to 6.13.0, DeviceResource.uploadImage authorizes the target device only through Condition.Permission(User.class, getUserId(), Device.class) and then immediately streams the uploaded body into mediaManager.createFileStream(...). Unlike the generic mutation path in BaseObjectResource.update and the explicit device mutation handler updateAccumulators, this route never invokes permissionsService.checkEdit(getUserId(), Device.class, false, false). The skipped guard is exactly where Traccar enforces readonly and deviceReadonly restrictions for non-admin users. An unauthorized user can replace a device’s stored image file under the server media directory. This allows modification of UI-visible device media and any downstream workflows that rely on the persisted image, despite other device update paths correctly rejecting the same identity. This vulnerability is fixed in 6.13.0.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In Traccar prior to 6.13.0, the device image upload endpoint lacks a permission check, allowing a readonly shared-device user to replace a device's stored image.
Vulnerability
In Traccar versions prior to 6.13.0, the DeviceResource.uploadImage method (in src/main/java/org/traccar/api/resource/DeviceResource.java) authorizes the target device only through Condition.Permission(User.class, getUserId(), Device.class) and then immediately streams the uploaded data into mediaManager.createFileStream(...). Unlike other mutation paths (e.g., BaseObjectResource.update or updateAccumulators), this route never calls permissionsService.checkEdit(getUserId(), Device.class, false, false), which enforces readonly and deviceReadonly restrictions for non-admin users [1].
Exploitation
An attacker must obtain a bearer token for a user with a shared-device permission. The ShareResource endpoint can create temporary users with readonly=true and issue such a token [1]. Using that token, the attacker sends a POST /devices/{id}/image request with a crafted image body. The endpoint writes the file to the server's media directory (media//device.) without checking whether the user is allowed to edit the device [1].
Impact
A successful attack replaces the device’s stored image file. This changes the UI-visible device media and can affect any downstream workflows that rely on the persisted image, such as image-based alerts or reports. The attacker does not gain code execution or broader system access, but the integrity of device images is compromised [1].
Mitigation
The vulnerability is fixed in Traccar version 6.13.0 [1]. Users should upgrade to 6.13.0 or later. No workaround is documented for earlier versions. The CVE is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
16f30f4898420Check permissions for device image upload
1 file changed · +2 −0
src/main/java/org/traccar/api/resource/DeviceResource.java+2 −0 modified@@ -194,6 +194,8 @@ public Response uploadImage( @PathParam("id") long deviceId, File file, @HeaderParam(HttpHeaders.CONTENT_TYPE) String type) throws StorageException, IOException { + permissionsService.checkEdit(getUserId(), Device.class, false, false); + Device device = storage.getObject(Device.class, new Request( new Columns.All(), new Condition.And(
Vulnerability mechanics
Root cause
"Missing permissionsService.checkEdit() call in DeviceResource.uploadImage allows a user with only view-level permission to write a device image file."
Attack vector
An attacker who possesses any authenticated account or shared-device bearer token that grants Condition.Permission access to the target device can call POST /devices/{id}/image [ref_id=1]. The endpoint authorizes only through Condition.Permission(User.class, getUserId(), Device.class) and then streams the uploaded body into mediaManager.createFileStream(...), bypassing the permissionsService.checkEdit() guard that enforces readonly and deviceReadonly restrictions [ref_id=1]. This allows a view-only user to replace a device's stored image file under the server media directory, modifying UI-visible device media and any downstream workflows that rely on the persisted image [ref_id=1].
Affected code
The vulnerable code is in DeviceResource.uploadImage at src/main/java/org/traccar/api/resource/DeviceResource.java:190-219 [ref_id=1]. The endpoint authorizes the target device only through Condition.Permission(User.class, getUserId(), Device.class) and then streams the uploaded body into mediaManager.createFileStream(...) without calling permissionsService.checkEdit() [ref_id=1].
What the fix does
The patch adds a single call to permissionsService.checkEdit(getUserId(), Device.class, false, false) at the top of the uploadImage method [patch_id=2565440]. This is the same guard that Traccar enforces in other mutation paths such as BaseObjectResource.update and updateAccumulators [ref_id=1]. By inserting this check before the file write, the fix ensures that readonly and deviceReadonly restrictions are applied consistently, preventing view-only users from writing device images [ref_id=1].
Preconditions
- authAttacker has any authenticated account or shared-device token that grants Condition.Permission access to the target device.
- configMedia storage is enabled so device images are persisted on disk.
- inputThe user is supposed to be view-only because readonly or deviceReadonly should block device mutations.
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1News mentions
0No linked articles in our index yet.