Skip to content

⬆️ Update motioneye-project/motioneye to v0.44.0#587

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/motioneye-project-motioneye-0.x
Open

⬆️ Update motioneye-project/motioneye to v0.44.0#587
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/motioneye-project-motioneye-0.x

Conversation

@renovate

@renovate renovate Bot commented Jun 20, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Update Change
motioneye-project/motioneye minor 0.43.10.44.0

Release Notes

motioneye-project/motioneye (motioneye-project/motioneye)

v0.44.0

Compare Source

🚨 This release closes a number of security vulnerabilities, please update ASAP! 🚀

The following vulnerabilities have been closed:

Their combination allowed the following attacks, for which every step has been mitigated:

Breaking changes: #​3332 @​motioneye-project
  • The signature authentication method has been replaced with session cookies. For using the API, a session cookie needs to be obtained by doing a POST request to the /login API, with username and password arguments as POST data/parameters. If credentials were correct, a session cookie is returned, which needs to be sent with the actual API requests. The cookie has a 24h lifetime, hence scripts/programs should automatically redo the login loop when receiving a 403.
  • For remote motionEye cameras exclusively, a HMAC authentication method has been added, generating a signature from a dedicated secret, request URL, nonce, and tight timestamp. This secret is automatically generated for every motionEye instance, and needs to be entered when adding a remote motionEye camera. Implicitly, motionEye v0.44.0 instances cannot work with older versions vice versa. On first admin login after the update, respectively when selecting the remote motionEye camera from the settings panel, a prompt will allow you to enter the new secret. A new button in the settings panel allows to change it any time later, in case it changes at the remote motionEye instance.
  • The HTTP basic authentication option has been removed.
  • Passwords are now enforced for both users: admin and surveillance/normal, and stored as Argon2 hash on the server. Existing SHA1 hashes and plain text passwords are still functional, and migrated automatically on login. Users are asked to apply passwords on login, if none applied yet.
  • The /action API does now require authentication.
Other changes
  • S3 uploads do now work with and without path elements in the filename, and the "Include Subdirectories" slider has an actual effect:
  • The exception it a remote motionEye instance does not respond to HTTP requests at all is now properly handled:
  • It is now possible to do S3 uploads with SSE-C server-side encryption enabled, defining the base64-encoded key:
  • Cameras can now be flagged as admin-only, which hides them from the normal/surveillance user GUI and requires admin credentials to access their API:
  • The picture/ID/current API has been fixed for requests which are not done within mjpg_client_idle_timeout (default: 10) seconds after another:
  • Python 3.14 compatibility has been fixed:
  • Accessing camera streaming with digest authentication enabled has been fixed @​MichaIng:
  • Streaming access is not automatically done via normal/surveillance user credentials anymore, instead one needs to enter username and password for each streamed camera individually. In the same turn, streaming is disabled by default, and needs to be enabled explicitly. On motionEye upgrade, existing camera re-streams are not affected, but we recommend to check whether re-streaming is needed, and if so, to apply individual credentials for each camera:
  • Our CI/CD tests have been hardened and extended, applying certain coding standards and typing across our code more widely:
  • Our frontend went through some major cleanup: removing obsolete scripts, updating all other scripts, updating or jQuery methods, or switching to vanilla JavaScript, and merging some of the frontend input validators to reduce the number of event listeners @​MichaIng:
  • Passwords and usernames with special characters for RTSP network cameras do not cause authentication issues anymore:
  • The motion configuration files are now created and stored with 0600 UNIX mode, to prevent read access for anyone but the motionEye daemon user and root @​MichaIng:
  • Any file or directory paths passed via API requests or internally do now cause a 403 response or exception respectively, when containing traversal path elements:
  • Fixed monitor info text on camera frames being wrapped into double quotes with extra backslash character \"\":
  • The input path validation at the backend has been extended, to prevent any kind of escaping the camera data dir:
  • The backup/restore feature is now limited to those config files which are actually generated by the web interface: motion.conf, camera-*.conf, prefs.json, and mask-*.pgm. Files that need to be created from console, like motioneye.conf and camera action scripts, are not included, and won't be restored anymore, if present in old backups:
  • A new button and dialog was added to change credentials for network cameras, including simple MJPEG cameras, and remote motionEye cameras. It is hence not needed anymore to remove and re-add a camera for this. If the connection to a remote motionEye camera fails, the dialog pops up automatically, which simplifies applying the new remote/client secret, required since motionEye 0.44.0b2:
  • An issue has been solved where passwords changed in the settings panel without manually typing into the input box, e.g. by letting a password manager auto-fill it, were not applied:
  • The aspect ratio of the camera placeholder icon has been fixed:
  • The name of the admin user can now be changed in the settings panel:
  • The motion %$ conversion specifier to reference the camera name can now be used in media filenames:
  • When restoring backups, the file type and paths are now checked more strictly, to assure that only real files are extracted to the root of the config dir, and nowhere else:
  • .mpg files inside the camera media directories are not treated as movie files regarding preview generation, cleanup, and similar tasks. Available motionEye options do not currently generate those files, but with custom settings, manual conversions, media files copied from elsewhere, the situation is generally possible:
  • Preview images for movie files with less than 4 seconds duration are now generated:
  • Several translations have been updated, and an initial addition of the Bulgarian language was done. Many thanks to all @​weblate contributors! ❤️

