Jan 05 2019
Jan 05

The Drupal Security Team is using funding from the EU-FOSS to pay for valid security issues found in Drupal 7 and 8 and top contributed modules. This program is open for participation by anyone.

The Drupal Security Team will be authorizing payment anywhere from €350 ($401) – €15.000 ($17,100) per issue. The more serious the issue, the more the Drupal Security Team will authorize for payment.

Who is running this program?

The Drupal Security Team with funds from the EU-FOSSA on the intigriti reporting platform.

What is covered?

Third-party libraries, even those bundled with Drupal core or contributed projects, are excluded from this program.

Can anyone participate?

You may not participate in this program if you fall into one of the following categories:

  • If you are a project maintainer (module, theme, etc), or you contribute a large amount to a project, you may not get paid for the project you maintain. This does not apply to Drupal Core.
  • You cannot report a bug you yourself created or committed. (If you find one, however, do report it via our normal processes (https://www.drupal.org/security-team/report-issue)

To get paid, you must have an account on Drupal.org.
Security Team members that are involved with the administration of this program and/or its funds are not eligible for payouts under the program.
This program is only valid for new issues submitted after 2019-01-29. (Duplicate reports of in-progress issues known to the Security Team may not eligible for payment.)
All issues submitted must be original research. Do not copy and paste results from a scanner without validating them first.

How can I get started?

Install a local copy of Drupal 8 or Drupal 7 from git (https://www.drupal.org/project/drupal/git-instructions). Find security issues such as XSS, SQL Injection, CSRF, Access Bypass etc.
Any submissions about a public Drupal website (including Drupal.org) will result in your account being blocked from any further payments. This bounty program applies to public Drupal open source code only. Not hosted website that run Drupal.

If you find a security issue you should:

  1. Write up the steps to reproduce the issue.
  2. Make sure you have a Drupal.org account created. Include this in your submission.
  3. Go to the intigriti platform and create a new report.
  4. WAIT, do not discuss or post anything anywhere yet. Members of the intigriti team and the Drupal Security Team must validate your report. This can take up to 3 weeks depending on the report and the complexity involved.
  5. If you have a valid report, we will issue payment. You still can not disclose this bug until we publish a release that fixes the bug.
  6. If you do not have a valid report, we will inform you as well.

What must be included in the report?

  • The reporter must provide a detailed explanation of the issue and steps to reproduce the issue.
  • The quality of the report will be taken into account when assigning a value to it.
  • We will also take into account the severity of the security issue.
  • Reporters will also need to confirm that the Drupal Security team will be the group to release the information.
  • Include your Drupal.org username.
  • Issues will be confirmed by the security team before payment is approved.

Do all security issues count?

Your testing should be done on a local environment, testing should NEVER be done on live Drupal sites. Any testing on ANY Drupal site that is not under your control (local or server you own) will automatically be rejected and your account blocked from further payment. We have a page on how to get started installing Drupal locally.

If a task requires the attacker to have advanced permissions as listed on our permission policy page (e.g. 'Access site reports', 'Administer users', 'Translate interface', etc.) will not be eligible for a payout. Other advanced permissions that are not white listed are at the discretion of the security team. Contributed modules (non-core code) must be eligible for a security advisory according to the security advisory policy. A list of projects currently eligible for the program is available.

Security issues excluded from the bounty program

The following are not being considered; while some may be legitimate security issues, they are out of scope for this bounty program.

  • Descriptive error messages (e.g. Stack Traces, application or server errors).
  • HTTP 404 codes/pages or other HTTP non-200 codes/pages.
  • Fingerprinting / banner disclosure on common/public services.
  • Disclosure of known public files or directories (e.g. robots.txt).
  • Clickjacking and issues only exploitable through clickjacking.
  • CSRF on forms that are available to anonymous users (e.g. the contact form).
  • Logout Cross-Site Request Forgery (logout CSRF).
  • Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
  • Lack of Secure/HTTP-Only flags on non-sensitive Cookies.
  • Lack of Security Speedbump when leaving the site.
  • User enumeration.
  • Missing HTTP security headers
  • Any Denial of service attack.
  • Other exceptions not listed.
  • We would still like to know about issues in these categories, and you may still get credit for reporting them, but we will not be issuing payments for them.

Other questions?

Questions regarding additional specifics of this program should be emailed to [email protected].

Oct 17 2018
Oct 17

The Drupal Security team has a core and contrib release window on the 3rd Wednesday of the month. This window normally ends at 5pm Eastern (9PM UTC).

Due to unforeseen circumstances, we are extending the current window we are in by 3 hours until Oct 17th, 2018 at 8pm Eastern (11:59PM UTC).

May 23 2017
May 23

Make your plans to join us for the Drupal Midwest Developer Summit, August 11-13, on the University of Michigan campus, in Ann Arbor MI.

Register here

The Event
Join us for 3 days this summer in Ann Arbor, Michigan, for the 2017 Midwest Drupal Summit.
For this year’s Summit, we’ll gather on the beautiful University of Michigan campus for three days of code sprints, working on issues such as porting modules and writing, updating documentation and informal presentations. We will start around 10AM and finish around 5PM each day.
Lunch, Coffee and Snacks will be provided each day.

What’s New This Year at MWDS?
This year, we’re adding lightning talks (more Drupal learnings!) and a social outing (more Drupal fun!)

What’s The Same?

Relaxed, low-key sprinting and socializing with Drupal core contributors and security team members.

What you can expect:

  • An opportunity to learn from Drupal core contributors and mentors, including Angie “webchick” Byron, Michael Hess, Peter Wolanin, Neil Drumm and xjm.
  • Code sprints. Let’s clear out some queues!
  • Help Porting modules to Drupal 8.
  • Lighting talks
  • Security issue sprints
  • Documentation writing
  • Good food and good community.


Ann Arbor is about 30 minutes by car from Detroit Metro Airport. Ann Arbor is also served by Amtrak.
Questions? Contact [email protected]

Sep 21 2016
Sep 21

Drupal 8.1.10, a maintenance release which contains fixes for security vulnerabilities, is now available for download.

See the Drupal 8.1.10 release notes for further information.

Upgrading your existing Drupal 8 sites is strongly recommended. There are no new features nor non-security-related bug fixes in this release. For more information about the Drupal 8.x release series, consult the Drupal 8 overview.

Change log

Drupal 8.1.10 is a security release only. For more details, see the 8.1.10 release notes. A complete list of all changes in the upcoming 8.2.x branch can be found in the git commit log.

Security vulnerabilities

Drupal 8.1.10 was released in response to the discovery of security vulnerabilities. Details can be found in the official security advisories:

To fix the security problem, please upgrade to Drupal 8.1.10. (Sites testing the 8.2.x release should update to 8.2.0-rc2.)

Update notes

See the 8.1.10 release notes for details on important changes in this release.

This is the final security release of the 8.1.x series. Sites should prepare to update to 8.2.0 following this release.

Known issues

See the 8.1.10 release notes for known issues.

Aug 08 2016
Aug 08

It’s 80 degrees and sunny in beautiful Ann Arbor, Michigan, and we are enjoying a tasty cold beverage while dreaming of sprints for Drupal 8 and the community that comes with them.

Make your plans to join us for the Drupal Midwest Developer Summit, August 19-21, on the University of Michigan campus, in Ann Arbor MI.

Drupal community members will be sprinting for 3 days to make D8 the best it can be. You don’t have to be a coder to come! We also need help with writing documentation, designing UI, and helping to organize the sprints.

We will be having a group lunch on Friday and Saturday provided by your registration fees.

Sign up now before registration closes in a little over a week.

Questions? Contact [email protected].

May 23 2016
May 23
akalata's picture

Where do we sign up? :)

manningpete's picture

click the words "Register Here" to sign up! ;-)

mlhess's picture

I also move the register here link to the top.

SpartyDan's picture

If you are coming in from out of town and need a place to stay let me know. I'm about 25 minutes from campus and have plenty of room.

Jul 19 2015
Jul 19

Drupal.org users* can now use Two factor authentication to increase the security of their accounts. It can be enabled via Security tab of your user profile page. Read the detailed instructions at Enabling TFA on Drupal.org.

This was made available to Drupal.org admins in May. It is now required for users who have advanced access on Drupal.org. However, every user can benefit from the security that two factor authentication offers.

If you want to make two factor authentication available on your own Drupal site, you can install the TFA module.

* Two factor authentication is available for all users with the 'confirmed user' role. If you don't see 'Security' tab on your profile page, you might be missing the role. Just keep posting content on Drupal.org and it will be granted soon. You can also apply to get the role.

Jun 29 2015
Jun 29
ianthomas_uk's picture

This is clearly a reaction to the recent security flaw, where two major hosts with staff members working on the security team were able to mitigate the flaw for their customers, even when those customers were running unpatched versions of Drupal.

It seems to be targeting two criticisms of that event:
1) These hosts were able to get a commercial advantage using confidential information from the security team. I see no issue with that - it is a small reward for the work they are putting in on the security team. If competitors want this confidential knowledge, they can get it by sponsoring a member of the security team.
2) It expanded the number of people who knew about the vulnerability, and therefore the chance that details would leak before the official announcement. The policy does help here, although there is a risk it will slow the development of a patch (e.g. if the manager refuses to sponsor the time without more details).

Had those hosts not acted how they did, many more sites would have been compromised, with potentially huge implications for those involved. It would also have been a tastier target for attackers, as unpatched sites would have been easier to find.

Proof reading: The term "COI" is used before it is defined.

nedjo's picture

Implicit in this comment is the contention that pre-notifying some groups is potentially beneficial.

I agree there's a conversation to be had around this idea. But it's not the same discussion as the one we're having here.

We would need to cleanly separate what did occur in response to SA-CORE-2014-005 from what a well designed pre-notification system might look like. There's no necessary relationship, and certainly no reason to suppose that the various justifications that have been offered are a sound basis for anything.

opratr's picture

Glad I checked before submitting my comments....basically identical to yours @ianthomas_uk.


Edit: So to be clear, I agree with this clarification regarding disclosure. It's strikes a good balance between the risk of premature vulnerability disclosure and allowing team members to take appropriate measures outside of the team to benefit the Drupal community when an opportunity presents itself.

ianthomas_uk's picture

As written, it's a bit unclear on exactly who could be brought in on the issue. For example, in a large host there will be developers involved in implementing the solution, and an ops person involved in deploying the solution. Should ops people be added to the drupal.org issue? Are they not allowed to be told until the public disclosure? My reading of it is that ops people should not be told, which means no early protection.

