Slide 1 of 28
Part 1 · What Is It?Slide 1
PART 1
What Is It?
Slides 1–8 · From story to definition
Slide 1 · The Setup
He added one field to a form. He became an admin.
Not a sophisticated exploit. Just a field that shouldn't have been accepted.
The Scenario

It's March 2012. Egor Homakov, a software developer in Russia, had already reported a security vulnerability to GitHub. They deleted his bug report. When he opened a new ticket, he was ignored again.

So on a Sunday morning, he decided to demonstrate it himself.

He opened the GitHub form for adding an SSH public key. He added one extra field to the HTTP request: public_key[user_id]=4223 — the user ID of the Ruby on Rails organization on GitHub.

He hit send. His public key was now associated with the Rails organization. He had write access to one of the most important repositories in the world.

What he did with it

To prove the point, he created an issue on the Rails repository timestamped 1,000 years in the future. Then he pushed a commit directly to the Rails master branch.

GitHub fixed the vulnerability within 1 hour. The Rails team fixed the underlying framework flaw in 5 hours. Homakov's account was suspended, then reinstated after GitHub reviewed what he'd done. He hadn't stolen anything — he'd written to a public repo to prove a bug existed.

Before we name it

Homakov didn't bypass authentication. He was logged in as himself. He didn't exploit a wrong object. He added an extra field to a routine form — a field the server should have ignored but didn't. That single unguarded property gave him admin access to another organization.

What do we call this? →