v0.44.0b3

Compare Source

What's new

  • A new button and dialog was added to change credentials for network cameras, including simple MJPEG cameras, and remote motionEye cameras. It is hence not needed anymore to remove and re-add a camera for this. If the connection to a remote motionEye camera fails, the dialog pops up automatically, which simplifies applying the new remote/client secret, required since motionEye 0.44.0b2: #​3353 @​Marijn0
  • An issue has been solved where passwords changed in the settings panel without manually typing into the input box, e.g. by letting a password manager auto-fill it, were not applied: #​3347 @​Marijn0
  • The aspect ratio of the camera placeholder icon has been fixed: #​3350 @​Marijn0
  • The name of the admin user can now be changed in the settings panel: #​3298 @​strawberry-poodle (anonymous study account)
  • The motion %$ conversion specifier to reference the camera name can now be used in media filenames: #​3273 @​strawberry-poodle (anonymous study account)
  • When restoring backups, the file type and paths are now checked more strictly, to assure that only real files are extracted to the root of the config dir, and nowhere else: #​3341 @​MichaIng
  • .mpg files inside the camera media directories are not treated as movie files regarding preview generation, cleanup, and similar tasks. Available motionEye options do not currently generate those files, but with custom settings, manual conversions, media files copied from elsewhere, the situation is generally possible: #​3300 @​strawberry-poodle (anonymous study account)
  • Preview images for movie files with less than 4 seconds duration are now generated: #​3304 @​strawberry-poodle (anonymous study account)
  • As always, several translations have been updated. Many thanks to all @​weblate contributors! ❤️

v0.44.0b2

Compare Source

Breaking changes: #​3332 @​motioneye-project
  • The signature authentication method has been replaced with session cookies. For using the API, a session cookie needs to be obtained by doing a POST request to the /login API, with username and password arguments as POST data/parameters. If credentials were correct, a session cookie is returned, which needs to be sent with the actual API requests. The cookie has a 24h lifetime, hence scripts/programs should automatically redo the login loop when receiving a 403.
  • For remote motionEye cameras exclusively, a HMAC authentication method has been added, generating a signature from a dedicated secret, request URL, nonce, and tight timestamp. This secret is automatically generated for every motionEye instance, and needs to be entered when adding a remote motionEye camera. Implicitly, motionEye v0.44.0 instances cannot work with older versions vice versa, and for now, remote motionEye cameras need to be removed, and readded with the secret. But we aim to expose an input field for the secret in the camera settings panel, so that it can be added and changed, without the need to remove and readd the camera as a whole.
  • The HTTP basic authentication option has been removed.
  • Passwords are now enforced for both users: admin and surveillance/normal, and stored as Argon2 hash on the server. Existing SHA1 hashes and plain text passwords are still functional, and migrated automatically on login. Users are asked to apply passwords on login, if none applied yet.
