Thursday, August 27, 2026
1 change · 19.0
Security fixes and vulnerability patches
When a production database is prepared for testing, debugging, or sharing, saved outgoing email usernames and passwords are now removed. This reduces the risk of real email credentials being exposed in database copies while keeping email sending disabled as before.
Original PR description
### Impacted versions 19.0 (the same applies to every branch shipping `base/data/neutralize.sql`) ### Steps to reproduce 1. On a database with an outgoing mail server configured with a username and…
### Impacted versions 19.0 (the same applies to every branch shipping `base/data/neutralize.sql`) ### Steps to reproduce 1. On a database with an outgoing mail server configured with a username and password, neutralize it (`odoo-bin neutralize`, or restore/duplicate with neutralization enabled). 2. Look at the `ir_mail_server` row. ### Current behavior The server is archived, so the database can no longer send. `smtp_user` and `smtp_pass` are left untouched, so the credentials stay in the database and travel with every dump taken from it. The password still authenticates against the real relay. ### Expected behavior Neutralization is what turns a production database into one that can be copied and handed around — a staging build, a dump downloaded for debugging. A database that is not allowed to send mail has no use for a credential to send it with, and keeping it means the credential leaves the platform with the copy. ### Fix Clear `smtp_user` and `smtp_pass` in the same statement that archives the servers. The stub relay inserted just below still blocks the fallback to the command-line SMTP settings, so behavior is unchanged otherwise. Tested by seeding a mail server with credentials, running the file, and checking the row: archived, credentials empty, stub relay present.