Daily updates from Odoo
Friday, July 10, 2026
7 changes
1 change
Resolved issues and error corrections
This update strengthens the security of our payment processing by ensuring only the transaction reference is used, rather than all payment data. This prevents potential vulnerabilities and ensures the system only processes data it needs to find and trigger payment processing, improving overall system stability.
Original PR description
The `/payment/custom/process` was blindly processing any payment data it was receiving while its only purpose is to find the transaction from the posted arguments and trigger its processing. This commit clarifies that only the transaction reference is expected as an argument and reconstructs the payment data payload from it.
1 change
Resolved issues and error corrections
This update strengthens the website's security by preventing users from subscribing to products that don't exist or using another user's email address. It now validates product availability and requires users to sign in before subscribing, reducing the risk of unauthorized access and misuse of accounts.
Original PR description
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This…
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This allows public users to potentially use emails that belong to registered accounts. Current behavior before PR: Users could subscribe to stock notifications for products that don’t exist or cannot be added (no stock). Public users could use emails already associated with registered accounts, allowing them to subscribe on behalf of another user. No validation is enforced, leading to potential security issues. Desired behavior after PR is merged: Adding a subscription for a non-existent or unavailable product raises a ValidationError. Public users trying to subscribe with an email that belongs to a registered user receive an AccessError prompting them to sign in first. Backend validation prevents misuse of registered user emails and improves security. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274937 Forward-Port-Of: odoo/odoo#271880
1 change
Security fixes and vulnerability patches
This change strengthens protection for database API keys by preventing them from being read through normal application access and hiding real key values in the interface. It reduces the risk of sensitive credentials being leaked accidentally or through bypassed access controls.
Original PR description
The aim of this commit is to harden the security of the `database_api_key` field. Before this commit: The field could be retrieved through the orm and could be leaked if the access rights were bypassed. A streamer pasting the key in the field could also leak his api key by mistake. After this commit: The only way to access the field is through direct SQL access. The api key isn't shown anymore in the UI: - The UI doesn't receive the key from the backend: it receives dummy **** - The field in the form view display dots instead of any char to prevent leaking the key by mistake. Task-id: None Forward-Port-Of: odoo/enterprise#122163
1 change
Security fixes and vulnerability patches
The Sign app now blocks unsafe or invalid bulk use of the auto-write feature, reducing the risk of unintended changes to related records. It also improves logging and test coverage so administrators get clearer feedback when automatic updates cannot be safely applied.
Original PR description
Fix scenarios where the auto-write feature could fail or be unsafe: - Prevent unsafe mass updates: Users could enable auto-write in bulk without proper awareness, leading to unintended behavior. Additionally, the field could be manually exposed even when no linked model/field is set. we add safeguards and constraints to prevent enabling it in invalid cases. - Improve test coverage: Update test cases to ensure correct behavior when users have access to partner records but must not be allowed to update sensitive fields (e.g., email) of other users through those records. task-6147410 Forward-Port-Of: odoo/enterprise#115118
1 change
Security fixes and vulnerability patches
Database API keys are now better protected from accidental or unauthorized exposure. The key is no longer sent to the user interface and is masked when entered, reducing the risk of sensitive credentials being leaked.
Original PR description
The aim of this commit is to harden the security of the `database_api_key` field. Before this commit: The field could be retrieved through the orm and could be leaked if the access rights were bypassed. A streamer pasting the key in the field could also leak his api key by mistake. After this commit: The only way to access the field is through direct SQL access. The api key isn't shown anymore in the UI: - The UI doesn't receive the key from the backend: it receives dummy **** - The field in the form view display dots instead of any char to prevent leaking the key by mistake. Task-id: None
2 changes
Security fixes and vulnerability patches
Website forms embedded in Helpdesk pages now protect signed fields from being changed in the browser before submission. This improves the integrity of customized website forms without changing the experience for visitors or editors.
Original PR description
Website forms can be customized using the website editor. These customized values are directly embedded in the form in a hidden input or injected via the data-for js mechanism. For website forms whose action is the route `/website/form/`, this commit ensures that input marked with `data-sign='true'` are not modified by the client. The signature is prepared during the compilation phase, and the signature is calculated at runtime (during rendering) to take into account values rendered dynamically. HTML fields do not pass through the QWeb engine. For this field the form signature is calculated statically. Passing embedded forms within HTML fields through the pre-compilation step allows their signatures to be determined since these forms are static. This mechanism is completely transparent to the end user. Task-6320608
Website forms now include a built-in integrity check so customized hidden values cannot be altered in the browser before submission. This helps ensure helpdesk and other website form data remains trustworthy without changing the user experience.
Original PR description
WIP Task-6320608