Other changes
  • Fixed monitor info text on camera frames being wrapped into double quotes with extra backslash character \"\": #​3322 @​Marijn0
  • The input path validation at the backend has been extended, to prevent any kind of escaping the camera data dir: #​3324 @​MichaIng
  • The backup/restore feature is now limited to those config files which are actually generated by the web interface: motion.conf, camera-*.conf, prefs.json, and mask-*.pgm. Files that need to be created from console, like motioneye.conf and camera action scripts, are not included, and won't be restored anymore, if present in old backups: #​3338 @​MichaIng
  • Several translations have been updated, and an initial addition of the Bulgarian language was done. Many thanks to all @​weblate contributors! ❤️

v0.44.0b1

Compare Source

Whats new:

  • S3 uploads do now work with and without path elements in the filename, and the "Include Subdirectories" slider has an actual effect:
  • The exception it a remote motionEye instance does not respond to HTTP requests at all is now properly handled:
  • It is now possible to do S3 uploads with SSE-C server-side encryption enabled, defining the base64-encoded key:
  • Cameras can now be flagged as admin-only, which hides them from the normal/surveillance user GUI and requires admin credentials to access their API:
  • The picture/ID/current API has been fixed for requests which are not done within mjpg_client_idle_timeout (default: 10) seconds after another:
  • Python 3.14 compatibility has been fixed:
  • Accessing camera streaming with digest authentication enabled has been fixed @​MichaIng:
  • Streaming access is not automatically done via normal/surveillance user credentials anymore, instead one needs to enter username and password for each streamed camera individually. In the same turn, streaming is disabled by default, and needs to be enabled explicitly. On motionEye upgrade, existing camera re-streams are not affected, but we recommend to check whether re-streaming is needed, and if so, to apply individual credentials for each camera:
  • Our CI/CD tests have been hardened and extended, applying certain coding standards and typing across our code more widely:
  • Our frontend went through some major cleanup: removing obsolete scripts, updating all other scripts, updating or jQuery methods, or switching to vanilla JavaScript, and merging some of the frontend input validators to reduce the number of event listeners @​MichaIng:
  • Passwords and usernames with special characters for RTSP network cameras do not cause authentication issues anymore:
  • API requests via basic authentication with http_basic_auth true in motioneye.conf do not fail anymore:
  • The motion configuration files are now created and stored with 0600 UNIX mode, to prevent read access for anyone but the motionEye daemon user and root @​MichaIng:
  • Any file or directory paths passed via API requests or internally do now cause a 403 response or exception respectively, when containing traversal path elements:
  • Several translation updates, many thanks to all @​weblate contributors ❤️

🚨 Since this version contains a number of security-related changes, we highly recommend to update your instances ASAP 🚀.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@MichaIng

MichaIng commented Jun 22, 2026

Copy link
Copy Markdown

Please take note of the breaking changes shipped with motionEye 0.44.0, notably the dropped SHA1 signature and HTTP basic authentication methods: https://github.com/motioneye-project/motioneye/releases/tag/0.44.0

Since motionEye 0.44.0, authentication is done via session token passed in a signed cookie. The flow needs to be like this:

  1. POST request to /login API, passing plain username and password as POST data parameters.
  2. Store the received signed cookie (if credentials were correct).
  3. Send this cookie along with API requests.
  4. Redo the /login loop on 403, as the session token expires after 24h and on server restart.

Let us know if there are any questions, or suggestions. This change was urgently needed, but we know that it comes with possible regressions, and might have issues in use cases not covered in our testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Upgrade or downgrade of project dependencies. no-stale This issue or PR is exempted from the stable bot.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant