Today’s Email Incident
Earlier today a routine system email was incorrectly sent to many of our GitHub Enterprise customers. In these errant emails, customer email addresses were included in the To: field, making…
![](https://github.blog/wp-content/uploads/2019/03/company-twitter.png?resize=1201%2C630)
Earlier today a routine system email was incorrectly sent to many of our GitHub Enterprise customers.
In these errant emails, customer email addresses were included in the To:
field, making them visible to anyone who received the message.
We are very sorry about this. We have determined what caused this incident and contacted all affected customers directly.
Background
The incident occured in the Rails application we use to manage trials and customer contact information for
GitHub Enterprise, not the product itself. No GitHub Enterprise installations were affected, and no license keys
or any other data were exposed. GitHub.com was not affected.
As part of a routine daily process, the system notifies the members of any organization whose
license is about to expire about the upcoming need for renewal. The app builds an email message
including the addresses of all of the active accounts tied to the given organization, putting them
in the To:
field to enhance deliverability. This morning, the email included
a great many more addresses than expected.
Technical details
Yesterday the Rails core team released four security patches
(CVE-2013-1854, CVE-2013-1855, CVE-2013-1856, CVE-2013-1857).
We immediately reviewed the patches and updated our Rails applications to stay current.
Unfortunately one of these security patches included a change that caused certain SQL queries to behave unexpectedly.
Here’s an example of this change in behavior:
class Organization < ActiveRecord::Base
has_many :teams
attr_accessible :name, :has_octocats
scope :has_octocats_scope, lambda { where(:has_octocats => true) }
def self.has_octocats_class_method
where(:has_octocats => true)
end
end
class Team < ActiveRecord::Base
belongs_to :organization
attr_accessible :name
def self.using_octocats_scope
where(:organization_id => Organization.has_octocats_scope.select(:id))
end
def self.using_octocats_class_method
where(:organization_id => Organization.has_octocats_class_method.select(:id))
end
end
> github = Organization.create(:name => "GitHub", :has_octocats => true)
> acme = Organization.create(:name => "Acme", :has_octocats => false)
> github.teams.create(:name => "Supportocats")
> acme.teams.create(:name => "Roadrunners")
> github.id
#=> 1
> acme.id
#=> 2
So, an Organization
owns a number of Team
records. We’ve defined a couple of methods to
help us scope queries for teams to only those organizations that have octocats.
Ideally, both of these methods will scope to the same thing: only Team
records with an
organization_id
of 1, the GitHub Organization
. And prior to this latest Rails release, they did.
But the latest release of Rails introduced a subtle change to this behavior. Let’s try to make some queries
based on the Organization
‘s teams:
> teams = github.teams
Team Load (0.4ms) SELECT `teams`.* FROM `teams` WHERE `teams`.`organization_id` = 1
> teams.length # => 1
> teams.first.name # => "Supportocats"
Great. Here we’ve asked for the GitHub organization’s teams, and we’ve gotten the correct one,
“Supportocats”, back. All is good so far. Now let’s use one of our scopes, just to be extra specific:
> teams = github.teams.using_octocats_class_method
Team Load (0.4ms) SELECT `teams`.* FROM `teams` WHERE `teams`.`organization_id` = 1 AND `teams`.`organization_id` IN (1)
> teams.length # => 1
> teams.first.name # => "Supportocats"
The results are the same, but the query is different. By going through an extra scope, we’ve added an additional
SQL predicate, one that says the returned Team
records must belong to an Organization
that has octocats. Since
the GitHub team has them, the result is the same.
Let’s try our scope that is restricted to octocat-having teams on the Acme org:
> teams = acme.teams.using_octocats_class_method
Team Load (0.4ms) SELECT `teams`.* FROM `teams` WHERE `teams`.`organization_id` = 2 AND `teams`.`organization_id` IN (1)
> teams.length # => 0
Here we see a different result, as expected, and a similar query, again asking for all of the Acme organization’s teams
that also belong to an Organization
that has octocats. The Acme Organization
has none, so no teams are returned.
But now we come to an unexpected difference. In the last couple of examples, we were using an Arel scope on Organization
that
was defined as a normal class method. But if we change to using the scope defined with ActiveRecord’s scope
method,
we get unexpected and potentially dangerous results:
> teams = acme.teams.using_octocats_scope
Team Load (0.4ms) SELECT `teams`.* FROM `teams` WHERE `teams`.`organization_id` IN (1)
> teams.length # => 1
> teams.first.name # => "Supportocats"
Now the Acme organization is returning the GitHub organization’s teams! This is obviously bad behavior. What’s happening? In
this case, when using the scope
method to define an Arel scope on Organization
, the where
clause of the
scope is overriding the condition imposed by the Organization#teams
association. The part of the WHERE
clause
meant to restrict the query to Team
records related to the Acme organization was dropped.
We’ve narrowed down this change in behavior to this commit.
We have fixed this issue on our affected applications and are working with the Rails core team to determine if this change was intentional as well as what action other users should take.
What we’re doing about it
We’re reviewing every piece of GitHub code that touches email so we can keep this from happening in the future.
We’re focusing on more stringent automated tests, sanity checks on email recipients, and even more careful review when we upgrade an external dependency like Rails.
Written by
Related posts
![](https://github.blog/wp-content/uploads/2023/10/Collaboration-DarkMode-2.png?resize=400%2C212)
2024 is the biggest global election year in history. What’s at stake for developers?
GitHub is considering what is at stake for our users and platform, how we can take responsible action to support free and fair elections, and how developers contribute to resilient democratic processes.
![](https://github.blog/wp-content/uploads/2023/10/AI-DarkMode-2.png?resize=400%2C212)
GitHub named a Leader in the Gartner first-ever Magic Quadrant for AI Code Assistants
This year, as part of its annual Magic Quadrant series, Gartner published a first-of-its-kind report analyzing the state of play in the AI Code Assistants market–and named GitHub a Leader.
![AI in software development 2024 survey results with colorful graphics and percentages.](https://github.blog/wp-content/uploads/2024/08/ai-survey-header.png?resize=400%2C212)
Survey: The AI wave continues to grow on software development teams
We surveyed 2,000 people on software development teams at enterprises in the U.S., Brazil, India, and Germany about the use, experience, and expectations around generative AI tools in software development.