Problem/Motivation
When a contact form's auto-reply message is enabled, spammers can put their message in the "Subject" field, put a 3rd-party email address in the "Your email address" field, and thereby use your Drupal site to send spam to other people. This is a kind of backscatter attack vector.
Steps to reproduce
- Create a new Drupal 9.2.2 site using the Standard installation profile
- On Administration > Structure > Contact forms > Website feedback, fill in some "Auto-reply" text
- Add a CAPTCHA, honeypot, or other abuse protection (which will block some but not all spam attempts)
- Deploy the site to production
- Over time, spammers will discover your contact form and start using your Drupal site to relay spam to 3rd parties. Because Drupal populates the auto-reply email subject with the user-submitted contact form content, spammers will use the subject field to send their message to 3rd parties.
- 3rd party recipients of the auto-reply spam will then report your Drupal site's email address as spam, which will potentially add it to email blocklists, making it less likely that legitimate email from your site will get through to people who actually want to receive it.
| Spammer fills out contact form with their message in the "Subject" field, and a 3rd-party email address in the "Your email address" field | 3rd party receives unsolicited spam message |
|---|---|
![]() |
![]() |
Proposed resolution
When the contact form auto-reply is enabled, Drupal should not include user-submitted content in the auto-reply email. Drupal could either use a predefined subject line (e.g. "[contact-form-name] site-name"), or provide a field into which the site maintainer can enter their own subject line. Then, when spammers attempt to use your Drupal site as a spam relay, 3rd parties would still receive unexpected emails, but those emails would not contain the spammer's message — thus removing the incentive for the spammer to exploit your site's contact forms.
Related: If #405338: Contact form: Add token functionaltiy is implemented, it should prevent using tokens containing user-submitted content, or (if tokens containing user-submitted content are permitted and used) show a warning stating that the contact form will potentially be used as a spam relay.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| Screen Shot 2021-07-24 at 10.48.07 AM.png | 53.02 KB | smokris | |
| Screenshot 2021-07-24 at 10-47-07 Website feedback 20210724-contact-d922.png | 43.4 KB | smokris |


Comments
Comment #2
cilefen commentedThere is some discussion on this related issue.
Comment #3
larowlanShould this be a private issue? Webform had an SA and private issue for a similar vulnerability
Comment #4
cilefen commentedhttps://www.drupal.org/sa-contrib-2021-004
Webform’s fix is probably the way to go. Lee, I’ve held opposing (with myself) views on spamming an obviously spammable form being public. Your call.
Comment #5
larowlanThe webform fix was to only mail logged in users.
Perhaps that's what we should do here too. Would require #601776: Remove the ability of registered users to change the sender name or email address in contact forms. too.
Comment #10
poker10 commentedAdding a missing tag.
Comment #11
quietone commentedThe Contact Module was approved for removal in #3476879: [Policy] Move Contact module to contrib.
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3520460: [meta] Tasks to deprecate the Contact module and the removal work in #3520466: [meta] Tasks to remove Contact module.
Contact will be moved to a contributed project after the Drupal 12.x branch is open.
Comment #13
andypost