Friday, August 21, 2026
2 changes · saas-19.4
Security fixes and vulnerability patches
Bancontact payment callbacks are now accepted after the provider changed its identifier, so POS terminals and self-order kiosks can receive payment confirmations again. The callback process is also stricter to prevent forged or replayed payment confirmations from completing transactions incorrectly.
Original PR description
..., pos_self_order_bancontact_pay --- Bancontact changed the issuer of their callbacks from "payconiq" to "Payconiq". Since our signature verification checked against the old lowercase value, every…
..., pos_self_order_bancontact_pay --- Bancontact changed the issuer of their callbacks from "payconiq" to "Payconiq". Since our signature verification checked against the old lowercase value, every callback was rejected, so the terminal never received the customer's payment confirmation. We have also added more logs diagnose similar issues more easily in the future. While fixing this, we found the signature check could be bypassed entirely: passing `mode=test` in the callback URL skipped verification altogether, so an attacker could forge their own unsigned callback just by adding it. Signature verification is now always performed, regardless of mode. On top of that, the webhook only checked that the JWS subject matched the caller-supplied `ppid`, never that this ppid actually belonged to the targeted POS config - both being plain URL parameters, an attacker with their own Bancontact account could point its own validly signed callback at a victim's config_id and finalize its pending payment instead. We replace `ppid`/`mode` with `payment_method_id` in the callback URL, and derive the expected ppid and preprod/production environment from that record server-side, checking it's actually configured on the target POS config before relaying the callback. Finally, guard the kiosk and register client-side handlers, and the webhook itself, against reprocessing an already-finalized payment, closing the impact of a replayed callback. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6449864 Forward-Port-Of: odoo/odoo#279417
This fix prevents interviewers from changing or deleting candidates they personally referred unless they are assigned to interview them. It helps keep recruitment data controlled and ensures referral access does not grant broader applicant management rights.
Original PR description
Steps to reproduce: - Create user A with interviewer role - A is referring a candidate B for a job - Go to referral and click on the number "1" - Group the view by stages - Drag & drop B between stages Current behavior: Interviewer can write/unlink on his referee aplicant Expected behavior: Interviewer has only rights on assigned interviewee applicant task-id: 6452353 Forward-Port-Of: odoo/enterprise#128131