IIRC Pantheon's workaround involved filtering the traffic before it even got to Drupal. Is that relevant for discussion on the issue?

Edit: Actually it's a bit more explicit than that. The policy states "We want to avoid ... creating a situation where people use still-private knowledge gained on the team to get an unfair advantage".

That basically rules out bringing anyone else in your organisation into the loop, unless they will be writing / reviewing the patch itself. You can only discuss deploying the patch once it is public.

nedjo's picture

While not without merits, this draft reads as a compromise document, the result of a process that ultimately ducks rather than directly addressing the key issues at stake. That lack of clarity is already evident in the couple of commenters so far, who form very different conclusions.

Rather than elaborating aims that the policy will supposedly address, the policy should just do it: state directly expectations of security team members. This sentence is so ambiguous as to be useless:

Creating a situation where people use still­-private knowledge gained on the team to get an unfair advantage with no regard for the health of the Drupal ecosystem.

Instead, the policy should cut to the quick and begin with clear, unambiguous guidelines for action. Suggested phrasing:

As a security team member:
* Minimize risk that issues will be leaked beyond the team and posted to the public, outside of the release window and before a patch is released.
* Do not use still-private knowledge gained on the team to get an advantage or benefit.

lesleyb's picture

@ianthomas_uk I think COI means Conflict Of Interest; the term has been used earlier but the abbreviation was not introduced then.

The difficulty seems to be people on the security team are in a privileged position. Not only are they aware of a security flaw before any other 'general Drupal user', they are also in a position to patch their own installations before anyone else in the community. By their involvement in the security effort, they are in some state of preparedness for any security issue that arises.

When the advisory is issued, then the 'general Drupal user' is able to read, digest and act on that information - the security team members are already prepared to act on that information. The security team members can, under the remit of the current document, inform their teams a security patch is coming out that must be attended to.

Presumably the security team will also have knowledge of the timing of that release of information so they will literally be able to set their actions in motion the second someone in the security team hits the send button on an advisory notice.

I think this is as much privilege as the security team can allow its members and is reasonable.

Having a patch tested, ready to go and permitting security team members act on it prior to an advisory going out clearly not only leaves the 'general Drupal user' excluded from the benefits endowed by having the security team but also threatens the security of information held by the security team .

I would think the 'general Drupal user' would object to that on both counts.

Although it seems clear - from the outside of the security team - what information can necessarily be shared when and what to do to expand the team where specific expertise is required to find a solution to a security flaw I think the document could be reorganised to better effect. The marketing advice will be useful to team members.

I would drop the first two paragraphs completely. The second two paragraphs, starting with 'This document aims ...' serve as the Aims of the Document.

The main document can then start with an introduction (section 1) at 'In general, information ..' and the three scenarios could be set as sections 2, 3 and 4 with headings within the document - obtaining sponsored time, enlisting expertise from outside the team and marketing advice. Setting these as individual sections now allows any future additions to the document to be handled in the same way. It also allows people to read and find applicable scenario(s) quickly.

The three following paragraphs on how to share information and what to share then deserves its own section, section 5, so it can then be referred to in the prior enlisting expertise section or any other section that needs it.

The COI policy is already in its own section, which would become section 6, and can be referred to from any of the preceding sections.

Hope this helps

Kind regards


About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web