Slide 13 of 28
Part 2 · How It WorksSlide 13
Slide 13 · Real Incident: Mass Assignment
One extra parameter. Admin access to 100 million repositories.
GitHub, 2012 — the canonical mass assignment breach.
Real Incident · March 4, 2012
GitHub — Mass Assignment via Ruby on Rails Auto-Binding

GitHub's API endpoint for adding SSH public keys used Ruby on Rails' update_attributes(params[:public_key]) — which bound all incoming parameters to the model without restriction.

The endpoint was designed to accept: public_key[key] (the SSH key content). Developer Egor Homakov added one extra parameter: public_key[user_id]=4223 — the user ID of the Ruby on Rails GitHub organization.

Rails bound the user_id field to the public key record, associating Homakov's SSH key with the Rails organization. He now had write access to the Rails master repository.

He demonstrated the access by creating an issue timestamped in the year 3012 and pushing a commit to the Rails codebase. GitHub fixed the vulnerability within 1 hour. The Rails framework added mass assignment protection within 5 hours.

Lesson: Auto-binding framework features must always be combined with an explicit allowlist of permitted fields. A developer who adds a new field to the model must actively decide whether it should be user-settable — the framework will not make that decision for them.
Homakov had reported this first

Before exploiting it, Homakov had reported the mass assignment vulnerability as a bug on GitHub's issue tracker. The report was dismissed and the thread was deleted. He demonstrated it to force the fix — and GitHub acknowledged the bug was real and restored his account after review.

← Back See it in attack scenarios →